New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
First call to 'xdotool search' from a graphical application returns BadWindow error #60
Comments
I wonder if this is a race condition. If a window is given by XQueryTree, and then before the window properties are queried, that window is deleted, then I could see how this error occurs. The fix may be to have libxdo's search feature ignore BadWindow errors. |
Is there any other circumstance that might cause a Would you have any suggestion on how I could debug this scenario so that I can give you more information to analyze ? Of course, if you need more information. I confess: my knowledge of X programming is 0. |
Workaround:
|
I'm getting the same problem on Ubuntu 18.04 with xdotool version 3.20160805.1. If I start the PC, start Firefox, and then later run xdotool to find it, I get the error on the first attempt, then subsequent attempts are fine. The exact circumstances are somewhat difficult to pin down but it will sometimes reappear if I restart Firefox, (I always wait for it to start fully) and then the first attempt after that sometimes fails.
I'm now running it twice, dumping errors from the first to /dev/null, but I can try to debug this if anybody's got suggestions as to how. |
I have the problem on Linux Mint 19, with xdotool 3.+20180415.1. |
|
I've been getting this (the X_QueryTree error on first search) since I release upgraded to Kubuntu 19.10. But today, after a git pull and recompile, it's stopped happening. The previous version was built on 2019-10-03. I had scripted a retry on the first failure, after logging it. |
I can confirm that I am getting the same issue on openSUSE tumbleweed with xdotool version 3.20160805.1. I am running
|
I now work around this by looping with
Presently, f I invoke the script from a widget in a panel, it fails once every time. The same script from the menu gets no error. |
The problem persist in xdotool 3.20160805.1-2. When 'xdotool search' is launched repeatedly from a PyQt app, it fails randomly, about 1 time out of 30. Calling the function more slowly, ie. each 2s vs continuous blocking calls) reduce the likelihood of the error, so it look like a race condition.. It can be worked around but it's not pretty
|
Made a simple |
When window disappear while search is trying to access it (either check its properties, or enumerate its children), X server will generate BadWindow error. Try to trigger this race, by opening 100 short living windows and execute xdotool search at the same time. The search should not crash, and since the window subject to search is there all the time, it should be found. The test relies on a specific siming, specifically that launching 100 instance of xterm takes more than 100ms, and that going from setup to the actual test takes less than 100ms. Those conditions are rather reasonable, and the test works reliably for me (at this stage - it fails - the fix is comming in the next commit). Related to jordansissel#60
When a window is destroyed while search command tries to inspect it (get its title, class or so), the X server generates BadWindow error. The default error handler terminates the program. This means the search can fail if any window is destroyed in the meantime, regardless if the window matches the search criteria or not. Fix this by setting an alternative error handler for the search time, that ignores BadWindow error. This makes the relevant libX11 functions return (with a negative status) in case of BadWindow error, instead of interrupting the whole xdotool process. While at it, fix uninitialized 'children' variable in XQueryTree error handling. Fix jordansissel#60
* Add a test for search race condition When window disappear while search is trying to access it (either check its properties, or enumerate its children), X server will generate BadWindow error. Try to trigger this race, by opening 100 short living windows and execute xdotool search at the same time. The search should not crash, and since the window subject to search is there all the time, it should be found. The test relies on a specific siming, specifically that launching 100 instance of xterm takes more than 100ms, and that going from setup to the actual test takes less than 100ms. Those conditions are rather reasonable, and the test works reliably for me (at this stage - it fails - the fix is comming in the next commit). Related to #60 * Fix race condition in search command When a window is destroyed while search command tries to inspect it (get its title, class or so), the X server generates BadWindow error. The default error handler terminates the program. This means the search can fail if any window is destroyed in the meantime, regardless if the window matches the search criteria or not. Fix this by setting an alternative error handler for the search time, that ignores BadWindow error. This makes the relevant libX11 functions return (with a negative status) in case of BadWindow error, instead of interrupting the whole xdotool process. While at it, fix uninitialized 'children' variable in XQueryTree error handling. Fix #60
* Add a test for search race condition When window disappear while search is trying to access it (either check its properties, or enumerate its children), X server will generate BadWindow error. Try to trigger this race, by opening 100 short living windows and execute xdotool search at the same time. The search should not crash, and since the window subject to search is there all the time, it should be found. The test relies on a specific siming, specifically that launching 100 instance of xterm takes more than 100ms, and that going from setup to the actual test takes less than 100ms. Those conditions are rather reasonable, and the test works reliably for me (at this stage - it fails - the fix is comming in the next commit). Related to jordansissel#60 * Fix race condition in search command When a window is destroyed while search command tries to inspect it (get its title, class or so), the X server generates BadWindow error. The default error handler terminates the program. This means the search can fail if any window is destroyed in the meantime, regardless if the window matches the search criteria or not. Fix this by setting an alternative error handler for the search time, that ignores BadWindow error. This makes the relevant libX11 functions return (with a negative status) in case of BadWindow error, instead of interrupting the whole xdotool process. While at it, fix uninitialized 'children' variable in XQueryTree error handling. Fix jordansissel#60
The 1st call to
xdotool search
from within a graphical application returns aBadWindow
error:The 2nd and subsequent calls don't return errors. If called directly from
bash
, no errors are returned.It's reproducible, suffice it to create a simple script with these lines:
and then run it from
bash
and a graphical app (I called the script from pluginCustom Commands
inquodlibet
, or from a.desktop
file as an external editor ingeeqie
).puddletag
can be replaced with any other suitable app name. When called frombash
directly, these were the (correct) resultsbut when called from either
quodlibet
orgeeqie
, the firstsearch
call failed and the second succeeded:This error was not tied neither to
quodlibet
nor togeeqie
: when called from any graphical application, whetherGTK+
orQt
,xdotool search
always failed with theBadWindow
error on its first invocation.I'm using:
xdotool
3.20130111.1-5xserver-xorg
7.7+7ubuntu2xfce
4.11Xubuntu
14.10The text was updated successfully, but these errors were encountered: