FS#4535 - GTK apps broken with latest libxfixes
Attached to Project:
Arch Linux
Opened by Pierre Schmitz (Pierre) - Saturday, 29 April 2006, 15:53 GMT
Last edited by Jan de Groot (JGC) - Saturday, 29 April 2006, 21:11 GMT
Opened by Pierre Schmitz (Pierre) - Saturday, 29 April 2006, 15:53 GMT
Last edited by Jan de Groot (JGC) - Saturday, 29 April 2006, 21:11 GMT
|
Details
I just synchronized to current und some x11-libs were
updated. After that Eclipse a Azureus(both are
SWT-Applications) won`t start.
I get the following errors: The program 'Eclipse' received an X Window System error. This probably reflects a bug in the program. The error was 'BadRequest (invalid request code or no such operation)'. (Details: serial 645 error_code 1 request_code 151 minor_code 23) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) The program 'eclipse' received an X Window System error. This probably reflects a bug in the program. The error was 'BadRequest (invalid request code or no such operation)'. (Details: serial 137 error_code 1 request_code 151 minor_code 23) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) |
This task depends upon
What basically happens here:
- fixesproto got upgraded to version 4.0
- libxfixes got upgraded to version 4.0, but gets the client version number from fixesproto
- Xorg 7.0 and higher contain a check for the fixes client version and return a BadRequest when the client is too new.
I'm leaving this bug open as many users will keep reporting bugs for this one. Either downgrade to 3.0.1.2-1, or "upgrade" to 3.0.1.2-2 to fix this problem. This bug has been fixed for now, but will re-appear as soon as we upgrade to Xorg 7.1 while users keep xorg-server on hold. I filed this bug upstream at freedesktop to discuss this problem (it will kill my X terminals eventually, since they use an older Xorg)
Freedesktop bugtracker ID: https://bugs.freedesktop.org/show_bug.cgi?id=6786
http://lists.freedesktop.org/archives/xorg/2006-April/015068.html