Bug 139846 - Cut and paste fails, crashes xterm
Cut and paste fails, crashes xterm
Status: CLOSED DUPLICATE of bug 137685
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
:
: 139672 139849 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-18 09:05 EST by Per Steinar Iversen
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-31 15:50:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Per Steinar Iversen 2004-11-18 09:05:47 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041020

Description of problem:
Open a remote xterm through ssh like this:

$ ssh -X -f <server> xterm

Then a cut and paste from the remote window to a local one crashes the
remote xterm.
Pasting from a local to a remote xterm does not seem to work.
Cut and paste works well between different remote xterms on the same
screen.

A typical error message received:

# xterm:  warning, error event received:
X Error of failed request:  BadAtom (invalid Atom parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Atom id in failed request:  0x181
  Serial number of failed request:  174
  Current serial number in output stream:  176



Version-Release number of selected component (if applicable):
metacity-2.8.6-2

How reproducible:
Always

Steps to Reproduce:
1. Open remote xterm with: ssh -X -f <server> xterm
2. Attempts to cut and paste ends with remote xterm crash
3.
    

Actual Results:  Xterm dies.

Expected Results:  The cut and paste operations should have worked.

Additional info:

This fails when the remote machines are FC3 and also AS3. I am not
really sure if this is a metacity bug or a gnome bug.
Comment 1 Havoc Pennington 2004-11-18 13:03:18 EST
*** Bug 139849 has been marked as a duplicate of this bug. ***
Comment 2 Per Steinar Iversen 2004-11-19 03:22:29 EST
The problem seems to be solved if the new -Y option is passed to ssh
and not -X as in previous versions.
Comment 3 Havoc Pennington 2004-11-19 13:05:36 EST
I don't see how this could be a metacity bug... 
Comment 4 Tom Morton 2004-11-25 11:04:19 EST
This appears to be a duplicate of 139672.  Thanks for the workaround.
Comment 5 Mike A. Harris 2004-11-25 12:25:07 EST
*** Bug 139672 has been marked as a duplicate of this bug. ***
Comment 6 Thomas E. Dickey 2004-11-25 15:54:32 EST
perhaps this (button.c).  It's the only user-visible bug I've
isolated recently in that area (causes a paste to be truncated):

***************
*** 2832,2838 ****
        }
        previous = c;
        if (screen->utf8_mode) {
!           lp = convertToUTF8(lp, c);
            if (c_1) {
                lp = convertToUTF8(lp, c_1);
                if (c_2)
--- 2796,2802 ----
        }
        previous = c;
        if (screen->utf8_mode) {
!           lp = convertToUTF8(lp, (c != 0) ? c : ' ');
            if (c_1) {
                lp = convertToUTF8(lp, c_1);
                if (c_2)
Comment 7 Thomas E. Dickey 2004-11-29 19:36:32 EST
The point of the fix was that in some cases, a null would be
inserted into the output, which is not expected.  I've not
been able to reproduce it, but have seen a few comments that
can cause a crash (though XStoreBuffer's manpage states that
it can include nulls, ICCM states that the only control characters
allowed in a STRING are tab and newline.  Null is a control
character, so I'm curious which document is correct.
Comment 8 Tomas Mraz 2005-01-31 15:49:49 EST

*** This bug has been marked as a duplicate of 137685 ***

Note You need to log in before you can comment on or make changes to this bug.