Bug 277941 - gnome applications quit unexpectedly
gnome applications quit unexpectedly
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: libwnck (Show other bugs)
6
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Søren Sandmann Pedersen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-05 04:01 EDT by Michael V. Antosha
Modified: 2014-06-18 05:09 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-15 09:38:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
my first gdb trace for xchat, got SIGPIPE (2.38 KB, text/plain)
2007-09-05 12:53 EDT, Michael V. Antosha
no flags Details
print screen: dialog window about "clock quit" event (1.04 MB, image/png)
2007-09-24 03:53 EDT, Michael V. Antosha
no flags Details
ps differences: before and after reloading the clock applet (943 bytes, text/plain)
2007-10-02 11:07 EDT, Michael V. Antosha
no flags Details

  None (edit)
Description Michael V. Antosha 2007-09-05 04:01:58 EDT
Description of problem:

I'm not sure if it's a gnome bug or not, but I don't know where to start...

Different applications quit from time to time unexpectedly when after one or
another mouse/keyboard event (mouse move, mouse click, pressing a key...)
Frequency: about several times per day.


Version-Release number of selected component (if applicable):
gnome-desktop-2.16.3-1.fc6.src.rpm
Can provide you with another rpm's versions if needed.


How reproducible:
Can't reproduce. But it happens usually several times per day.
Different applications (xchat, thunderbird, firefox, gnome terminal, clock, task
switcher and others...)
  
Actual results:
Application exits. It appears that exits normally
(maybe as if SIGTERM was received, but I'm not sure for now).
If I have several windows (thunderbird, firefox, terminal) --
they all disappears at once.



Additional info:
I'm ready to gather any additional information, but I don't know what to start with.
Comment 1 Michael V. Antosha 2007-09-05 05:07:14 EDT
(In addition to my comment #0)
> 
> Different applications quit from time to time unexpectedly when after one or
> another mouse/keyboard event (mouse move, mouse click, pressing a key...)

Actually, I'm not sure about when it happens to panel applications (task
switcher, workspace switcher, clock, maybe more...)
I didn't notice the moment they quit. I just know they do. Some time after that
I discover that a dialog window appeared (at workspace 1, not in focus), which
informs me that the panel application has quit unexpectedly, and proposes me to
reload it. As I can remember, usually they come in groups, that is I have to
reload several panel application at once.

As for window applications (firefox, xchat, thunderbird, gnome terminal), I'm
completely sure that it always happens after some mouse/keyboard event occurs.
It's less than a second between the mouse/keyboard event and the moment when the
window is no longer exists on my desktop.

I couldn't narrow the scope of event types. It can remember when it was mouse
move, mouse wheel move, mouse click or key press.

I haven't been able to to predict the moment when the problem take place.
Comment 2 Ray Strode [halfline] 2007-09-05 11:50:33 EDT
This sounds like a libwnck bug.
 
Maybe the problem happens when you hover over the task list and a tooltip pops
up (or goes away after being popped up)?

If so, this may be 

http://bugzilla.gnome.org/show_bug.cgi?id=139080

Comment 3 Michael V. Antosha 2007-09-05 12:53:48 EDT
Created attachment 187721 [details]
my first gdb trace for xchat, got SIGPIPE
Comment 4 Michael V. Antosha 2007-09-05 12:55:48 EDT
Maybe you're right, but I'm not sure.
Anyway, here is the library version:

   libwnck-2.16.3-1.fc6.src.rpm

Meanwhile, I'm trying to gather stack trace information (gdb xchat). Never did
such things before, but I hope for the best  :)

I even got one stack trace from xchat, but I have strong feeling that it's not
the stack trace for my problem. Is it?

As I said I'm new to gdb, and, while doing "gdb xchat", I've been having those
annoying messages when gdb internal (?) pager stops output (and stops my xchat,
as well) every time when number of lines doesn't fit on my terminal:

   ---Type <return> to continue, or q <return> to quit---

That's why I'm not sure why my xchat finally got that SIGPIPE (see attachment):
because of initial problem, or because of my stupid gdb pager problems
:)
Comment 5 Michael V. Antosha 2007-09-05 12:57:13 EDT
gdb-6.5-15.fc6.src.rpm
xchat-2.6.6-4.fc6.src.rpm
Comment 6 Ray Strode [halfline] 2007-09-05 13:42:07 EDT
well, the clock, task switcher, workspace switcher, and show desktop button are
all provided by the same process (which is powered by libwnck), so when one
crashes they all go down.

