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.
(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.
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
Created attachment 187721 [details] my first gdb trace for xchat, got SIGPIPE
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 :)
gdb-6.5-15.fc6.src.rpm xchat-2.6.6-4.fc6.src.rpm
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?
(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?
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?
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
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)
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.
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?
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.
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...
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)?
Created attachment 213551 [details] ps differences: before and after reloading the clock applet this is what I told about (comment #15)
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.
Thanks for your advice! I'm going to follow it. Further investigation concerning the clock applet matter will be there: Bug 316521
The problem persists: now wnck-applet (workspace switcher and window list) died again. Should I try to run "wnck-applet" under gdb now?
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.]
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.}