Hi,

I am back with the asserts happening inside a critical section in signaler.cpp. The problem still is that in signale.cpp make_fdpair(..) creates system-wide critical section and does a number of things that can generate a wsa_assert() or win_assert() before releasing the session.

I have seen that in the trunk someone has added a CloseHandle(sync) at the end of the function, I do not know if it had something related with this but I understand that the problem is still there. wsa_assert() and wsa_windows() end up in RaiseException (0x40000015, EXCEPTION_NONCONTINUABLE, 1, extra_info) which I understand is a cul de sac that has no way out to clean up before leaving.

I guess we need a special assert function to use inside this critical but I'd like a more documented opinion (Kiu?).

thanks,

Pau Ceano

El 21/01/2013 23:37, KIU Shueng Chuan escribió:

Hi Pau, a fix for the assertion on connection to port 5905 is in trunk branch.

I think the dangling critical section possibility could be fixed by changing the Event to a Mutex. When an assertion occurs the mutex would just be abandoned. However this change will cause backward compatibility issues with older versions.

On Jan 22, 2013 2:04 AM, "Pieter Hintjens" <[email protected] <mailto:[email protected]>> wrote:

    Hi Pau,

    So there are two different problems here, one is that we're hitting a
    socket limit on WXP, and the other is that the asserts are happening
    inside a critical section.

    I don't think we can fix the first one easily but we can presumably
    assert in a smarter way. Do you want to try making a patch for this?

    -Pieter

    On Mon, Jan 21, 2013 at 6:23 PM, Pau <[email protected]
    <mailto:[email protected]>> wrote:
    >
    > Hi,
    >
    >
    > I am using (not yet in production) ZMQ on Windows and I have
    found what
    > I think is a big problem for Windows users.
    > We use WXP and W7 and Visual C++ different versions. ZMQ version
    3.2.0
    > (as far as I see the same problem happens in 3.2.2)
    >
    > I do not fully understand ZMQ internals but I've seen that every
    time a
    > socket is created the function make_fdpair(..) is called and in
    > signaler.cpp(line244) a system event "zmq-signaler-port-sync" is
    created.
    > This event is used as a system-wide critical section and, so all
    > applications that try to create an event will
    WaitForSingleObject (sync,
    > INFINITE) until  SetEvent (...) is called.
    > The problem is that the code between:
    >   HANDLE sync = CreateEvent (NULL, FALSE, TRUE, TEXT
    > ("zmq-signaler-port-sync"));
    > and
    > SetEvent (sync);
    > is full of wsa_asserts(..) that will terminate the application if
    > something goes wrong.
    >
    > It is clear that terminating the application not leaving the
    system-wide
    > critical section is a bad idea because all applications in the
    system
    > will hang and you will have to stop all them to start again.
    > I understand that no errors should happen but anyway to escape
    from the
    > error is not a good idea in this case.
    >
    > I do not know all possible reasons to generate a fatal
    wsa_assert(..)
    > but there is at least one:
    >
    > I have seen that in XP it is possible that line 301  rc =
    connect (*w_,
    > (sockaddr *) &addr, sizeof (addr)); returns an error when a
    socket tries
    > to connect to 5905 and this has happened many times.
    > Windows uses port numbers starting near 1400 and XP has a limit
    at 5000.
    > In W7 this does not look as a problem because maximum is 65000
    > It sounds as if the number was big enough but apart from the
    fact that
    > ZMQ uses a big number of connections (at least in my tests) I have
    > experienced that Windows jumps port numbers by 7, so 5000 happens
    > sometimes with catastrophic consequences.
    >
    > best,
    >
    > Pau Ceano
    > _______________________________________________
    > zeromq-dev mailing list
    > [email protected] <mailto:[email protected]>
    > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
    _______________________________________________
    zeromq-dev mailing list
    [email protected] <mailto:[email protected]>
    http://lists.zeromq.org/mailman/listinfo/zeromq-dev



_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to