When attempting to ltrace audacious , in both invoke and attatch form, ltrace -p <pid> or ltrace audacious audacious dies from a SIGTRAP during widget creation. It always does this at the exact same point. g_type_check_instance_cast(0x812c760, 0x810cd58, 0xbf9e83d8, 0x806becc, 0x80e1b30) = 0x812c760 gtk_check_menu_item_set_active(0x812c760, 1, 0xbf9e83d8, 0x806becc, 0x80e1b30) = 0 +++ killed by SIGTRAP +++ With strace it completely locked up my X session. I could see X responding to the mouse, and the system ran however all key sequences including magic-sysreq had no effect. I was forced to ssh in and sent a number of -TERM signals to various applications. When I finally sent a -9 to strace all of the signals previously sent were delivered. Without a second computer and ssh this would have been a hard reset. audacious: 1.2.2 ltrace: 0.3.36 strace: 4.15.4
Why exactly are you wishing to ltrace/strace audacious? For what it's worth, the X lockup was probably due to an incomplete request sent to the X server. SIGTRAP is typically only used with a debugger, and does not normally (infact, can't normally) occur without any breakpoints set. Try rebuilding audacious? What CFLAGS do you have?
I am debugging a problem with alsa ( #160397 ). Using ltrace is a quick pre-cursor to drilling down with gdb for me. My CLFAGS are quite tame: CFLAGS="-pipe -Os -march=athlon-xp" CHOST="i686-pc-linux-gnu" also of note is that I tried tracing other media programs such as aplay and mplayer, both of which executed normally while being traced.
Also got X lock when stracing, but, I can still: - use keyboard to switch to console - press remote to switch console (yes, since 1y I got a LIRC bind to "chvt 1" hehe :P ) as root, killall -9 audacious cleared the X lock problem. bug #160397 should be marked WONTFIX ASAP ... For myself, I needed to strace audacious because I got a new bug on it, and ned logs to google for something, cause it's a hard crash: output just says "we crashed, please report", and I dont even have any error number to look or search for ... so any strace output would really help me :) any any way, strace should not interfeer with application functioning !!!
note that redirecting output to file avoids hang: dhp@moon_gen_2:~$ strace audacious >/tmp/audacious_strace.log 2>&1 dhp@moon_gen_2:~$ I will attach my log in here; you may find there why outputing to console makes X hang ...
Created attachment 111692 [details] /tmp/audacious_strace.log
Crash reports with output from strace will not be accepted. Please provide a backtrace with gdb before reporting a crash in 1.2.2. strace is not thread safe, which means, basically, don't use it with X applications.
Please discuss this with upstream developers. It is not caused by the way audacious is packaged, and no patches have been provided to rectify the behaviour. I'm sorry to tell you that this does not belong in the Gentoo bug tracker.
an answer is resolution enough for me. Thanks for looking into this.
