valgrind/dselect questions
Hi,
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==
==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
shown.
==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: