[pulseaudio-discuss] Pulseaudio threading debug output.

[Maarten Bosmans]

2011/9/9 Dan <dan at h4.cx>:
> Hello all,
>
> For the past few days I have been working with mkbosmans and coling in
> #sourcemage trying to determine what exactly is wrong with my pulseaudio
> setup. The issue seems to be a problem with PA hanging once my sink thread
> starts up. Everything looks seemingly normal in PA's output but I am unable
> to connect to the PA server when I have a sink.
>
> [snip]
> (gdb) thread apply all bt
>
> Thread 2 (Thread 0x7fffed954700 (LWP 22201)):
> #0  0x00007ffff2a9e578 in ppoll () from /lib/libc.so.6
> #1  0x00007ffff7b81a19 in pa_rtpoll_run (p=0x652f40, wait_op=true) at
> pulsecore/rtpoll.c:314
> #2  0x00007fffed956d0f in thread_func (userdata=0x654f70) at
> modules/module-null-sink.c:233
> #3  0x00007ffff700f638 in internal_thread_func (userdata=0x657860) at
> pulsecore/thread-posix.c:83
> #4  0x00007ffff35d0e1c in start_thread () from /lib/libpthread.so.0
> #5  0x00007ffff2aa6fdd in clone () from /lib/libc.so.6
>
> Thread 1 (Thread 0x7ffff7fd7760 (LWP 22198)):
> #0  0x00007ffff35d84dd in pause () from /lib/libpthread.so.0
> #1  0x00007ffff59d1689 in sem_wait () from /usr/lib/libpthread-stubs.so.0
> #2  0x00007ffff700f898 in pa_semaphore_wait (s=0x6582f0) at
> pulsecore/semaphore-posix.c:63
> #3  0x00007ffff7b65ffa in pa_asyncmsgq_send (a=0x64e4b0, object=<optimized
> out>, code=<optimized out>, userdata=<optimized out>, offset=<optimized
> out>, chunk=<optimized out>) at pulsecore/asyncmsgq.c:167
> #4  0x00007ffff7b937a3 in sink_set_state (s=0x658720, state=PA_SINK_IDLE) at
> pulsecore/sink.c:420
> #5  0x00007ffff7b95327 in pa_sink_put (s=0x658720) at pulsecore/sink.c:653
> #6  0x00007fffed957690 in module_null_sink_LTX_pa__init (m=0x654f10) at
> modules/module-null-sink.c:318
> #7  0x00007ffff7b79238 in pa_module_load (c=0x643920, name=0x63d510
> "module-null-sink", argument=0x0) at pulsecore/module.c:109
> #8  0x00007ffff7b6d6dd in pa_cli_command_load (c=0x643920, t=0x63c5c0,
> buf=0x63b8d0, fail=<optimized out>) at pulsecore/cli-command.c:429
> #9  0x00007ffff7b6eefe in pa_cli_command_execute_line_stateful (c=0x643920,
> s=<optimized out>, buf=0x63b8d0, fail=0x63ac05, ifstate=<optimized out>) at
> pulsecore/cli-command.c:1833
> #10 0x00007ffff7b6f4d4 in pa_cli_command_execute_file_stream (c=0x643920,
> f=0x648d20, buf=0x63b8d0, fail=0x63ac05) at pulsecore/cli-command.c:1873
> #11 0x0000000000407774 in main (argc=<optimized out>, argv=<optimized out>)
> at daemon/main.c:1074

This reminds me of a couple of weeks back when I put pulse through
valgrind's thread error detector helgrind. There were lot's of
warnings like:

Possible data race during read of size 4 at 0xbec020d8 by thread #2
   at 0x403DBE2: pa_asyncmsgq_done (asyncmsgq.c:215)
   by 0x4062C52: asyncmsgq_read_work (rtpoll.c:565)
   by 0x40618A1: pa_rtpoll_run (rtpoll.c:238)
   by 0x41B2EC8: thread_func (module-null-sink.c:233)
   by 0x412B69C: internal_thread_func (thread-posix.c:83)
   by 0x4026F60: mythread_wrapper (hg_intercepts.c:221)
   by 0x420CE98: start_thread (pthread_create.c:304)
   by 0x42F473D: clone (clone.S:130)
 This conflicts with a previous write of size 4 by thread #1
   at 0x403D75B: pa_asyncmsgq_send (asyncmsgq.c:157)
   by 0x407DB5D: sink_set_state (sink.c:420)
   by 0x407EEB3: pa_sink_put (sink.c:653)
   by 0x41B344C: module_null_sink_LTX_pa__init (module-null-sink.c:318)
   by 0x4056A06: pa_module_load (module.c:109)
   by 0x4041B7A: pa_cli_command_load (cli-command.c:429)
   by 0x4048305: pa_cli_command_execute_line_stateful (cli-command.c:1833)
   by 0x40485D0: pa_cli_command_execute_file_stream (cli-command.c:1873)
 Location 0xbec020d8 is 0 bytes inside i.semaphore,
 declared at asyncmsgq.c:142, in frame #3 of thread 1

Which I ignored at the time, because surely our threading primitives
couldn't be wrong, could they?

I'm not sure whether it could be the same issue you're seeing, or that
both stack traces just coincedentally include pa_asyncmsgq and
pa_rtpoll. Perhaps someone else can shed a better light on this
matter.

Maarten