PR #28 broke REP sockets

Description

PR #28 on zeromq2-1 supposedly fixes a memory leak, but actually prevents REP sockets from sending any (non-VSM) messages by causing a double-free situation. For a test case, simply run the hwserver.c example, changing the reply message to be large enough to not fit in a VSM, e.g.

zmq_msg_init_size (&reply, 50);

gdb output of hwserver (hwclient is run unaltered):

Received Hello
hwserver(25168,0x100481000) malloc: *** error for object 0x100101610: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT, Aborted.
[Switching to process 25168 thread 0x313]
0x00007fff8a2a5ce2 in __pthread_kill ()
(gdb) bt
#0  0x00007fff8a2a5ce2 in __pthread_kill ()
#1  0x00007fff8a47e7d2 in pthread_kill ()
#2  0x00007fff8a46fa7a in abort ()
#3  0x00007fff8a4ce84c in free ()
#4  0x000000010001d2c4 in zmq_msg_close (msg_=0x313) at zmq.cpp:153
#5  0x0000000100007672 in zmq::encoder_t::message_ready (this=0x100101508) at encoder.cpp:56
#6  0x000000010001efc3 in zmq::encoder_base_t<zmq::encoder_t>::get_data (this=0x100101508, data_=0x6, size_=0x10047ed70, offset_=0x0) at encoder.hpp:80
#7  0x000000010001e827 in zmq::zmq_engine_t::out_event (this=0x313) at zmq_engine.cpp:165
#8  0x000000010000bf5e in zmq::object_t::process_command (this=0x1001019b0, cmd_=@0x1001014f8) at object.cpp:63
#9  0x0000000100008833 in zmq::io_thread_t::in_event (this=0x313) at io_thread.cpp:83
#10 0x0000000100009507 in zmq::kqueue_t::loop (this=0x313) at kqueue.cpp:185
#11 0x0000000100019329 in thread_routine (arg_=0x100300460) at thread.cpp:75
#12 0x00007fff8a47c8bf in _pthread_start ()
#13 0x00007fff8a47fb75 in thread_start ()

Resetting to the commit prior to merge (d3a1ba6ae4a0e3939fb9e48935ac341504cd513d) avoids the error.

Aside: Jira is not aware that 2.1.10 has been released, so I cannot mark this as affecting 2.1.11, so I marked it as 2.1.10, which isn't accurate.

Environment

OSX 10.7.2, Ubuntu 11.10

Activity

Show:

Min RK December 12, 2011 at 4:03 AM

The offending commit was reverted, marking as fixed.

PieterP November 30, 2011 at 11:18 PM

So, reverted commit 1fb107 which was causing memory violations:

==6137== Invalid free() / delete / delete[]
==6137== at 0x4C282E0: free (vg_replace_malloc.c:366)
==6137== by 0x5068609: zmq_msg_close (zmq.cpp:153)
==6137== by 0x5053A94: zmq::encoder_t::message_ready() (encoder.cpp:56)
==6137== by 0x5069D63: zmq::zmq_engine_t::out_event() (encoder.hpp:80)
==6137== by 0x50585CD: zmq::object_t:rocess_command(zmq::command_t&) (object.cpp:63)
==6137== by 0x50552DB: zmq::io_thread_t::in_event() (io_thread.cpp:83)
==6137== by 0x505429D: zmq::epoll_t::loop() (epoll.cpp:161)
==6137== by 0x5064A55: thread_routine (thread.cpp:75)
==6137== by 0x561FEFB: start_thread (pthread_create.c:304)
==6137== by 0x535A89C: clone (clone.S:112)
==6137== Address 0x63ceed0 is 0 bytes inside a block of size 72 free'd
==6137== at 0x4C282E0: free (vg_replace_malloc.c:366)
==6137== by 0x5068609: zmq_msg_close (zmq.cpp:153)
==6137== by 0x5066682: zmq::xrep_t::xsend(zmq_msg_t*, int) (xrep.cpp:217)
==6137== by 0x5060D00: zmq::socket_base_t::send(zmq_msg_t*, int) (socket_base.cpp:505)
==6137== by 0x4E344BA: zframe_send (zframe.c:163)
==6137== by 0x4E375FC: zmsg_send (zmsg.c:139)
==6137== by 0x401A9F: main (mdbroker.c:411)

I've pushed that change to master. Not sure where the pull request #34 went to, it was already closed when I saw it.

PieterP November 27, 2011 at 3:29 PM

Thanks for catching this. Mato is adding the 2.1.11 release to Jira (the CSS was messed up, hiding the necessary menu option). I'm not quite sure how to revert a merge, so will wait for a new pull request that fixes this issue.