GNOME Bugzilla – Bug 336750
Shift-Printscreen causes gnome-screenshot to forkbomb
Last modified: 2015-09-17 16:33:24 UTC
Steps to reproduce: 1. Hit Printscreen. Sreenshot taken normally. 2. Hit Shift-Printscreen. No reaction, desktop appears to freeze. 3. SSH in from another machine and run "ps aux". Note lots and lots of gnome-screenshot processes. 4. "killall gnome-screenshot" doesn't help; more keep on getting created. 5. Only solution I've found once the forkbomb has launched is to reboot. Stack trace: Other information: This is a forkbomb rather than a crash, so I couldn't get a stack trace (in part because I didn't know which process was causing the forkbomb). So perhaps the "Crasher" status isn't correct, but it seemed the best way to describe the problem.
the screenshot application uses Print Screen for the whole desktop and alt + print screen for the focused window. anyway, I can't reproduce the bug (with alt + print screen).
Ubuntu bug about that: https://launchpad.net/products/gnome-utils/+bug/34492 "keybindings-properties: DoS by screenshot When using a keycombination such as: Alt-PrtScrn-s it is possible to cause a temporary Denial of Service on the machine as the gnome-screenshot utility is launched at a rate of $keyboard_repeat_rate per second, causing a huge number of processes to be sprawned. Ideally, this should be rate-limited to a maximum of two of the same key-action per second, or restrict sprawning further actions of the same type until the first one has completed loading. ..." Emmanuele, pressing the print key for some seconds should be enough to have an idea of the issue That bug is probably not critical though, updating the setting
I think using libguniqueapp would be a good solution to that problem I don't see any reason for multiple gnome-screenshot instance. If someone wants to do multiple screenshots, gnome-screenshot should allow that within itself.
*** Bug 361451 has been marked as a duplicate of this bug. ***
*** Bug 488866 has been marked as a duplicate of this bug. ***
This bug now appears again in gnome 2.24 (Tested under Ubuntu 8.10)
The Ubuntu bug just received a new comment that the DoS-by-Screenshot bug is still present, and indeed it is (as verified by holding down PrntScrn down for about five seconds and then dealing with the---somewhat delay---consequence).
This bug is still happening on 2.26 too.
xset -r <keycode> helps avoid the problem if it is an immediate issue, it disables autorepeat for the given key. keycode is 107 for evdev users. This is likely a key repeat issue similar to the one in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=506369 in some cases, repeat gets stuck though the cause is unknown as of yet.
Created attachment 148427 [details] [review] a patch Here is a patch that ignores key repeats for screenshooting. Maybe the same should be done for all run_command bindings.
-> metacity Reassigning the bug; the patch makes sense to me.
Created attachment 148649 [details] [review] new patch The first version of the patch had an oversight that made other run_command bindings work only once.
Review of attachment 148649 [details] [review]: I'm trying to test this patch, but when I hold down alt-PrintScreen it generates KeyRelease codes anyway, so the patch doesn't seem to be effective. Am I doing something obvious wrong?
does metacity/gtk set detectable autorepeat? if not, how does it detect key repeats?
This has been a problem for me for years (today I had over 390 gnome-screenshot processes), the reason being that sometimes one of our pet cats stands on the keyboard. I have also had dozens or even hundreds of yelp processes running. The screenshots were all called Untitled-2 by the way. I don't have a use case in which I'd want 400 screenshots of the same screen, all with the same filename. If it's smart enough to notice Untitled-1 and increment the counter, it needs to be smart enough to count to three and beyond. At least this keyboard doesn't have a button that turns off the computer - with the previous keyboard, the cat could turn off the computer, until I removed the key with a sharp knife. Seems to me that, (1) function keys have no need to auto-repeat (2) keyboard keys should not, by default, do destructive or irreversible things without active confirmation. "Your computer will turn off in 30 seconds unless you..." isn't going to work for a cat, and neither is "all your memory will be used up unless your cat moves." :-) I can live with one or two or even three or four screenshot windows if a cat is walking on the keyboard, but not 400.
Dupe of bug 737456?
Screenshot shortcuts are no longer part of metacity: 1) https://git.gnome.org/browse/gnome-settings-daemon/commit/plugins/media-keys?id=f32ae44259468baedc2044403237301ab7c0cd7b 2) https://git.gnome.org/browse/metacity/commit/src/include/all-keybindings.h?id=a228546d3cdf3364b82d76b374fb08aae202ab87