Red Hat Bugzilla – Bug 213800
gaim crashes with debug window
Last modified: 2007-11-30 17:11:47 EST
Description of problem:
gaim crashes reliably run alone, more randomly run from GDB
Version-Release number of selected component (if applicable):
reliably run alone, more randomly run from GDB
Steps to Reproduce:
1. launch gaim
2a. (standalone) either double click on a buddy or right click and select IM
2b. (run from GDB) use gaim normally and wait trepidation
gaim freezes up. Its windows don't refresh. When running under gdb, gdb itself
often hangs waiting on a gaim zombie (some intermmediate thread has apparently
gaim Just Works
I, for one*, see many crashes in gaim, mainly when I'm in some critical
conversation with a client about a P1 on their production servers.
This probably isn't https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212818,
but for all I know could be related to the delightfully vague
At first, gaim would reliably crash when I double-clicked on a budddy or
right-clicked and selected IM. Once I installed the -debuginfo rpms, ala
http://gaim.sf.net/gdb.php and started running gaim under gdb, the crashes
became much more random and clustered as I mentioned above (sigh). To me, the
back traces reveal nothing - just a bunch of thread births and deaths until ...
"Couldn't get registers: No such process." At this point, if I'm lucky I can
tell gdb to quit, but mostly (i.e all but once), it just wedges gdb until I kill
-9 gdb and all its gaim-y children. I didn't save the first several gdb session
logs, because they were so unrevealing.
The following attachments contains the logs of my last two runs of gaim under
gdb. FWIW, I have a KDE desktop and yum upgrade my:
moby(~) uname -a
Linux moby.eshu.net 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:37:32 EDT 2006 i686
i686 i386 GNU/Linux
system obsessively at least once a day.
I'm marking the severity high, due to the adverse effect this is having on my
business. It's souring my relationship with an important client.
Created attachment 140201 [details]
GDB log: crash when I clicked on help in the buddy list menu bar
Created attachment 140202 [details]
GDB log: crash when I clicked on a link in the conversation window
*) ... welcome our new buggy and unreliable IM overlords.
Since installing FC6, I have yet to successfully complete an IM conversation. In
fact, running standalone, I have yet to initiate one - crashes every time!
Please calm down and show a little patience. Many thousands of users are using
gaim on FC6 successfully.
Hmm, your symptoms do not appear to make any sense. You could try to talk to
the gaim developers in #gaim on irc.freenode.net? Use xchat for now.
Woah there, Captain Itchypants. No overlords were oppressing your IM usage in
those *five minutes*.
I suspect this is 212818, and both of these bugs are caused by some sort of
broken d-bus interaction. Is your Gaim more stable if you run it as (from a
If so, this is the case.
Also, make sure you aren't loading any third party plugins -- things changed
from beta3 to beta4, and third party plugins could be troublesome. (I think
they shouldn't load, but still...)
Also, if stuff crashes while you're running in gdb, you should type "bt" or "bt
full" (or both) to get a backtrace. Otherwise the gdb output isn't very useful.
Created attachment 140302 [details]
GDB log: wedge when I try to close a conversation window
This time I actually got a backtrace, sort of.
I was closing a conversation window by clicking the close button in the window
frame. gaim put up a dialog asking if I was sure I wanted to close the window,
and something told me that it was about to crash, so I clicked cancel in that
confirm dialog. At that point gaim wedged - windows didn't respond or refresh.
Going back to the GDB console, I saw that I wasn't at a gdb> prompt so I ^C-ed
in the gdb console window, got a prompt and then was able to get a backtrace.
It's not clear to me whether the backtrace reflects the state of the wedged
gaim, or merely the result of my SIGINT.
Here come three more back traces, all from another thrice interrupted AIM
conversation with the CTO of Important Client.
Since I was trying to focus on solving his problem I don't remember exactly what
I was doing in each.
I believe that the first time I was simply responding in the conversation, the
second time I was trying to switch from one conversation to a another by
clicking in its window, and the third time I was tring to cut and paste.
Created attachment 140328 [details]
Another GDB back trace
Created attachment 140330 [details]
... and another
Created attachment 140331 [details]
... and yet another
Trying DBUS_SESSION_BUS_ADDRESS="" gaim ala
We have plenty of backtraces (I assume you've actually looked at them, and
noticed they're all the same), thanks.
Incidentally, why is this bugzilla so unusably slow? Warren?
It looks like it's crashing in some threading/mutex stuff in gtk list store. I
have no idea why that would happen. Does it crash if you don't have the debug
window open (and also aren't running with '-d')? Are you using the standard
version of gtk that ships with FC6?
warren, do you know if your RPM includes a patch that calls gtk_threads_init()
or some such, intended to work around that dbus/gtk_file_chooser()/Nautilus
crash from a month or so ago?
(In reply to comment #14)
> ... Does it crash if you don't have the debug
> window open (and also aren't running with '-d')?
Yes. Absolutely every time - see the Bug Summary, How Reproducible, Steps 1 & 2a
of Steps to Reproduce, and the third paragraph of my intial report:
>> At first, gaim would reliably crash when I double-clicked on a budddy or
>> right-clicked and selected IM. Once I installed the -debuginfo rpms, ala
>> http://gaim.sf.net/gdb.php and started running gaim under gdb ...
To recapitulate: Every time I would launch gaim, then try to initiate a
conversation, it would either freeze up or crash outright.
When I started running gaim from GDB, it became marginally more usable and the
crashes were less repeatable, though still inevitable. Since the crashes were
now less predicatable under GDB, as time wore on I got in the habit of opening
the debug window (on a dedicated, uncluttered virtual desktop) at launch to try
and get a handle on what threads were doing what in the back trace.
Unfortunately, this required interrupting my (paid) work flow on a different,
cluttered virtual desktop to go and check the gaim debug window. Obviously this
never showed me the most pertinent data from immediately before gaim wedges and
stops refreshing its windows.
> Are you using the standard
> version of gtk that ships with FC6?
This is a clean install of the OS as of 2006-10-27, updated at least once a day,
with no gaim-plugins whatsoever, just gaim-2.0.0-0.17.beta4.fc6 (though it has
been updated once, on 2006-10-28, from the original gaim-2.0.0-0.15.beta3.fc6).
> warren, do you know if your RPM includes a patch that calls gtk_threads_init()
> or some such, intended to work around that dbus/gtk_file_chooser()/Nautilus
> crash from a month or so ago?
Oviously I can't speak for Warren, but looking at the SRPM's spec file there are
no Fedora or backported patches and the tarball from which it builds is:
-rw-r--r-- 1 joe wheel 6298151 Oct 23 10:10 gaim-2.0.0beta4.tar.bz2
with sha1sum = c4aaa9417d897e38c630699eb76c5f26e4a54881
I hope that helps.
I guess disabling DBUS (per the DBUS_SESSION_BUS_ADDRESS instructions) didn't help?
Didn't have an opportunity to test it until today, but alas, no joy.
Launched without gdb via
moby(~) DBUS_SESSION_BUS_ADDRESS="" gaim
but running with the debug window open. This time I didn't even click anything,
just typing when, in mid sentence, the screen of echo of what I was keying
ceased and I was buack in that old familar state where the window won't refresh
or respond. Sigh.
All of the backtraces you have posted are either a) useless, contain no
information or b) lockups caused by a bug which happens when you have the debug
That particular bug is fixed with this patch:
If you have problems _without_ the debug window open, please get a backtrace for
that. If you have problems with reproducing the problem running under gdb,
obtain a core file and then run gdb on that as described in
http://gaim.sf.net/gdb.php under "The Hard Way" (it's not really hard)
(In reply to comment #18)
> All of the backtraces you have posted are either ...
> b) lockups caused by a bug which happens when you have the debug
> window open.
Hmmm. I could have sworn that I was seeing the wedging under GDB before it
occurred to me to open the debug window.
> If you have problems _without_ the debug window open, please get a backtrace for
> If you have problems with reproducing the problem running under gdb,
> obtain a core file and then run gdb on that as described in
> http://gaim.sf.net/gdb.php under "The Hard Way" (it's not really hard)
Since the problem most often evidences itself by wedging gaim, I'm going to
have to kill(1) gaim. It's been quite a while since I last did that; could you
remind which signal would be best for your purpose, SIGQUIT, SIGABRT, or SIGTRAP?
Would it help to run the cbi enabled gaim rpm from the Cooperative Bug Isolation
SIGABRT ("killall -6 gaim")
I guess running cbi enabled Gaim might help... but for now I think it's better
to just get a backtrace from a normal Gaim crash without the debug window open.
comment #5 works for me, gaim always had a crash when try connect to
OK I launched gaim within GDB (ts is a script that writes a timestamp to disc):
moby(GaimCrashes) ts && gdb gaim
(gdb) handle SIGPIPE nostop
Signal Stop Print Pass to program Description
SIGPIPE No Yes Yes Broken pipe
Starting program: /usr/bin/gaim
[Thread debugging using libthread_db enabled]
I got two conversation going and typed as hard and fast as I could into one w/
my kid (me actually, on her computer). Things seemed to be quite stable, but
then I clicked over to the link I had IM'ed to nosnilmot26 and gaim wedged.
At this point I have the following running:
moby(~) ps wwuaxf | egrep -v grep | egrep -B1 gaim
joe 4575 0.0 0.0 4624 1500 pts/53 Ss Nov05 0:00 | \_ /bin/bash
joe 15773 0.0 2.4 55100 50524 pts/53 S+ Nov05 0:02 | | \_ gdb
joe 15777 0.0 1.4 135632 29736 pts/53 T Nov05 0:31 | | \_
joe 5482 0.0 0.6 135632 13196 pts/53 T 09:11 0:00 | |
moby(~) kill -6 5482
moby(~) kill -6 15777
moby(~) kill -6 15777 5482
all leave gaim running & wedged, and no core file in sight:
moby(~) sudo find / -type f -newer ~joe/tmp/GaimCrashes/ts-2006-11-05-214327
-name core\* -print
I have a gdb prompt in the controlling terminal, but bt full does nothing:
(gdb) bt full
Couldn't get registers: No such process.
What should I do now get you all some useful debugging information?
That's strange. I'm not sure what would cause that. When you say "wedged," you
mean "froze and was unresponse and if I hid the Gaim windows then unhid them
they would be gray and ugly and I couldn't close it and had to kill -9 it"?
Also, did you actually click on the link? Or just mouse over it? Did your web
browser open? If Gaim is hung then I guess you could run strace on the process
and see if it's doing ANYTHING. I dunno, I'm out of ideas.
(In reply to comment #24)
> ... When you say "wedged," you
> mean "froze and was unresponse and if I hid the Gaim windows then unhid them
> they would be gray and ugly and I couldn't close it and had to kill -9 it"?
> Also, did you actually click on the link?
> Or just mouse over it?
> Did your web
> browser open?
> If Gaim is hung then I guess you could run strace on the process
> and see if it's doing ANYTHING.
moby(~) strace -o tmp/GaimCrashes/strace-2006-11-07-0637/strace.out -ff -tt -p
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
> I dunno, I'm out of ideas.
I'm finishing the fresh FC6 install on my laptop today - I can see if it happens
On this machine, I think that I'll try the CBI enabled gaim, then the rpm that
Jan Kratochvil for 212818
Hmm, does it ALWAYS crash when clicking on links? Have you checked to make sure
that your browser setting is reasonable in Tools-->Preferences?
(In reply to comment #26)
> Hmm, does it ALWAYS crash when clicking on links?
> Have you checked to make sure
> that your browser setting is reasonable in Tools-->Preferences?
Created attachment 140601 [details]
Messages in controlling tty from strace'd gaim w/ CBI
Today I intsalled the CBI instrumented rpm and then did:
moby(GaimCrashes) ts && strace -tt -o strace-2006-11-07-0637/gaim-strace.out -ff
In a little less than 5 hours, about 45 minutes stressing it as hard as I know
how, trying everything that I can remember that has crashed it before, not a
hiccup. I do have some minor warning looking messages in the controlling console
(see above), could these be related? Could it be that the drag of strace and the
CBI instrumentation is slowing execution enough that some race condition is
Of course, by now I have straces of 672 threads, totalling 80M, so strace-ing
clearly isn't a long term solution to achieving stability ;).
Please test this FC6 candidate update package here, does this solve your problem?
Well, no crashes/hangs/etc. in my first simple test. Let me give it some time. I
have my fingers crossed. Alas I lost the important client - should have known
better than to use a package w/ beta in the name on the job. Sigh.
This works for me with gaim-2.0.0-0.19.beta4.fc6.