From: SourceForge.net <no...@so...> - 2011-04-25 11:17:15
|
Bugs item #3292605, was opened at 2011-04-25 12:17 Message generated for change (Tracker Item Submitted) made by dangerousben You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clx Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Spencer (dangerousben) Assigned to: Bruno Haible (haible) Summary: new-clx get-property unpacks properties incorrectly on 64bit Initial Comment: >From the XGetWindowProperty man page: 'If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes).' But XLIB:GET-PROPERTY casts prop_return to a uint32 when actual_format is 64. Attached patch casts it to long instead, which fixes the issue at least on my amd64 machine. This was the ultimate cause of the issue described here (and explains why other clx implementations were apparently unaffected): http://sourceforge.net/mailarchive/forum.php?thread_name=4A954322.80106%40gnu.org&forum_name=clisp-devel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&group_id=1355 |
From: SourceForge.net <no...@so...> - 2011-04-27 16:08:51
|
Bugs item #3292605, was opened at 2011-04-25 07:17 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clx Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Spencer (dangerousben) Assigned to: Bruno Haible (haible) Summary: new-clx get-property unpacks properties incorrectly on 64bit Initial Comment: >From the XGetWindowProperty man page: 'If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes).' But XLIB:GET-PROPERTY casts prop_return to a uint32 when actual_format is 64. Attached patch casts it to long instead, which fixes the issue at least on my amd64 machine. This was the ultimate cause of the issue described here (and explains why other clx implementations were apparently unaffected): http://sourceforge.net/mailarchive/forum.php?thread_name=4A954322.80106%40gnu.org&forum_name=clisp-devel ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2011-04-27 12:08 Message: thanks for the patch. do you have a test case? The reason I am asking is that I am not quite sure it is quite correct. (specifically, make_uint32(unsigned long) should be UL_to_I) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&group_id=1355 |
From: SourceForge.net <no...@so...> - 2011-04-27 19:39:46
|
Bugs item #3292605, was opened at 2011-04-25 07:17 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clx Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Spencer (dangerousben) Assigned to: Bruno Haible (haible) Summary: new-clx get-property unpacks properties incorrectly on 64bit Initial Comment: >From the XGetWindowProperty man page: 'If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes).' But XLIB:GET-PROPERTY casts prop_return to a uint32 when actual_format is 64. Attached patch casts it to long instead, which fixes the issue at least on my amd64 machine. This was the ultimate cause of the issue described here (and explains why other clx implementations were apparently unaffected): http://sourceforge.net/mailarchive/forum.php?thread_name=4A954322.80106%40gnu.org&forum_name=clisp-devel ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2011-04-27 15:39 Message: at any rate, on my 64-bit linux box, the following works without the patch and breaks with it: (xlib:with-open-display (dpy) (dolist (screen (xlib:display-roots dpy)) (dolist (window (xlib:query-tree (xlib:screen-root screen))) (multiple-value-bind (data type format bytes-after) (xlib:get-property window :WM_NORMAL_HINTS) (when data (assert (eq type :WM_SIZE_HINTS)) (assert (= format 32)) (assert (= bytes-after 0)) (assert (= (length data) 18)) (print (list (xlib:wm-name window) data)) (print (xlib:wm-normal-hints window))))))) ("Firefox" (532 0 0 635674972 0 0 0 0 0 4586067 10117896 18 4294862976 10121144 4294862672 4294862752 2872256880 6587458)) *** - AREF: index 6587458 for #(:UNMAP :NORTH-WEST :NORTH :NORTH-EAST :WEST :CENTER :EAST :SOUTH-WEST :SOUTH :SOUTH-EAST :STATIC) is out of range ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-04-27 12:08 Message: thanks for the patch. do you have a test case? The reason I am asking is that I am not quite sure it is quite correct. (specifically, make_uint32(unsigned long) should be UL_to_I) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&group_id=1355 |
From: SourceForge.net <no...@so...> - 2011-04-27 20:05:52
|
Bugs item #3292605, was opened at 2011-04-25 07:17 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clx Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Spencer (dangerousben) Assigned to: Bruno Haible (haible) Summary: new-clx get-property unpacks properties incorrectly on 64bit Initial Comment: >From the XGetWindowProperty man page: 'If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes).' But XLIB:GET-PROPERTY casts prop_return to a uint32 when actual_format is 64. Attached patch casts it to long instead, which fixes the issue at least on my amd64 machine. This was the ultimate cause of the issue described here (and explains why other clx implementations were apparently unaffected): http://sourceforge.net/mailarchive/forum.php?thread_name=4A954322.80106%40gnu.org&forum_name=clisp-devel ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2011-04-27 16:05 Message: 1. actual_format_return is 32, not 64; value of 64 raises an exception (NOTREACHED) 2. the text you are quoting comes from http://www.x.org/releases/X11R7.5/doc/man/man3/XGetWindowProperty.3.html and http://www.x.org/releases/X11R7.6/doc/man/man3/XChangeProperty.3.xhtml which say: "If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes)." what could "padded in the upper 4 bytes" mean? how should it be handled? ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-04-27 15:39 Message: at any rate, on my 64-bit linux box, the following works without the patch and breaks with it: (xlib:with-open-display (dpy) (dolist (screen (xlib:display-roots dpy)) (dolist (window (xlib:query-tree (xlib:screen-root screen))) (multiple-value-bind (data type format bytes-after) (xlib:get-property window :WM_NORMAL_HINTS) (when data (assert (eq type :WM_SIZE_HINTS)) (assert (= format 32)) (assert (= bytes-after 0)) (assert (= (length data) 18)) (print (list (xlib:wm-name window) data)) (print (xlib:wm-normal-hints window))))))) ("Firefox" (532 0 0 635674972 0 0 0 0 0 4586067 10117896 18 4294862976 10121144 4294862672 4294862752 2872256880 6587458)) *** - AREF: index 6587458 for #(:UNMAP :NORTH-WEST :NORTH :NORTH-EAST :WEST :CENTER :EAST :SOUTH-WEST :SOUTH :SOUTH-EAST :STATIC) is out of range ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-04-27 12:08 Message: thanks for the patch. do you have a test case? The reason I am asking is that I am not quite sure it is quite correct. (specifically, make_uint32(unsigned long) should be UL_to_I) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&group_id=1355 |
From: SourceForge.net <no...@so...> - 2011-04-28 06:34:35
|
Bugs item #3292605, was opened at 2011-04-25 12:17 Message generated for change (Comment added) made by dangerousben You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clx Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Spencer (dangerousben) Assigned to: Bruno Haible (haible) Summary: new-clx get-property unpacks properties incorrectly on 64bit Initial Comment: >From the XGetWindowProperty man page: 'If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes).' But XLIB:GET-PROPERTY casts prop_return to a uint32 when actual_format is 64. Attached patch casts it to long instead, which fixes the issue at least on my amd64 machine. This was the ultimate cause of the issue described here (and explains why other clx implementations were apparently unaffected): http://sourceforge.net/mailarchive/forum.php?thread_name=4A954322.80106%40gnu.org&forum_name=clisp-devel ---------------------------------------------------------------------- Comment By: Ben Spencer (dangerousben) Date: 2011-04-28 07:34 Message: I tried to write a simple test case but found that it fails (differently) both with and without the patch, so I'm pretty confused now :( > 1. actual_format_return is 32, not 64; value of 64 raises an exception Yep, sorry, that was a typo. > what could "padded in the upper 4 bytes" mean? how should it be handled? I assumed it meant padded with zeroes. However, having looked more more closely at the source of xprop, it does: value = * (const unsigned long *) *pointer & 0xffffffff; Changing the patch to do this didn't help though. Here's my test case and results: (let* ((display (xlib:open-display "")) (screen (first (xlib:display-roots display))) (window (xlib:create-window :parent (xlib:screen-root screen) :x 0 :y 0 :width 100 :height 100)) (hints (xlib:make-wm-size-hints :x 1 :y 2 :width 3 :height 4))) (setf (xlib:wm-normal-hints window) hints) (print hints) (print (xlib:wm-normal-hints window))) Without patch: #S(XLIB:WM-SIZE-HINTS :USER-SPECIFIED-POSITION-P NIL :USER-SPECIFIED-SIZE-P NIL :X 1 :Y 2 :WIDTH 3 :HEIGHT 4 :MIN-WIDTH NIL :MIN-HEIGHT NIL :MAX-WIDTH NIL :MAX-HEIGHT NIL :WIDTH-INC NIL :HEIGHT-INC NIL :MIN-ASPECT NIL :MAX-ASPECT NIL :BASE-WIDTH NIL :BASE-HEIGHT NIL :WIN-GRAVITY NIL :PROGRAM-SPECIFIED-POSITION-P NIL :PROGRAM-SPECIFIED-SIZE-P NIL) #S(XLIB:WM-SIZE-HINTS :USER-SPECIFIED-POSITION-P NIL :USER-SPECIFIED-SIZE-P NIL :X 0 :Y 2 :WIDTH 0 :HEIGHT 4 :MIN-WIDTH NIL :MIN-HEIGHT NIL :MAX-WIDTH NIL :MAX-HEIGHT NIL :WIDTH-INC NIL :HEIGHT-INC NIL :MIN-ASPECT NIL :MAX-ASPECT NIL :BASE-WIDTH NIL :BASE-HEIGHT NIL :WIN-GRAVITY NIL :PROGRAM-SPECIFIED-POSITION-P T :PROGRAM-SPECIFIED-SIZE-P T) With patch: #S(XLIB:WM-SIZE-HINTS :USER-SPECIFIED-POSITION-P NIL :USER-SPECIFIED-SIZE-P NIL :X 1 :Y 2 :WIDTH 3 :HEIGHT 4 :MIN-WIDTH NIL :MIN-HEIGHT NIL :MAX-WIDTH NIL :MAX-HEIGHT NIL :WIDTH-INC NIL :HEIGHT-INC NIL :MIN-ASPECT NIL :MAX-ASPECT NIL :BASE-WIDTH NIL :BASE-HEIGHT NIL :WIN-GRAVITY NIL :PROGRAM-SPECIFIED-POSITION-P NIL :PROGRAM-SPECIFIED-SIZE-P NIL) #S(XLIB:WM-SIZE-HINTS :USER-SPECIFIED-POSITION-P NIL :USER-SPECIFIED-SIZE-P NIL :X 2 :Y 4 :WIDTH 0 :HEIGHT 0 :MIN-WIDTH NIL :MIN-HEIGHT NIL :MAX-WIDTH NIL :MAX-HEIGHT NIL :WIDTH-INC NIL :HEIGHT-INC NIL :MIN-ASPECT NIL :MAX-ASPECT NIL :BASE-WIDTH NIL :BASE-HEIGHT NIL :WIN-GRAVITY NIL :PROGRAM-SPECIFIED-POSITION-P T :PROGRAM-SPECIFIED-SIZE-P T) Your test code works (or at least runs without error) both with and without the patch on my system. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-04-27 21:05 Message: 1. actual_format_return is 32, not 64; value of 64 raises an exception (NOTREACHED) 2. the text you are quoting comes from http://www.x.org/releases/X11R7.5/doc/man/man3/XGetWindowProperty.3.html and http://www.x.org/releases/X11R7.6/doc/man/man3/XChangeProperty.3.xhtml which say: "If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes)." what could "padded in the upper 4 bytes" mean? how should it be handled? ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-04-27 20:39 Message: at any rate, on my 64-bit linux box, the following works without the patch and breaks with it: (xlib:with-open-display (dpy) (dolist (screen (xlib:display-roots dpy)) (dolist (window (xlib:query-tree (xlib:screen-root screen))) (multiple-value-bind (data type format bytes-after) (xlib:get-property window :WM_NORMAL_HINTS) (when data (assert (eq type :WM_SIZE_HINTS)) (assert (= format 32)) (assert (= bytes-after 0)) (assert (= (length data) 18)) (print (list (xlib:wm-name window) data)) (print (xlib:wm-normal-hints window))))))) ("Firefox" (532 0 0 635674972 0 0 0 0 0 4586067 10117896 18 4294862976 10121144 4294862672 4294862752 2872256880 6587458)) *** - AREF: index 6587458 for #(:UNMAP :NORTH-WEST :NORTH :NORTH-EAST :WEST :CENTER :EAST :SOUTH-WEST :SOUTH :SOUTH-EAST :STATIC) is out of range ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-04-27 17:08 Message: thanks for the patch. do you have a test case? The reason I am asking is that I am not quite sure it is quite correct. (specifically, make_uint32(unsigned long) should be UL_to_I) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&group_id=1355 |
From: SourceForge.net <no...@so...> - 2011-04-28 17:35:36
|
Bugs item #3292605, was opened at 2011-04-25 07:17 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clx >Group: lisp error >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ben Spencer (dangerousben) >Assigned to: Sam Steingold (sds) Summary: new-clx get-property unpacks properties incorrectly on 64bit Initial Comment: >From the XGetWindowProperty man page: 'If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes).' But XLIB:GET-PROPERTY casts prop_return to a uint32 when actual_format is 64. Attached patch casts it to long instead, which fixes the issue at least on my amd64 machine. This was the ultimate cause of the issue described here (and explains why other clx implementations were apparently unaffected): http://sourceforge.net/mailarchive/forum.php?thread_name=4A954322.80106%40gnu.org&forum_name=clisp-devel ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-04-28 13:35 Message: thank you for your bug report. the bug has been fixed in the source tree (mercurial/hg). you can either wait for the next release (recommended) or check out the current mercurial tree (see http://clisp.org) and build CLISP from the sources (be advised that between releases the source tree is very unstable and may not even build on your platform). ---------------------------------------------------------------------- Comment By: Ben Spencer (dangerousben) Date: 2011-04-28 02:34 Message: I tried to write a simple test case but found that it fails (differently) both with and without the patch, so I'm pretty confused now :( > 1. actual_format_return is 32, not 64; value of 64 raises an exception Yep, sorry, that was a typo. > what could "padded in the upper 4 bytes" mean? how should it be handled? I assumed it meant padded with zeroes. However, having looked more more closely at the source of xprop, it does: value = * (const unsigned long *) *pointer & 0xffffffff; Changing the patch to do this didn't help though. Here's my test case and results: (let* ((display (xlib:open-display "")) (screen (first (xlib:display-roots display))) (window (xlib:create-window :parent (xlib:screen-root screen) :x 0 :y 0 :width 100 :height 100)) (hints (xlib:make-wm-size-hints :x 1 :y 2 :width 3 :height 4))) (setf (xlib:wm-normal-hints window) hints) (print hints) (print (xlib:wm-normal-hints window))) Without patch: #S(XLIB:WM-SIZE-HINTS :USER-SPECIFIED-POSITION-P NIL :USER-SPECIFIED-SIZE-P NIL :X 1 :Y 2 :WIDTH 3 :HEIGHT 4 :MIN-WIDTH NIL :MIN-HEIGHT NIL :MAX-WIDTH NIL :MAX-HEIGHT NIL :WIDTH-INC NIL :HEIGHT-INC NIL :MIN-ASPECT NIL :MAX-ASPECT NIL :BASE-WIDTH NIL :BASE-HEIGHT NIL :WIN-GRAVITY NIL :PROGRAM-SPECIFIED-POSITION-P NIL :PROGRAM-SPECIFIED-SIZE-P NIL) #S(XLIB:WM-SIZE-HINTS :USER-SPECIFIED-POSITION-P NIL :USER-SPECIFIED-SIZE-P NIL :X 0 :Y 2 :WIDTH 0 :HEIGHT 4 :MIN-WIDTH NIL :MIN-HEIGHT NIL :MAX-WIDTH NIL :MAX-HEIGHT NIL :WIDTH-INC NIL :HEIGHT-INC NIL :MIN-ASPECT NIL :MAX-ASPECT NIL :BASE-WIDTH NIL :BASE-HEIGHT NIL :WIN-GRAVITY NIL :PROGRAM-SPECIFIED-POSITION-P T :PROGRAM-SPECIFIED-SIZE-P T) With patch: #S(XLIB:WM-SIZE-HINTS :USER-SPECIFIED-POSITION-P NIL :USER-SPECIFIED-SIZE-P NIL :X 1 :Y 2 :WIDTH 3 :HEIGHT 4 :MIN-WIDTH NIL :MIN-HEIGHT NIL :MAX-WIDTH NIL :MAX-HEIGHT NIL :WIDTH-INC NIL :HEIGHT-INC NIL :MIN-ASPECT NIL :MAX-ASPECT NIL :BASE-WIDTH NIL :BASE-HEIGHT NIL :WIN-GRAVITY NIL :PROGRAM-SPECIFIED-POSITION-P NIL :PROGRAM-SPECIFIED-SIZE-P NIL) #S(XLIB:WM-SIZE-HINTS :USER-SPECIFIED-POSITION-P NIL :USER-SPECIFIED-SIZE-P NIL :X 2 :Y 4 :WIDTH 0 :HEIGHT 0 :MIN-WIDTH NIL :MIN-HEIGHT NIL :MAX-WIDTH NIL :MAX-HEIGHT NIL :WIDTH-INC NIL :HEIGHT-INC NIL :MIN-ASPECT NIL :MAX-ASPECT NIL :BASE-WIDTH NIL :BASE-HEIGHT NIL :WIN-GRAVITY NIL :PROGRAM-SPECIFIED-POSITION-P T :PROGRAM-SPECIFIED-SIZE-P T) Your test code works (or at least runs without error) both with and without the patch on my system. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-04-27 16:05 Message: 1. actual_format_return is 32, not 64; value of 64 raises an exception (NOTREACHED) 2. the text you are quoting comes from http://www.x.org/releases/X11R7.5/doc/man/man3/XGetWindowProperty.3.html and http://www.x.org/releases/X11R7.6/doc/man/man3/XChangeProperty.3.xhtml which say: "If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes)." what could "padded in the upper 4 bytes" mean? how should it be handled? ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-04-27 15:39 Message: at any rate, on my 64-bit linux box, the following works without the patch and breaks with it: (xlib:with-open-display (dpy) (dolist (screen (xlib:display-roots dpy)) (dolist (window (xlib:query-tree (xlib:screen-root screen))) (multiple-value-bind (data type format bytes-after) (xlib:get-property window :WM_NORMAL_HINTS) (when data (assert (eq type :WM_SIZE_HINTS)) (assert (= format 32)) (assert (= bytes-after 0)) (assert (= (length data) 18)) (print (list (xlib:wm-name window) data)) (print (xlib:wm-normal-hints window))))))) ("Firefox" (532 0 0 635674972 0 0 0 0 0 4586067 10117896 18 4294862976 10121144 4294862672 4294862752 2872256880 6587458)) *** - AREF: index 6587458 for #(:UNMAP :NORTH-WEST :NORTH :NORTH-EAST :WEST :CENTER :EAST :SOUTH-WEST :SOUTH :SOUTH-EAST :STATIC) is out of range ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-04-27 12:08 Message: thanks for the patch. do you have a test case? The reason I am asking is that I am not quite sure it is quite correct. (specifically, make_uint32(unsigned long) should be UL_to_I) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&group_id=1355 |