audacious2 crashed with SIGSEGV in __lll_lock_wait() when quitting

[Eliah Kagan]

Binary package hint: audacious

Audacious2 usually quits with no problems, but occasionally it crashes on exit with SIGSEGV in __lll_lock_wait(). Since audacious2 often has a large number of threads, it takes a long time for Apport to generate a .crash file, during which time the interface is frozen--therefore, it is easy to mistake this crash for a hang. But audacious2 does terminate by itself, without user intervention, every time.

I first reported this with audacious 2.4.0-0ubuntu3 on Maverick amd64 (see original description, duplicate bug 688599, and duplicate bug 690432). I have subsequently gotten this crash with audacious 2.4.4-1 on Natty amd64 on the same physical machine (see duplicate bug 800078). I have never gotten a useful stack trace with Apport, but I got some mediocre manual traces in gdb on the Maverick system (https://bugs.launchpad.net/ubuntu/+source/audacious/+bug/691378/comments/7 is the best). If I get a trace in Natty that's as good or better, I'll post it and edit this to link to it.

Please note that the original description and a number of comments below suggest that this problem may be related to an input-output bug in the Linux kernel. That may be the case, and many of the times this crash occurred was when the machine was under heavy I/O. However, I have found that the situation in the original report--where my music library was on an external hard drive that may have been malfunctioning--is not necessary to produce this problem. While in all cases the music library was on a partition or network drive mounted as a fuse filesystem (ntfs-3g originally, and now mount.cifs), that may or may not be relevant.

Since Apport is always entirely unsuccessful backtracing this bug, the original title was "audacious2 crashed with SIGSEGV". I have edited the title to reflect specific information from the manual traces.

ProblemType: Crash
DistroRelease: Ubuntu 10.10
Package: audacious 2.4.0-0ubuntu3
ProcVersionSignature: Ubuntu 2.6.35-24.42-generic 2.6.35.8
Uname: Linux 2.6.35-24-generic x86_64
Architecture: amd64
CrashCounter: 1
Date: Thu Dec 16 20:07:13 2010
Disassembly: => 0x7f21bb5d4286: Cannot access memory at address 0x7f21bb5d4286
ExecutablePath: /usr/bin/audacious2
InstallationMedia: Xubuntu 10.04 "Lucid Lynx" - Beta amd64 (20100406)
ProcCmdline: audacious
ProcEnviron:
 LANGUAGE=en_US.utf8
 LANG=en_US.utf8
 LC_MESSAGES=en_US.utf8
 SHELL=/bin/bash
SegvAnalysis:
 Segfault happened at: 0x7f21bb5d4286: Cannot access memory at address 0x7f21bb5d4286
 PC (0x7f21bb5d4286) not located in a known VMA region (needed executable region)!
 Stack memory exhausted (SP below stack segment)
SegvReason: executing unknown VMA
Signal: 11
SourcePackage: audacious
StacktraceTop:
 ?? ()
 ?? ()
 ?? ()
 ?? ()
 ?? ()
Title: audacious2 crashed with SIGSEGV
UserGroups: adm admin cdrom lpadmin plugdev sambashare

[Apport retracing service (apport)]

StacktraceTop:
 ?? ()
 ?? ()
 ?? ()
 ?? ()
 ?? ()

[Eliah Kagan (degeneracypressure)]

I still don't have a perfect stacktrace, but for the past week I've run audacious exclusively in gdb, and I now have a gdb session transcript for a session where the bug occurred. It shows some information about the I/O errors that occurred immediately prior to the crash, and gdb was able to generate this stack trace (excerpted from the complete transcript, which is attached):

#0 0x00007ffff544c6b6 in __lll_lock_wait () from /lib/libpthread.so.0
#1 0x00007ffff5447849 in _L_lock_953 () from /lib/libpthread.so.0
#2 0x00007ffff544766b in pthread_mutex_lock () from /lib/libpthread.so.0
#3 0x00007fffe895e5b5 in ?? ()
#4 0x00007fffd4001bf0 in ?? ()
#5 0x00007ffff5448c70 in ?? () from /lib/libpthread.so.0
#6 0x0000000000000001 in ?? ()
#7 0x00007ffff6c677e4 in g_thread_create_proxy (data=0x63fee0)
    at /build/buildd/glib2.0-2.26.1/glib/gthread.c:1897
#8 0x00007ffff5445971 in start_thread () from /lib/libpthread.so.0
#9 0x00007ffff4d8d92d in clone () from /lib/libc.so.6
#10 0x0000000000000000 in ?? ()

Since the package libc6 provides both /lib/libpthread.so.0 and /lib/libc.so.6, I've installed libc6-dbg. I will continue to run audacious in gdb with the hope of generating a better stack trace. But since weeks sometimes pass between occurrences of this crash, I'm posting what I have, in case it's useful.

One clarifying note: the binary /usr/bin/audacious is a symlink to /usr/bin/audacious2.

[Eliah Kagan (degeneracypressure)]

Note that, contrary to what I said in the original bug report, I do not think this bug is possibly a duplicate of Bug 640732 or Bug 650531. The stack trace information that is available does not make it look like those bugs. I believe that this is in fact a new bug.

[Eliah Kagan (degeneracypressure)]

Here's a better, but not perfect, backtrace from gdb. Complete gdb session log attached.

#0 __lll_lock_wait ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:137
#1 0x00007ffff5447849 in _L_lock_953 () from /lib/libpthread.so.0
#2 0x00007ffff544766b in __pthread_mutex_lock (mutex=0x7fffe8b6aa08)
    at pthread_mutex_lock.c:61
#3 0x00007fffe895e5b5 in ?? ()
#4 0x00007fffd8003000 in ?? ()
#5 0x00007ffff5448c70 in ?? () at pthread_mutex_unlock.c:71
   from /lib/libpthread.so.0
#6 0x0000000000000001 in ?? ()
#7 0x00007ffff6c677e4 in g_thread_create_proxy (data=0x63fee0)
    at /build/buildd/glib2.0-2.26.1/glib/gthread.c:1897
#8 0x00007ffff5445971 in start_thread (arg=<value optimized out>)
    at pthread_create.c:304
#9 0x00007ffff4d8d92d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()

[Eliah Kagan (degeneracypressure)]

I have recently been experiencing this crash again whenever I quit audacious. (Previously, I had experienced it only occasionally, as documented above.) This is since I moved my music from a malfunctioning external USB drive to a remote machine, and started accessing the music via a Samba share (with smbmount, i.e. mount.cifs). I am able to create playlists and play music without problems, but (so far) I get this crash whenever I try to quit Audacious.

The most recent time this occurred, before quitting Audacious, I tried to unmount the Samba share, which, since the music was still playing, had the result I predicted:

ek@Apok:~$ sudo umount /media/dAlembertian
[sudo] password for ek:
umount: /media/dAlembertian: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))

