libzmq
  1. libzmq
  2. LIBZMQ-325

Crash on two sockets with same identity

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.1.0
    • Fix Version/s: 3.2.0
    • Component/s: core
    • Labels:
      None

      Description

      If two sockets connect with the same identity then when one of them disconnects any activity on the other will trigger an assertion on the server.

      I tested this with the master branch, here is an example code here: https://gist.github.com/1860052

      Just run the server and then the client and wait.
      The server will shows this:

      Assertion failed: false (xrep.cpp:93)
      Abort trap: 6

      And the client this:

      Completed
      Assertion failed: (rc == 0 || errno == ETERM), function zsockopt_set_linger, file zsockopt.c, line 641.
      Abort trap: 6

      I am running this on mac os x 10.7.2

      1. test.c
        0.7 kB
        Ian Barber

        Activity

        Hide
        Ian Barber added a comment -

        Confirmed with direct API

        Show
        Ian Barber added a comment - Confirmed with direct API
        Hide
        Ian Barber added a comment -

        I think this is due to a race between the reaper and the closing of the second socket - so the issue isn't sending, it's the closing. The socket is handed off to the reaper, but then reestablished with the same identity as part of the auto reconnecting, and again handed off to the reaper. The XREP xterminated has an assert if there were no outpipes left to clear:

        void zmq::xrep_t::xterminated (pipe_t *pipe_)
        {
        fq.terminated (pipe_);

        for (outpipes_t::iterator it = outpipes.begin ();
        it != outpipes.end (); ++it) {
        if (it->second.pipe == pipe_)

        { outpipes.erase (it); if (pipe_ == current_out) current_out = NULL; return; }

        }
        zmq_assert (false);
        }

        Thing is, I can't see what that assert is catching - if there are no outpipes, the process has been terminated properly, and it's just that an additional term has made it's way though. The question is whether this really should be an exceptional situation - I'm not sure enough about the implications to just remove the assert - but it looks like it should be safe.

        Show
        Ian Barber added a comment - I think this is due to a race between the reaper and the closing of the second socket - so the issue isn't sending, it's the closing. The socket is handed off to the reaper, but then reestablished with the same identity as part of the auto reconnecting, and again handed off to the reaper. The XREP xterminated has an assert if there were no outpipes left to clear: void zmq::xrep_t::xterminated (pipe_t *pipe_) { fq.terminated (pipe_); for (outpipes_t::iterator it = outpipes.begin (); it != outpipes.end (); ++it) { if (it->second.pipe == pipe_) { outpipes.erase (it); if (pipe_ == current_out) current_out = NULL; return; } } zmq_assert (false); } Thing is, I can't see what that assert is catching - if there are no outpipes, the process has been terminated properly, and it's just that an additional term has made it's way though. The question is whether this really should be an exceptional situation - I'm not sure enough about the implications to just remove the assert - but it looks like it should be safe.
        Hide
        Ian Barber added a comment -

        On further thought, removing this assert would be a bad idea, it would be much better to either combine the reaping or serialise reaping and reestablishment somehow!

        Show
        Ian Barber added a comment - On further thought, removing this assert would be a bad idea, it would be much better to either combine the reaping or serialise reaping and reestablishment somehow!
        Hide
        Pieter Hintjens added a comment -

        I've fixed this by changing the semantics for duplicate identities: now when two clients try to use the same identity the second one is simply ignored; it uses the automatic identity instead.

        Show
        Pieter Hintjens added a comment - I've fixed this by changing the semantics for duplicate identities: now when two clients try to use the same identity the second one is simply ignored; it uses the automatic identity instead.

          People

          • Assignee:
            Unassigned
            Reporter:
            Julien Ammous
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: