Skip to content
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
61 lines (36 sloc) 2.26 KB
original_url created_at updated_at closed_at status type resolution reporter owner priority milestone component version
2011-04-25 10:27:48 -0700
2015-09-01 21:50:32 -0700
2011-04-29 11:27:16 -0700
2.6.1 (xserver-1.9.5)

pbproxy bug on 64-bit systems

The functions x-selection.m:get_property and x-selection.m:find_preferred assumes that the data returned by XGetWindowProperty is made of chunks of (format / 8) bits. However, quoting the XGetWindowProperty manpage:

"If the returned format is 8, the returned data is represented as a char array. If the returned format is 16, the returned data is represented as a short array and should be cast to that type to obtain the elements. If the returned format is 32, the returned data is represented as a long array and should be cast to that type to obtain the elements."

Hence, the data is incorrectly decoded on systems where sizeof(long) is 8. I found this issue because I noticed that, when copying with Command-C the primary selection owned by an urxvt terminal to clipboard, pbproxy requests the type 'STRING' even though urxvt advertizes 'UTF8 STRING' and x-selection.m:find_preferred prefers 'UTF8 STRING' over 'STRING'. The bug can be easily observed by dumping the atoms in find_preferred. in urxvt case the decoded atoms are:

404 0 413 0 31 0

instead of

404 413 31 402 411 403

where 403 is "UTF8 STRING". find_preferred chooses 'STRING' because it doesn't find 'UTF8 STRING'.

The attached patch fixes the issue for me.

emanuele.giaquinta@… commented on Apr 25, 2011

jeremyhu@… commented on Apr 29, 2011

  • Status changed from new to closed
  • Resolution changed from to fixed

Thanks. This will be in 2.6.2

You can’t perform that action at this time.