valgrind stuff

Brandon Black blblack at gmail.com
Wed Apr 9 17:49:51 CEST 2008


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




More information about the libev mailing list