lyngwyst@gmail.com wrote:
I am maintaining a legacy application that uses XWindows. I am encountering
a low-level crash in Red Hat 6 that does not occur in Red Hat 5. It occurs under XFlush(), and outputs the message:
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 58 (X_SetDashes)
Value in failed request: 0x0
Serial number of failed request: 6120
Current serial number in output stream: 7090
Running under gdb does not provide additional information; by the time this error occurs, the program has terminated and there is no stack.
Yes, an X error per default results in a function call that, after
printing out the message, calls exit(). But you can set up your own
X error handler with XSetErrorHandler(). If you do to find out where
the problem is coming from you should also make Xlib behave synchro-
nously by calling XSynchronize() - this makes sure errors are repor-
ted the moment they happen.
I do not expect anyone here to solve this problem for me. I just wanted to find out if there were known XWindows issues in Red Hat 6, and how low-level this issue might be. Google searches turn up discussions about device drivers, which, I must admit, is not an area I am equipped to go into.
I have no idea if there's something special about RH 6, but it might
be something that's much simpler than a driver issue. The X error
message says rather clearly that the problem is some bad value
passed to the function for setting the lengths of dashes. That would
rather likely be XSetDashes() (a Bad Value error is, for example,
the result of the last argument being less than 1). Is there a call
of this function in this program? If yes it might be interesting
to take a look at the arguments passed to it. One possible reason
why they suddenly are off could be that with a new compiler version
a previously undetected memory bug (writing past the end of an array,
use of a stray pointer etc.) now results in one of the arguments be-
coming corrupted.
I have not included source code because 1) I do not have the XWindows source code that is crashing, and 2) this seems to be at a much lower level than my application's source code.
Well, it doesn't look very "low-level" and it's not really a crash
- Xlib terminates the program (which you can avoid by installing
your own error handler). If your program doesn't use Xlib directly
but a library on top of it then you might consider talking to the
maintainers of the library (though they rather likely will need
some code that triggers the problem).
Regards, Jens
--
\ Jens Thoms Toerring ___
jt@toerring.de
\__________________________
http://toerring.de
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)