Hi, I'm experiencing a strange sort of a race condition or a stale semaphore when using threaded mainloops excessively. It's somehow tricky to debug as it might take hunderts of iterations to trigger. I wrote a little test that might help hunt this issue. What it does is: it continuously creates new threaded mainloops, connects to the local PulseAudio server instance, creates some streams and starts them. Asynchronously, from the main thread, it tears down the streams, the context and the mainloop and starts over again, all based on random timing. After a while, the server refuses new connections and hangs, and its backtrace reads as follows: #0 0x00007fff86d912ee in semaphore_timedwait_trap () #1 0x00007fff80f831de in MPWaitOnSemaphore () #2 0x00000001001a5ca3 in pa_semaphore_wait (s=0x10081b4b0) at pulsecore/semaphore-osx.c:61 #3 0x000000010001fd9b in pa_asyncmsgq_send (a=0x100c295c0, object=0x101861400, code=11, userdata=0x1, offset=0, chunk=0x0) at pulsecore/asyncmsgq.c:169 #4 0x000000010005dc5e in sink_set_state (s=0x101861400, state=PA_SINK_IDLE) at pulsecore/sink.c:415 #5 0x000000010005f58c in pa_sink_update_status (s=0x101861400) at pulsecore/sink.c:672 #6 0x00000001000557db in pa_sink_input_unlink (i=0x101886e00) at pulsecore/sink-input.c:540 #7 0x0000000100bb38e5 in playback_stream_unlink (s=0x100c33ac0) at pulsecore/protocol-native.c:731 #8 0x0000000100bb5432 in native_connection_unlink (c=0x10081b4d0) at pulsecore/protocol-native.c:1241 #9 0x0000000100bc10ef in pstream_die_callback (p=0x10081c3f0, userdata=0x10081b4d0) at pulsecore/protocol-native.c:4537 #10 0x0000000100190de6 in do_something (p=0x10081c3f0) at pulsecore/pstream.c:196 #11 0x0000000100190f64 in io_callback (io=0x100c2f770, userdata=0x10081c3f0) at pulsecore/pstream.c:209 #12 0x0000000100179999 in callback (m=0x100809be8, e=0x100c31700, fd=9, f=PA_IO_EVENT_HANGUP, userdata=0x100c2f770) at pulsecore/iochannel.c:161 #13 0x0000000100112642 in dispatch_pollfds (m=0x100809b90) at pulse/mainloop.c:681 #14 0x00000001001133e0 in pa_mainloop_dispatch (m=0x100809b90) at pulse/mainloop.c:931 #15 0x000000010011355e in pa_mainloop_iterate (m=0x100809b90, block=1, retval=0x7fff5fbff614) at pulse/mainloop.c:962 #16 0x00000001001135ba in pa_mainloop_run (m=0x100809b90, retval=0x7fff5fbff614) at pulse/mainloop.c:977 #17 0x0000000100010336 in main (argc=5, argv=0x7fff5fbff768) at daemon/main.c:1135 #18 0x000000010000695c in start () I'm on Mac OS X, so it could be a platform specific issue, but maybe more test coverage shows the problem on other platforms as well. I also exchanged the semaphore implementation for an alternative, but that didn't help. Attached is a patch to add the test to the tree. Am I doing anything wrong? Thanks for trying this test on your machines and for sharing your ideas :) Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-tests-add-a-connection-stress-test.patch Type: application/octet-stream Size: 7064 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110331/3a1b8753/attachment.obj>
