From Newsgroup: comp.windows.x

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

On Thu, 27 Dec 2018 08:48:56 -0000 (UTC)
gazelle@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.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

In article <q029o0$evi$1@gioia.aioe.org>,
<blt_801s6@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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

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

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.

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

On Thu, 27 Dec 2018 12:08:46 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) wrote:

In article <q029o0$evi$1@gioia.aioe.org>,
<blt_801s6@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.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

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

In article <q029o0$evi$1@gioia.aioe.org>,
<blt_801s6@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.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

In article <q023lo$2cv$1@news.xmission.com>,
Kenny McCormack <gazelle@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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

In article <q0nrjn$30gj$1@macpro.inf.ed.ac.uk>,
Richard Tobin <richard@cogsci.ed.ac.uk> wrote:

In article <q023lo$2cv$1@news.xmission.com>,
Kenny McCormack <gazelle@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.

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".
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.windows.x

In article <q0o48b$fsn$1@news.xmission.com>,
Kenny McCormack <gazelle@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
--- Synchronet 3.21d-Linux NewsLink 1.2