Bug 490 - Sequence number byte swapping error in GLX replies
Summary: Sequence number byte swapping error in GLX replies
Alias: None
Product: AMD Catalyst™Proprietary Display Driver
Classification: Unclassified
Component: OpenGL Driver (show other bugs)
Version: .archived
Hardware: All Linux
: low major
Assignee: nobody
Depends on:
Reported: 2012-04-26 03:00 CDT by Kevin POCHAT
Modified: 2013-01-26 10:50 CST (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Kevin POCHAT 2012-04-26 03:00:50 CDT
Description of problem: 
When displaying remote OpenGL applications (using DISPLAY environment variables) from a big-endian system to a Linux system using FGLRX driver (tested on 10.7 to 12.3) and X.org x server (tested on xserver releases 1.6 to 1.12), the sequence numbers applied to the GLX replies are badly byte-swapped. All the GLXGet[Float|Integer|...][v]() methods on (from the libglx.so file) seem to swap the X.org internal sequence number (which is an integer) as a 16 bit short without masking it with 0xFFFF. This results in all replies sent after the 65635th having wrong sequence numbers.

The following behavior is observed : the sequence numbers from 0x0 to 0xFFFF are correctly swapped, i.e. 0x1234 -> 0x3412, but once 0x10000 is reached the bits matching the 0xFF0000 mask are binary-or'd with the ones matching the 0xFF mask, i.e. 0x12345 -> 0x4623 (instead of 0x4523).

The exact same behavior can be observed using X.org's libglx.so, where the issue can be found in src/glx/indirect_util.c where the __glXSendReplySwap() method does a "bswap16( client->sequence )" (line 176 in current X.org git) while it should do "bswap16( client->sequence & 0xFFFF )". I hope it helps fix the issue in the fglrx source tree.

Steps to reproduce:
1. Run an openGL application from a big-endian system (Solaris/SPARC here), with DISPLAY set to a linux X.org server with ATI (or now AMD) graphics adapter with FGLRX driver in use.
2. Use a tool like wireshark or tcpdump to observe the GLX replies sent by the X.org server to the client.
3. Manipulate the OpenGL application so that it sends more than 65635 GLX requests (resizing the window seems to trigger a lot of these, when window manager is configured to keep drawing the client while resizing its window)

Actual result: 
The sequence numbers field of the replies is not increasing in a linear way after the 65635th one (0x0000, 0x0001 ... 0xFFFF, 0x0100, 0x0200).

Expected result: 
The sequence numbers shall always increase linearily, rolling back to 0 after the 65635th one (0x0000, 0x0001 ... 0xFFFF, 0x0000, 0x0001)
Comment 1 Kevin POCHAT 2012-04-26 04:17:32 CDT
Matching X.org/xserver/GLX bug created : https://bugs.freedesktop.org/show_bug.cgi?id=49166
Comment 2 Michael Cronenworth 2013-01-19 11:00:44 CST
This message is a reminder that your bug is marked as Catalyst 12.3.

The current Catalyst version is 13.1.

Approximately 7 days from now the Bugzilla administrator will be removing the
12.3 version. At that time your bug will be CLOSED as WONTFIX.

Bug Reporter: Thank you for reporting this issue. However, the Bugzilla
administrator provides this as a unofficial, free service to AMD customers, and
I like to keep my systems neat and tidy. If you would like to keep your bug
from being closed, please try a new Catalyst version and update the 'version'
field if the issue still occurs.

If you are unable to update the version, please make a comment and someone will
change it for you.
Comment 3 Michael Cronenworth 2013-01-26 10:49:57 CST
This bug is being closed due to the 'version' being 12.3 after 7 days of the
previous closure notice.

Thank you for your bug report.