Bug 253349

Created attachment 161786 [details]
Full thread backtrace

 $ pulseaudio -vv
W: main.c: WARNING: called SUID root, but not in group 'pulse-rt'.
E: pid.c: stale PID file, overwriting.
I: module-hal-detect.c: Trying capability alsa
D: module-hal-detect.c: Not loaded device
/org/freedesktop/Hal/devices/computer_alsa_timer
D: module-hal-detect.c: Not loaded device
/org/freedesktop/Hal/devices/computer_alsa_sequencer
D: module-hal-detect.c: Not loaded device
/org/freedesktop/Hal/devices/pci_1102_4_alsa_playback_4
D: module-hal-detect.c: Not loaded device
/org/freedesktop/Hal/devices/pci_1102_4_alsa_capture_4
D: module-hal-detect.c: Not loaded device
/org/freedesktop/Hal/devices/pci_1102_4_alsa_playback_3
D: module-hal-detect.c: Not loaded device
/org/freedesktop/Hal/devices/pci_1102_4_alsa_playback_2
D: module-hal-detect.c: Not loaded device
/org/freedesktop/Hal/devices/pci_1102_4_alsa_capture_2
D: module-hal-detect.c: Not loaded device
/org/freedesktop/Hal/devices/pci_1102_4_alsa_capture_1
D: module-hal-detect.c: Loading module-alsa-sink with arguments 'device=hw:1
sink_name=alsa_output.pci_1102_4_alsa_playback_0'
I: module-alsa-sink.c: Successfully enabled mmap() mode.
I: alsa-util.c: Using mixer control "Master".
I: sink.c: Created sink 0 "alsa_output.pci_1102_4_alsa_playback_0" with sample
spec "s16le 2ch 44100Hz"
I: source.c: Created source 0 "alsa_output.pci_1102_4_alsa_playback_0.monitor"
with sample spec "s16le 2ch 44100Hz"
I: module-alsa-sink.c: Using 4 fragments of size 4408 bytes.
I: module.c: Loaded "module-alsa-sink" (index: #0; argument: "device=hw:1
sink_name=alsa_output.pci_1102_4_alsa_playback_0").
D: sound-file.c: POSIX_FADV_SEQUENTIAL succeeded.
D: module-alsa-sink.c: Thread starting up
I: module-alsa-sink.c: Starting playback.
D: memblock.c: Memory block too large for pool: 441428 > 16368
pulseaudio: pulsecore/fdsem.c:181: pa_fdsem_after_poll: Assertion
`pa_atomic_dec(&f->waiting) >= 1' failed.
Aborted

I have exactly the same problem, attaching my backtrace as well.

Created attachment 161995 [details]
Full thread backtrace

Note I'm on x86_64 rawhide too.

Is this an SMP/multicore system?

Could you please run this through valgrind and paste the output?

(In reply to comment #5)
> Is this an SMP/multicore system?

A single core single processor system in my case. I'll attach the valgrind
output when I'm back home (currently @ work).

Okay, here is the requested valgrind run. Notice this is with the suid root bit
removed, as valgrind otherwise exits with a permission denied error.

 [root@shalem ~]# valgrind pulseaudio --log-target=syslog
==7803== Memcheck, a memory error detector.
==7803== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==7803== Using LibVEX rev 1732, a library for dynamic binary translation.
==7803== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==7803== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==7803== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==7803== For more details, rerun with: -v
==7803== 
==7803== Syscall param futex(futex) points to uninitialised byte(s)
==7803==    at 0x50734DA: __pthread_initialize_minimal (in
/lib64/libpthread-2.6.90.so)
==7803==    by 0x5072DE8: (within /lib64/libpthread-2.6.90.so)
==7803==  Address 0x7FF0007BC is on thread 1's stack
pulseaudio: pulsecore/fdsem.c:181: pa_fdsem_after_poll: Assertion
`pa_atomic_dec(&f->waiting) >= 1' failed.
==7803== 
==7803== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 1)
==7803== malloc/free: in use at exit: 210,832 bytes in 1,759 blocks.
==7803== malloc/free: 10,031 allocs, 8,272 frees, 3,360,594 bytes allocated.
==7803== For counts of detected errors, rerun with: -v
==7803== searching for pointers to 1,759 not-freed blocks.
==7803== checked 13,106,520 bytes.
==7803== 
==7803== LEAK SUMMARY:
==7803==    definitely lost: 0 bytes in 0 blocks.
==7803==      possibly lost: 23,464 bytes in 390 blocks.
==7803==    still reachable: 187,368 bytes in 1,369 blocks.
==7803==         suppressed: 0 bytes in 0 blocks.
==7803== Rerun with --leak-check=full to see details of leaked memory.
Killed
[root@shalem ~]# 

