[zeromq-dev] Pub/sub, inproc shutdown Assert failure

[Brian Knox]

Thanks Martin!

Brian

On Tue, Jun 12, 2012 at 4:15 AM, Martin Hurton <hurtonm at gmail.com> wrote:

> Should be fixed in 3ec8e576d99a332514a5338671a18413ce03ba98.
> Thanks for reporting.
>
> - Martin
>
> On Mon, Jun 11, 2012 at 12:10 PM, Brian Knox <briank at talksum.com> wrote:
> > Just a heads up that I reported test_shutdown_stress segfaulting
> recently on
> > the list as well, so +1
> >
> >
> > On Mon, Jun 11, 2012 at 2:52 AM, Martin Hurton <hurtonm at gmail.com>
> wrote:
> >>
> >> I will look into it. Thanks!
> >>
> >> - Martin
> >>
> >> On Mon, Jun 11, 2012 at 2:23 AM, hp010170 <hp010170 at gmail.com> wrote:
> >> > Marc, Martin:
> >> >
> >> > I am not sure if this is related, however, I have observed that:
> >> >
> >> > 1. tests/test_shutdown_stress.cpp seg-faults on seemingly random runs
> >> > 2. test_shutdown_stress uses PUB/SUB
> >> > 3. test_shutdown_stress does uses tcp:// instead of inproc://
> >> >
> >> > To illustrate:
> >> >
> >> > --x--x--
> >> > hp $ for i in {1..20}; do ./tests/test_shutdown_stress; done
> >> > test_shutdown_stress running...
> >> > Segmentation fault
> >> > test_shutdown_stress running...
> >> > Segmentation fault
> >> > test_shutdown_stress running...
> >> > test_shutdown_stress running...
> >> > Segmentation fault
> >> > test_shutdown_stress running...
> >> > test_shutdown_stress running...
> >> > test_shutdown_stress running...
> >> > test_shutdown_stress running...
> >> > test_shutdown_stress running...
> >> > Segmentation fault
> >> > test_shutdown_stress running...
> >> > test_shutdown_stress running...
> >> > test_shutdown_stress running...
> >> > test_shutdown_stress running...
> >> > test_shutdown_stress running...
> >> > Segmentation fault
> >> > test_shutdown_stress running...
> >> > Segmentation fault
> >> > test_shutdown_stress running...
> >> > Segmentation fault
> >> > test_shutdown_stress running...
> >> > Segmentation fault
> >> > test_shutdown_stress running...
> >> > test_shutdown_stress running...
> >> > test_shutdown_stress running...
> >> > Segmentation fault
> >> > --x--x--
> >> >
> >> > As you can see, I am not able to make out a pattern from a precursory
> >> > glance.  I haven't plugged in the debugging tools yet, this was just
> >> > from regularly building the code, I noticed the issue.
> >> >
> >> > The above is from the latest libzmq in the repository.
> >> >
> >> > Let me know if I can provide any more information.
> >> >
> >> > -HP
> >> >
> >> > On 10/06/2012 18:39, Martin Hurton wrote:
> >> >> Hi Marc,
> >> >>
> >> >> 1) could you create an issue
> >> >> 2) could you put together minimal C program reproducing this bug and
> >> >> make pull request so it finds its way into issues repo
> >> >>
> >> >> Thanks, martin
> >> >>
> >> >> On Sat, Jun 9, 2012 at 9:19 PM, Marc Criley <mcriley.1979 at gmail.com>
> >> >> wrote:
> >> >>> I'm getting:
> >> >>>
> >> >>> Assertion failed: ok (mailbox.cpp:79)
> >> >>>
> >> >>> when trying to shut down my application. After having searched the
> >> >>> archives
> >> >>> and whitepapers I'm still at a loss. Here's the structure of what I
> >> >>> have and
> >> >>> am trying to do (version 2.1.9-1, distributed with Ubuntu):
> >> >>>
> >> >>> - One main thread establishes a PUB socket using the 'inproc'
> >> >>> transport.
> >> >>> - Four separate threads each open a SUB socket.
> >> >>> - 'inproc' requires the pub and sub sockets to use the same context,
> >> >>> so that
> >> >>> is done.
> >> >>> - Each subscriber socket waits on 'recv()' for something to arrive,
> >> >>> which is
> >> >>> then processed, and returns back to waiting for the next message.
> >> >>>
> >> >>> Everything runs fine in the application. However, at shutdown:
> >> >>>
> >> >>> - There is no pending traffic, it has all been cleared.
> >> >>> - The main thread closes its PUB socket.
> >> >>> - The main thread invokes zmq_term, which blocks.
> >> >>> - This unblocks the four subscriber threads waiting on recv().
> >> >>> - Each subscriber thread closes its socket and the thread
> terminates.
> >> >>>
> >> >>> At this point I expect the main thread call of zmq_term() to
> complete.
> >> >>> That's not what happens, instead I get:
> >> >>>
> >> >>> Assertion failed: ok (mailbox.cpp:79)
> >> >>>
> >> >>> I believe I did this in accordance with the 0MQ Termination
> whitepaper
> >> >>> (http://www.zeromq.org/whitepapers:0mq-termination), and this is
> the
> >> >>> sequence I use to shutdown a tcp transport client thread, which
> works
> >> >>> without problem.
> >> >>>
> >> >>> Deferring closing the PUB socket until after zmq_term doesn't work,
> as
> >> >>> zmq_term blocks until the socket is closed.
> >> >>>
> >> >>> Any suggestions would be appreciated.
> >> >>>
> >> >>> Marc C
> >> >>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> 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
> >> _______________________________________________
> >> 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
> >
> _______________________________________________
> 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/20120612/47c7748f/attachment.htm>