valgrind stuff

Brandon Black blblack at gmail.com
Wed Apr 9 23:08:00 CEST 2008


Marc Lehmann wrote:
> On Wed, Apr 09, 2008 at 10:49:51AM -0500, Brandon Black <blblack at gmail.com> wrote:
>> meaningful runtime leakage in practice).  The first is that the signals 
>> array isn't ever deallocated.  This fixed it for me locally:
> 
> thats not a problem, it does not leak (the signals array cannot be
> deallocated for various reasons, but its not per-loop, so no leak).
>

It doesn't leak in the long term, because it's a one shot thing, but it 
is an annoyance when you're trying to get clean valgrind output.  I'll 
add an exception for it I guess.

>> Also, the default ev_realloc() does a realloc to zero for allocs of size 
>> zero, instead of an actual free(), which results in valgrind reporting a 
>> bunch of leaks of size zero at exit.  Glibc's docs say realloc() to zero 
> 
> actually, realloc is defined to be free in that case in the C programming
> language. this is a known bug in valgrind. you might want to look if somebody
> has reported it yet and if not, do so.
>

Fair enough.

>> It happens just once, when I start up my default loop.  Usually this 
>> indicates a real code bug that should be fixed, although given the deep 
>> magic of libev, it wouldn't surprise me terribly if the code was ok and 
>> valgrind just can't understand what's going on :)
> 
> Hmm, realloc (*, 0) to free memory is usually a code bug? That would
> be surprising, realloc was designed to be a full-blwon memory manager
> function, and lots of programs use it. If memory is resized and later the
> pointer is accessed beyond the reallocated size, that would be a bug, of
> course, but that is a bug regardless of how large the size parameter was.
> 
> realloc (*, 0) is a bug in the same cases where free(x) would be a bug, and
> free does not usually indicate a real code bug.
> 
>> I haven't further tracked this down yet, but I will get around to it, 
>> just a heads up in case something obvious occurs to someone else.
> 
> It is never wrong to report what you see (well, if the reports have a
> certain minimum quality, like yours :), even if its not a real issue,
> sometimes it should be documented to spare people some work.
> 

Sorry maybe I wasn't clear.  Those error messages I pasted are a 
completely separate issue from the realloc thing.  I tracked it down now 
to the point that I can interpret the messages (and exactly when they 
occur) as meaning: when poll_poll() is called, the 0th member of the 
poll set, which is the read side of the pipe that's set up for signals 
and such, has an "revents" member which is uninitialized memory, and 
poll_poll() is making decisions based on reading that ununitialized 
memory.  The reason I don't see any worse behavior is that even though 
it's "uninitialized", being an early allocation it tends to be zero'd 
out anyways by chance.

-- Brandon



More information about the libev mailing list