Bug 90108 - Multiple pulseaudio crashes.
Summary: Multiple pulseaudio crashes.
Status: RESOLVED FIXED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-20 00:34 UTC by Luke Yelavich
Modified: 2015-09-07 13:03 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Thread stack trace (18.63 KB, text/plain)
2015-04-20 00:34 UTC, Luke Yelavich
Details
Thread stack trace (1.45 KB, text/plain)
2015-04-20 00:35 UTC, Luke Yelavich
Details
Write warning patch (696 bytes, patch)
2015-05-21 13:05 UTC, David Henningsson
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Yelavich 2015-04-20 00:34:19 UTC
Created attachment 115202 [details]
Thread stack trace

Multiple crashes have been reported in Ubuntu Vivid, pulseaudio version 6.0.

Original bug report locations:
https://bugs.launchpad.net/bugs/1442506
https://bugs.launchpad.net/bugs/1425447

Thread stack traces are attached.
Comment 1 Luke Yelavich 2015-04-20 00:35:59 UTC
Created attachment 115203 [details]
Thread stack trace
Comment 2 Raymond 2015-04-20 01:58:00 UTC
any steps to reproduce seem null sink was involved?

0x00007f91ca5afd39 in thread_func (userdata=0x96b4a0) at modules/module-null-sink.c:227


udev-detect fail to load any sink when language is Greek

https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1445358
Comment 3 Luke Yelavich 2015-04-20 04:04:36 UTC
errors.ubuntu.com, which is where these crashes are from, is used to capture crashes, and when enough people report a crash, it is then reported to launchpad as a bug, as you can see with the launchpad bug reports that I linked to.
Comment 4 Raymond 2015-04-20 05:09:13 UTC
this url is private

https://errors.ubuntu.com/problem/*

and your two launchpad reports do not have pulseaudio verbose log or JournalErrors.txt 

only pulselist show default sink is auto-null , this mean that there is no alsa-sink loaded
Comment 5 Tanu Kaskinen 2015-04-29 15:43:30 UTC
Marking as a release blocker.
Comment 6 David Henningsson 2015-05-21 13:03:58 UTC
So I've been trying to figure out what's causing modules to reload again, but it's difficult without having a verbose log.

It's quite high on errors.ubuntu.com and there are also fedora bugs ( https://bugzilla.redhat.com/show_bug.cgi?id=1012141 ) so it feels wrong to drop it.
Anyone who can reproduce it with logging on?
Comment 7 David Henningsson 2015-05-21 13:05:36 UTC
Created attachment 115946 [details] [review]
Write warning patch

If we can't figure out what it is, we could at least add a warning about what modules are reloading themselves, see attached patch.
Comment 8 David Henningsson 2015-06-18 09:09:45 UTC
Hi Luke,

As you see we're having difficulties getting someone who can reproduce this crash and can help us out further with finding the root cause.

The best we can do at this point is to add a warning (which I just committed as http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=8f12ef901c183454eecce2faefd759f040e738fd ) and hopefully that would make the problem more visible.

Unmarking as release blocker for upstream PulseAudio 7.0.
Comment 9 Pierre Ossman 2015-09-02 09:05:19 UTC
I think I'm hitting this, and I've found out why.

What happens is this:

 1. module-always-sink is loaded
 2. it pulls in module-sink
 3. pulseaudio is shut down
 4. pa_module_unload_all() is called
 5. module-always-sink is unloaded
 6. it requests an unload of the module-sink it loaded
 7. pa_module_unload_all() proceeds to unload module-sink
 8. pa_core_free() is called
 9. an assert is triggered as the request in 6. was never handled

A quick fix is to clear out core->modules_pending_unload in pa_module_free() as well.


A note is that module-always-sink tries to check if the core is shutting down. However, checking for PA_CORE_SHUTDOWN seems highly suspect as that state is entered at a point where are cleanup is already done and the core object is about to be freed. In other words, if it is safe to dereference core->state, then state cannot be PA_CORE_SHUTDOWN. So all of commit 967c17a1 could be pointless.
Comment 10 Pierre Ossman 2015-09-02 09:11:55 UTC
(In reply to Pierre Ossman from comment #9)
> 
> A quick fix is to clear out core->modules_pending_unload in pa_module_free()
> as well.
> 

Actually, it's probably better here where we destroy the defer event that's supposed to do the unloading:

Index: src/pulsecore/module.c
===================================================================
--- src/pulsecore/module.c      (revision 30726)
+++ src/pulsecore/module.c      (working copy)
@@ -300,6 +300,7 @@
         c->mainloop->defer_free(c->module_defer_unload_event);
         c->module_defer_unload_event = NULL;
     }
+    pa_hashmap_remove_all(c->modules_pending_unload);
 }
 
 static void defer_cb(pa_mainloop_api*api, pa_defer_event *e, void *userdata) {
Comment 11 David Henningsson 2015-09-03 07:44:56 UTC
Hi Pierre and thanks for looking into this bug!

I don't really follow what's happening on your side and I can't reproduce it either, but I found something that might be related to your bug.

Could you (and others affected by this bug) check if this patch resolves the problem?

http://lists.freedesktop.org/archives/pulseaudio-discuss/2015-September/024324.html
Comment 12 Pierre Ossman 2015-09-04 11:56:17 UTC
Seems to work just as nicely. Thanks.
Comment 13 David Henningsson 2015-09-07 13:03:28 UTC
Ok, thanks for testing!

I've pushed the patch now (after changing an idxset to a hashmap, ahem). Let's hope that's what resolves this bug.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.