On Mon, Jun 18, 2012 at 3:06 PM, Marc Lehmann <[email protected]> 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@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
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
