Testing a ZeroMQ wrapper

[SPC]

My team is looking at ZeroMQ (http://zeromq.org/) as a replacement for the interprocess communications mechanism we presently use. Since we provide a library to our end users, we need to make ZeroMQ's use completely hidden. No new requirements for callers to our API. This has presented me with a real challenge in getting ZeroMQ's resources allocated and released at appropriate times. I'm using CppuTest to do TDD for my code and have a suite of tests that work...most of the time. Apparently there are race conditions which cause the memory leak detector to throw a fit. I already have the leak detector turned off for some of my tests, but its beginning to look like I'm just going to have to turn it off full time, which I really don't like. ZeroMQ appears to use static objects (possible singletons?) which have been part of the issue. Has anyone done any development with ZeroMQ and CppuTest? If so, how did you deal with these issues?

[Felipe de Andrade Neves Lavratti]

Hi,

I worked with CppUTest and ZeroMQ and don't remember turning off the
memory leak detector.

Did you try to include the zmq header *before* the cpputest's
MemoryLeakDetectorMallocMacros.h header on your code and test?

At.

On Mon, Sep 29, 2014 at 4:38 PM, SPC <spc.pro...@gmail.com> wrote:
>
> My team is looking at ZeroMQ (http://zeromq.org/) as a replacement for the interprocess communications mechanism we presently use. Since we provide a library to our end users, we need to make ZeroMQ's use completely hidden. No new requirements for callers to our API. This has presented me with a real challenge in getting ZeroMQ's resources allocated and released at appropriate times. I'm using CppuTest to do TDD for my code and have a suite of tests that work...most of the time. Apparently there are race conditions which cause the memory leak detector to throw a fit. I already have the leak detector turned off for some of my tests, but its beginning to look like I'm just going to have to turn it off full time, which I really don't like. ZeroMQ appears to use static objects (possible singletons?) which have been part of the issue. Has anyone done any development with ZeroMQ and CppuTest? If so, how did you deal with these issues?
>

> --
> You received this message because you are subscribed to the Google Groups "cpputest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cpputest+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.




--
Skype: felipeanl

[Felipe de Andrade Neves Lavratti]

FIY:
http://codepad.org/sWSBOEOQ

This is a peace of a test code where the CUT were a wrapper of Zmq functions.
No leak happened.

--
Skype: felipeanl

[A. Robert S.]

Hi,

 

Ideally, you need to make sure that those static objects do all their allocation stuff before the memory leak detection starts its magic.

 

I had similar problems with std c++ lib objects, because I wanted a static object, say, a std::map, but once you start using it, it allocates memory internally (and I don't mean the actual elements) which is only released (if ever) after the memory leak detector has already done its checks.

 

So if you can manage to have it do all its allocation before you start checking for leaks, you should be okay. I believe there is a way to disable and re-enable memory leak checking from within your tests, but I have never used this so I don't know off-hand how to do it.

 

Regards,

Robert

[SPC]

I suspect you didn't encounter my issue because you aren't trying to hide the existence of 0MQ. Because of our requirements I need to use statics. I've pruned down my tests to the simplest form I could that produces problems (see attachment).  We don't want to create a new context every time we create a socket, so a static instance we can grab at need makes sense. If I turn off memory checking and run the test with valgrind there are no leaks. Running the test though with memory checking enabled results in numerous leaks being falsely reported. There are times that static instances are the right solution for a problem, so how is one supposed to successfully test with CppUTest in such a case???

[SPC]

I've tried disabling for the duration of the test in the setup / teardown functions, but it still detects strange stuff. I try forcing allocation before the tests start, but badness still ensues. I've included code in my most recent post prior to this response.

[SPC]

Here is the output for those that don't have ZMQ available:

make

compiling zmqLeaks.cpp

Linking zmq_leaks_tests

Running zmq_leaks_tests

static zmq::context_t& ContextWrapper::get()

virtual void TEST_GROUP_CppUTestGroupZmq::setup()

virtual void TEST_Zmq_socketsCauseLeaks_Test::testBody(): allocating socket.

static zmq::context_t& ContextWrapper::get()

virtual void TEST_Zmq_socketsCauseLeaks_Test::testBody(): allocated socket.

virtual void TEST_GROUP_CppUTestGroupZmq::teardown()

tests/zmqLeaks.cpp:41: error: Failure in TEST(Zmq, socketsCauseLeaks)

        Memory leak(s) found.

Alloc num (6) Leak size: 136 Allocated at: <unknown> and line: 0. Type: "new"

        Memory: <0x1d72c40> Content:

    0000: 10 59 52 95 d2 2a 00 00  8e 6b f9 45 a5 6e 00 00 |.YR..*...k.E.n..|

    0010: 3f 90 7f 03 00 00 00 00  00 00 00 00 00 00 00 00 |?...............|

    0020: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|

    0030: 60 2c d7 01 00 00 00 00  60 2c d7 01 00 00 00 00 |`,......`,......|

    0040: 00 00 00 00 00 00 00 00  01 00 00 00 05 00 00 00 |................|

    0050: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|

    0060: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|

    0070: 50 e6 2e 95 d2 2a 00 00  40 2c d7 01 00 00 00 00 |P....*..@,......|

    0080: 00 67 73 96 d2 2a 00 00                          |.gs..*..|

Alloc num (11) Leak size: 8 Allocated at: <unknown> and line: 0. Type: "new"

        Memory: <0x1d732d0> Content:

    0000: c0 2e d7 01 00 00 00 00                          |........|

Alloc num (7) Leak size: 24 Allocated at: <unknown> and line: 0. Type: "new"

        Memory: <0x1d72d20> Content:

    0000: 04 00 00 00 01 00 00 00  20 2d d7 01 00 00 00 00 |........ -......|

    0010: 88 29 d7 01 00 00 00 00                          |.)......|

Alloc num (5) Leak size: 224 Allocated at: <unknown> and line: 0. Type: "new"

        Memory: <0x1d72970> Content:

    0000: 70 6b 52 95 d2 2a 00 00  c0 02 d7 01 00 00 00 00 |pkR..*..........|

    0010: 01 00 00 00 00 00 00 00  28 6c 52 95 d2 2a 00 00 |........(lR..*..|

    0020: 30 5e 52 95 d2 2a 00 00  a0 2a d7 01 00 00 00 00 |0^R..*...*......|

    0030: 00 00 00 00 00 00 00 00  a0 2a d7 01 00 00 00 00 |.........*......|

    0040: 01 00 00 00 00 00 00 00  a0 2a d7 01 00 00 00 00 |.........*......|

    0050: 02 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|

    0060: b8 2a d7 01 00 00 00 00  b8 2a d7 01 00 00 00 00 |.*.......*......|

    0070: b8 2a d7 01 00 00 00 00  b8 2a d7 01 00 00 00 00 |.*.......*......|

    0080: 04 00 00 00 04 00 00 00  4f 7b 00 00 00 00 00 00 |........O{......|

    0090: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|

    00a0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|

    00b0: 00 00 00 00 00 00 00 00  01 00 00 00 00 00 00 00 |................|

    00c0: 20 2d d7 01 00 00 00 00  40 2c d7 01 00 00 00 00 | -......@,......|

    00d0: 00 00 00 00 00 00 00 00  4f 7b 00 00 00 00 00 00 |........O{......|

Alloc num (24) Leak size: 8 Allocated at: <unknown> and line: 0. Type: "new"

        Memory: <0x1d73b70> Content:

    0000: 60 34 d7 01 00 00 00 00                          |`4......|

Alloc num (9) Leak size: 136 Allocated at: <unknown> and line: 0. Type: "new"

        Memory: <0x1d73180> Content:

    0000: 10 59 52 95 d2 2a 00 00  d0 9b fb 45 a5 6e 00 00 |.YR..*.....E.n..|

    0010: 3f 90 7f 03 00 00 00 00  00 00 00 00 00 00 00 00 |?...............|

    0020: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|

    0030: a0 31 d7 01 00 00 00 00  a0 31 d7 01 00 00 00 00 |.1.......1......|

    0040: 00 00 00 00 00 00 00 00  01 00 00 00 07 00 00 00 |................|

    0050: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|

    0060: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|

    0070: 50 e6 2e 95 d2 2a 00 00  80 31 d7 01 00 00 00 00 |P....*...1......|

    0080: 00 77 93 96 d2 2a 00 00                          |.w...*..|

Alloc num (10) Leak size: 24 Allocated at: <unknown> and line: 0. Type: "new"

        Memory: <0x1d73260> Content:

    0000: 06 00 00 00 01 00 00 00  60 32 d7 01 00 00 00 00 |........`2......|

    0010: d8 2e d7 01 00 00 00 00                          |........|

Alloc num (22) Leak size: 409

etc etc etc etc. !!!! Too much memory leaks to report. Bailing out

Total number of leaks:  9

.

Errors (1 failures, 1 tests, 1 ran, 0 checks, 0 ignored, 0 filtered out, 2 ms)

make: *** [all] Error 1