memory leak or something wrong

Brandon Black blblack at
Mon Jun 18 23:50:22 CEST 2012

On Mon, Jun 18, 2012 at 3:06 PM, Marc Lehmann <schmorp at> wrote:
> It could also be some esoteric form of internal memory fragmentation,
> which I would also consider a bug in the allocator.

This is what I suspect as well, as the "leak" is a very slow growth in
the Data size, but valgrind won't report it.  However, whether it's a
simple bug or somehow intentional behavior is unclear to me given all
that arguing about malloc(p,0) between glibc/C/POSIX people.
Modifying the original example loop to compile on my box with the
distro's libev-4.04, as:

#include <time.h>
#include "libev/ev.h"

int main(int argc, char* argv[]) {
    while (1) {
        struct timespec slp;
        slp.tv_sec = 0;
        slp.tv_nsec = 10*1e6;

        struct ev_loop *evp = ev_loop_new( 0 );
        ev_loop_destroy( evp );
        nanosleep( &slp, NULL );

Then running it and monitoring the VmData size via procfs, I see results like:

[blblack at mysteron ~]$ while [ 1 ]; do grep VmData /proc/30936/status;
sleep 5; done
VmData:	    2352 kB
VmData:	    2736 kB
VmData:	    2992 kB
VmData:	    3376 kB
VmData:	    3632 kB
VmData:	    4016 kB

Using ev_set_allocator() to transform realloc(p,0) into free(p) calls
stops the growth.

-- Brandon

More information about the libev mailing list