After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 597435 - [PATCH] Crash when using interactive mode to take a screenshot of the active window
[PATCH] Crash when using interactive mode to take a screenshot of the active ...
Status: RESOLVED FIXED
Product: gnome-utils
Classification: Deprecated
Component: screenshot
2.26.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-utils Maintainers
gnome-utils Maintainers
: 648790 649306 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-10-05 16:15 UTC by Jérôme Guelfucci
Modified: 2011-06-13 20:22 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
a patch (1.18 KB, patch)
2009-11-24 23:46 UTC, Matthias Clasen 		none Details | Review

Description Jérôme Guelfucci 2009-10-05 16:15:10 UTC 
When using interactive mode to take a screenshot of the active window with a null delay, it results in a crash with the X BadWindow error.

From what I was able to understand, this happens because the window manager / Xserver does not update the active window quickly enough, so the detected active window is some garbage, then calling find_wm_window crashes.

Emmanuele Bassi was able to confirm this.
Comment 1 Matthias Clasen 2009-11-24 23:45:33 UTC 
Also reported here: https://bugzilla.redhat.com/show_bug.cgi?id=541006
Comment 2 Matthias Clasen 2009-11-24 23:46:24 UTC 
Created attachment 148419 [details] [review]
a patch

Here is a patch that fixes it. Just checking GDK_WINDOW_DESTROYED would be sufficient, actually.
Comment 3 Jérôme Guelfucci 2009-11-27 17:58:58 UTC 
This patch fixes the crash but the behaviour is weird : while the user selected the option to grab the active window, it grabs the desktop. Personally, I would expect to have the next focused window grabbed.
Comment 4 Matthias Clasen 2009-11-27 19:11:33 UTC 
A timeout of 0 is really just a pathological corner case. I would not worry too much about it. What might be nicer than the timeout business altogether would be to simply wait for the user to activate another window, and take a screenshot of that, regardless of how long it takes.
Comment 5 Cosimo Cecchi 2011-06-13 20:21:02 UTC 
I fixed this in git master now.
Comment 6 Cosimo Cecchi 2011-06-13 20:21:47 UTC 
*** Bug 648790 has been marked as a duplicate of this bug. ***
Comment 7 Cosimo Cecchi 2011-06-13 20:22:32 UTC 
*** Bug 649306 has been marked as a duplicate of this bug. ***