GTK errors out with XI_BadDevice error

[Swâmi Petaramesh]

SRU Justificaiton
-----------------

Impact:

This bug causes fatal X session errors when resuming. This bug is affecting a large Canonical OEM on certain yet-to-be-released platforms and will greatly impact the release schedule if this is not fixed.

Fix:

Add gdk_x11_display_error_trap_push() and gdk_x11_display_error_trap_pop() calls around XIQueryDevice() and conditionally use it's result instead of assuming it succeeded.

Patch:

http://git.gnome.org/browse/gtk+/commit/?id=9b967ab8aff46b79494d75a3129fa8780545ecd1

Regression Potential:

There should be very little potential for regression.

TEST CASE:

* Log in to a gnome session.
* Suspend system
  - Close laptop lid or select suspend from indicator-session in the upper right hand
    corner of the screen.
* Resume by pressing the power button.
* Your desktop session should still be available. If the bug persists, gnome-session will
  crash and you'll be returned to LightDM.

------------------------

This issue looks somewhat recent, I don't recall it ever happening in the past.

On Dell XPS M1330, Oneiric, when resuming from "suspend to RAM" the X server and Gnome session dies and I'm back to the DM.

I file this under "Gnome-session" as the same machine shows absolutely no problem when resuming in a KDE session.

Video is: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: gnome-session 3.2.1-0ubuntu1
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Uname: Linux 3.0.0-12-generic i686
ApportVersion: 1.23-0ubuntu3
Architecture: i386
CheckboxSubmission: 1ea6109db29b53f721a523a77b7f3abf
CheckboxSystem: d00f84de8a555815fa1c4660280da308
Date: Fri Oct 28 09:43:26 2011
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=fr_FR:fr:en_US:en
 PATH=(custom, user)
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-session
UpgradeStatus: Upgraded to oneiric on 2011-10-01 (26 days ago)

[Bojan (bojan-redhat-bugs)]

Description of problem:
On suspend, kernel hangs. If iwlagn is put in SUSPEND_MODULES, suspend will succeed, but other problems are encountered on resume, such as gnome-terminals going away (probably because GConf dies in the background).

Version-Release number of selected component (if applicable):
2.6.40.1-0.fc15.x86_64
2.6.40-4.fc15.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Boot into Gnome.
2. Try to suspend.

Actual results:
Hangs on suspend after VT switch.

Expected results:
Did not hang with 2.6.38.8-35.fc15.x86_64.

Additional info:
Listing iwlagn in SUSPEND_MODULES helps only marginally, as explained above.

Similar problems reported here:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/811214
https://bugzilla.kernel.org/show_bug.cgi?id=40072
http://lists.debian.org/debian-kernel/2011/07/msg00639.html

[Bojan (bojan-redhat-bugs)]

Kernel kernel-2.6.40.1-1.fc15.x86_64 from koji indeed fixes the suspend problem.

However, on resume, all gnome-terminals are gone. I still don't know why that is.

[Bojan (bojan-redhat-bugs)]

Kernel 2.6.40.1-2.fc15.x86_64 is not much better. On resume, nautius died this time. On second resume/suspend cycle, gnome-panel died and was automatically restarted (i.e. I can see a different PID for it).

So, something is still very wrong on suspend/resume here.

[Hans (hans-redhat-bugs)]

Not sure of this is an oversight, or deliberate since this bug is still being worked on, but judging from the kernel spec changelog , this patch has not been added to F-16, I guess we want it there too?

[Bojan (bojan-redhat-bugs)]

