[zeromq-dev] zmq::signaler_t::make_fdpair hangs application on crash

[Felipe Farinon]

Windows 8, ZeroMQ 3.2.2. I think that the problem is that the 
application is running in a test environment that doesn't close it 
graceously, instead it just terminates the application which leaves the 
possibility for that event to hang around. I have not tested with libzmq 
master, I have just fixed it myself using the mutex and the problem has 
gone away.

Sure, I can submit the change mutex + port change myself.

Em 13/11/2013 11:11, KIU Shueng Chuan escreveu:
>
> Which versions of Windows and ZeroMQ does it happen on? Does your 
> application open and close lots of ZeroMQ sockets? How about with 
> libzmq master?
>
> Actually you could submit the change to mutex and port yourself?
>
> On Nov 13, 2013 3:02 AM, "Felipe Farinon" 
> <felipe.farinon at powersyslab.com 
> <mailto:felipe.farinon at powersyslab.com>> wrote:
>
>     My application is hanging frequently in one co-worker's machine.
>     Whenever I diagnose the machine, I see the event still set with no
>     application running. I'm afraid that when the application ships
>     the bug happens much more.
>
>     We wouldn't be taking "one more port", just changingthe old one.
>
>     Em 12/11/2013 10:52, KIU Shueng Chuan escreveu:
>>     I thought of the same thing before, port 5906 too. But I don't
>>     feel comfortable taking up one more port without some consensus.
>>     Maybe if there were more people reporting that their ZeroMQ
>>     applications (with heavy socket creation!) were hanging on
>>     Windows...
>>
>>     For now, I have modified signaler.cpp to not assert within the
>>     "critical section".
>>     https://github.com/zeromq/libzmq/commit/4a7f07a19ae226fe92c3c7320bd425f9a18d0c79
>>
>>
>>     On Mon, Nov 11, 2013 at 11:16 PM, Felipe Farinon
>>     <felipe.farinon at powersyslab.com
>>     <mailto:felipe.farinon at powersyslab.com>> wrote:
>>
>>         Maybe we could change signaler_port to another value and
>>         define that port 5905 is protected by the Event and the new
>>         port (e.g. 5906) is protected by Mutex. This way we don't
>>         need to check if the Event is present.
>>
>>         Em 11/11/2013 11:16, Felipe Farinon escreveu:
>>>         Ok.
>>>
>>>         Seems reasonable to me and I think that a 4 seconds timeout
>>>         is fine. The only scenario where I could imagine that this
>>>         would break is if some heavy socket creation is going on and
>>>         IFF the WaitForSingleObject wakeup order for Events is not FIFO.
>>>
>>>         Em 11/11/2013 11:02, KIU Shueng Chuan escreveu:
>>>>
>>>>         Realistically, I think only bind, accept and connect have a
>>>>         chance of failing. The rest of the asserts just test for
>>>>         programming errors. Accept and connect are already handled.
>>>>         What's left is handling bind error.
>>>>
>>>>
>>>>
>>>>         _______________________________________________
>>>>         zeromq-dev mailing list
>>>>         zeromq-dev at lists.zeromq.org  <mailto:zeromq-dev at lists.zeromq.org>
>>>>         http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>>>
>>>         _______________________________________________
>>>         zeromq-dev mailing list
>>>         zeromq-dev at lists.zeromq.org  <mailto:zeromq-dev at lists.zeromq.org>
>>>         http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>>         _______________________________________________
>>         zeromq-dev mailing list
>>         zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
>>         http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>>
>>
>>     _______________________________________________
>>     zeromq-dev mailing list
>>     zeromq-dev at lists.zeromq.org  <mailto:zeromq-dev at lists.zeromq.org>
>>     http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>     _______________________________________________
>     zeromq-dev mailing list
>     zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
>     http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131118/019fa02b/attachment.htm>