Red Hat Bug 491813: When we updated Fedora 10 from libX11 1.1.4 to libX11 1.1.5, quite a number of apps refuse to start - they just hang at various stages. Applications affected range from opera to xterm. We bisected it down to the following commit, reverting this in F-10's libX11 removed the symptoms. commit b11ea7ab3a436745e5244599048516600e47ab5d Refs: libX11-1.1.4-22-gb11ea7a Author: James Cloos <cloos@jhcloos.com> AuthorDate: Thu Jul 17 17:16:50 2008 -0400 Work on making the en_US and pt_BR UTF-8 Compose as similar as possible. The eventual goal here is to have a single primary UTF-8 Compose file which the locale-specific UTF-8 Compose.pre files can #include. (cherry picked from commit 4ba091255bb953d53078ba5619d6751052c739f7) Not all systems are equally affected, some users aren't affected at all or only very infrequently. I have no idea why this may be causing the hangs. We're shipping rawhide with libX11 1.2 which doesn't seem to have this issue. Is there a patch that needs to be cherry-picked that I haven't found yet?
Note that commit b11ea7ab3a436745e5244599048516600e47ab5d says that it was cherry picked from commit 4ba091255bb953d53078ba5619d6751052c739f7. If you do a: :; git log 4ba091255bb953d53078ba5619d6751052c739f7.. you see the commit history along master. If you do a: :; git log b11ea7ab3a436745e5244599048516600e47ab5d.. you see a history which has a log of « Merge branch 'master' into xge » which suggests that something from the xge branch should be the true final result of the bisect. Interestingly, I also see b11ea7ab rather than 4ba09125 when I do: :; git log libX11-1.1.4..libX11-1.1.5 which should not be the case. It looks like a bug in git is preventing correct bisecting and log generation between those tags.
Actually, we did bisecting through rpms, not git. I created a new rpms reverting the patches one-by-one between 1.1.4 and 1.1.5 and had one of the affected users test it. This is how we stumbled onto this patch. If it had been the xge merge it would have made more sense (shifting LASTEvent up by one). (In reply to comment #1) > Interestingly, I also see b11ea7ab rather than 4ba09125 when I do: > > :; git log libX11-1.1.4..libX11-1.1.5 > > which should not be the case. no, this is correct behaviour. 1.1.4 and 1.1.5 are on a separate branch, so the patch that is 4ba0 in master is b11ea in the libX11-1.1 branch. Once you branch off, the histories are separate in git.
> 1.1.4 and 1.1.5 are on a separate branch, so the patch that is 4ba0 in > master is b11ea in the libX11-1.1 branch. D’oh. I completely forgot about the 1.1 branch. [SIGH] I still don’t see how that commit would cause a lockup. And note that commit a788792e9de95f8db0639557859722a35087481d (which is the 2nd commit after 4ba091255bb953d53078ba5619d6751052c739f7) undid part of that. Confusing.
righty-o, we've found the culprit and it is indeed a788792e9de95f8db0639557859722a35087481d. applying this one onto 1.1 fixes the issue. Does that make sense to you? If so, it'd be good to cherry-pick it onto libX11-1.1 and make another release in due time.
I pushed the cherry pick into the branch. Are there any other issues with 1.1.5 which need work? Or should we push out 1.1.6 sooner rather than later? One could argue that most of the commits to master since that point are valid for the 1.1 branch, too.... Does anyone have an idea of how many dists/users are not switching to handoff?
On Sun, Apr 05, 2009 at 10:53:00PM -0700, bugzilla-daemon@freedesktop.org wrote: > Are there any other issues with 1.1.5 which need work? Or should we > push out 1.1.6 sooner rather than later? I haven't noticed anything yet, but then again libX11 only hit stable in F-10 a short while ago. maybe best to wait a bit to see if there's more complaints about other things.
> maybe best to wait a bit to see if there's more complaints > about other things. Sounds like a plan.
fwiw, I didn't find any other big issues with 1.1.5 in Fedora. So whenever you feel like it, go for 1.1.6.
http://lists.freedesktop.org/archives/xorg-announce/2009-September/001007.html
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.