Hmm, on my system when i run with —leak-check=full the output makes a distinction between ‘definitely lost’ and ‘still reachable’. The latter are those which are referenced by a global variable, and in general are not a problem as some libraries e.g. libc and libxml2 need to statically allocate some data structures on startup, which there’s no easy way (or need) to delete on process shutdown. We do this ourselves in some cases e.g. the map of built-in XML name mappings.
Here’s what I get after running dftest through valgrind (version 3.10.0 on Ubuntu 14.04 64-bit) ==4511== ==4511== HEAP SUMMARY: ==4511== in use at exit: 420,746 bytes in 10,364 blocks ==4511== total heap usage: 5,934,384 allocs, 5,924,020 frees, 2,013,062,817 bytes allocated ==4511== ==4511== LEAK SUMMARY: ==4511== definitely lost: 0 bytes in 0 blocks ==4511== indirectly lost: 0 bytes in 0 blocks ==4511== possibly lost: 0 bytes in 0 blocks ==4511== still reachable: 420,746 bytes in 10,364 blocks ==4511== suppressed: 0 bytes in 0 blocks ==4511== Reachable blocks (those to which a pointer was found) are not shown. ==4511== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==4511== ==4511== For counts of detected and suppressed errors, rerun with: -v ==4511== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) When I tested dfconvert with the table.html sample document (converting in both directions, including the case where an error is reported because the file doesn’t exist), it reported 0 bytes as definitely/indirectly/possibly lost, and the same 420,746 bytes above as still reachable. When I use —show-leak-kinds=all, most of the allocations are in the in the name map static initialisation (our own code), and libxml2 where it creates a character encoding handler (which I assume it only needs to do once). What version of valgrind are you running? It’s also possible that the document you’re testing with uses features that are missed by the testcases; if there’s anything in definitely/indirectly/possibly lost, it’s supposed to show the locations in the code where these occur - are you seeing these? — Dr Peter M. Kelly [email protected] PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) > On 16 Apr 2015, at 9:21 pm, Gabriela Gibson <[email protected]> wrote: > > I ran valgrind on dfconvert. > > With file foo1.html not existing yet, and the same thing with file foo1.html > existing. > > valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes > ./dfconvert get demo.docx foo1.html 2> log_leaky_with_foo1_not_existing.txt > > (see attached txt files) > > In both cases we drop 327k bytes somewhere: > > Case 1, file does not exist: > > ==20807== Command: ./dfconvert get demo.docx foo1.html > ==20807== > ==20807== > ==20807== HEAP SUMMARY: > ==20807== in use at exit: 327,842 bytes in 10,364 blocks > ==20807== total heap usage: 62,491 allocs, 52,127 frees, 25,363,368 bytes > allocated > > > Case 2, file exists: > > ==20788== Command: ./dfconvert get demo.docx foo1.html > ==20788== > Error: foo1.html: File already exists > ==20788== > ==20788== HEAP SUMMARY: > ==20788== in use at exit: 327,842 bytes in 10,364 blocks > ==20788== total heap usage: 56,384 allocs, 46,020 frees, 23,169,533 bytes > allocated > > I'm still exploring the code base with gdb and such, and the above problem > may be above my pay grade ;-) > > Then again, it might be nothing to worry about. > > I used the demo.docx file Peter posted yesterday. > > G > > > <log_leaky_with_foo1_not_existing.txt><log_leaks_get_with_existing_file.txt>
