Since glib 2.8.5 i have been experiencing sudden application freezing with audacious. After discussion with the audacious devs the conclussion was reached that it is probably a glib problem. After some more testing glib-2.8.6 without debug produces deadlock after random playing time, with debug enabled there seems to be no problem. Friend of mine did have the same prob but switching to x86_64 did the trick for him. Portage 2.1_pre5-r2 (default-linux/x86/2005.1, gcc-3.4.5, glibc-2.3.6-r0, 2.6.15-gentoo-r1-reiser4-devh i686) ================================================================= System uname: 2.6.15-gentoo-r1-reiser4-devh i686 AMD Athlon(TM) XP 2200+ Gentoo Base System version 1.6.14 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [disabled] dev-lang/python: 2.3.5-r2, 2.4.2-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=athlon-xp -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=athlon-xp -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" MAKEOPTS="-j2"
I'd drop the -O3 syswide for a start.
Attaching gdb to the running but frozen process yields following: (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb77bc54e in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #2 0xb77b916b in _L_mutex_lock_24 () from /lib/libpthread.so.0 #3 0x00000001 in ?? () #4 0x00000000 in ?? () (gdb) info thread 6 Thread -1220752464 (LWP 1207) 0xffffe410 in __kernel_vsyscall () 5 Thread -1239225424 (LWP 1297) 0xffffe410 in __kernel_vsyscall () 4 Thread -1247618128 (LWP 1298) 0xffffe410 in __kernel_vsyscall () 3 Thread -1258292304 (LWP 1333) 0xffffe410 in __kernel_vsyscall () 2 Thread -1266685008 (LWP 32298) 0xffffe410 in __kernel_vsyscall () 1 Thread -1220503888 (LWP 1170) 0xffffe410 in __kernel_vsyscall ()
did you try the suggestion from Comment #1?
no response from reporter
