|
From: Nicholas N. <nj...@cs...> - 2005-12-16 17:15:52
|
Hi, In this message: ==22516== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 3) ==22516== malloc/free: in use at exit: 0 bytes in 0 blocks. ==22516== malloc/free: 5,000,000 allocs, 5,000,000 frees, 80,000,000 bytes allocated. ==22516== For counts of detected errors, rerun with: -v ==22516== No malloc'd blocks -- no leaks are possible. the last line always confuses me -- it makes it sound like the program did no heap allocation. Would anyone object to changing it to: "All malloc'd blocks were freed -- no leaks are possible" ? And I wonder if we should still output this stuff: ==22614== LEAK SUMMARY: ==22614== definitely lost: 0 bytes in 0 blocks. ==22614== possibly lost: 0 bytes in 0 blocks. ==22614== still reachable: 0 bytes in 0 blocks. ==22614== suppressed: 0 bytes in 0 blocks. in this case, to be more consistent? (Talking about malloc/free is also a little confusing here since the user might have used new/delete...) Nick |
|
From: Jeroen N. W. <jn...@xs...> - 2005-12-17 09:30:34
|
> > Hi, > > In this message: > > ==22516== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from > 3) > ==22516== malloc/free: in use at exit: 0 bytes in 0 blocks. > ==22516== malloc/free: 5,000,000 allocs, 5,000,000 frees, 80,000,000 > bytes allocated. > ==22516== For counts of detected errors, rerun with: -v > ==22516== No malloc'd blocks -- no leaks are possible. > > the last line always confuses me -- it makes it sound like the program did > no heap allocation. Ditto, escpecially as it contradicts the '5,000,000 allocs' above it. > > Would anyone object to changing it to: > > "All malloc'd blocks were freed -- no leaks are possible" > > ? > > And I wonder if we should still output this stuff: > > ==22614== LEAK SUMMARY: > ==22614== definitely lost: 0 bytes in 0 blocks. > ==22614== possibly lost: 0 bytes in 0 blocks. > ==22614== still reachable: 0 bytes in 0 blocks. > ==22614== suppressed: 0 bytes in 0 blocks. > > in this case, to be more consistent? Please make these improvements. > > (Talking about malloc/free is also a little confusing here since the user > might have used new/delete...) > > Nick > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Julian S. <js...@ac...> - 2005-12-17 12:57:26
|
> Would anyone object to changing it to: > > "All malloc'd blocks were freed -- no leaks are possible" > > ? Seems good to me. Yes, it is poorly phrased. > And I wonder if we should still output this stuff: > > ==22614== LEAK SUMMARY: > ==22614== definitely lost: 0 bytes in 0 blocks. > ==22614== possibly lost: 0 bytes in 0 blocks. > ==22614== still reachable: 0 bytes in 0 blocks. > ==22614== suppressed: 0 bytes in 0 blocks. > > in this case, to be more consistent? That might give a regression testing problem. Imagine P which does free all its blocks, but the underlying glibc may or may not do so depending on version etc. Then P's regtest output would or would not include the summary if you made that change? (All in all I prefer to leave it as it is). > (Talking about malloc/free is also a little confusing here since the user > might have used new/delete...) "All malloc/new/new[] blocks were freed -- no leaks are possible" ? J |