Bug 23562 - GetProperty can return BadMatch error under certain conditions
Summary: GetProperty can return BadMatch error under certain conditions
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Protocol/Core (show other bugs)
Version: 7.4 (2008.09)
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-27 14:42 UTC by Chris Coulson
Modified: 2009-09-02 21:21 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Don't return BadMatch from GetProperty (506 bytes, patch)
2009-08-27 14:42 UTC, Chris Coulson
no flags Details | Splinter Review

Description Chris Coulson 2009-08-27 14:42:47 UTC
Created attachment 28963 [details] [review]
Don't return BadMatch from GetProperty

I've recently been investigating an application crash caused by an unhandled BadMatch error from XGetWindowProperty. BadMatch is not mentioned as a valid error from this call in the xlib documentation, so I'm unsure of whether this is a documentation bug, or a bug in xorg itself.

I did some debugging, and the BadMatch is returned from dixLookupDrawable() in dix/dixutils.c, because the returned drawable has type mask M_DRAWABLE_PIXMAP rather than M_WINDOW.

What seems to be happening in the client application is that it stores a pointer to some Window. This Window is then destroyed (but the client doesn't notice it), and at some point in the future, the client application calls XGetWindowProperty with the pointer to the Window that was destroyed earlier. However, I don't really understand why dixLookupResourceByClass() finds a valid drawable, seeing as the window was destroyed earlier. My Xorg knowledge is quite limited, but perhaps some other client created a pixmap that has the same ID as the window that got destroyed earlier.

Anyway, regardless of what is happening, the Window that the client passes to XGetWindowProperty is not valid, and I would have expected it to return a BadWindow error ("A value for a Window argument does not name a defined Window").

I've attached a patch which makes this call return a BadWindow error under these conditions, although I don't know if it is correct as this may still be a documentation error.
Comment 1 Peter Hutterer 2009-09-02 21:21:55 UTC
Fix pushed as f04fe06ae244b851b38be824b1a80f2f8a030591. Not quite the one from here though but the end result is the same. Thanks for reporting,.


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.