Created attachment 115203 [details]
Thread stack trace

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

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.

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

Marking as a release blocker.

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?

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.

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.

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.

(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) {

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

Seems to work just as nicely. Thanks.

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.