GNOME Bugzilla – Bug 73284
Doubleclick to copy and then paste crashes terminal
Last modified: 2004-12-22 21:47:04 UTC
Here's a reproducable crash with gnome-terminal a.k.a. profterm: Steps: 1.) Open a gnome-terminal 2.) Double-click on text in the first terminal to select a word (note: no highlighting occurs) 3.) Middle-click-paste the copied text into the terminal (pasting into another app that can accept middle-click-pastes Result: Boom Expected: Double-clicked text gets highlighted and pasted on middle-click Note: Triple-clicks work: the whole line gets highlighted and pasted on middle-click without problems. Also, highlighting/copying by dragging works Here's an strace: write(2, "gnome-terminal", 14gnome-terminal) = 14 write(2, " (pid:", 6 (pid:) = 6 getpid() = 1675 write(2, "1675", 41675) = 4 write(2, "): ", 3): ) = 3 write(2, "Gdk", 3Gdk) = 3 write(2, "-", 1-) = 1 write(2, "CRITICAL **: ", 13CRITICAL **: ) = 13 write(2, "file gdkselection-x11.c: line 64"..., 93file gdkselection-x11.c: line 640 (gdk_utf8_to_compound_text): assertion `str != NULL' failed) = 93 write(2, "\n", 1 ) = 1 write(3, "\31\0\v\0P\0\200\1\0\0\0\0\37.\10\10gt\335\\P\0\200\1\1"..., 48) = 48 read(3, "\1\2R\2\0\0\0\0\5\0\200\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32 ioctl(3, 0x541b, [32]) = 0 read(3, "\36\25R\2gt\335\\\36\0\0\1P\0\200\1\1\0\0\0\37\0\0\0h\1"..., 32) = 32 poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}, {fd=9, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN}, {fd=11, events=PO LLIN}], 6, 0) = 0 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++
Ooops. In "2.) Double-click on text in the first terminal to select a word (note: no highlighting occurs)" please s/in the first terminal/in the terminal
Duh. 3.) Middle-click-paste the copied text into the terminal (pasting into another app that can accept middle-click-pastes ***has the same effect)***
Can you do a backtrace?
Backtrace: (gdb) run [New Thread 1024 (LWP 2880)] gnome-terminal gnome-terminal --window-with-profile-internal-id=Default --hide-menubar gnome-terminal (pid:2880): Gdk-CRITICAL **: file gdkselection-x11.c: line 640 (gdk_utf8_to_compound_text): assertion `str != NULL' failed Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 2880)] 0x40c006df in strlen () from /lib/libc.so.6 (gdb) BTW, shouldn't bug-buddy catch it, too? It doesn't
I only get every 2nd comment right (hopefully). Sorry. This is what I got out of ddd:
+ Trace 18595
Zvt shouldn't be passing that NULL string to gtk_selection_data_set_text. (Once that's fixed, should also reassign to GTK to add a g_return_if_fail to catch that.)
Jacob: did this get fixed? I can no longer duplicate the crash...
i can reproduce it still.
I am not able to reproduce this problem. When I doubleclick a word, it gets highlighted. On another window I am able to paste it. I could also paste it on gedit. If this problem still exist, could you please tell me under what conditions this is reproducible.
i just reproduced it again. i think the key is for the top left part of the terminal to have spaces instead of text. in a terminal run 'top' then C-c hit enter a few times until you get a line at the top of the terminal like: 1057 root 15 0 88508 16M 5852 S 23.2 5.1 2:42 X and double click in the part with the space, then paste into a terminal.
I can reproduce it as Jacob just described. However, I am not entirely sure that this is exactly the same bug as I initially experienced. I seem to remember that when I first reported the bug, I got the crash everytime I doubleclicked anywhere and then pasted. However, my memory is hazy. Anyway, if it indeed had been so, I can't reproduced it as reported earlier
Jacob: What is the expected behaviour when you double-click on space. Should it get highlighted? Also, when we paste the selected item, should it give those many number of spaces? Currently, the selection is NULL when you double-click on space. Hence, it crashes when you paste.
it should to what xterm does - select the spaces.
This goes a bit deeper than just not selecting spaces. Do we want it to act _exactly_ as xterm? if so then the string : bash-2.05 $ would get broken into the words: --------- bash - 2 . 05 $ --------- instead of the behaviour now of breaking it into --------- bash-2.05 $ --------- is this expected?
this fixes the not selecting spaces. To change the behavior of the word selection to separate by dashes, dots, etc. it is a simple define in zterm.c that looks like this zvt_term_set_wordclass (ZVT_TERM (term), "-A-Za-z0-9/_:.,?+%="); which we can change to include/not include whatever we want --- libzvt-1.114.0/libzvt/update.c Thu Dec 6 17:54:04 2001 +++ libzvt-1.114.0.new/libzvt/update.c Tue May 14 11:35:34 2002 @@ -921,8 +920,6 @@ while ((sx>0) && (( (vt_in_wordclass(vx, s->data[sx]))))) sx--; - if (!vt_in_wordclass(vx, s->data[sx])) - sx++; } d(printf("%d\n", sx));
okay, I lied, this patch fixes one problem, but reopens a different bug (can't remember the number) that has to do with appending extraneous characters. Will look into more.
nope, wrong again, after investigating more, that patch fixes this bug, will open a different one for bug I am experiencing. (double click pastes three copies of text, not two)
patch below makes it so libzvt selects at least one character. Filing a different bug for full xterm compatability. --- libzvt-1.115.2/libzvt/update.c Thu Dec 6 17:54:04 2001 +++ libzvt-1.115.2.new/libzvt/update.c Tue May 21 02:56:33 2002 @@ -935,7 +935,8 @@ while ((ex<e->width) && ( (vt_in_wordclass(vx, e->data[ex])))) ex++; - + if (ex == sx) + sx--; break; case VT_SELTYPE_CHAR: default:
Jacob: what is the situation with this bug? I know it isn't yours, but does this patch fix the situation? If so, can you apply?
this patch is bogus. i think the correct solution is to check if sx == ex && sy == ey, then scan fwd. back for "blank" characters
sy == ey doesn't make a difference right now as we do not do line wrapping selects on words. Also scanning forward will result in the wrong(?) character getting selected e.g. in " &" if you double click the space then the & sign will get selected if you increment the pointer. Maybe I misunderstoood, or maybe that is what is wanted.
the same thing is observed with all the chars which are not there in list of "Select-by-word characters" in the profile. As for my understanding the chars which are not in this set will act as seprator. Here the space/tab has to considered as special case
Hrm... so can someone update me on the status of this one? I'd /really/ like to see a fix for this in the Release Candidate.
not too sure whether this is the 100% correct solution but i tested out on my machine and this patch seems to fix atleast the crash issues. Whether it should be returning NULL or not in zvttermc:2183 is somebody who knows utf stuff. This is inline with havoc's comment. To explain it further, second parameter passed to gtk_selection_set_data_text() is 0x0 and down below its never checked for NULL at all and during strlen() zvt dumps core. Now before passing it to gtk_selection_set_data_text() check if its Non-null. Index: libzvt/libzvt/zvtterm.c =================================================================== RCS file: /export/cvs/gnome-2.0/libzvt/libzvt/zvtterm.c,v retrieving revision 1.6 diff -p -u -5 -r1.6 zvtterm.c --- libzvt/libzvt/zvtterm.c 2002/06/03 21:27:06 1.6 +++ libzvt/libzvt/zvtterm.c 2002/06/06 07:27:18 @@ -2179,10 +2179,12 @@ zvt_term_selection_get (GtkWidget term = ZVT_TERM (widget); vx = term->vx; converted = zvt_term_convert_selection (term, info, &len); + g_return_if_fail (converted != NULL); + gtk_selection_data_set_text (selection_data_ptr, converted, len); g_free(converted); } /**
This just makes it so you can't cut/paste spaces (or any other special, nonword character). I don't think this is the 'correct' fix. I think the patch I had above should be something more along the correct line, and Bharat's patch as well, just for some double checking. Anyone with more input as to what the correct way is? Do we want it to select all contiguous spaces? all contiguous non-word characters? I don't know what is wanted here.
bharat's latest patch doesn't fix anying. in fact, in optimized builds g_return_* statements aren't even compiled in. the desired behaviour is to do what xterm does - i think it just selects tabs / spaces
oh sorry about it, though i was more worried about the terminal crash rather than the functionality implementation. Jacob will it be okay to have a hack/fixme which just checks whether the converted is NULL and if it is, just return from the function. I know thats not a solution but if we go for the 2.0.0 release and luis finds this as a blocker bug, atleast the crash will be prevented.
Like Jacob said, that g_return statement won't even get compiled in. If we are just looking for stopping the crash, and fixing full xterm emulation in 2.x or so just apply my patch above (with some offset probably). Also as Jacob said before you should add in a check for sy == ey just in case bug 80950 gets fixed.
Created attachment 9077 [details] [review] updated patch for CVS as of 6/8
above patch does not fix the problem completely to the point of xterm compliance, but it is a workaround that will make it so the terminal won't crash. As 2.0.0 is approaching maybe we should push xterm cut/paste compliance to 2.0.1.
Yeah. All I want (all I'd accept as a release team member ATM, even, given the possibility of other things breaking in gnome-terminal) is it not to crash :) Jacob?
can sx be 0 before you decrement it? what happens in this case?
sx cannot be 0 at that point, no. sx always starts on the right hand side of the selection and goes to the left.
are you sure? /* range check horizontal */ if (vx->selstartx<0) vx->selstartx=0; ... sx = vx->selstartx; ... etc? or am i reading things wrong (that code is not easy to understand)
gdk_window_get_pointer should (key word) always returns >0 so that shouldn't happen. Even when sx does = 0 and gets decremented to -1 the selection still goes from -1 to 1 and highlights/cuts/pastes just the first word on the line (or first character if it is special). So I don't see any new bugs popping up with the introduction of this code. I vow I will clean this up some more later:)
ok, the patch will be committed shortly. we'll see how it does ;)
*** Bug 85080 has been marked as a duplicate of this bug. ***