Bug 78729

Summary: not stack'd, malloc'd or free'd, but written to anyway
Product: [Developer tools] valgrind Reporter: Xavier Bestel <xavier.bestel>
Component: memcheckAssignee: Julian Seward <jseward>
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version: 2.1.1   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:

Description Xavier Bestel 2004-03-30 12:01:25 UTC
during a valgrind session I stumbled on that (this is the first error):

==22013== Invalid read of size 1
....
==22013==    Address 0x48C1D128 is not stack'd, malloc'd or free'd


When I attach to gdb at this point, and I examine the content of memory
at 0x48C1D128 (to which a char* is pointing), I find a string which
really seems like it has been written by my program.

How is this possible ? How could my program write to a non stack'd,
malloc'd or free'd address before this point and not been caught by
valgrind ?
Comment 1 Tom Hughes 2004-03-30 12:04:50 UTC
Well it might have valid at the point that you wrote to it. There is a limit to how much freed memory valgrind will hang on to before it starts discarding it and once that happens the memory will probably appear to be neither malloced nor freed.
Comment 2 Xavier Bestel 2004-03-30 13:02:03 UTC
Ok, I've retried with a --freelist-vol=<big_amount_of_mem>, and effectively it now tells me the memory was previously freed. Thanks !

Would it be possible for memcheck to throw a warning when it starts reusing the freed memory pool, to tell the user it's possible subsequent 'not freed' indications may be invalid ?
Comment 3 Nicholas Nethercote 2004-03-30 13:13:05 UTC
I don't think that's the right way to do it;  the default freelist-vol is 1MB,
so any program that frees more than 1MB of heap memory will get that warning --
it would just be noise.

A simpler solution is to change the message to say "not stack'd, malloc'd or (recently) free'd".  Also, it would be good in general to have a section in the manual explaining situations where Valgrind doesn't do as well as it might;
this would be one of them.  How does that sound, Xavier?
Comment 4 Xavier Bestel 2004-03-30 14:05:50 UTC
Well, any program that frees more than freelist-vol of heap memory may get potentially wrong reports. So reporting the warning (only in case of "not freed" error) seems not so noisy to me.
You could also change the message, but make it a bit more explicit (tell the user to perhaps increase freelist-vol), and only when some freed memory has been discarded.

Any way I would agree, and yes a section in the manual explaining why it seems it doesn't work in some cases would help greatly - although I must say I don't reread the whole manual when I upgrade valgrind.

Thank you for your invaluable debugging tool,

         Xav
Comment 5 Nicholas Nethercote 2004-05-10 17:20:47 UTC
I changed it to "(recently) freed", seems like a good compromise.