X Error of failed request (xdotool)

[Kenny McCormack]

I have a shell script that uses xdotool to drive a GUI web browser.

It's been developed (by me) over a fairly long period of time, and it is
pretty well debugged. It does what it is supposed to do.

However, every once in a while, it generates the following sort of message:

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

And here's the funny thing: the script is running with "set -e", so any
error (non-zero return) should cause the script to abort. However, when
the above message is displayed, there is no error abort. From this, I
conclude that xdotool isn't returning a non-zero status, even though
something has gone wrong.

In fact, what I think is going on is that Xlib (or some other low-level
library) is generating this message directly. Note that I also see this
message from time to time when running xev, so it is not unique to any
particular X app. Thus, as I say, it seems to be coming directly from the
library.

My main problem is that I can't tell which of the many invocations of
xdotool is causing this message to be displayed. Short of turning on
"set -x" mode in the script, which I do not want to do, I need a way to
detect which line in my script is causing the message to be displayed.

One way, and not a particularly bad idea, would be to wrap every call to
xdotool with Expect and watch for the string. I could probably do this,
but I'm posting here to see if anyone has any ideas for a better way.

Note, incidentally, that this error is not actually fatal. The script
still works - did what it was supposed to do - even though the message was
displayed. I would just like to know where it is coming from.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/InsaneParty

[blt_...@mydwnbxz32vpvm.co.uk]

On Thu, 27 Dec 2018 08:48:56 -0000 (UTC)
gaz...@shell.xmission.com (Kenny McCormack) wrote:
>I have a shell script that uses xdotool to drive a GUI web browser.
>
>It's been developed (by me) over a fairly long period of time, and it is
>pretty well debugged. It does what it is supposed to do.
>
>However, every once in a while, it generates the following sort of message:
>
>X Error of failed request: BadWindow (invalid Window parameter)
> Major opcode of failed request: 3 (X_GetWindowAttributes)
> Resource id in failed request: 0x3000001
> Serial number of failed request: 371
> Current serial number in output stream: 372

Possibly some sort of race condition error - something is requesting
information on a window that has just been destroyed, or a simple coding error
and the window parameter is unset and is any old value. Its a bug and it could
be either in a client program or in the X server. Its unlikely to be in Xlib
since thats just a simple interface layer on top of the X protocol and the core
lib hasn't changed in literally decades so this bug would have been spotted and
fixed a long long time ago.

[Kenny McCormack]

In article <q029o0$evi$1...@gioia.aioe.org>,
<blt_...@mydwnbxz32vpvm.co.uk> wrote:
...

>Possibly some sort of race condition error - something is requesting
>information on a window that has just been destroyed, or a simple
>coding error and the window parameter is unset and is any old value.
>Its a bug and it could be either in a client program or in the X
>server. Its unlikely to be in Xlib since thats just a simple interface
>layer on top of the X protocol and the core lib hasn't changed in
>literally decades so this bug would have been spotted and fixed a long
>long time ago.

I'm not sure what this response means - or what point you are driving at -
but I don't think it addresses any of the issues raised in the OP.

Others, please do carry on...

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:

http://user.xmission.com/~gazelle/Sigs/ModernXtian

[Paul]

You have a resource id.

Could you trace down the culprit call that way ?

xwininfo -tree -root

This isn't your exact situation, but some programs will
have rather complicated sets of windows all running
under one or more PIDs. The modern Firefox uses more
than one process, as would say Chromium.

https://askubuntu.com/questions/1098769/import-unable-to-read-x-window-image-resource-temporarily-unavailable

Paul

[blt_wi...@zld47.gov.uk]

On Thu, 27 Dec 2018 12:08:46 -0000 (UTC)
gaz...@shell.xmission.com (Kenny McCormack) wrote:
>In article <q029o0$evi$1...@gioia.aioe.org>,
> <blt_...@mydwnbxz32vpvm.co.uk> wrote:

>....

>>Possibly some sort of race condition error - something is requesting
>>information on a window that has just been destroyed, or a simple
>>coding error and the window parameter is unset and is any old value.
>>Its a bug and it could be either in a client program or in the X
>>server. Its unlikely to be in Xlib since thats just a simple interface
>>layer on top of the X protocol and the core lib hasn't changed in
>>literally decades so this bug would have been spotted and fixed a long
>>long time ago.
>
>I'm not sure what this response means - or what point you are driving at -
>but I don't think it addresses any of the issues raised in the OP.

Or more likely you didn't understand my response. He didn't understand why
a client was erroring. Unlike you I gave him. some reasons. Perhaps go learn
something about X windows.

>Others, please do carry on...

Being patronising never works well when you're standing in a hole you've just
dug.

[Sam]

Kenny McCormack writes:

> However, every once in a while, it generates the following sort of message:
>
> X Error of failed request: BadWindow (invalid Window parameter)
> Major opcode of failed request: 3 (X_GetWindowAttributes)
> Resource id in failed request: 0x3000001
> Serial number of failed request: 371
> Current serial number in output stream: 372

> My main problem is that I can't tell which of the many invocations of
> xdotool is causing this message to be displayed. Short of turning on
> "set -x" mode in the script, which I do not want to do, I need a way to
> detect which line in my script is causing the message to be displayed.

