Summary: | xcb_io.c: record extension is broken | ||||||
---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Rami Ylimaki <rami.ylimaki> | ||||
Component: | Lib/Xlib | Assignee: | Xorg Project Team <xorg-team> | ||||
Status: | VERIFIED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||
Severity: | normal | ||||||
Priority: | medium | CC: | xcb | ||||
Version: | git | ||||||
Hardware: | Other | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
i915 platform: | i915 features: | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 23614 | ||||||
Attachments: |
|
Description
Rami Ylimaki
2010-06-18 02:37:55 UTC
With latest X server you should also apply the following fix first before using record extension: http://lists.freedesktop.org/archives/xorg-devel/2010-June/010302.html. CCing Jamey. Jamey and I fixed this in commit c115095d7f2bc4f5a4fb26380e3698fefdad7611. Turned out we had a bug in the async-reply handling in poll_for_response. Nobody noticed until someone tried to use async replies, like RECORD does. :) The commit message: poll_for_response: Really handle xcb_poll_for_reply getting a reply. Don't lose async replies. That's bad. `xlsfonts -l`, which uses XListFontsWithInfo, worked fine, because the _XReply path worked; that path waited for replies, rather than polling. However, XRecordProcessReplies, which does nothing but call XPending, relied on the event-handling path to process async replies, and that was busted. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=28595 Signed-off-by: Jamey Sharp <jamey@minilop.net> Signed-off-by: Josh Triplett <josh@joshtriplett.org> Hi, Record extension is now fixed, but after applying the patch, rendercheck is always dumping core. # rendercheck rendercheck 1.3 Render extension version 0.10 Window format: r5g6b5 Segmentation fault (core dumped) (In reply to comment #4) > Hi, > > Record extension is now fixed, but after applying the patch, rendercheck is > always dumping core. > > # rendercheck > rendercheck 1.3 > Render extension version 0.10 > Window format: r5g6b5 > Segmentation fault (core dumped) OK, fixed that one in commit 4a8b6528ff69f6feb8c0e119939b4ce6c088f29e. Apparently we had never tested the case where an application calls _XReadEvents and gets an I/O error and doesn't have any async replies to wait for. I'm not sure whether rendercheck is supposed to get an I/O error there, though. You'll have to tell me if that's normal. If not, please open a new bug about it. This should have been a separate bug, by the way. It's harder to keep track of which patch fixes what if they all have the same bug number. OK, Josh and I botched the original fix, and the followup fix I pushed was masking the symptom, not fixing the problem. So I've reverted both and pushed a commit that actually seems to work for the RECORD test case and rendercheck and my Gnome desktop. Sorry for the confusion. Let me know if I got it right this time. (In reply to comment #6) > OK, Josh and I botched the original fix, and the followup fix I pushed was > masking the symptom, not fixing the problem. So I've reverted both and pushed a > commit that actually seems to work for the RECORD test case and rendercheck and > my Gnome desktop. Sorry for the confusion. Let me know if I got it right this > time. Thanks, it seems to work now. |
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.