>Okay, > >but how/where can I see the actual memory leak occurring? dmesg?
Didn't know you can track memory leaks with dmesg. My response: valgrind short and quick test (~5 minutes) with valgrind results in: valgrind qtodo [snip] ==24808== HEAP SUMMARY: ==24808== in use at exit: 17,133,408 bytes in 179,976 blocks ==24808== total heap usage: 9,682,825 allocs, 9,502,849 frees, 728,701,362 bytes allocated ==24808== ==24808== LEAK SUMMARY: ==24808== definitely lost: 14,821,387 bytes in 154,807 blocks ==24808== indirectly lost: 886,821 bytes in 14,860 blocks ==24808== possibly lost: 384 bytes in 4 blocks ==24808== still reachable: 1,424,816 bytes in 10,305 blocks ==24808== suppressed: 0 bytes in 0 blocks ==24808== Rerun with --leak-check=full to see details of leaked memory ==24808== ==24808== For counts of detected and suppressed errors, rerun with: -v ==24808== Use --track-origins=yes to see where uninitialised values come from ==24808== ERROR SUMMARY: 47 errors from 9 contexts (suppressed: 42 from 6) entire report: https://gist.github.com/1632930 -- darkestkhan ------------------------------------------ Feel free to CC me. jid: [email protected] May The Source be with You. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