Then, within a couple of seconds after clicking the X at the upper-right corner of Audacious, I tried again, and this succeeded. Perhaps this means that the error is not really related to accessing the music. Or perhaps it is, but audacious had already terminated and the audacious window was only still up because Apport was still collecting data.

[Eliah Kagan (degeneracypressure)]

I have just tried opening Audacious, playing a song for a few seconds, and quitting it, and I did not get this problem. Every time I had run Audacious since migrating my music library to the remote machine, I had gotten this crash when closing it, but in each of those times, Audacious had been running for a long while (five hours or more, in most cases). Since having been running a long time seemed to be strongly associated with this crash occurring before, it seems that perhaps the frequency of this crash (or, to be more precise, the likelihood of it occurring) has not increased after all. So the only thing I really have to report is that this crash still happens, even now that the music is not on a malfunctioning USB drive, and it therefore seems likely that it is not related to the filesystem on which it resides (though both mount.ntfs and mount.cifs use fuse, which is a similarity).

[Eliah Kagan (degeneracypressure)]

I can confirm that this still happens with audacious 2.4.4-1 in Natty. Also, this is a crash, and not a hang--it only appears to be a hang due to the very large number of threads that audacious2 has causing apport to take a very long time to write a .crash file for it (and thus keeping the process a zombie with an open but unresponsive interface).

This is definitely not bug 640732 (as suggested in my original description), since that bug has been found to be due to a bug in gcc-4.4, and this is on Natty, which is gcc-4.5 based. This is also not bug 650531 (as similarly suggested), as that bug's trace is highly inconsistent with the manual traces I obtained for this bug (this bug is a locking problem, and that bug isn't).

I've reported this in Natty as bug 800078. If Apport retracing service can make anything of that bug's stack trace, I'll mark this as a duplicate of that bug and edit its description to make it more informative. Otherwise, I'll mark it as a duplicate of this bug and edit this bug's description to reflect the above information.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.