Ticket #800 (new defect)

Opened 5 months ago

Last modified 5 months ago

module-null-sink aborting with fdsem.c: Assertion 'pa_atomic_dec(&f->data->waiting) >= 1' failed at pulsecore/fdsem.c:283, function pa_fdsem_before_poll()

Reported by: maginot Owned by: lennart
Milestone: Component: module-null-*
Keywords: module-always-sink module-null-sink module-alsa-sink assertion lib atomic atomic_ops Cc:

Description

Since no solution was proposed and every requirement seens to be ok I'm creating a new ticket to the problem related to loading pulseaudio with module-always-sink and module-alsa-sink which seen to use module-null-sink and crashing at this point.

the full strace log is attached

Link to the thread of the problem: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-March/006776.html

Attachments

55.log (156.9 kB) - added by maginot 5 months ago.
Strace of pulseaudio -vvvv
pulseaudio_gdb (2.8 kB) - added by maginot 5 months ago.
Last debug
config-log-pulseaudio.txt (17.2 kB) - added by maginot 4 months ago.

Change History

Changed 5 months ago by maginot

Strace of pulseaudio -vvvv

Changed 5 months ago by coling

Can you please also attach a backtrace of the problem? Many thanks.

http://pulseaudio.org/wiki/Community#BugsPatchesTranslations

Changed 5 months ago by coling

Hmm, Trac is playing up so not sure the previous message would have been mailed to you or not. Please check the web version of this bug (assuming this message gets mailed....)

Changed 5 months ago by maginot

I think this is what you're requesting:

$ LD_BIND_NOW=1 gdb pulseaudio GNU gdb (GDB) 7.0 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/pulseaudio...done. (gdb) r Starting program: /usr/bin/pulseaudio [Thread debugging using libthread_db enabled] W: pid.c: Stale PID file, overwriting. E: module-gconf.c: Unable to read or parse data from client. E: module.c: Failed to load module "module-gconf" (argument: ""): initialization failed. E: fdsem.c: Assertion 'pa_atomic_dec(&f->data->waiting) >= 1' failed at pulsecore/fdsem.c:283, function pa_fdsem_before_poll(). Aborting.

Program received signal SIGABRT, Aborted. 0xb7fde422 in kernel_vsyscall () (gdb) bt #0 0xb7fde422 in kernel_vsyscall () #1 0xb79b99a2 in raise () from /lib/libc.so.6 #2 0xb79bb2e0 in abort () from /lib/libc.so.6 #3 0xb7f78a3f in pa_fdsem_before_poll (f=0x809b538) at pulsecore/fdsem.c:283 #4 0xb7f62dae in pa_asyncq_read_before_poll (l=0x809b918) at pulsecore/asyncq.c:282 #5 0xb7f61396 in pa_asyncmsgq_read_before_poll (a=0x809a860) at pulsecore/asyncmsgq.c:294 #6 0xb7fbc452 in pa_thread_mq_init (q=0x809a7c8, mainloop=0x80811c0, rtpoll=0x809a7f8) at pulsecore/thread-mq.c:94 #7 0xb36de999 in module_null_sink_LTX_painit (m=0x809a3d0) at modules/module-null-sink.c:283 #8 0xb7f7bfda in pa_module_load (c=0x80823a0, name=0xb36e24e7 "module-null-sink",

argument=0x809a368 "sink_name=auto_null sink_properties='device.description=\"Saída fictícia\"'") at pulsecore/module.c:112

#9 0xb36e1f4b in load_null_sink_if_needed (c=0x80823a0, sink=<value optimized out>, u=0x8098b88) at modules/module-always-sink.c:84 #10 0xb36e21ab in module_always_sink_LTX_painit (m=0x80986b0) at modules/module-always-sink.c:168 #11 0xb7f7bfda in pa_module_load (c=0x80823a0, name=0x80990e0 "module-always-sink", argument=0x0) at pulsecore/module.c:112 #12 0xb7f69095 in pa_cli_command_load (c=0x80823a0, t=0x807ef50, buf=0x807e898, fail=0x8059975) at pulsecore/cli-command.c:426 #13 0xb7f63997 in pa_cli_command_execute_line_stateful (c=0x80823a0, s=0xbfffef28 "load-module module-always-sink", buf=0x807e898, fail=0x8059975, ifstate=0xbffff328)

at pulsecore/cli-command.c:1744

#14 0xb7f641d7 in pa_cli_command_execute_file_stream (c=0x80823a0, f=0x8084ff0, buf=0x807e898, fail=0x8059975) at pulsecore/cli-command.c:1784 #15 0x08052c28 in main (argc=1, argv=0xbffff484) at daemon/main.c:930

[ ]'s

Changed 5 months ago by maginot

Hmm, the copy paste didn't go so well, I attached the file.

thks

Changed 5 months ago by tanuk

This is the code for pa_fdsem_before_poll():

int pa_fdsem_before_poll(pa_fdsem *f) {
    pa_assert(f);

    flush(f);

    if (pa_atomic_cmpxchg(&f->data->signalled, 1, 0))
        return -1;

    pa_atomic_inc(&f->data->waiting);

    if (pa_atomic_cmpxchg(&f->data->signalled, 1, 0)) {
        pa_assert_se(pa_atomic_dec(&f->data->waiting) >= 1);
        return -1;
    }
    return 0;
}

Looks like pa_atomic_cmpxchg() is acting weird. The failing pa_fdsem_before_poll() call is done while initializing a message queue, so I think it's impossible that some other thread could have any effect on f->data->signalled at this point. Still, the first invocation of pa_atomic_cmpxchg() returns FALSE (i.e. f->data->signalled was 0, as expected) and the second invocation returns TRUE. That means that between those two calls f->data->signalled changed from 0 to 1. I can't think of any other reason except that the compare-and-swap implementation is somehow broken.

So, what to do? I guess it would be helpful to determine which atomic ops implementation you have. I think your config.h would be the best source to find out about that (grep for "ATOMIC"). I don't think I can help further, but someone might know off-hand whether there are known bugs in some version of that implementation.

Changed 5 months ago by maginot

Last debug

Changed 5 months ago by maginot

Well, I tried removing libatomic_ops-1.2 and pulseaudio-0.9.21 (on that order) and recompiled both, actually I download on more time libatomic_ops from the link on http://pulseaudio.org/wiki/DownloadPulseAudio#Requirements and after building all again the problem is the same...

I updated my attached gdb backtrace with some variables information.

Changed 5 months ago by coling

IIRC if you use a recent GCC, libatomicops will not be used.

Perhaps try moving libatomic_ops out of hte way and see if configure fails. If it does perhaps consider trying a newer GCC?

I'm not really any kind of expert in this area tho' :s

Changed 4 months ago by maginot

Note: See TracTickets for help on using tickets.