[pulseaudio-discuss] Trying to debug segfault in pa_mainloop_dispatch().

[Tanu Kaskinen]

On Fri, 2017-07-28 at 10:30 -0700, Rich Eakin wrote:
> I also wanted to ask about the logging - is it enough to export the symbols
> I'm finding at
> https://freedesktop.org/software/pulseaudio/doxygen/index.html#logging_sec
> before running my application, or do I also need to restart the pulseaudio
> deamon with something like '--log-target=syslog'? Right now I'm doing both
> and seeing some output, though I don't know which part is required, or both.

The client side logging is independent from the server side logging.
You only need to set the PULSE_LOG environment variable to control the
client logging verbosity.

> On Fri, Jul 28, 2017 at 9:50 AM, Rich Eakin <rtepub at gmail.com> wrote:
> 
> > Hi,
> > 
> > We have adopted use of the pulseaudio library in the framework I work on
> > (libcinder) and we are just beginning to do production work with it. I've
> > hit a snag however, and I'm searching for ways to debug. Very occasionally
> > (less than twice a day), I'm seeing the application segfault with the
> > following backtrace on the audio thread:
> > 
> > ```
> > #0  0x00007ffff61451c9 in pa_mainloop_dispatch () from
> > /usr/lib/x86_64-linux-gnu/libpulse.so.0
> > #1  0x00007ffff61454bc in pa_mainloop_iterate () from
> > /usr/lib/x86_64-linux-gnu/libpulse.so.0
> > #2  0x00007ffff6145560 in pa_mainloop_run () from
> > /usr/lib/x86_64-linux-gnu/libpulse.so.0
> > #3  0x00007ffff61537a9 in ?? () from /usr/lib/x86_64-linux-gnu/
> > libpulse.so.0
> > #4  0x00007ffff0ef0078 in ?? () from /usr/lib/x86_64-linux-gnu/pulseaudio/
> > libpulsecommon-8.0.so
> > #5  0x00007ffff58416ba in start_thread () from /lib/x86_64-linux-gnu/
> > libpthread.so.0
> > #6  0x00007ffff4cd63dd in clone () from /lib/x86_64-linux-gnu/libc.so.6
> > ```
> > 
> > I haven't been able to track down if we're doing something wrong from the
> > client side yet, though I was wondering if there is a way to turn on some
> > sort of verbosity to track this sort of thing,

No, I don't think the mainloop will log anything even with maximum
verbosity.

> > or it sticks out to some
> > folks as far as some things I can check?

Crashes in the mainloop are usually due to accessing the mainloop from
multiple threads without proper locking. At least the open() methods
look like they don't lock the mainloop when they should.

-- 
Tanu

https://www.patreon.com/tanuk