The xchat and thunderbird issues may be separate.

How often do they crash?

We can try pushing an update for libwnck to see if it improves your situation. 
Would you be up for trying test packages?
Comment 7 Michael V. Antosha 2007-09-06 04:54:43 EDT
(In reply to comment #6)
>
> well, the clock, task switcher, workspace switcher, and show desktop button are
> all provided by the same process (which is powered by libwnck), so when one
> crashes they all go down.

hmm... actually, they don't always crash altogether.
It seems I can remember the day when only task switcher disappeared, no more.

I will pay more attention to this, and 'll give more info as soon as I can.

> The xchat and thunderbird issues may be separate.

Of course they can. It just seems to me they are all related.

Is there some relatively simple way to find out?
I'd like to try something to help in resolving the bug, but I don't know what
kind of help you need.

By the way, it's the problem with xchat/firefox/thunderbird/terminal, that
annoys me more, because panel application are easyly restored with that dialog I
told about earlier.

> How often do they crash?

Every day.
I don't remember the day when it didn't happen, at least once.

Usually it happens 1-2 (or more) times during each day.

> We can try pushing an update for libwnck to see if it improves your situation. 
> Would you be up for trying test packages?

I'm ready to install and try test versions of libwnck rpm.
I hope there should be no problems when I'll want to switch back to the original
libwnck?
Comment 8 Ray Strode [halfline] 2007-09-06 10:53:15 EDT
it won't be hard, but it will require you to run rpm from the command line

rpm -Uvh --oldpackage libwnck-theoldversion.i386.rpm 

or some such.

I'll try to push test packages to updates-testing for the libwnck issue.  It
won't help your xchat and firefox and thunderbird issues though.  Can you file
those as separate reports?
Comment 9 Michael V. Antosha 2007-09-07 12:49:10 EDT
okay, I'm ready to test rpm's from "updates-testing"
I'll be away for a week, but after that I'm available for continuing.

P.S. I've just created separate bug report, for xchat:

   https://bugzilla.redhat.com/show_bug.cgi?id=282691
Comment 10 Ray Strode [halfline] 2007-09-07 14:31:15 EDT
Should be libwnck-2.16.3-2.fc6 in updates-testing

I'll mark this MODIFIED now, and you can either close the bug or move back to
ASSIGNED when you've verified the packages (or just leave a comment with your
testing results and I can do the bug state frobbing)
Comment 11 Michael V. Antosha 2007-09-18 07:15:14 EDT
I've just updated the libwnck:

   yum update --enablerepo='updates-testing' libwnck-2.16.3-2.fc6

I have this package installed now:

===
Name        : libwnck                      Relocations: (not relocatable)
Version     : 2.16.3                            Vendor: Red Hat, Inc.
Release     : 2.fc6                         Build Date: 2007-09-06T19:36:07 EEST
Install Date: 2007-09-18T14:08:45 EEST      Build Host: hs20-bc2-2.build.redhat.com
Group       : System Environment/Libraries   Source RPM:
libwnck-2.16.3-2.fc6.src.rpm
Size        : 538825                           License: LGPL
Signature   : DSA/SHA1, 2007-09-07T18:57:41 EEST, Key ID da84cbd430c9ecf8
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
===

Now I'm waiting and observing...
As soon as I have my panel apps crashed I'll inform you.
Comment 12 Michael V. Antosha 2007-09-24 03:53:16 EDT
Created attachment 203941 [details]
print screen: dialog window about "clock quit" event

Well, it happened again. Now with the new version of libwnck
(libwnck-2.16.3-2.fc6.src.rpm, from updates-testing).

I've just unlocked my desktop after two-days absence, and got the dialog window
I told you about earlier (this time it was "Clock" application which quit). You
can see the dialog window in the attachment.

Neither of other panel applications (task switcher, window switcher) quit, by
the way. Now I'm absolutely sure about this.
Therefore, they don't quit altogether.

Is there a way to debug such sort of things?
I need a way to have my panel apps running from under GDB all the time.
Or some other way to get more info about the problem.

What I have to do now to be useful in finding the bug?
Comment 13 Ray Strode [halfline] 2007-09-24 07:57:40 EDT
Hi Michael,

The clock applet is separate.  The task switcher, window switcher, show desktop
button and window menu are the same (confusing I know).

you don't need to run everything under gdb all the time.  When one crashes and
the initial bugbuddy window pops up, you can install the -debuginfo package and
then attach to gdb then.

