Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail From: jt@toerring.de (Jens Thoms Toerring) Newsgroups: comp.os.linux.development.system Subject: Re: X11 error in Red Hat 6, but not Red Hat 5 Date: 2 Oct 2015 10:22:23 GMT Organization: Freie Universitaet Berlin Lines: 54 Message-ID: References: <45e9873a-fc47-4aa7-97e4-5444f6c17526@googlegroups.com> X-Trace: news.uni-berlin.de sTf2K7fSnatibYzhOow/HwgRqoO7QOp/kOwW5qu//S96rV X-Orig-Path: not-for-mail User-Agent: tin/2.1.1-20120623 ("Mulindry") (UNIX) (Linux/3.2.0-4-amd64 (x86_64)) Xref: csiph.com comp.os.linux.development.system:733 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