Summary: | x11-libs/libxcb has tightened locking requirements, numerous applications fail | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dale Pontius <depontius> |
Component: | [OLD] Library | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | ahbritto, amadeus.bit, bug.hunter, charliecompany, depontius, gentoo, ikelos, iyosifov, jaime.mj, Martin.vGagern, orlin, pacho, rb6, russ, thothonegan, vyacheslavovich, zlin |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 174434 | ||
Attachments: |
libxcb-1.0 ebuild with sloppy-lock flag
sloppy lock patch from Novell libxcb-no-assert-on-lock.patch |
Description
Dale Pontius
2007-05-02 18:17:23 UTC
Created attachment 121264 [details]
libxcb-1.0 ebuild with sloppy-lock flag
I've attached an updated ebuild including the lazy locking patch from Novell which allows enabling of lazy locks by setting the LIBXCB_ALLOW_SLOPPY_LOCK use flag. This is not an optimal solution, but this method allows users to enable it selectively.
Created attachment 121266 [details, diff]
sloppy lock patch from Novell
sloppy lock patch for ${FILESDIR} for previously attached ebuild
As far as I'm concerned, (as the originator) this problem can be considered FIXED, though I would like to see it pushed out for regular release. I built and tested it against Cadence IC-6.1.1, and found the lock fails happen by default, but go away when I set the LIBXCB_ALLOW_SLOPPY_LOCK=true environment variable. IMHO this is the preferred way to allow use of known-buggy (hopefully reported to the developers) applications while running properly, and perhaps finding new buggy applications to report. don't close bugs until we actually have the fix in portage ;) Wow, I just read my description of the previously attached ebuild, I must have been smoking crack (actually, I think it was about 4am). Just for clarity: The above ebuild adds the use flag: 'sloppy-lock' When enabled, the sloppy locking patch from Novell is applied, providing the ability to loosen the locking strategy in libxcb to avoid asserts when the 'LIBXCB_ALLOW_SLOPPY_LOCK' environment variable is present. The ebuild also adds einfo output describing this behaviour and suggesting the possibility to enable it globally via env.d. Created attachment 122380 [details, diff]
libxcb-no-assert-on-lock.patch
Here is an alternative patch that I have been using for quite a while now (I don't usually report much because I usually get told to go somewhere else and i'm too lazy to). This one however is probably a worse choice because I *believe* that it removes some of the locking requirements entirely instead of introducing that environment variable to check. Just thought another option and my say that i've been using this for about four months (i think) w/o any problems would be useful.
In the libxcb-1.1 release notes: This release contains several important bug fixes, summarized below. It also contains a patch much like Novell's libxcb-sloppy-lock.diff. <rationale skipped> Enhancements: * Print a backtrace, if possible, on locking assertion failures. * Skip abort() on locking assertions if LIBXCB_ALLOW_SLOPPY_LOCK is set. ... Now if old java would set it up somehow, we might be golden with libxcb-1.1 I am using libxcb-1.1 with the sloppy lock enabled and everything runs fine. Can't it be marked as stable? It is currently keyworded. Yeah, we're working on that. *** Bug 240440 has been marked as a duplicate of this bug. *** *** Bug 249670 has been marked as a duplicate of this bug. *** One of the apps likely to crash seems to be kwin. There is an upstream bug at http://bugs.kde.org/182462 but reporters seem to come from Gentoo exclusively. So it would be a good thing for Gentoo devs to have a look. Would you deal with this in this report here, or should I file a separate specifically for kwin? All the requires patches have been put in upstream libxcb. Closing fixed. Thanks |