small memory leak #46

Closed
matthiasg opened this Issue Jun 21, 2012 · 9 comments

Projects

None yet

3 participants

writing my new app using boost, i detected a small memory leak in czmq. Just creating a context and destroying it again, leaves two blocks.

Detected memory leaks!
Dumping objects ->
{912} normal block at 0x01CA4088, 16 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{911} normal block at 0x01CAEE08, 24 bytes long.
Data: < w5 @ > 20 77 35 02 88 40 CA 01 01 00 00 00 01 00 00 00

This is on Intel11.1 Compiler x86 with current boost library.

I have not yet had time to look closer, but maybe someone already knows why this is. It is not highly relevant since it does not grow obviously, but it is annoying not to have a clean test run and even worse having to communicate this to all other devs.

Member

I'll look at this today!

@felipecruz did you find anything ?

Member

Hello!
I don't know what happened but my answer was deleted.. or my post didn't worked..

anyway.. I ran a small example

#include <zmq.h>
#include <czmq.h>

int
    main(int argc, char *argv[])
{
    zctx_t *ctx = zctx_new();
    zctx_destroy(&ctx);

    return 0;
}

compiled with gcc leakcheck.c -lzmq -lczmq -g -o leakcheck and then valgrind --leak-check=full --show-reachable=yes ./leakcheck

On my linux box, I got no leaks.. on my osx box I got no leaks but:

....
==12471==    still reachable: 88 bytes in 1 blocks
.....

This can be ignored using a valgrind supress file.. It's not a leak..

What's your OS?
Could you run this example with valgrind and post your results here?

thanks.

oops did not write the os into the issue at first.

this is on windows 8 RP 64 and seems to behave identically on win7 64. I am rewriting a lot of our code in order to be able to port it to mac/unix but I don't have make files for unix yet. I am testing with boost though and it has automatic memory leak detection built-in. I will try to get a smaller working test running asap (which will sadly be not before tomorrow).

Member

@matthiasg problem solved? or not? :)

sorry for not following up, so many tickets to work through. i did re-run the test but it still leaked. i will have to create a smaller solution to upload to github as a test case. maybe we can convert it to unix then and re-run to make sure there isnt an issue with the compiler and its standard libraries with the windows port.

Owner

The selftests have full leak detection and I run these under valgrind systematically (at least when I remember, cause I just ran them and found a memory overwrite in zsockopt :-). There are no leaks I can find.

If you can find the actual source for the leaks, that'd be necessary to fixing it.

@ghost
ghost commented Nov 15, 2013

I'd say this problem is "solved". Test case produces no leaks (reachable
or otherwise). No updates in a year.

Owner

Closing as unreproducible in that case.

@hintjens hintjens closed this Nov 15, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment