| Summary: | NVIDIA x86_64-1.0-8756 "Caught Signal 11. Server aborting" | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Victor Trac <victor.trac> | ||||
| Component: | Driver/nVidia (proprietary) | Assignee: | Andy Ritger <aritger> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | high | CC: | eich, mat, sndirsch | ||||
| Version: | 7.0.99.903 (7.1RC3) | ||||||
| Hardware: | x86 (IA32) | ||||||
| OS: | Linux (All) | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 5041 | ||||||
| Attachments: |
|
||||||
|
Description
Victor Trac
2006-05-15 10:27:43 UTC
This failure is due to an ABI breakage in the core X server. The DrawableRec's id field was changed from 8 bytes to 4 bytes. Any driver that touches Windows or Pixmaps will not work across this ABI change. This ABI breakage was made to address this bug: https://bugs.freedesktop.org/show_bug.cgi?id=6438 While I agree that the old size was incorrect, and the change that introduced this ABI breakage was a good cleanup, I'd like to make a plea for deferring this size fix until a time when other similarly pervasive ABI changes need to be made, so that we can go through the ABI breakage pain less often and have fewer ABI versions that need to be supported. (In reply to comment #1) > This failure is due to an ABI breakage in the core X server. The DrawableRec's > id field was changed from 8 bytes to 4 bytes. Any driver that touches Windows > or Pixmaps will not work across this ABI change. > > This ABI breakage was made to address this bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=6438 > > While I agree that the old size was incorrect, and the change that introduced > this ABI breakage was a good cleanup, I'd like to make a plea for deferring this > size fix until a time when other similarly pervasive ABI changes need to be > made, so that we can go through the ABI breakage pain less often and have fewer > ABI versions that need to be supported. I apologize for not responding to this in list mail, my email setup is quite horked atm. If you have a patch for this that restores the DrawableRec ABI to its 7.0 form while keeping #6438 fixed, I'll be happy to take it. Created attachment 5680 [details] [review] Patch to restore ABI on 64-bit platforms. Attaching a patch that restores the old ABI behavior. I'm not setup to test it on big endian (32-bit, or 64-bit) platforms, but I believe it is correct. Unfortunately, the change is admittedly ugly. It is too bad to include Xarch.h, but that is needed in order to check the byte order. The padding is also a bit gross. My preference is for this patch to be applied and the ABI restored, but I will understand if the release managers vote it down. In the latter case, NVIDIA will need to provide an updated driver to work with the new ABI. (In reply to comment #3) > Created an attachment (id=5680) [edit] > Patch to restore ABI on 64-bit platforms. > > Attaching a patch that restores the old ABI behavior. > > I'm not setup to test it on big endian (32-bit, or 64-bit) platforms, but I > believe it is correct. It's not correct on LP64-BE. See: http://people.freedesktop.org/~ajax/abi-test.c In that example, 'one' and 'two' are the old and new layouts of ColormapRec, and 'three' and 'four' are the old and new layouts of DrawableRec. By tweaking the defines at the top of the file appropriately, corresponding lines will print equal numbers. Verified on x86, amd64, and ppc64 with gcc, and on amd64 and sparc64 with sun c. Updated patch applied to 1.1 branch and HEAD. Thanks! Just saw a git commit for branches
- refs/tags/XORG-7_1
- refs/tags/xorg-server-1_1_0
Bug #6924: Restore the ABI for DrawableRec and ColormapRec to the state
they were in prior to the fix for #6438. Based on a patch from Andy
Ritger.
So this issue has *not* been resolved in time for initial X.Org 7.1 release,
correct? Just a question ...
|
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.