Redirect each individual invocation of xdotool's stderr to a file together
with an indication of which invocation it is, to determine which individual
invocation results in this.

But you will probably end up determining that this is a waste of time. As
it's been pointed out to you, it's a race condition. xdotool was instructed
to send an event to a window that no longer exists by the time xdotool gets
in gear.

So, uou have now determined that a particular invocation of xdotool was
invoked too late and the window no longer exists. Great. Now what?

This is the inherent nature of X11; or specifically any situation where
you're trying to work with windows from another application. At any point in
time that other window can go away, and your window handle is no longer
valid. And if you wait too long, the same XID range can even be assigned to
another, newly started, unrelated program and now that window is some other
window entirely.

No matter in what manner you have obtained the window id that you've handed
over to xev or xdotool, you have no guarantee, whatsoever, that this window
id is still valid by the time those programs get down to business. As soon
as you've grabbed those window ids, from somewhere, all your data is no
longer current, and it may be out of date. You never had this guarantee, and
you never will, as long as X11 works in fundamentally the same way it works
today. And there's absolutely nothing you can about it. It is what it is.
These kinds of diagnostic messages are to be expected, every once in a
while. You just have to deal with them.

[Joe Pfeiffer]

gaz...@shell.xmission.com (Kenny McCormack) writes:

> In article <q029o0$evi$1...@gioia.aioe.org>,
> <blt_...@mydwnbxz32vpvm.co.uk> wrote:
> ...
>>Possibly some sort of race condition error - something is requesting
>>information on a window that has just been destroyed, or a simple
>>coding error and the window parameter is unset and is any old value.
>>Its a bug and it could be either in a client program or in the X
>>server. Its unlikely to be in Xlib since thats just a simple interface
>>layer on top of the X protocol and the core lib hasn't changed in
>>literally decades so this bug would have been spotted and fixed a long
>>long time ago.
>
> I'm not sure what this response means - or what point you are driving at -
> but I don't think it addresses any of the issues raised in the OP.
>
> Others, please do carry on...

The response is crystal clear, and describes a very common situation
that leads to the message you're seeing. Asking for help understanding
it would have been a *much* more productive followup.

[Richard Tobin]

In article <q023lo$2cv$1...@news.xmission.com>,

Kenny McCormack <gaz...@shell.xmission.com> wrote:

>I have a shell script that uses xdotool to drive a GUI web browser.
>
>It's been developed (by me) over a fairly long period of time, and it is
>pretty well debugged. It does what it is supposed to do.
>
>However, every once in a while, it generates the following sort of message:
>
>X Error of failed request: BadWindow (invalid Window parameter)
> Major opcode of failed request: 3 (X_GetWindowAttributes)
> Resource id in failed request: 0x3000001
> Serial number of failed request: 371
> Current serial number in output stream: 372

This looks like the default message that X prints when you haven't set
an error handler.

Presumably xdotool does not override the default error handler (so you
get the message) and does not check every return value (so it does not
act on the error).

So the right thing is to fix xdotool. The simplest thing would be to
add an error handler (using XSetErrorHandler()) that just exits with
an error status. That should be trivial. Of course that will only be
satisfactory if it doesn't need to do any cleaning up in the event of
an error, and if you don't mind it exiting as a result of what may be
an unimportant error.

-- Richard

[Kenny McCormack]

In article <q0nrjn$30gj$1...@macpro.inf.ed.ac.uk>,

Thanks for the info. Alas, I don't think fixing xdotool is within my pay
grade.

As I noted in the OP, the issue isn't so much "fixing" this, and, as you
say, it isn't at all clear whether or not it should be treated as fatal,
but rather, just one of detection. I'd like to know which line in the
script is producing the error.

The simplest way seems to be to turn on tracing (set -x) in the script,
then redirect stderr (but not stdout) to a file. The file will end up with
the line-by-line trace and any error messages (and it will be intermingled
correctly). I have yet to try this, but it seems straightforward enough.

--
Modern Conservative: Someone who can take time out from flashing her
wedding ring around and bragging about her honeymoon to complain that a
fellow secretary who keeps a picture of her girlfriend on her desk is
"flauting her sexuality" and "forcing her lifestyle down our throats".

[Richard Tobin]

In article <q0o48b$fsn$1...@news.xmission.com>,

Kenny McCormack <gaz...@shell.xmission.com> wrote:

>>So the right thing is to fix xdotool. The simplest thing would be to
>>add an error handler (using XSetErrorHandler()) that just exits with
>>an error status. That should be trivial. Of course that will only be
>>satisfactory if it doesn't need to do any cleaning up in the event of
>>an error, and if you don't mind it exiting as a result of what may be
>>an unimportant error.

>Thanks for the info. Alas, I don't think fixing xdotool is within my pay
>grade.

I'm pretty sure you know how to make a small edit to a C program...

>As I noted in the OP, the issue isn't so much "fixing" this, and, as you
>say, it isn't at all clear whether or not it should be treated as fatal,
>but rather, just one of detection. I'd like to know which line in the
>script is producing the error.

You may well find that it isn't one particular line. As others have
said, it's quite likely a race condition in which some window ceases
to exist between two operations on it, and that might happen randomly
during any invocation of xdotool.

-- Richard