Skip to content
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

Closed
marcelpaulo opened this issue Mar 25, 2015 · 11 comments · Fixed by #335
Closed

Comments

@marcelpaulo
Copy link

The 1st call to xdotool search from within a graphical application returns a BadWindow error:

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  3 (X_GetWindowAttributes)
  Resource id in failed request:  0x4e011ca
  Serial number of failed request:  318
  Current serial number in output stream:  319

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:

#!/bin/bash
echo 'Attempt #1'
xdotool search --class puddletag
echo 'Attempt #2'
xdotool search --class puddletag

and then run it from bash and a graphical app (I called the script from plugin Custom Commands in quodlibet, or from a .desktop file as an external editor in geeqie). puddletag can be replaced with any other suitable app name. When called from bash directly, these were the (correct) results

Attempt #1
65011714
65011732
Attempt #2
65011714
65011732

but when called from either quodlibet or geeqie, the first search call failed and the second succeeded:

Attempt #1
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  3 (X_GetWindowAttributes)
  Resource id in failed request:  0x4e011ca
  Serial number of failed request:  318
  Current serial number in output stream:  319
Attempt #2
65011714
65011732

This error was not tied neither to quodlibet nor to geeqie: when called from any graphical application, whether GTK+ or Qt, xdotool search always failed with the BadWindow error on its first invocation.

I'm using:

xdotool 3.20130111.1-5
xserver-xorg 7.7+7ubuntu2
xfce 4.11
Xubuntu 14.10

@jordansissel
Copy link
Owner

I wonder if this is a race condition. search will list windows (via XQueryTree), then, for each window listed, queries the window's properties.

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.

@marcelpaulo
Copy link
Author

Is there any other circumstance that might cause a BadWindow error, or is this the only one ?

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.

@kenorb
Copy link

kenorb commented Oct 6, 2015

Workaround:

set +e
WINDOW_ID=$(xdotool search --name "Foo*")
set -e

@daver1691
Copy link

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.

$  xdotool search --classname Navigator
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  15 (X_QueryTree)
  Resource id in failed request:  0x1a343ef
  Serial number of failed request:  402
  Current serial number in output stream:  402
$  xdotool search --classname Navigator
  56623120

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.

@ghost
Copy link

ghost commented Sep 19, 2018

I have the problem on Linux Mint 19, with xdotool 3.+20180415.1.

@sabrehagen
Copy link

Slack window id from --search: 18874369
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  12 (X_ConfigureWindow)
  Resource id in failed request:  0x1200001
  Serial number of failed request:  18
  Current serial number in output stream:  20
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  3 (X_GetWindowAttributes)
  Resource id in failed request:  0x1200001
  Serial number of failed request:  18
  Current serial number in output stream:  19

xdotool version 3.20160805.1
Ubuntu 19.04

@jlittlenz
Copy link

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.
No X windows were opening or closing when the error occurred. Yesterday it reproduced every time.

@tgharib
Copy link

tgharib commented Dec 27, 2019

I can confirm that I am getting the same issue on openSUSE tumbleweed with xdotool version 3.20160805.1.

I am running xdotool search --class "dota2" in a terminal bash script. It runs roughly once an hour. Randomly ~5% of the time, it fails with this output:

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  15 (X_QueryTree)
  Resource id in failed request:  0x2404083
  Serial number of failed request:  489
  Current serial number in output stream:  489

@jlittlenz
Copy link

I now work around this by looping with

    errors=$(xdotool search --name whatever windowactivate 2>&1)
    if [[ -z "$errors" ]]; then
        .... no problem
        break
    fi
   .... log error

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.

@willbelr
Copy link

willbelr commented Feb 1, 2020

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

def _embed(self, ref):
        """ Find and embed the terminal window into a QWindow > QWidget > Layout """
        fetch = QtCore.QProcess(self)
        fetch.start(f"xdotool search --sync --classname {ref}")
        fetch.waitForFinished()
        wid = fetch.readAllStandardOutput().split("\n")[0]
        err = str(fetch.readAllStandardError().split("\n")[0])

        if wid:
            self.window = QtGui.QWindow.fromWinId(int(wid))
            self.widget = QtWidgets.QWidget.createWindowContainer(self.window, self)
            self.widget.setSizePolicy(QtWidgets.QSizePolicy.Expanding,QtWidgets.QSizePolicy.Expanding)
            self.gridLayout.addWidget(self.widget, 1, 0, 1, 3)
        elif err.count("BadWindow"):
            # Workaround for 'X Error of failed request: BadWindow (invalid Window parameter)'
            # https://github.com/jordansissel/xdotool/issues/60
            self._embed(ref)
        else:
            print(f"Null window id for '{self.name}': xdotool search --sync --classname {ref}")

@shvchk
Copy link

shvchk commented Feb 28, 2021

Made a simple sh wrapper to work around this: https://gist.github.com/shvchk/ecfcb9c43050a08cb55ece9efb935da9

marmarek added a commit to marmarek/xdotool that referenced this issue Jun 21, 2021
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
marmarek added a commit to marmarek/xdotool that referenced this issue Jun 21, 2021
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
jordansissel pushed a commit that referenced this issue Jul 17, 2021
* 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
buldi pushed a commit to buldi/xdotool that referenced this issue Apr 23, 2022
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants