Marc Lehmann wrote:
On Wed, Apr 09, 2008 at 10:49:51AM -0500, Brandon Black <[EMAIL PROTECTED]>
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
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
