Bugzilla Bug 160407

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 an attachment (id=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.