Bugzilla – Bug 15208
Closing graphic devices window by close button causes R to use 100% CPU if getGraphicsEvent was called before.
Last modified: 2013-10-23 09:10:03 UTC
If close your graphic device window using the close button ("X") provided by your window manager R consumes 100% CPU if you called getGraphicsEvent before.
Steps to Reproduce:
## in R:
## in another terminal
## close the graphic device window by hitting the close button and see "top" output
R consumes 100% CPU until you hit "Ctrl+C" in the R console.
Closing the graphic device window should quit getGraphicsEvent, too.
Build Date & Platform:
R version 2.15.2 Patched (2013-02-14 r61949)
Platform: x86_64-unknown-linux-gnu (64-bit)
 LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
 LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
 LC_PAPER=C LC_NAME=C
 LC_ADDRESS=C LC_TELEPHONE=C
 LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
 stats graphics grDevices utils datasets methods base
Created attachment 1476 [details]
Adds a helper function which determines if there are any graphics devices currently listening for events.
Calls the helper function at each polling step and throws an error if it returns false (no currently open graphics devices are listening for events).
The patch could be changed so that, eg, the helper function is only called when the number of open devices changes, but limited local testing did not indicate any significant performance benefit for doing so, and it made the code less clean.
Checking in to see if anyone has had a chance to look at this patch yet. If there is a problem with it I'm happy to submit a revised version.
I just confirmed the bug and Gabriel's patch fixes it, but I don't really like the behaviour. I see (in OS X) it immediately opens a new window as soon as I close the one that is waiting for the event. Wouldn't it be better to return NULL, perhaps with a warning, but not with an error?
I'll soon commit a version that returns NULL with no error or warning.
*** Bug 15500 has been marked as a duplicate of this bug. ***