Hmm, that valgrind output is not particularly useful. 

Hmm, please run pa through gdb and do a full backtrace of all threads. If you
need help for that, just give me another ping.

Thank you!

Is that any different than what is in attachment 161786 [details] in comment 1, or
attachment 161995 [details] in comment 4?

Oh, sorry, I am an idiot. This is just what I was looking for. Sorry.

No problem. Bugzilla confuses the hell out of me... :)

Hmm, OK I got myself now an amd64 machine and tried to reproduce this issue. No
luck. I used 0.9.7.svn20070823 which has some modifications ins semaphore
handling so I might have fixed this issue as a side effect.

In the initial bug report you mentioned that you used 0.9.7-0.7.svn20070816.
Could you please retry with 20070823 version from Rawhide? 

Tried with pulseaudio-0.9.7-0.8.svn20070823.fc8. Results identical.

Hmm, could you please paste the output of pulseaudio -vv with
pulseaudio-0.9.7-0.8.svn20070823.fc8 here? gdb backtrace would be cool, too!

Thanks!

Created attachment 174841 [details]
pulseaudio -vv

pulseaudio-0.9.7-0.8.svn20070823.fc8
Linux datatype 2.6.23-0.129.rc3.git4.fc8 #1 SMP Wed Aug 22 01:28:57 EDT 2007
x86_64 x86_64 x86_64 GNU/Linux

Created attachment 174861 [details]
Full thread backtrace pulseaudio-0.9.7-0.8.svn20070823.fc8

Ok, this was a hard bug to fix. The bug seems to be specific to amd64, and
doesn't appear on x86_64. libatomic_ops doesn't seem to work properly on amd64.
I replaced that implementation now by the native gcc atomic builtins which are
available on amd64, and the problem seems to be gone away. At least on the two
amd64 machines I got access to.

Please, could you try 0.9.7-0.10.svn20070905?

If it works for you as well, I will close the bug.

I'm afraid it still doesn't work, things have changed, but it still fails for
me, using the pulseaudio packages from here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=17804

Which are the correct ones I assume, I now get this bt:
(gdb) run
Starting program: /usr/bin/pulseaudio 
[Thread debugging using libthread_db enabled]
[New process 3493]
pulseaudio: pulsecore/mutex-posix.c:79: pa_mutex_unlock: Assertion `_r == 0' failed.
[New Thread 46912522439936 (LWP 3493)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 46912522439936 (LWP 3493)]
0x00002aaaac0a2895 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00002aaaac0a2895 in raise () from /lib64/libc.so.6
#1  0x00002aaaac0a4340 in abort () from /lib64/libc.so.6
#2  0x00002aaaac09bc9f in __assert_fail () from /lib64/libc.so.6
#3  0x0000000000433c25 in pa_mutex_unlock (m=<value optimized out>)
    at pulsecore/mutex-posix.c:79
#4  0x00002aaaaaee3960 in lt_dlmutex_register () from /usr/lib64/libltdl.so.3
#5  0x000000000040e901 in main (argc=1, argv=0x7fff20fe4558)
    at daemon/main.c:339
(gdb)

Ah. That's an issue with a borked libltdl 1.5.22.

You need to update to libtool-ltdl 1.5.24 at least, which is available in
rawhide. I presume you did a manual upgrade of the PA packages and thus left
libltdl at 1.5.22?

It works! Note that I did have the same problem on my Intel x86_64 (not AMD), so
I assume that in Comment 18 you mean to say "doesn't appear on x86" (not x86_64).

Also, I got a segfault until I wiped out /system/pulseaudio stuff in gconf. I'm
attaching that log.

Created attachment 188161 [details]
pulseaudio -vv log of segfault before wiping gconf info

I have reproduced the crash. If you select "Allow other machines in LAN to
browse for local sound devices", thus publishing the sound source, it segfaults
in avahi stuff. I'm attaching the backtrace.

Created attachment 188231 [details]
Backtrace on avahi crash (-vv log in Attachment 188161 [details])

Adam, I suspect the crash you mention in comment #21 and later is a different
problem than the original crash.

Original bug: pulseaudio always aborts on startup on x86_64
New bug: pulseaudio aborts on startup on x86_64 *if* avahi is enabled

If that's the case, could you file this new issue in a separate bug report?

Yes, that is correct. I think this bug can be closed.

New bug is #284141.

Oops, didn't really mean to close this bug yet.

After updating libtool-ltdl it starts for me now too, but no matter what I do
pulseaudio-manager always says connection refused. (and other apps still play
through alsa I believe).

Any clues? This is still on an x86_64 machine.

Adam, the original bug here is fixed, so this bug should be closed.

For other pulseaudio problems, either ask on the mailing lists or file new bugs.