Thanks Martin! Brian
On Tue, Jun 12, 2012 at 4:15 AM, Martin Hurton <[email protected]> wrote: > Should be fixed in 3ec8e576d99a332514a5338671a18413ce03ba98. > Thanks for reporting. > > - Martin > > On Mon, Jun 11, 2012 at 12:10 PM, Brian Knox <[email protected]> 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 <[email protected]> > wrote: > >> > >> I will look into it. Thanks! > >> > >> - Martin > >> > >> On Mon, Jun 11, 2012 at 2:23 AM, hp010170 <[email protected]> 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 <[email protected]> > >> >> 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 > >> >>> [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 > > > > > > > > _______________________________________________ > > 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 >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
