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.
*** Bug 139849 has been marked as a duplicate of this bug. ***
The problem seems to be solved if the new -Y option is passed to ssh and not -X as in previous versions.
I don't see how this could be a metacity bug...
This appears to be a duplicate of 139672. Thanks for the workaround.
*** Bug 139672 has been marked as a duplicate of this bug. ***
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)
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.
*** This bug has been marked as a duplicate of 137685 ***