Bug 160407 – media-sound/audacious-1.2.2 dies from SIGTRAP when traced with ltrace. strace'ing it locked my system up hard

• Product: Gentoo Linux
• Status: RESOLVED UPSTREAM

[Description Mike Mattie 2007-01-06 10:55:12 UTC]

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

[Comment 1 William Pitcock 2007-01-10 13:31:43 UTC]

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?

[Comment 2 Mike Mattie 2007-01-10 19:15:51 UTC]

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.

[Comment 3 DEMAINE Benoît-Pierre, aka DoubleHP 2007-03-01 12:59:06 UTC]

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 !!! 

[Comment 4 DEMAINE Benoît-Pierre, aka DoubleHP 2007-03-01 13:00:40 UTC]

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 ...

[Comment 5 DEMAINE Benoît-Pierre, aka DoubleHP 2007-03-01 13:03:48 UTC]

Created attachment 111692 [details]
/tmp/audacious_strace.log

[Comment 6 William Pitcock 2007-03-01 14:06:34 UTC]

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.

[Comment 7 Tony Vroon (RETIRED) 2007-03-01 14:39:15 UTC]

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.

[Comment 8 Mike Mattie 2007-03-02 20:29:44 UTC]

an answer is resolution enough for me. Thanks for looking into this.