Summary: | libX11 1.1.5 causes some applications to freeze | ||
---|---|---|---|
Product: | xorg | Reporter: | Peter Hutterer <peter.hutterer> |
Component: | Lib/Xlib | Assignee: | Xorg Project Team <xorg-team> |
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | major | ||
Priority: | medium | CC: | cloos |
Version: | git | ||
Hardware: | Other | ||
OS: | Linux (All) | ||
URL: | https://bugzilla.redhat.com/show_bug.cgi?id=491813 | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Peter Hutterer
2009-03-26 17:08:04 UTC
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. |
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.