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

Felipe Farinon felipe.farinon at powersyslab.com
Mon Nov 18 13:59:41 CET 2013


Sorry: Windows 7.

Em 18/11/2013 10:58, Felipe Farinon escreveu:
> 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
>
>
>
> _______________________________________________
> 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/29059f86/attachment.htm>


More information about the zeromq-dev mailing list