Bug 48608 - "Assertion 'b' failed at pulsecore/memblock.c:454, function pa_memblock_acquire()" when running anything that deals with sound levels
Summary: "Assertion 'b' failed at pulsecore/memblock.c:454, function pa_memblock_acqui...
Status: RESOLVED FIXED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: All All
: medium major
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-12 07:13 UTC by Sam Morris
Modified: 2014-12-19 13:29 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

Attachments

Description Sam Morris 2012-04-12 07:13:12 UTC 
I find that sometimes my system gets into a state where I can't run anything to do with adjusting volume levels without hitting this assertion. I can play sounds fine (e.g., with paplay) but running 'gnome-control-center sound' for instance causes the assertion.

I have seen this regularly for a log time, at least since before 1.0. I'm currently using 1.1 with Linux 3.2.0 on a VirtualBox virtual machine.

$ gdb src/pavucontrol
Reading symbols from /tmp/pavucontrol-0.99.2/src/pavucontrol...done.

(gdb) run
Starting program: /tmp/pavucontrol-0.99.2/src/pavucontrol 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Assertion 'b' failed at pulsecore/memblock.c:454, function pa_memblock_acquire(). Aborting.

Program received signal SIGABRT, Aborted.
0x00007ffff2e01475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.

(gdb) bt full
#0  0x00007ffff2e01475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
        pid = <optimized out>
        selftid = <optimized out>
#1  0x00007ffff2e046f0 in *__GI_abort () at abort.c:92
        act = {
          __sigaction_handler = {
            sa_handler = 0, 
            sa_sigaction = 0
          }, 
          sa_mask = {
            __val =               {3362584353597078016,
              140737488345760,
              10614784,
              140737488346056,
              140737488346040,
              140737267981216,
              140737353912320,
              7083248,
              4294967295,
              0,
              1,
              2498760,
              0,
              0,
              7083248,
              140737197969408}
          }, 
          sa_flags = -136403134, 
          sa_restorer = 0x1
        }
        sigs = {
          __val =             {32,
            0 <repeats 15 times>}
        }
#2  0x00007fffeeb3c6be in pa_memblock_acquire (b=<optimized out>) at pulsecore/memblock.c:454
No locals.
#3  pa_memblock_acquire (b=<optimized out>) at pulsecore/memblock.c:453
No locals.
#4  0x00007ffff3b3d203 in pa_stream_peek (s=0xa1f800, data=0x7fffffffdbc8, length=0x7fffffffdbb8) at pulse/stream.c:1600
        __func__ =           "pa_stream_peek"
        __PRETTY_FUNCTION__ =           "pa_stream_peek"
#5  0x00000000004242fd in read_callback (s=0xa1f800, length=4, userdata=0x8ed290) at mainwindow.cc:377
        w = 0x8ed290
        data = <optimized out>
        v = <optimized out>
        __PRETTY_FUNCTION__ =           "void read_callback(pa_stream*, size_t, void*)"
#6  0x00007ffff3b20da3 in pstream_memblock_callback (p=<optimized out>, channel=<optimized out>, offset=0, seek=PA_SEEK_RELATIVE, chunk=0x7fffffffdc60, userdata=0x82ff20) at pulse/context.c:365
        l = <optimized out>
        c = 0x82ff20
        s = 0xa1f800
        __func__ =           "pstream_memblock_callback"
        __PRETTY_FUNCTION__ =           "pstream_memblock_callback"
#7  0x00007fffeeb4811a in do_read (p=0x90b780) at pulsecore/pstream.c:844
        chunk = {
          memblock = 0x0, 
          index = 0, 
          length = 4
        }
        b = 0x0
        release_memblock = 0x0
        d = <optimized out>
        l = <optimized out>
        r = 16
#8  do_something (p=0x90b780) at pulsecore/pstream.c:177
        __func__ =           "do_something"
        __PRETTY_FUNCTION__ =           "do_something"
#9  0x00007ffff3d5cbc3 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse-mainloop-glib.so.0
No symbol table info available.
#10 0x00007ffff3faa79a in g_main_dispatch (context=0x6c14f0) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:2515
        dispatch = 0x7ffff3d5ca40
        was_in_call = 0
        user_data = 0x0
        callback = 0
        cb_funcs = 0x0
        cb_data = 0x0
        current_source_link = {
          data = 0x8fd700, 
          next = 0x0
        }
        need_destroy = <optimized out>
        source = 0x8fd700
        current = 0x90ed80
        i = <optimized out>
#11 g_main_context_dispatch (context=0x6c14f0) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:3052
No locals.
#12 0x00007ffff3faab60 in g_main_context_iterate (dispatch=1, block=<optimized out>, context=0x6c14f0, self=<optimized out>) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:3123
        timeout = 0
        some_ready = 1
        fds = <optimized out>
        max_priority = 110
        nfds = 4
        allocated_nfds = <optimized out>
#13 g_main_context_iterate (context=0x6c14f0, block=<optimized out>, dispatch=1, self=<optimized out>) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:3060
        some_ready = 1
#14 0x00007ffff3faaf5a in g_main_loop_run (loop=0x939c90) at /tmp/buildd/glib2.0-2.32.0/./glib/gmain.c:3317
        __PRETTY_FUNCTION__ =           "g_main_loop_run"
#15 0x00007ffff5d9e4bd in gtk_main () at /tmp/buildd/gtk+3.0-3.4.0/./gtk/gtkmain.c:1161
        loop = 0x939c90
