[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

valgrind/dselect questions


Figuring it would be a good learning experience to try out the recent 
patch for bug #395140 I applied it, installed the result, did:

$ valgrind --tool=massif dselect select  # which confirmed less mem used
$ dselect select  # played around a bit (scrolling through the pkg list,
                  # resizing the screen) without any obvious problem 
then got a bit craz^W braver and went for
# dselect select  # followed by a status manipulation 
                  # (specifically: "_", "^x"), still no problem

Then I tried the same with "valgrind dselect", but upon trying to exit 
the selection screen it went nuts and used up all available VM 
(600-700M depending on whether X was running or not) then started 
killing processes. Reinstalling the proper dselect and repeating got me 
the same result. :-(

Scaling back to simply starting dselect then exiting without accessing 
the selection screen gets me...

root@onegee:~# valgrind --leak-check=yes dselect
==2528== Memcheck, a memory error detector.
==2528== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1)
==2528== malloc/free: in use at exit: 66,183 bytes in 328 blocks.
==2528== malloc/free: 437 allocs, 109 frees, 68,629 bytes allocated.
==2528== For counts of detected errors, rerun with: -v
==2528== searching for pointers to 328 not-freed blocks.
==2528== checked 257,412 bytes.
==2528== LEAK SUMMARY:
==2528==    definitely lost: 0 bytes in 0 blocks.
==2528==      possibly lost: 0 bytes in 0 blocks.
==2528==    still reachable: 66,183 bytes in 328 blocks.
==2528==         suppressed: 0 bytes in 0 blocks.
==2528== Reachable blocks (those to which a pointer was found) are not 
==2528== To see them, rerun with: --show-reachable=yes

...with both the proper and patched versions.

Is dselect leaking memory? [the "437 allocs, 109 frees" bit]
How much VM does/should valgrind need?

- Bruce

Reply to: