|
From: Hailong X. <xia...@gm...> - 2012-01-18 17:05:19
|
Hi I just started to use valgrind. I got the following errors. Are these series bugs? My code is running fine. Generally, how many memory leak is really bad? ==407== LEAK SUMMARY: ==407== definitely lost: 3,752 bytes in 79 blocks ==407== indirectly lost: 696 bytes in 87 blocks ==407== possibly lost: 0 bytes in 0 blocks ==407== still reachable: 1,040 bytes in 2 blocks ==407== suppressed: 0 bytes in 0 blocks ==407== Reachable blocks (those to which a pointer was found) are not shown. ==407== To see them, rerun with: --leak-check=full --show-reachable=yes ==407== ==407== For counts of detected and suppressed errors, rerun with: -v ==407== Use --track-origins=yes to see where uninitialised values come from ==407== ERROR SUMMARY: 10000076 errors from 679 contexts (suppressed: 11 from 9) Could you give some hints? -- Hailong |
|
From: John R. <jr...@bi...> - 2012-01-18 17:41:18
|
> Are these series bugs? I suppose you mean "serious bugs", that is, bugs that have a large impact or must not be ignored. > > My code is running fine. > > Generally, how many memory leak is really bad? > > > ==407== LEAK SUMMARY: > ==407== definitely lost: 3,752 bytes in 79 blocks > ==407== indirectly lost: 696 bytes in 87 blocks > ==407== possibly lost: 0 bytes in 0 blocks > ==407== still reachable: 1,040 bytes in 2 blocks > ==407== suppressed: 0 bytes in 0 blocks Those leaks look relatively harmless, but ONLY IF: that program runs quickly, and not too many times per day, and is not a testcase for a long-running process (several hours or longer) or for a process that will be run by many users simultaneously on the same machine. If the program takes a long time to run (minutes), or is run more than five times per day, or is a simple example of a a larger or longer-running process, or with many simultaneous instantiations on the same machine, then such errors start to become serious. > ==407== ERROR SUMMARY: 10000076 errors from 679 contexts (suppressed: 11 from 9) That's what I would worry about first: ten million errors (use of uninitialized values) noticed at hundreds of locations in the code. Probably you have a few (2 or 3 or 4) _systematic_ errors. Not only is there a problem, but the problem occurs nearly every time, and will taint _everything_. Such errors must be fixed. Reduce the number of errors to fewer than ten. There may be a programming concept which the author of the code does not understand correctly. -- |
|
From: Nick O. <ni...@as...> - 2012-01-18 17:44:22
|
Depends on a lot of things. You can determine for yourself if leaks are bad, but the other errors, such as invalid access, you want to fix. Always. On 18 jan. 2012, at 18:05:10, Hailong Xiao wrote: > Hi > > I just started to use valgrind. > I got the following errors. > Are these series bugs? > > My code is running fine. > > Generally, how many memory leak is really bad? > > > ==407== LEAK SUMMARY: > ==407== definitely lost: 3,752 bytes in 79 blocks > ==407== indirectly lost: 696 bytes in 87 blocks > ==407== possibly lost: 0 bytes in 0 blocks > ==407== still reachable: 1,040 bytes in 2 blocks > ==407== suppressed: 0 bytes in 0 blocks > ==407== Reachable blocks (those to which a pointer was found) are not shown. > ==407== To see them, rerun with: --leak-check=full --show-reachable=yes > ==407== > ==407== For counts of detected and suppressed errors, rerun with: -v > ==407== Use --track-origins=yes to see where uninitialised values come from > ==407== ERROR SUMMARY: 10000076 errors from 679 contexts (suppressed: 11 from 9) > > > > Could you give some hints? > -- > Hailong > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d_______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: <pa...@fr...> - 2012-01-18 17:44:52
|
----- Original Message ----- > > Hi > > I just started to use valgrind. > I got the following errors. > Are these series bugs? > > My code is running fine. > > Generally, how many memory leak is really bad? Hi Just my opinion. You might tolerate one-off leaks in initialization code. You might also tolerate leaks if your application has short execution times and/or you have plenty of RAM. If you have leaks in loops or event handlers, and your application has long execution times, then you're going to risk your application terminating due to memory exhaustion (it may even cause other apps to terminate). If your app is leaking a megabyte a second then your upper limit for run time on a 32bit system is going to be about half an hour. A+ Paul |
|
From: Ashley P. <as...@pi...> - 2012-01-18 18:01:42
|
On 18 Jan 2012, at 17:05, Hailong Xiao wrote: > Hi > > I just started to use valgrind. > I got the following errors. > Are these series bugs? > > My code is running fine. > > Generally, how many memory leak is really bad? Depends on the application, for short-lived utilities (like ls or something that'll be restarted every day) it's mostly a style issue, for anything designed to run continuously as a system service like X, dhcpd or apache they are critical as any memory leak will crash the application given enough time. Ashley. |
|
From: Hailong X. <xia...@gm...> - 2012-01-18 18:28:22
|
Thank you all. I am running code for scientific computing which is short time running. So this should be ok, right? Hailong On Wed, Jan 18, 2012 at 11:05 AM, Hailong Xiao <xia...@gm...> wrote: > Hi > > I just started to use valgrind. > I got the following errors. > Are these series bugs? > > My code is running fine. > > Generally, how many memory leak is really bad? > > > ==407== LEAK SUMMARY: > ==407== definitely lost: 3,752 bytes in 79 blocks > ==407== indirectly lost: 696 bytes in 87 blocks > ==407== possibly lost: 0 bytes in 0 blocks > ==407== still reachable: 1,040 bytes in 2 blocks > ==407== suppressed: 0 bytes in 0 blocks > ==407== Reachable blocks (those to which a pointer was found) are not > shown. > ==407== To see them, rerun with: --leak-check=full --show-reachable=yes > ==407== > ==407== For counts of detected and suppressed errors, rerun with: -v > ==407== Use --track-origins=yes to see where uninitialised values come from > ==407== ERROR SUMMARY: 10000076 errors from 679 contexts (suppressed: 11 > from 9) > > > > Could you give some hints? > -- > Hailong > -- Hailong |
|
From: David C. <dcc...@ac...> - 2012-01-18 19:12:52
|
On 1/18/2012 10:28 AM, Hailong Xiao wrote:
> Thank you all.
>
> I am running code for scientific computing which is short time running.
> So this should be ok, right?
>
> Hailong
>
As another poster said, the 10 million other errors suggest use of
uninitialized data, which could corrupt your results. If you fix all of
those then the memory leaks might not be a big deal. Tolerating memory
leaks is not a good idea, IMO.
--
David Chapman dcc...@ac...
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
|
|
From: David C. <dcc...@ac...> - 2012-01-18 18:36:02
|
On 1/18/2012 9:05 AM, Hailong Xiao wrote:
> Hi
>
> I just started to use valgrind.
> I got the following errors.
> Are these series bugs?
>
> My code is running fine.
>
> Generally, how many memory leak is really bad?
>
>
> ==407== LEAK SUMMARY:
> ==407== definitely lost: 3,752 bytes in 79 blocks
> ==407== indirectly lost: 696 bytes in 87 blocks
> ==407== possibly lost: 0 bytes in 0 blocks
> ==407== still reachable: 1,040 bytes in 2 blocks
> ==407== suppressed: 0 bytes in 0 blocks
> ==407== Reachable blocks (those to which a pointer was found) are not
> shown.
> ==407== To see them, rerun with: --leak-check=full --show-reachable=yes
> ==407==
> ==407== For counts of detected and suppressed errors, rerun with: -v
> ==407== Use --track-origins=yes to see where uninitialised values come
> from
> ==407== ERROR SUMMARY: 10000076 errors from 679 contexts (suppressed:
> 11 from 9)
>
>
If your program will never run for very long, and if your test run
represents the worst possible case, then you can ignore the memory
leaks. If your test run was much smaller than a "real" run, then the
memory leaks could be very serious.
For example, I am having problems right now with a memory leak in
Firefox. It leaks somewhere between a few kilobytes per minute and a
megabyte per minute when I play streaming audio from an Internet radio
station. I have 4 GB of memory, so this shouldn't be a big deal, but my
machine is on all day long, and now I have to restart Firefox once or
twice per day. Clearly this is a significant error for me, but someone
playing the radio station for a few minutes would never notice.
As a rule I fix *all* memory leaks. They are bugs in the program, and I
don't intentionally ship code with bugs. Fixing all bugs is a good
software development practice.
The other thing to worry about is the error summary at the bottom:
10000076 errors. This number should be very small - only suppressed
errors (those that are part of the C libraries and thus are beyond your
control) should be present. You definitely want to find out why
valgrind is reporting so many errors.
--
David Chapman dcc...@ac...
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
|