| Summary: | xprop SEGVs when asked to read unset properties | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Branden Robinson <branden> |
| Component: | App/xprop | Assignee: | Xorg Project Team <xorg-team> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | high | ||
| Version: | 7.1 (2006.05) | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| URL: | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=197526 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
(In reply to comment #0) > Well, it turns out you can get back zero for actual_format_return. I don't know > if this is Xlib's or the XFree86 (and subsequently XOrg) X server's fault, but > this would appear to be commonplace behavior despite the attestations of > XGetWindowProperty(3x). It's the X server's fault. Xlib just blindly passes back what it gets from the protocol reply. $ grep -1n actual_format libx11/src/GetProp.c 36-XGetWindowProperty(dpy, w, property, offset, length, delete, 37: req_type, actual_type, actual_format, nitems, bytesafter, prop) 38- register Display *dpy; -- 43- Atom *actual_type; /* RETURN */ 44: int *actual_format; /* RETURN 8, 16, or 32 */ 45- long offset, length; -- 128- *actual_type = reply.propertyType; 129: *actual_format = reply.format; 130- *nitems = reply.nItems; Is it a low-level client library's responsibility to validate the data coming back from the X server? Shouldn't it at least squawk if an X server is behaving out of spec? commit 47514347db811d002e7f3ca05d390565bc3ee5e5 Author: Branden Robinson <branden@debian.org> Date: Thu Jul 27 06:14:54 2006 +0300 handle actual_format_return == 0 (#7647) Handle buggy servers which set actual_format_return == 0, instead of aborting. (In reply to comment #1) > (In reply to comment #0) > > > Well, it turns out you can get back zero for actual_format_return. I don't know > > if this is Xlib's or the XFree86 (and subsequently XOrg) X server's fault, but > > this would appear to be commonplace behavior despite the attestations of > > XGetWindowProperty(3x). I was wrong about zero being out of spec. Farther down in the XGetWindowProperty(3x) manpage, it says: "If the specified property does not exist for the specified window, XGetWindowProperty returns None to actual_type_return and the value zero to actual_format_return and bytes_after_return. The nitems_return argument is empty. In this case, the delete argument is ignored." I missed this in favor of the "never zero" language in the next paragraph. So it was only xprop that was broken all along. If my comment text was committed along with the fix, that should probably be removed, or updated. |
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.
This was reported to Debian on multiple occasions, years ago. I believe I have a fix for it. As far as I can tell, xprop deliberately abort()s in Get_Window_Property_Data_And_Type() if the *actual_format_return from XGetWindowProperty is not 8, 16, or 32. Well, it turns out you can get back zero for actual_format_return. I don't know if this is Xlib's or the XFree86 (and subsequently XOrg) X server's fault, but this would appear to be commonplace behavior despite the attestations of XGetWindowProperty(3x). Here's the patch. It tidies things up nicely. Index: xprop.c =================================================================== --- xprop.c (revision 2474) +++ xprop.c (working copy) @@ -1199,6 +1199,12 @@ nbytes = sizeof(short); else if (actual_format == 8) nbytes = 1; + else if (actual_format == 0) + /* + * Some broken implementations can return zero, despite what the + * XGetWindowProperty manual page says. + */ + nbytes = 0; else abort(); *length = min(nitems * nbytes, max_len);