PulseAudio thread dies, causes segfault #4

jussi-kalliokoski opened this Issue May 21, 2012 · 3 comments


None yet

2 participants


This is possibly the same problem as 756944. The Pulse Audio thread dies of seemingly stuff blocking for too long in the main thread. This bug has come up in my (slow) attempt to create node-cubeb. I've attached a stacktrace for gdb node here just in case my assumptions are wrong:

(gdb) run tests/sine-tone.js 
Starting program: /usr/bin/node tests/sine-tone.js
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0x7ffff637a700 (LWP 6958)]
Creating a context...
[New Thread 0x7fffef461700 (LWP 6959)]
Asserting context properties...
Creating a stream...
[New Thread 0x7fffeec60700 (LWP 6960)]
Asserting stream properties...
Starting stream...
Stopping stream after 4000 ms
Data callback: 11069
State changed 0
Data callback: 5520
Data callback: 5520
Data callback: 5520
Data callback: 5520
Data callback: 5520
Data callback: 5520
[Thread 0x7fffef461700 (LWP 6959) exited]
Stopping stream...

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff50fa159 in pa_thread_is_running () from /usr/lib/libpulsecommon-1.1.so
(gdb) bac
#0  0x00007ffff50fa159 in pa_thread_is_running () from /usr/lib/libpulsecommon-1.1.so
#1  0x00007ffff5552873 in pa_threaded_mainloop_lock () from /usr/lib/libpulse.so.0
#2  0x00007ffff576bb96 in stream_cork (stm=0xc90840, state=3) at src/cubeb_pulse.c:175
#3  0x00007ffff576c221 in cubeb_stream_stop (stm=0xc90840) at src/cubeb_pulse.c:355
#4  0x00007ffff5974e78 in CubebStream::stop (this=0xc907c0) at ../src/stream.cpp:63
#5  0x00007ffff5975db5 in CubebStream::Stop (args=...) at ../src/stream.cpp:168
#6  0x000000000059b34d in ?? ()
#7  0x00001aa40daf414e in ?? ()
#8  0x00001aa40daf40c1 in ?? ()
#9  0x00007fffffffdf10 in ?? ()
#10 0x00007fffffffdf50 in ?? ()
#11 0x00001aa40db66668 in ?? ()
#12 0x00002ca629ab69d9 in ?? ()
#13 0x00002ca629ab5659 in ?? ()
#14 0x00000b75abed4b19 in ?? ()
#15 0x00000b75abf050f9 in ?? ()
#16 0x00007fffffffdfb8 in ?? ()
#17 0x00001aa40db95d2f in ?? ()
#18 0x00002ca629ac7171 in ?? ()
#19 0x00007fffffffe040 in ?? ()
#20 0x00002ca629ac5b51 in ?? ()
#21 0x00007fffffffdfb8 in ?? ()
#22 0x0000000000000001 in ?? ()
#23 0x00001aa40db95c38 in ?? ()
#24 0x00000fa000000000 in ?? ()
#25 0x00002fa8dc005251 in ?? ()
#26 0x00002ca629ac7171 in ?? ()
#27 0x00000b75abf03459 in ?? ()
#28 0x00002ca629ac5b51 in ?? ()
#29 0x00007fffffffdfe8 in ?? ()
#30 0x00001aa40daf540e in ?? ()
#31 0x00002ca629ac7291 in ?? ()
#32 0x0000000100000000 in ?? ()
#33 0x00000b75abf03459 in ?? ()
#34 0x0000000800000000 in ?? ()
#35 0x00007fffffffe028 in ?? ()
#36 0x00001aa40db0fea1 in ?? ()
#37 0x0000000000000000 in ?? ()

The test case is written in JS and whenever I do something blocking for a long time in the JS, the data callbacks stop occuring like this. I can give you the latest version of my test case if that's any help, but I doubt it as its merely blocking and not even communicating back to the cubeb instance for now.

Oh yeah, sorry for reporting it here, I wasn't sure where to report it.


This is a good place to report it, thanks! The bug you linked to is about importing ALSA, so I assume you meant one of the comments in bug 751030 or bug 752401. I think this looks like a different issue.

What version of PulseAudio are you running (and on what distribution)?

Can you post the result of printing stm in gdb in frame 2? Alternatively, if setting up and reproducing this is fairly simple, I can take a look if you point me at some instructions.


Sorry, I forgot about this completely! Anyway the problem seems to have disappeared.


Jussi and I solved this via email, but to close the loop in the bug tracker:

What's happening is that the cubeb context is destroyed (presumably by the GC when reaching the end of the test), but since the timer keeps the stream alive, cubeb_stream_stop is called on a live stream with a destroyed context.

As a hack to confirm my theory, I added "ctx.foo();" to the timer callback in the test (so now the timer holds a reference to the context), and the test now runs correctly, with the callback firing multiple times until the timer expires after 4s... at which point there's an exception caused by the context having no 'foo' method.

One way to fix this correctly would be to make any stream created from a given context hold an internal reference to that context.

I've been meaning to add an assert to cubeb_destroy that fires if there are still streams live, since it would make bugs in like this easier for API users to find.

@kinetiknz kinetiknz added a commit that referenced this issue Sep 28, 2016
@kinetiknz Travis retry #4. e0e010d
@kinetiknz kinetiknz added a commit that referenced this issue Sep 29, 2016
@kinetiknz Travis retry #4. cef8e36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment