Community
Participate
Working Groups
Build ID: 3.3RC2 Steps To Reproduce: Sorry I failed to reproduce the error and that's why I haven't reported it earlier (I see it since a few months). Nevertheless it happens regularly (a few times per day): If I try to copy and paste text for a C/C++ project in the editor (or cut and insert) the last line is sometimes not inserted. If I press Ctrl+X to cut text all lines are removed but copying nevertheless ignores the last line. I will try to make it reproducable but maybe you can fix it without further information as well ... More information:
Is this only happening in C/C++ editors or normal text or Java editors as well?
(In reply to comment #1) > Is this only happening in C/C++ editors or normal text or Java editors as well? Sorry, I do not have access to Java files. I just edited C++ files ...
But you must have access to .txt files or could easily make one... Does it happen with them?
Please reproduce with an SDK level example (as Kim suggests) and reopen with the additional information. We need to determine first if this is a CDT problem or platform problem.
(In reply to comment #4) > Please reproduce with an SDK level example (as Kim suggests) and reopen with > the additional information. We need to determine first if this is a CDT problem > or platform problem. I tried again to reproduce it and think this error only occurs for C++ files. It is not possible to reproduce it directly. Nevertheless I noticed that the following example file hello.cpp (without quotes) is sufficient to show this error: "line1" " line2" " line3" "line4 " " " Try to mark the first "l" in line2 up to "3" (I did not marked the end of line). Now copy and paste it via Ctrl+C/Ctrl+V to the last line and you get either line2 line3 or line2 This error should not need more than 5 minutes to occur. I use CDT 4.0 RC3.
Did you check the log for an error message?
(In reply to comment #6) > Did you check the log for an error message? Yes, I did. The log is empty (at least for the time of testing). I know it's no fun to reproduce this problem :-) Nevertheless since it could cause data loss it should be considered as a major bug.
To give you a few more hints: I now installed a new clean Eclipse 3.3 RC4, installed CDT 4.0 RC3 via Help menu, created a new C++ project (Hello World), deleted the old test.cpp content and was able to reproduce the problem with my example multiple times in only two minutes. So it is not related to any non standard formatter option, ...
Do you know if this happens on Windows too? So far I could not reproduce it there.
(In reply to comment #9) > Do you know if this happens on Windows too? So far I could not reproduce it > there. No, and there is no way for me to test it until they fix there license :-)
I now tried with the same setup (Eclipse 3.3 RC4, CDT 4.0 RC3) on Linux, but without success. You are indicating that it does not happen every time, so could you describe what you are doing to repeat it (Ctrl+V again, or first undo, then Ctrl+V, etc.)? Is line 5 the "last line" you are referring to in comment 5, or is it the line below? Did you try with a new workspace? Which JVM are you using? Anything else, that might shed some light on this?
(In reply to comment #11) > I now tried with the same setup (Eclipse 3.3 RC4, CDT 4.0 RC3) on Linux, but > without success. You are indicating that it does not happen every time, so > could you describe what you are doing to repeat it (Ctrl+V again, or first > undo, then Ctrl+V, etc.)? Now I was able to get this error in the second iteration of: * Move the cursor (via cursor keys, no mouse) to "l" in line2 * Hold Shift, press cursor down key and the End key, release Shift * Ctrl+C * Press cursor down twice, cursor is now on the first empty line in the second column * Ctrl+V * Ctrl+Z * Goto step 1 > Is line 5 the "last line" you are referring to in comment 5? Yes, but is should not matter. There can also be multiple lines following. Please note that my "test" file is very exotic. A normal file should show this error as well (not sure whether it will occur so often but it will occur!). > Did you try with a new workspace? Yes. > Which JVM are you using? $ java -version java version "1.6.0_01" Java(TM) SE Runtime Environment (build 1.6.0_01-b06) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_01-b06, mixed mode) It's a 64 bit Java as I'm working on a Intel(R) Core(TM)2 Quad CPU @ 2.40GHz. I'm not sure but I think I observed this error also a few weeks ago when I used a 32 bit JVM on an older PC. I extracted eclipse-SDK-3.3RC4-linux-gtk-x86_64.tar.gz and installed via Help->Update cdt-4.0.0-RC2-linux.x86_64.tar.gz > Anything else, that might shed some light on this? I use a German locale (de_DE.UTF-8). Sorry, I have no further ideas. I would start now valgrind for a C++ program :-)
I tried it again on a different PC (via ssh connection). $ java -version java version "1.5.0_10" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_10-b03, mixed mode) Eclipse 3.2.0, I20060602-1317 CDT 3.1.0.200606261600 The error occurs as well but the behaviour is much more funny: Each second time both lines are pasted, all other times only one (cyclic)!! So the error exists already since some time ...
Hm, still no success (or failure, rather). Could you check, if the clipboard actually contains both lines? Is it maybe a drawing problem? Could you try saving the file and reopening when only line2 got pasted? Does it depend on the typing speed? Actually, if the same (or worse) happens with CDT 3.1.x, then I'd guess that it also happens with the Eclipse Text Editor, because the smart paste feature (which would be to blame here) was added in 4.0.
(In reply to comment #14) > Could you check, if the clipboard actually contains both lines? I did not know that X has a clipboard :-) I knew only of the selection buffer. OK, I found the program xclipboard and it indeed doesn't show the second line on errors! But the really funny behaviour is the following: If xclipboard is open during the test the error does *not* occur at all! (I tested Eclipse 3.2 only, as the problem is directly reproducable in it.) > Is it maybe a drawing problem? Could you try saving the file and reopening when > only line2 got pasted? No, line2 is not saved. > Does it depend on the typing speed? No. but I noticed another reason. In comment 12 I explained that I press the End key to get to the end of line2. If I use the Left cursor key the problem does not occur! > Actually, if the same (or worse) happens with CDT 3.1.x, then I'd guess that it > also happens with the Eclipse Text Editor, because the smart paste feature > (which would be to blame here) was added in 4.0. Oops, sorry. You're right. Now that it is 100% reproducable it was easy to verify this for a .txt file in a generic project. Sorry that you tried it so long without success. I tried my sequence also in other programs such as mcedit (only 3 times), kwrite (multiple minutes, it uses also the clipboard as I verified) but could not reproduce it there. xedit, the ancient X editor, doesn't support copy and paste (only selection mode via 3 mouse button), so I could not test it. PS: Both PC's I tested are OpenSuse 10.2 (X86-64) systems.
Sending back to Platform.
Passing to SWT for comment.
Could this be the Klipper bug where the clipboard gets stolen/locked? Duong to investigate.
(In reply to comment #18) > Could this be the Klipper bug where the clipboard gets stolen/locked? Duong to > investigate. After killing klipper according to http://bugzilla.gnome.org/show_bug.cgi?id=172881 the problem does no longer occur. $ klipper --version Qt: 3.3.7 KDE: 3.5.5 "release 45" Klipper: v0.9.7 Thanks
Duong, close as a dup?
Maybe mark it as a dup of Bug 153809?
*** This bug has been marked as a duplicate of bug 153809 ***
