[zeromq-dev] Random zmq_abort when receiving data form ZMQ_STREAM socket

Auer, Jens jens.auer at cgi.com
Fri Jul 29 15:16:04 CEST 2016


Hi,

I am seeing random core files with an internal assertion from ZeroMQ when receiving data on a ZMQ_STREAM socket:
#0  0x00007fea3ca015f7 in raise () from /lib64/libc.so.6
#1  0x00007fea3ca02ce8 in abort () from /lib64/libc.so.6
#2  0x00007fea3d9fc7a9 in zmq::zmq_abort (errmsg_=errmsg_ at entry=0x7fea3da2ca2d "check ()") at src/err.cpp:84
#3  0x00007fea3da03262 in zmq::msg_t::size (this=this at entry=0x7ffc1dbc05a0) at src/msg.cpp:248
#4  0x00007fea3da2abc5 in zmq_msg_size (msg_=msg_ at entry=0x7ffc1dbc05a0) at src/zmq.cpp:626
#5  0x00007fea3da2afa5 in s_recvmsg (s_=<optimized out>, msg_=0x7ffc1dbc05a0, flags_=<optimized out>) at src/zmq.cpp:459
#6  0x00000000004f660d in auto commons::zmq::socket::callZMQWithSignalHandling<std::experimental::optional<zmq::message_t> commons::zmq::socket::receiveMessage<zmq::socket_t>(zmq::socket_t&)::{lambda()#1} const&>(std::experimental::optional<zmq::message_t> commons::zmq::socket::receiveMessage<zmq::socket_t>(zmq::socket_t&)::{lambda()#1} const&) ()
#7  0x00000000004f6e99 in react::sources::SocketSource<zmq::socket_t>::readSome(std::vector<react::EventData, std::allocator<react::EventData> >&) ()
#8  0x000000000050c496 in react::ZMQReactor::callCalbacksForData(react::EventDemultiplexor::SourceEvent const&, std::map<boost::uuids::uuid, std::unique_ptr<react::EventCallback, std::default_delete<react::EventCallback> >, std::less<boost::uuids::uuid>, std::allocator<std::pair<boost::uuids::uuid const, std::unique_ptr<react::EventCallback, std::default_delete<react::EventCallback> > > > > const&) ()

We inspected the message in the debugger and all bytes are 0.

My function to receive messages creates a new empty message as a local variable to receive the data and then calls recv with ZMQ_DONTWAIT on the socket. The assertion is raised when the internal recv call returns. There is an assertion msg->check() at the beginning of socket_base_t::recv which is not raised, so I think the message is ok and something in socket_base_t::recv breaks it.

I cannot reliably reproduce it. It seems that disconnecting the other side of the socket seems to trigger it, but I do not have enough data to justify this assumption. We use ZeroMQ 4.1.4. The process which crashes is connected to another process with a ZMQ_STREAM socket and data flows in the direction of the crashing process only (after some handshaking at the beginning).

Best wishes,
  Jens

--
Dr. Jens Auer | CGI | Software Engineer
CGI Deutschland Ltd. & Co. KG
Rheinstraße 95 | 64295 Darmstadt | Germany
T: +49 6151 36860 154
jens.auer at cgi.com
Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben.

CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail.





More information about the zeromq-dev mailing list