[zeromq-dev] What causes assert(*tmpbuf < 0) to trip?

[Dana Leonard]

Some background:
I have an object that serves as a message hub. It receives either
association requests (serviced locally) or messages to be forwarded to
another client/service connected to the hub.

In my simplest test case, I have the message hub running and I start a
client (communicating via IPC) who associates. This works just fine. The
client then sends a message that requests data from another serivce (who is
not connected at the moment). The hub cannot find the forwarding address and
replies to the client with an error message. This reply somehow trips the
assert(*tmpbuf < 0) in zmq_decoder's one_byte_size_ready() everytime.

I added a printf() to one_byte_size_ready() and it looks like it runs
several times after the reply comes in (I'm sure there are other state
transitions but they aren't instrumented with debug code).

Here is the debug output of my test.

Client thread:
MESSENGER: associate send
MESSENGER: associate recv
ZMQ_DECODER: tempbuf = 01 00 00 00 00 00 00
ZMQ_DECODER: tempbuf = 01 00 00 00 00 00 00
ZMQ_DECODER: tempbuf = 0e 00 00 00 00 00 00
MESSENGER: sending
ZMQ_DECODER: tempbuf = 01 00 00 00 00 00 00
ZMQ_DECODER: tempbuf = 01 00 00 00 00 00 00
MESSENGER: receiving
ZMQ_DECODER: tempbuf = 40 00 00 00 00 00 00
ZMQ_DECODER: tempbuf = 40 00 00 00 00 00 00
ZMQ_DECODER: tempbuf = 00 00 00 00 00 00 00
Assertion failed. *tmpbuf > 0

Hub thread:
ZMQ_DECODER: tempbuf = 01 00 00 00 00 00 00
ZMQ_DECODER: tempbuf = 01 00 00 00 00 00 00
ZMQ_DECODER: tempbuf = 02 00 00 00 00 00 00
HUB: receiving assoc
HUB: replying assoc
ZMQ_DECODER: tempbuf = 01 00 00 00 00 00 00
ZMQ_DECODER: tempbuf = 01 00 00 00 00 00 00
ZMQ_DECODER: tempbuf = 40 00 00 00 00 00 00
HUB: receiving work order
HUB: replying error
<operation continues, no crash>

Is there anyway that the message payload influences the first byte of
tmpbuf? I've tried tracing the code but it is plenty confusing. It seems
like this first byte should be some header information that I can't muck
with.

Thanks for the help,
Dana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101123/dbbd2087/attachment.htm>