Bug 25209

Summary: xterm(1) doesn't allow pasting more than 1024 bytes
Product: xorg Reporter: Wei.Xue
Component: Lib/XlibAssignee: Alan Coopersmith <alan.coopersmith>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: high CC: dickey, jeremyhu
Version: unspecifiedKeywords: patch
Hardware: All   
OS: All   
URL: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6714036
Whiteboard: 2011BRB_Reviewed
i915 platform: i915 features:

Description Wei.Xue 2009-11-20 20:34:32 UTC
The xterm(1) utility doesn't allow pasting more than 1024 bytes
of data.  This is independent of the program running in the xterm and is
easily reproduceable.
Comment 1 Wei.Xue 2009-11-21 02:18:43 UTC
I fixed on Opensolaris. I'll summit patch with Xorg patch format.
Comment 2 Thomas E. Dickey 2010-09-19 11:56:30 UTC
There's no followup, and I was unable to find any information in Sun/Oracle's
bug-tracking.
Comment 3 Julien Cristau 2010-09-20 05:25:21 UTC
Let's close as invalid, this can be reopened if more information or a patch is provided.
Comment 4 Alan Coopersmith 2010-09-21 08:39:09 UTC
The submitter no longer works at Sun/Oracle, so the e-mail to him would be
bouncing.

The fix he applied to the OpenSolaris libX11 can be seen at:
http://src.opensolaris.org/source/xref/x-cons/xnv-clone/open-src/lib/libX11/6714036.patch

The explanation provided by another engineer in the Sun internal bug database
(which unfortunately isn't part of what's exported to the external view shown
 in the bug report in the URL link):

  The problem here is not in xterm, but in libX11.

  xterm calls XmbTextListToTextProperty to convert the highlighted text
  to UTF8 when its selection is requested by the paster.  *This*
  function silently truncates the amount of data it will convert to 1K,
  resulting in the apparent malfunction in xterm.

  XmbTextListToTextProperty() eventually calls indirect_convert(),
  which does a conversion by performing two conversion steps through an
  intermediate format.  It does so piecemeal using a 1K temporary
  buffer:

    128 static int
    129 indirect_convert(
    ...
    137 {
    ...
    142     char buf[BUFSIZ], *cs;
    ...
    156     while (*from_left > 0) {
    157         cs = buf;
    158         cs_left = BUFSIZ;
    159         tmp_args[0] = (XPointer) &charset;
    160 
    161         ret = (*from_conv->methods->convert)(from_conv, from, from_left, &cs,
    162                                              &cs_left, tmp_args, 1);
    ...
    168         length = cs - buf;
    169         if (length > 0) {
    170             cs_left = length;
    171             cs = buf;
    172 
    173             tmp_args[0] = (XPointer) charset;
    174 
    175             ret = (*to_conv->methods->convert)(to_conv, &cs, &cs_left, to, to_left,
    176                                                tmp_args, 1);

  This by itself is innocuous, but the 1K buffer size seems like
  too much of a coincidence to ignore.  The conversion function
  called by indirect_convert, mbstocs(), itself calls a second
  function, mbtocs(), that turns out to be the cause:

    1754 mbtocs(
    1755     XlcConv conv,
    1756     XPointer *from,
    1757     int *from_left,
    1758     XPointer *to,
    1759     int *to_left,
    1760     XPointer *args,
    1761     int num_args)
    1762 {
    ...
    1789     if (*from_left > *to_left)
    1790         *from_left = *to_left;
    1791
    1792     while (*from_left && *to_left) {
    ...

  All these functions take a pointer to the number of remaining input
  and output bytes, so the caller can tell how much of the input was
  converted and how much of the output buffer is left.  When clamping
  the number of bytes to convert, however, this function lies to its
  caller -- and the rest of the conversion stack -- claiming that all
  input bytes had been converted.  Since the intermediate output buffer
  provided by indirect_convert() is 1K in size, only 1K of input is
  converted.
Comment 5 Jeremy Huddleston Sequoia 2011-10-08 19:53:46 UTC
I'm getting a timeout connecting to that URL.  It looks like 
src.opensolaris.org is down.

Alan, could you please send the patch in question to the list for review?  
Thanks.
Comment 6 Alan Coopersmith 2011-10-09 10:27:36 UTC
(In reply to comment #5)
> I'm getting a timeout connecting to that URL.  It looks like 
> src.opensolaris.org is down.
> 
> Alan, could you please send the patch in question to the list for review?  
> Thanks.

The data center containing both the opensolaris.org machines and our source
repositories is down for maintenance on the building's power system this 
weekend - should be back online Monday morning, and I'll try to remember to
forward the patch after that.

(If you can't wait, a community provided mirror is at:
http://hg.openindiana.org/upstream/oracle/xnv/file/3838ec082c2e/open-src/lib/libX11/6714036.patch )
Comment 7 Alan Coopersmith 2011-10-14 17:49:02 UTC
Patch submitted for review: http://patchwork.freedesktop.org/patch/7585/
Comment 8 Alan Coopersmith 2011-10-21 20:10:03 UTC
No review after a week so went ahead and pushed.

http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=002b36e308a26a152504f9b40aa08a0dce9a7991

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.