I've been running valgrind on some code with an embedded copy of libev.
There are two things in libev that cause pointless valgrind memory
leak warnings (pointless as in they don't constitute any kind of
meaningful runtime leakage in practice). The first is that the signals
array isn't ever deallocated. This fixed it for me locally:
Index: ev.c
===================================================================
RCS file: /schmorpforge/libev/ev.c,v
retrieving revision 1.223
diff -u -r1.223 ev.c
--- ev.c 6 Apr 2008 14:34:50 -0000 1.223
+++ ev.c 9 Apr 2008 15:27:23 -0000
@@ -1266,6 +1266,7 @@
#if EV_ASYNC_ENABLE
array_free (async, EMPTY);
#endif
+ ev_free (signals);
backend = 0;
}
But I suspect that only works because I'm not using multiplicity,
probably needs some check for whether it's the default loop being
destroyed, or something like that.
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
is equivalent to free(), so I don't know why valgrind is reporting that
to begin with. It's not too hard to silence these in various ways (like
a custom reallocator that does an explicit free() and returns NULL on
realloc to zero). Just FYI.
Memory "leak" stuff aside, valgrind is also giving me this:
==8341== Conditional jump or move depends on uninitialised value(s)
==8341== at 0x804E52B: poll_poll (ev_poll.c:105)
==8341== by 0x804F285: ev_loop (ev.c:1632)
==8341== by 0x8049E17: main (main.c:135)
==8341==
==8341== Conditional jump or move depends on uninitialised value(s)
==8341== at 0x804E563: poll_poll (ev_poll.c:108)
==8341== by 0x804F285: ev_loop (ev.c:1632)
==8341== by 0x8049E17: main (main.c:135)
==8341==
==8341== Conditional jump or move depends on uninitialised value(s)
==8341== at 0x804E58F: poll_poll (ev_poll.c:108)
==8341== by 0x804F285: ev_loop (ev.c:1632)
==8341== by 0x8049E17: main (main.c:135)
[Those line numbers are in the 3.2 sources]
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 :)
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.
-- Brandon
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