Note, if a lot of unrelated things seem to be crashing, it could be a hardware
issue.  Another thing you could try, is installing memtest86, rebooting into it
and letting it run overnight.  That might tell you if you have a bad ram stick.
Comment 14 Michael V. Antosha 2007-09-24 12:40:29 EDT
Hello, Ray!

I'm not sure I understood what "the initial bugbuddy window" means.
Is it that dialog window with "Reload" and "Don't Reload" buttons?

I'd like to be sure I understood you right.
Let me describe what I'm going to do:

Next time I get the same error message I will press neither "Reload", nor "Don't
Reload" button. I'll just leave that (bugbuddy's?) dialog window as it is.
Then (or maybe even now), I'll install the debuginfo package:

   yum --enablerepo='updates-debuginfo' gnome-panel-debuginfo

Then, while having the dialog untouched and gnome-panel-debuginfo installed,
I'll run gdb, attaching it to the PID of my /usr/libexec/clock-applet process.

Is this what I have to do or not?

By the way, what if the process (clock-applet) will no longer exist at the time
I try to attach gdb to it? (and I have a feeling that it will be this way)
I'll have no use of gdb, then.

As for hardware problems, I doubt they take place. Yes, I have problems with
several apps, but the problems are very similar (it seems to me). And I have no
problems of other kinds. In case of memory problems I would have a lot more
problems that are not similar to each other, and with different kinds of
applications. This is not what I have.

P.S. Debugging xchat and thunderbird, by the way, gives me the same results:

   X Window System error
   BadRequest (invalid request code or no such operation)
   error_code 1 request_code 0 minor_code 0

Now I'm trying to get backtraces for them by always running
xchat/firefox/thunderbird under GDB, with the break point at gdk_x_error()
function...
Comment 15 Michael V. Antosha 2007-10-02 10:43:25 EDT
Hi, Ray!

Now I have another "Clock has quit unexpectedly" dialog window...
I haven't closed the dialog window, and saved the output from "ps ax" to be sure
that the "clock-applet" process no longer exists. And I don't have any
bugbuddy's processes, as well (yes, I have bug-buddy installed -- does it need
special activation procedures to work properly?).

Do you insist that there's no need to use gdb (or some other instruments) to
find out the cause of the problems?

Should I open another bug report about this problem, with "gnome-panel" package
as a component (because this is about "libwnck" now)?
Comment 16 Michael V. Antosha 2007-10-02 11:07:57 EDT
Created attachment 213551 [details]
ps differences: before and after reloading the clock applet

this is what I told about (comment #15)
Comment 17 Ray Strode [halfline] 2007-10-02 11:13:26 EDT
hmm, if bug buddy doesn't come up then the process crash won't get caught.   You
can make the clock applet run under gdb by killing the process, running gdb
/usr/libexec/clock-applet, typing run, and then clicking the Reload button from
the dialog that came up after killing the process.

Yea, please file the clock thing as a separate bug report.


Comment 18 Michael V. Antosha 2007-10-03 04:12:50 EDT
Thanks for your advice!
I'm going to follow it.
Further investigation concerning the clock applet matter will be there:

   Bug 316521
Comment 19 Michael V. Antosha 2007-10-08 05:52:47 EDT
The problem persists: now wnck-applet (workspace switcher and window list) died
again. Should I try to run "wnck-applet" under gdb now?
Comment 20 Matěj Cepl 2007-12-10 04:21:47 EST
Fedora Core 6 is no longer supported, could you please reproduce this with the
updated version of the currently supported distribution (Fedora 7, 8, or
Rawhide)? If this issue turns out to still be reproducible, please let us know
in this bug report. If after a month's time we have not heard back from you, we
will have to close this bug as CANTFIX.

Setting status to NEEDINFO, and awaiting information from the reporter.

[This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or
Gecko. If you see any other reason, why this bug shouldn't be closed, please,
comment on it here.]
Comment 21 Matěj Cepl 2008-01-15 09:38:39 EST
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received feedback to the
information we have requested above, we will assume the problem was not
reproducible, or has been fixed in one of the updates we have released for the
reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest
update of their distribution, and if this issue turns out to still be
reproducible in the latest update, please reopen this bug with additional
information.

Closing as INSUFFICIENT_DATA.

{This is mass-closing of all obsolete bugs; if this bug was in your opinion
closed by mistake, please, reopen it with additional information; thanks a lot
and I am sorry for bothering you in such case.}

Note You need to log in before you can comment on or make changes to this bug.