Bug 102549

Sounds bad, but I can't reproduce this. Can you attach the full debug log? It seems that you already know how to run pulseaudio in a terminal, so I don't have to explain that. Just pass "-vv" on the command line to get debug logging (if you're not already doing that).

Please use the "Add an attachment" link. (Sometimes people paste long logs to the comment box, which makes it hard to read the discussion.)

How did you install the new pulseaudio version? Is it already packaged for Debian, or did you build from source?

Created attachment 133991 [details]
pulseaudio -vv >pulse11-ladspa.log 2>&1

I compiled pulseaudio by hand as I always do because I try to avoid from systemd, avahi and bluetooth. (gcc version 7.2.0)
I have 2 soundcards as you can see: one internal and one external on usb.

default.pa contains:
load-module module-ladspa-sink sink_name=ladspa_output.fast_lookahead_limiter master=@DEFAULT_SINK@ plugin=fast_lookahead_limiter_1913 label=fastLookaheadLimiter control=14,-15,0.8
load-module module-ladspa-sink sink_name=ladspa_output.dyson_compress_1403.dysonCompress master=ladspa_output.fast_lookahead_limiter plugin=dyson_compress_1403 label=dysonCompress  control=0,0.25,0.5,0.5

Created attachment 133994 [details] [review]
0001-sink-add-more-logging.patch

I tried with a USB sound card and with those same lines in default.pa, but I still can't reproduce. I didn't find anything interesting in the log either.

I attached a patch that adds a bit more logging regarding the sink states (since the crashes were caused by some sink being in a wrong state).

Could you apply the patch and attach a new log? Also, a backtrace from gdb would be helpful. Instructions:

1) gdb --args pulseaudio -vv

2) When the gdb prompt appears, enter "run".

3) When the crash happens, enter "thread apply all bt".

4) You can exit gdb by entering "quit".

Created attachment 134010 [details]
pulse11-gdb.log

Here you are. The same effect. :-/

(I've used screen to catch all the output.)

Thanks! I found out what change introduced this problem, but I don't know yet how it should be fixed. I'll look into this tomorrow.

As a workaround, you can put "flat-volumes = no" to ~/.config/pulse/daemon.conf.

I had flat volumes disabled, which is why I failed to reproduce the problem at first. With flat volumes enabled the crash happens when loading any filter sink.

Created attachment 134128 [details]
GDB log of PA crash on a different system than OP

I do not think this is only 'medium' severity. I updated my system and on login pulseaudio went into an infinite startup-crash loop that ate lots of system resources as well as creating a gigabyte worth of coredumps before I could stop it.

Running Arch Linux, which shipped version 11.0. Included a GDB session as per the instructions which looks a bit different to the other one. Hope it is helpful.

(In reply to Johannes Jordan from comment #7)

> I do not think this is only 'medium' severity.

Yeah I agree, this is a pretty horrible regression. If you're referring to the "Importance" field though, that doesn't have any real effect in our process, so don't worry about that. I now bumped the "Importance" nevertheless.

I have a patch available now.

Created attachment 134139 [details] [review]
0001-sink-source-don-t-try-to-update-volumes-of-not-yet-l.patch

Okie, 0001-sink-source-don-t-try-to-update-volumes-of-not-yet-l.patch fixed the crash problem, at least for me.

I confirm, the bug is real, fortunately `flat-volumes = no` fixes the startup crash. This system has no ladspa module configured. Attached patched seems to make a move in the right direction.

This has been fixed in PulseAudio 11.1.