zmsg_unwrap asserts on empty or single frame zmsg about czmq HOT 14 CLOSED

Good call. I've pushed a patch for this and added a test case in the zmsg.c
selftest.

On Sun, Jul 14, 2013 at 6:21 AM, lhope [email protected] wrote:

This is due to it unconditionally calling zframe_size on the empty frame.
zframe_size asserts on NULL argument.

Is this behaviour desired? If not, a trivial check for !empty could be
added to zmsg.c:403.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/208
.

from czmq.

After merging your patch, the CZMQ travis build fails because of failed libzmq checks, but your pull request has been confirmed to build successfully by Travis.

Do you have any idea why?

from czmq.

I bisected the issue to commit zeromq/libzmq@c56d797, however I still don't know why the libzmq travis build does not fail.

from czmq.

I'm out of the house atm but will check later.
On Jul 14, 2013 2:01 PM, "Uli Köhler" [email protected] wrote:

I bisected the issue to commit c56d797c56d797,
however I still don't know why the libzmq travis build does not fail.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/208#issuecomment-20935376
.

from czmq.

Thanks! I checked the return code, zmq_strerror says "No route to host" just before the assertion fails.

from czmq.

For me (Linux x86_64, GCC 4.7) the error occurs in test_spec_req, but it's not 100% reproducible. It occurs in about 80% of the cases I run test_spec_req, that also explains why the travis build doesn't fail reproducibly.

I will try to continue debugging the issue, however my knowledge of the libzmq internals is quite limited.

from czmq.

(Sorry for comment-spamming)
I inserted SIGTRAPs in case of rc == -1, which leads to this stacktrace:

#1 0x0000000000401a3a in s_send_seq (socket=0x414f00) at testutil.hpp:140
#2 0x00000000004020a8 in test_req_only_listens_to_current_peer (ctx=ctx@entry=0x406010) at test_spec_req.cpp:122

The corresponding testcase is executed for both inproc and TCP endpoints, but the error seems to occur for TCP only.

The diff that seems to have cause the issues re-enables the testcase:

-        // *** Test disabled until libzmq does this properly ***
-        // test_req_only_listens_to_current_peer (ctx);
+        test_req_only_listens_to_current_peer (ctx);

Therefore I don't consider this an error, the pull request by @ckamm just doesn't fix it in 100% of the cases.

I will submit a pull request to disable the testcase. That will fix the symptoms, but, citing the diff, zmq doesn't seem to do this properly at the moment.

from czmq.

Was this with current master? A fix was merged earlier today with which I could not reproduce this problem any more.

from czmq.

I just saw your most recent pull request (zeromq/libzmq#614), commit 4fb004f59b81a09a8b428409b61baa79b642712d, but I can confirm the issue also occurs with the latest master (however, there's only a ~80% chance it occurs when executing the testcase).

Could you try to execute make check ~10 times?

from czmq.

I just ran it about 40 times, no failures of test_spec_req. Could you try increasing the timeout I added? Maybe 10 ms was overly optimistic.

from czmq.

I just did a fresh checkout of libzmq on my Server (Ubuntu 12.04, x86_64, GCC 4.6.3), the problem is reproducible there.

I'm not sure what timeout you are referring to -- increasing the ROUTER receive timeout (line 90) to 100k (milliseconds?) does not fix the problem so I suppose you're referring to line 110.

Increasing it to 10k milliseconds makes the test fail after about 10 seconds, so I suppose the problem originates there, but the underlying issue must be somewhere else. Increasing the timeout beyond 10 seconds also makes the test fail after the timeout.

from czmq.

Yes, I meant line 110, but that doesn't seem to be it. What error do you get? I assume an assert is triggered by the call in line 126?

If so, could you put a printf before that (printing i) as well as before req.cpp:75 and 163? That'd help me understand what's going on.

Thanks!

from czmq.

There was a failing test on libzmq master, which should be taken care of
now.

On Mon, Jul 15, 2013 at 8:34 AM, ckamm [email protected] wrote:

Yes, I meant line 110, but that doesn't seem to be it. What error do you
get? I assume an assert is triggered by the call in line 126?

If so, could you put a printf before that (printing i) as well as before
req.cpp:75 and 163? That'd help me understand what's going on.

Thanks!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/208#issuecomment-20953691
.

from czmq.

@ulikoehler can you confirm @hintjens comment?

from czmq.