#16 0x00007ffff7a31a26 in Gtk::Main::run (window=...) at main.cc:384
No locals.
#17 0x000000000040f0b6 in main (argc=1, argv=0x7fffffffe098) at pavucontrol.cc:670
        kit = {
          <sigc::trackable> = {
            callback_list_ = 0x8eda30
          }, 
          members of Gtk::Main: 
          _vptr.Main = 0x7ffff7d758b0, 
          static signal_key_snooper_ = {<No data fields>}, 
          static instance_ = 0x7fffffffdf10
        }
        mainWindow = 0x8ed290
        m = 0x8fd700
        options = {
          _vptr.OptionContext = 0x7ffff6d51f90, 
          gobject_ = 0x64d840, 
          has_ownership_ = true
        }
        group = {
          _vptr.OptionGroup = 0x7ffff6d52050, 
Python Exception <class 'gdb.error'> No type named std::_Rb_tree_node< std::pair< const Glib::ustring, Glib::OptionGroup::CppOptionEntry > >.: 
          map_entries_ = std::map with 1 elements, 
          gobject_ = 0x64d990, 
          has_ownership_ = false
        }
        entry = {
          _vptr.OptionEntry = 0x7ffff6d52010, 
          GOptionFlags = 4359654, 
          gobject_ = 0x64d8c0
        }
        __PRETTY_FUNCTION__ =           "int main(int, char**)"
Comment 1 Sam Morris 2012-05-02 09:22:33 UTC 
This seems to correlate with the 'pid' and 'dbus-socket' files going missing from the pulseaudio directory in /tmp.


$ cd $TMP
 
$ find pulse-*
pulse-fxXeyjndr5n9
pulse-fxXeyjndr5n9/native

$ pavucontrol 
Assertion 'b' failed at pulsecore/memblock.c:454, function pa_memblock_acquire(). Aborting.
Aborted

$ pulseaudio -k
E: [pulseaudio] main.c: Failed to kill daemon: No such process

$ kill 93621

$ pavucontrol

(at this point pulseaudio is re-launched and operates normally)

$ find pulse-*
pulse-fxXeyjndr5n9
pulse-fxXeyjndr5n9/native
pulse-fxXeyjndr5n9/dbus-socket
pulse-fxXeyjndr5n9/pid
Comment 2 Tanu Kaskinen 2012-05-02 09:54:35 UTC 
It seems that pa_stream_peek() doesn't take into account the possibility that there's a gap in s->record_memblockq. I'm not sure what would cause that gap, but the stack trace shows that there is a gap - there's no other explanation for s->peek_memchunk.memblock being NULL after a successful pa_memblockq_peek() call. The fix might be as simple as giving a silence memchunk to pa_memblockq_new() so that the gaps will be filled by silence, but maybe first it should be understood in which conditions record streams can have gaps - if there shouldn't be gaps at all, then the silence memchunk solution is only a workaround.


(In reply to comment #1)
> This seems to correlate with the 'pid' and 'dbus-socket' files going missing
> from the pulseaudio directory in /tmp.

That's peculiar. I don't know what that means. Especially the pid file disappearing sounds odd.

> $ cd $TMP
> 
> $ find pulse-*
> pulse-fxXeyjndr5n9
> pulse-fxXeyjndr5n9/native
> 
> $ pavucontrol 
> Assertion 'b' failed at pulsecore/memblock.c:454, function
> pa_memblock_acquire(). Aborting.
> Aborted
> 
> $ pulseaudio -k
> E: [pulseaudio] main.c: Failed to kill daemon: No such process
> 
> $ kill 93621

What's 93621?

> $ pavucontrol
> 
> (at this point pulseaudio is re-launched and operates normally)
> 
> $ find pulse-*
> pulse-fxXeyjndr5n9
> pulse-fxXeyjndr5n9/native
> pulse-fxXeyjndr5n9/dbus-socket
> pulse-fxXeyjndr5n9/pid
Comment 3 Sam Morris 2012-05-02 10:28:46 UTC 
(In reply to comment #2)
> It seems that pa_stream_peek() doesn't take into account the possibility that
> there's a gap in s->record_memblockq. I'm not sure what would cause that gap,
> but the stack trace shows that there is a gap - there's no other explanation
> for s->peek_memchunk.memblock being NULL after a successful pa_memblockq_peek()
> call. The fix might be as simple as giving a silence memchunk to
> pa_memblockq_new() so that the gaps will be filled by silence, but maybe first
> it should be understood in which conditions record streams can have gaps - if
> there shouldn't be gaps at all, then the silence memchunk solution is only a
> workaround.
> 
> 
> (In reply to comment #1)
> > This seems to correlate with the 'pid' and 'dbus-socket' files going missing
> > from the pulseaudio directory in /tmp.
> 
> That's peculiar. I don't know what that means. Especially the pid file
> disappearing sounds odd.

I suspect it's systemd's tmpfiles cleaning task going amok, though this is hard to confirm as the file only disappears every few days. I've added some debgug logging to the service and will report back if this appears to be the case.

> > $ kill 93621
> 
> What's 93621?

Sorry, that was the pulseaudio process.
Comment 4 Chris Wilson 2014-11-18 12:28:36 UTC 
This happened to me when a script remounted the ramdisk on /dev/shm (/run/shm on Ubuntu), thus hiding all the files in there, including the shared memory segment that PulseAudio processes use to communicate.
Comment 5 Tanu Kaskinen 2014-12-19 13:29:35 UTC 
I believe this crash has been fixed since 3.0 by this commit: http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=dfd44036b54d65314664622ff93dfd18eee03c7b

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.