[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