(In reply to comment #3)
> Not sure of this is an oversight, or deliberate since this bug is still being
> worked on, but judging from the kernel spec changelog , this patch has not been
> added to F-16, I guess we want it there too?

I'm having a feeling upstream is working on a different, more complicated fix for this. So, maybe that will go into F-16 when upstream finalises it?

Anyway, as I said before, even with the fix, I'm losing processes on resume, so things are still not as good as on .38.

[Bojan (bojan-redhat-bugs)]

Just tried 2.6.40.2-0.fc15.x86_64. Still no good. It comes back from suspend and a whole lot of stuff dies. I'll attach a screenshot of what popped up, but Evo died, gnome-terminals did too and more.

[Bojan (bojan-redhat-bugs)]

Created attachment 518164
Programs die on resume in Gnome

[Fedora (fedora-redhat-bugs)]

kernel-2.6.40.3-0.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/kernel-2.6.40.3-0.fc15

[Fedora (fedora-redhat-bugs)]

Package kernel-2.6.40.3-0.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-2.6.40.3-0.fc15'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/kernel-2.6.40.3-0.fc15
then log in and leave karma (feedback).

[Fedora (fedora-redhat-bugs)]

kernel-2.6.40.3-0.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.

[Bojan (bojan-redhat-bugs)]

Reopening, changing what the problem actually is.

[Bojan (bojan-redhat-bugs)]

Note that with kernel-2.6.40.3-0.fc15 the problem is less severe, but it still happens. I have seen gnome-panel and nautilus die on resume thus far. The widespread process death (as seen in the screenshots) is not happening any more, but there is no doubt that the problem still persists.

[Dave (dave-redhat-bugs)]

please attach a dmesg from after the resume when things have been killed.

[Bojan (bojan-redhat-bugs)]

Created attachment 518969
dmesg on resume when processes die

[Bojan (bojan-redhat-bugs)]

And again, X crash on resume. Nothing worth reporting in the log. Abrt didn't catch anything.

[Bojan (bojan-redhat-bugs)]

Ditto with 2.6.40.6-0.fc15.x86_64.

[Bojan (bojan-redhat-bugs)]

Not sure whether this is a fluke, but I cannot replicate this with F-16 Beta Live on the same hardware. Suspended/resumed many times. Hmm...

[Bojan (bojan-redhat-bugs)]

(In reply to comment #46)
> And again, X crash on resume. Nothing worth reporting in the log. Abrt didn't
> catch anything.

Another crash of X on resume, this time with no Gnome sessions opened (i.e. at GDM login screen).

[Fedora (fedora-redhat-bugs)]

This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.

[Peter (peter-redhat-bugs)]

I'm just going to reassign this to gtk for now. XI_BadDevice is the standard error clients will get when they use an invalid device parameter for an X Input extension request. Even if there's a bug in the server or libXi, since devices can disappear at any time, any client must expect such an error to happen and handle it appropriately.

[Matthias (matthias-redhat-bugs)]

(In reply to comment #45)
> This must be something in one of the libraries. For the first time I had Evo
> die as well:
> --------------------------
> (evolution:1995): Gdk-WARNING **: The program 'evolution' received an X Window
> System error.
> This probably reflects a bug in the program.
> The error was 'XI_BadDevice (invalid Device parameter)'.
> (Details: serial 236980 error_code 149 request_code 141 minor_code 48)
> (Note to programmers: normally, X errors are reported asynchronously;
> that is, you will receive the error a while after causing it.
> To debug your program, run it with the --sync command line
> option to change this behavior. You can then get a meaningful
> backtrace from your debugger if you break on the gdk_x_error() function.)
> --------------------------

Can you do what GTK+ is asking you to do in those messages you posted ?

[Bojan (bojan-redhat-bugs)]

(In reply to comment #52)

> Can you do what GTK+ is asking you to do in those messages you posted ?

I actually tried this (although some programs that are crashing were not aware of --sync option), but was unable to replicate the problem. I'll try again.

[Bojan (bojan-redhat-bugs)]

nautilus: doesn't understand --sync
gnome-terminal: doesn't understand --sync
gnome-panel: doesn't understand --sync

These crash most often. Any other ideas?

[Matthias (matthias-redhat-bugs)]

Oh bummer. Looks like that error message is outdated in gdk.

You can set the GDK_SYNCHRONIZE env var to achieve the same, nowadays.

[Bojan (bojan-redhat-bugs)]

Running things like that now. I set break gdk_x_error() in gdb instances that are tracing several binaries that usually crash. Of course, now they won't crash - isn't it always like this? :-(

Will keep running my system like this in the hope that they do eventually crash. Keep you posted.

[Luca (luca-redhat-bugs)]

I think I'm hitting this bug on my Thinkpad T510 with F15 and gnome. It happens frequently after resuming from suspend, sometimes the whole Xorg session crashes while some others just some program gets terminated.

Excerpt from my .xsession-errors:

(gnome-power-manager:12475): Gdk-WARNING **: The program 'gnome-power-manager' received an X Window System error.
This probably reflects a bug in the program.
The error was 'XI_BadDevice (invalid Device parameter)'.
  (Details: serial 24339 error_code 149 request_code 141 minor_code 48)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

(gnome-screensaver:12420): Gdk-WARNING **: The program 'gnome-screensaver' received an X Window System error.
This probably reflects a bug in the program.
The error was 'XI_BadDevice (invalid Device parameter)'.
  (Details: serial 25521 error_code 149 request_code 141 minor_code 48)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

gnome-session[12202]: WARNING: Detected that screensaver has left the bus

(gnome-settings-daemon:12366): media-keys-plugin-WARNING **: Unable to get default sink
** (deja-dup-monitor:12421): DEBUG: monitor.vala:263: Invalid next run date. Not scheduling a backup.
Error getting primary device: GDBus.Error:org.gnome.PowerManager.Failed: There is no primary device to reflect system state (don't show any UI)
gnome-session[12202]: WARNING: Detected that screensaver has left the bus
gnome-session[12202]: WARNING: Detected that screensaver has left the bus
gnome-session[12202]: WARNING: Detected that screensaver has left the bus

Please let me know if there is anything I can do to help identifying the root cause of the issue.

[Bojan (bojan-redhat-bugs)]

I was tracing notification area applet in gdb with that environment variable set to 1, but got nothing - the program did not break on gdk_x_error() function at all - just existed. No stack.

No idea what to do next.

[Bojan (bojan-redhat-bugs)]

I meant to say, just exited, not just existed.

[Dag (dag-redhat-bugs)]

Hans de Goede forwarded me to this problem, I am not sure if this is related.

On RHEL 6.2 Beta I have had a few incidents that after a resume I immediately get a complaint of Gnome that was XKB related. The window reappears immediately after close for about 15 times.

Meanwhile, any Gnome application complains about unable to write (eg. LibreOffice etc...). While inside a terminal window there are no I/O related issues, all file systems are mounted r/w and I can still perform writes to disk. So it's as if the gnome-vfs back-end died or something ?

If there's anything I can do to increase verbosity in order to analyse this better next time, let me know. If this deserves another bug report, I'll do that as well.

PS Looking at .xsession-errors.old I find (among others) the below, but I am not entirely sure that this was a direct result from the problem (ie. it might have been due to a shutdown). The fact that this file has no timestamps makes it hard to relate it with incidents after the fact:

----

 (polkit-gnome-authentication-agent-1:2627): polkit-gnome-1-WARNING **: Error enumerating temporary authorizations: Remote Exception invoking org.freedesktop.PolicyKit1.Authority.EnumerateTemporaryAuthorizations() on /org/freedesktop/PolicyKit1/Authority at name org.freedesktop.Po licyKit1: org.freedesktop.PolicyKit1.Error.Failed: Cannot determine session the caller is in
 gnome-settings-daemon: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 gpk-update-icon: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 gnome-volume-control-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 gdu-notification-daemon: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 local: fatal IO error 11 (Resource temporarily unavailable) or KillClient on X server ":0.0"
 polkit-gnome-authentication-agent-1: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 bluetooth-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 seapplet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 applet.py: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 abrt-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 gnome-screensaver: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 nm-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 Stopping Bluetooth ObexFTP server failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
----

[Hans (hans-redhat-bugs)]

While trying to find this bug for Dag, I did a google search and I also found this archlinux bug, which almost certainly is the same issue, and which *may* contain relevant info:

https://bugs.archlinux.org/task/24096

[Bojan (bojan-redhat-bugs)]

(In reply to comment #61)
> While trying to find this bug for Dag, I did a google search and I also found
> this archlinux bug, which almost certainly is the same issue, and which *may*
> contain relevant info:
>
> https://bugs.archlinux.org/task/24096

Yeah, that looks like the same thing.

Dag's RHEL 6.2 problem, don't think so.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Paweł Moll (pawel-moll)]

This entry in syslog seems relevant (full suspend and resume log attached):

Oct 29 18:55:01 rojo gnome-session[9054]: Gdk-WARNING: The program 'gnome-session' received an X Window System error.#012This probably reflects a bug in the program.#012The error was 'XI_BadDevice (invalid Device parameter)'.#012 (Details: serial 167 error_code 149 request_code 141 minor_code 48)#012 (Note to programmers: normally, X errors are reported asynchronously;#012 that is, you will receive the error a while after causing it.#012 To debug your program, run it with the --sync command line#012 option to change this behavior. You can then get a meaningful#012 backtrace from your debugger if you break on the gdk_x_error() function.)#012

(I have the same XPS M1330 variant, but use x86_64 arch)

[Bojan (bojan-redhat-bugs)]

I upgraded my laptop to F-16 now. Didn't have this problem on resume yet, but it might be just a fluke.

PS. I am running metacity again, because of bug #750476. As we've seen from other people's reports here, it shouldn't matter, but just for the record.

[erny (erevilla)]

It seems that a "xinput" device is not resuming correctly. I bet this is the integrated cam or synaptics touchpad.

The same error in RH bug tracker:
https://bugzilla.redhat.com/show_bug.cgi?id=728044

[erny (erevilla)]

Hi.

Could you please try the following:

 * Create a file /etc/pm/sleep.d/50_custom with the following content:

--8<-- cut --8<-- cut --8<-- cut --8<-- cut --8<-- cut --8<-- cut --8<--
#!/bin/sh

# Action script to shutdown modules before suspending.
# before a hibernate
#
# Copyright: Copyright (c) 2009 Ernesto Revilla
# License: GPL-2
#

PATH=/sbin:/usr/sbin:/bin:/usr/bin

case "${1}" in
        suspend|suspend_hybrid|hibernate)
            rmmod uvcvideo
            rmmod usbhid
            rmmod psmouse
                ;;

        resume|thaw)
            modprobe uvcvideo
            modprobe usbhid
            modprobe psmouse
                ;;

--8<-- cut --8<-- cut --8<-- cut --8<-- cut --8<-- cut --8<-- cut --8<--

Regards

[Ernesto (ernesto-redhat-bugs)]

Hi.

I had a similar issue:
https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/882956

(see https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/882956/comments/4)

I could resolve it by unloading kernel modules before suspend. That removes X input devices. After wakeup, I just load modules again.

Regards.

[Ivan Jimenez (ij-dakar)]

erny (erevilla):

This patch seems to work, at least until now. I had this problem but it would not happen every time I suspended. I will see how it behaves now.

Thank you!

[Bojan (bojan-redhat-bugs)]

(In reply to comment #64)
> Hi.
>
> I had a similar issue:
> https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/882956
>
> (see
> https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/882956/comments/4)
>
> I could resolve it by unloading kernel modules before suspend. That removes X
> input devices. After wakeup, I just load modules again.

Thanks for the tips. These sound like workarounds more than solutions to me, to be honest.

Anyhow, I'm now on Fedora 16 and I haven't had this happen once. So, maybe there is hope. :-)

[Paweł Moll (pawel-moll)]

I'd just like to point out that the mentioned script:

1. Is missing "esac" at the end of the file
2. Must be made executable (sudo chmod +x 50_custom)

I'll do some testing during the next few days and report.

[Swâmi Petaramesh (swami-petaramesh)]

I'm normally more of a KDE user (and I went back to KDE because of this error, among other issues and dislikes I have with Gnome).

However I've been back to Gnome for testing this issue, and have to say that since latest updates, I've been unable to reproduce the Gnome crash at system wake up. (I've done it only 5-6 times without a crash, where previously it would crash most, if not all, the times).

- I've tried without the above script, so the conditions are the same as before (except for the DM maybe ? I'm back to KDM...), and would have nothing more to report anyway as I couldn't observe the crash.

So I'm not sure whether the issue is still there or has been fixed ? I will try again for a while and let you know.

[Bojan (bojan-redhat-bugs)]

(In reply to comment #65)

> Anyhow, I'm now on Fedora 16 and I haven't had this happen once. So, maybe
> there is hope. :-)

Still haven't seen this in F-16. I know I'm going to regret saying this, but it looks like it's been fixed there.

[Bojan (bojan-redhat-bugs)]

(In reply to comment #66)
> I know I'm going to regret saying this, but it
> looks like it's been fixed there.

I knew I'd eat my words here. Yeah, it happened - essentially everything went down and I got logged off. I'll attach .xsession-errors form F-16.

[Bojan (bojan-redhat-bugs)]

Created attachment 532925
X session errors from F-16 (got completely logged out)

[Matthias (matthias-redhat-bugs)]

Unfortunately, all those xsession-errors, and X logs are of no use here. I really need a stack trace from a crashing client, to show which X request is triggering the BadDevice.

[Bojan (bojan-redhat-bugs)]

(In reply to comment #69)
> Unfortunately, all those xsession-errors, and X logs are of no use here. I
> really need a stack trace from a crashing client, to show which X request is
> triggering the BadDevice.

As you can see from comment #58 and above, I tried. Got absolutely nothing in gdb. No idea what to do next.

[Sebastien Bacher (seb128)]

Could somebody having the issue get a stacktrace as described on https://wiki.ubuntu.com/Backtrace

[erny (erevilla)]

Hi.

If nobody does provide one, I'll try to. It does not seem trivial to me. I'll see if I can give feedback within some days.

[Pedro Villavicencio (pedro)]

erny any news regarding the backtrace?

[Bojan (bojan-redhat-bugs)]

Just FYI, new Intel X graphics drivers didn't make a difference here.

[Ernesto (ernesto-redhat-bugs)]

No, it's a input device. Does the computer has a fingerprint reader?

[Bojan (bojan-redhat-bugs)]

(In reply to comment #72)
> No, it's a input device. Does the computer has a fingerprint reader?

It does.

[micred (tict)]

To get the stacktrace we have to attach to gnome-session, right?

[micred (tict)]

I'm debugging wrong. Please give me some suggestion.
I've attached gdb to gnome-session, I have reproduce the bug (sudo /usr/share/checkbox/scripts/suspend_test --enable repeat) but this is all I get:
...
[Thread 0x7fa275fa2700 (LWP 2232) exited]
[Thread 0x7fa2757a1700 (LWP 2233) exited]
[Thread 0x7fa274fa0700 (LWP 2241) exited]
[Inferior 1 (process 2186) exited with code 01]
(gdb) backtrace full
No stack.
(gdb) info registers
The program has no registers now.
(gdb) x/16i $pc
No registers.

Suggestions?

[erny (erevilla)]

Well, I would attach to one of the applications which get killed, not gnome-session.

I was much more thinking about a X application like gedit, nautilus, etc.

For Pedro:

Sorry, I've still not had the time. I'll try to this weekend if the bug still persists in Ubuntu 11.10

Regards.

[Bojan (bojan-redhat-bugs)]

Created attachment 537274
Kernel divide error when trying to replicate this problem in F-16

This happened probably after about 50 suspend/resume cycles. The box hung. 3.1.2-1.fc16.x86_64. Just FYI.

[erny (erevilla)]

Yesterday I was testing the suspend / wakeup cycle during nearly 2 hours. Currently it is much less frequent and very difficult to reproduce. I just got one gnome crash at the beginning. I tried to get a backtrace of gnome-session process crash, but I wasn't able to do it. This morning I got a wakeup crash again, but I hadn't the debugger attached. Sorry. (Now I'll try to run it with a debugger attached whenever I can using a script.)

It has definitely to do with some X input device (uvcvideo, psmouse, usbhid). Some more notes:
 * I had ThinkFinger package installed until after upgrade to 11.10. I removed it and the system seems more stable.
 * I used GDK_SYNCHRONIZE=1 to see if it makes a difference, that seems not to be the case

Regards.
Erny

[Samuel (samuel-redhat-bugs)]

I get this regularly with F16. It may be be aggravated by the fact that I'm suspending it while docked and resuming without. The laptop has a fingerprint reader, but it isn't supported, so that's most likely not relevant.

[Bojan (bojan-redhat-bugs)]

(In reply to comment #74)
> Created attachment 537274 [details]
> Kernel divide error when trying to replicate this problem in F-16
>
> This happened probably after about 50 suspend/resume cycles. The box hung.
> 3.1.2-1.fc16.x86_64. Just FYI.

And again. Looks like newer kernel are even more rotten on this hardware.

[Matthias (matthias-redhat-bugs)]

The only thing that will help fix this bug is an actual stacktrace...

[Samuel (samuel-redhat-bugs)]

I have no idea what to get a stacktrace on. The last time this happened there was no indication in any of the logs to suggest what happened.

[Bojan (bojan-redhat-bugs)]

(In reply to comment #77)
> The only thing that will help fix this bug is an actual stacktrace...

Been running nautilus, gnome-terminal and gnome-panel like this for a while, under the gdb, with GDK_SYNCHRONIZE=1. It either doesn't happen (did suspend/resume in the vicinity of 300 times like that) or when it does, there is no usable trace.

Will keep trying...

[Bojan (bojan-redhat-bugs)]

(In reply to comment #79)

> Will keep trying...

For instance, I just switched user a few times, which crashed my X session. Got no usable traces from that.

[Samuel (samuel-redhat-bugs)]

Upstream bug for the chipset I have:
https://bugs.freedesktop.org/show_bug.cgi?id=40625

[Fedora (fedora-redhat-bugs)]

gtk3-3.2.2-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/gtk3-3.2.2-2.fc16

[Swâmi Petaramesh (swami-petaramesh)]

Might or not be related... As I'm back to my good old KDE, I couldn't give more feedback on this issue.

But yesterday I've noticed that my KDE had turned off desktop effects "because it crashed once", and I reactivated them. It works. But since I've noticed a couple of KDE session crashes at system wakeup - just as Gnome does - where it was never happening before I reactivated KDE's desktop effects...

[erny (erevilla)]

When I had a crash, GDB didn't return anything useful:

[Thread 0x7f07f3bf1700 (LWP 10342) terminado]
[Thread 0x7f07f33f0700 (LWP 10345) terminado]
[Thread 0x7f07f2bef700 (LWP 10346) terminado]
[Inferior 1 (process 10286) exited with code 01]
(gdb) No stack.
(gdb) El programa no tiene registros ahora.
(gdb) No hay registros.

Any suggestions?

[Fedora (fedora-redhat-bugs)]

Package gtk3-3.2.2-2.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gtk3-3.2.2-2.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-16634/gtk3-3.2.2-2.fc16
then log in and leave karma (feedback).

[Bojan (bojan-redhat-bugs)]

Thank you for pushing this update. Of course, it will take a while to verify that the problem is fixed. Will keep you posted.

[Fedora (fedora-redhat-bugs)]

gtk3-3.2.2-2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gtk+3.0 - 3.3.6-0ubuntu1

---------------
gtk+3.0 (3.3.6-0ubuntu1) precise; urgency=low

  * New upstream version, dropped the patches backported from git:
    - trap XIQueryDevice errors to avoid sessions errors issues after suspend
      (lp: #882956)
    - don't grab mouse input when the menu bar or the resize-grip are clicked
      (lp: #878859)
  * debian/control.in:
    - updated glib requirement
  * debian/libgtk-3-0.postinst.in, debian/rules:
    - don't list the old non-multi-arch ims directory, everything using gtk3
      should be updated and it breaks the update when the directory is empty
      (lp: #908801)
  * debian/libgtk-3-0.symbols:
    - new version update
  * debian/patches/003_gdk.pc_privates.patch:
    - dropped, upstream did similar changes in the new version
  * debian/patches/042_treeview_single-focus.patch:
    - comment that debian change, it has no comment explaining what it's
      supposed to do and needs to be updating if still needed.
  * debian/rules:
    - updated shlibs version
 -- Sebastien Bacher <email address hidden> Tue, 03 Jan 2012 22:35:24 +0100

[Christopher Townsend (townsend)]

OEM Priority justification:

This is affecting a large Canonical OEM on certain yet-to-be-released platforms and will greatly impact the release schedule if this is not fixed.

[Martin Pitt (pitti)]

Uploaded, unsubscribing sponsors.

[Martin Pitt (pitti)]

Hello Swâmi, or anyone else affected,

Accepted gtk+3.0 into oneiric-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Chris Van Hoof (vanhoof)]

The package https://launchpad.net/ubuntu/oneiric/+source/gtk+3.0/3.2.0-0ubuntu6 has been confirmed to fix the issue reported in this bug.

--chris

[Launchpad Janitor (janitor)]

This bug was fixed in the package gtk+3.0 - 3.2.0-0ubuntu6

---------------
gtk+3.0 (3.2.0-0ubuntu6) oneiric-proposed; urgency=low

  * Add git_push_error_traps_around_xiquerydevice_calls.patch:
    git backport to handle session errors after suspend/resume. This may help
    against the crashes at resume time that some people have been hitting when
    input devices mysteriously disappear. (LP: #882956)

gtk+3.0 (3.2.0-0ubuntu5) oneiric-proposed; urgency=low

  * Add git_cell_area_editing.patch: Fix signal emission for cell areas when
    clicking a different widget after editing. Patch backported from newer GTK
    versions. (LP: #898114)
 -- Ayan George <email address hidden> Fri, 03 Feb 2012 12:02:39 -0500