crash when pasting clipboard from mouse
Dominique Pelle
I observe a bug with the latest Vim-7.2.42 (huge) on Linux x86.
It's not recently introduced since I can reproduce at least with
Vim-7.1.314 which comes with Ubuntu-8.10. It only happens in
a terminal (gvim does not seem affected).
Steps to reproduce:
1/ start Vim in a terminal (xterm or gnome-terminal) with: vim -u NONE
2/ enter INSERT mode with: i
3/ select (into clipboard) a few lines of text with the mouse from
another terminal
4/ paste those selected lines with the mouse into Vim (middle click)
5/ visual select all text with and reformat with: <Esc>1GVGgq
6/ delete everything with: :%d
7/ enter insert mode again with: i
8/ paste same again text still in clipboard with the mouse (middle click)
Observe that after pasting test in step 8/, Vim either crashes with:
Vim: Caught deadly signal ABRT
Vim: preserving files...
.. or sometimes Vim just misbehaves (hangs or not longer accepts all
keystrokes for example). Sometimes the text is not inserted at all
when pasting the second time at step 8/.
Running the same test with Valgrind, I see errors 100% of the times
but so far I did not find how to fix them:
==11904== Conditional jump or move depends on uninitialised value(s)
==11904== at 0x47D8548: (within /usr/lib/libXt.so.6.0.0)
==11904== by 0x47D891A: (within /usr/lib/libXt.so.6.0.0)
==11904== by 0x47C23E4: XtDispatchEventToWidget (in /usr/lib/libXt.so.6.0.0)
==11904== by 0x47C2D87: (within /usr/lib/libXt.so.6.0.0)
==11904== by 0x47C1CF6: XtDispatchEvent (in /usr/lib/libXt.so.6.0.0)
==11904== by 0x81415D6: xterm_update (os_unix.c:6513)
==11904== by 0x813F8A1: RealWaitForChar (os_unix.c:4969)
==11904== by 0x813F50E: WaitForChar (os_unix.c:4640)
==11904== by 0x813B53B: mch_inchar (os_unix.c:366)
==11904== by 0x81A4706: ui_inchar (ui.c:193)
==11904== by 0x80D274A: inchar (getchar.c:2959)
==11904== by 0x80D237D: vgetorpeek (getchar.c:2735)
==11904== by 0x80D0919: vgetc (getchar.c:1552)
==11904== by 0x80D0E94: safe_vgetc (getchar.c:1757)
==11904== by 0x806368A: edit (edit.c:711)
==11904== by 0x81233CC: invoke_edit (normal.c:8885)
==11904== by 0x8123372: nv_edit (normal.c:8858)
==11904== by 0x8116C54: normal_cmd (normal.c:1184)
==11904== by 0x80DE8DA: main_loop (main.c:1180)
==11904== by 0x80DE427: main (main.c:939)
(more errors after that)
Does anybody else see that bug too?
-- Dominique
Dominique Pelle
I see that:
- vim 'small' is not affected by the bug
- vim 'normal' has the bug.
Tweaking feature.h manually, I got 2 version of them,
which only differ by the FEAT_XCLIPBOARD feature:
- the one with FEAT_XCLIPBOARD is affected by the bug
- the one without FEAT_XCLIPBOARD is not affected by the bug.
So +xterm_clipboard is the feature that is triggering the bug.
-- Dominique
Matt Wozniski
>
> 2008/11/17 Dominique Pelle:
>
>> Hi
>>
>> I observe a bug with the latest Vim-7.2.42 (huge) on Linux x86.
>> It's not recently introduced since I can reproduce at least with
>> Vim-7.1.314 which comes with Ubuntu-8.10. It only happens in
>> a terminal (gvim does not seem affected).
>>
>> Steps to reproduce:
>> Observe that after pasting test in step 8/, Vim either crashes with:
>>
>> Vim: Caught deadly signal ABRT
>> Vim: preserving files...
>>
>> .. or sometimes Vim just misbehaves (hangs or not longer accepts all
>> keystrokes for example). Sometimes the text is not inserted at all
>> when pasting the second time at step 8/.
>>
>> Running the same test with Valgrind, I see errors 100% of the times
>> but so far I did not find how to fix them:
>> Does anybody else see that bug too?
>
>
> - vim 'small' is not affected by the bug
> - vim 'normal' has the bug.
>
> Tweaking feature.h manually, I got 2 version of them,
> which only differ by the FEAT_XCLIPBOARD feature:
>
> - the one with FEAT_XCLIPBOARD is affected by the bug
> - the one without FEAT_XCLIPBOARD is not affected by the bug.
>
> So +xterm_clipboard is the feature that is triggering the bug.
I'm not having any luck at all reproducing this, with 7.2.025 and
+xterm_clipboard...
~Matt
John Little
> Does anybody else see that bug too?
+xterm_clipboard.
Regards, John
Dominique Pelle
OK, so it looks like I'm the only one affected so far. I will try on
another machine when I get a chance.
Or maybe my description was not clear enough. Step 8/
deserves some clarification:
> 8/ paste same again text still in clipboard with the mouse (middle click)
Pasting same text must be done *without* reselecting it (text
should still be clipboard). If I reselect it, then it does not show
the bug. It looks as if the clipboard content has been corrupted.
-- Dominique
Taylor Venable
"Dominique Pelle" <dominiq...@gmail.com> wrote:
> I observe a bug with the latest Vim-7.2.42 (huge) on Linux x86.
> It's not recently introduced since I can reproduce at least with
> Vim-7.1.314 which comes with Ubuntu-8.10. It only happens in
> a terminal (gvim does not seem affected).
[...]
> Does anybody else see that bug too?
Could NOT reproduce with Vim 7.2.42 with HUGE and +xterm_clipboard on
OpenBSD 4.4 (i386). Complete version info attached; hope this helps.
--
Taylor Christopher Venable
http://real.metasyntax.net:2357/
How many shells could Shell sort
sort if Shell sort could sort shells?
François Ingelrest
<dominiq...@gmail.com> wrote:
> Does anybody else see that bug too?
Works fine for me.
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Nov 17 2008 08:42:16)
Included patches: 1-42
Normal version with GTK2 GUI
Bram Moolenaar
Dominique Pelle wrote:
Perhaps you can trigger it earlier, when it's caused, by setting the
'writedelay' option to some value.
--
GOD: That is your purpose Arthur ... the Quest for the Holy Grail ...
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Dominique Pelle
Setting writedelay does not change anything. It just makes
refreshing screen slower, but I see see the same problem.
But I can simplify the way to reproduce it. It happens whenever
I do a visual selection in between:
- selecting text in clipboard with the mouse
- and pasting with middle click.
Example:
1/ start vim with valgrind: valgrind 2> valgrind.log vim -u NONE
2/ select some text with mouse outside vim (one line is enough)
3/ enter INSERT mode in vim and type some text: iThis is a test<Esc>
4/ visual select line typed in 3/ with: V
5/ click middle mouse to paste text selected in 2/
Observe errors in valgrind.log right after middle mouse click in step 5/
I see this with Vim-7.2.42 (normal or huge, GTK2) on Ubuntu-8.10
as well as Vim-7.1.314 (GTK2-GNOME) on Ubuntu-8.10
I tried on 2 other machines:
- vim-7.2.42 (huge, GTK2 GUI) on openSUSE 10.3 : no bug
observed, valgrind does not complain either (I tried several times)
- vim-7.2.42 (huge, GTK2 GUI) on Ubuntu-7.04 : no apparent bug
but valgrind reports errors as soon as I paste text in step 5/
==12698== Syscall param write(buf) points to uninitialised byte(s)
==12698== at 0x40007F2: (within /lib/ld-2.5.so)
==12698== by 0x487A64E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0)
==12698== by 0x4872526: (within /usr/lib/libX11.so.6.2.0)
==12698== by 0x48725FA: _XReply (in /usr/lib/libX11.so.6.2.0)
==12698== by 0x486C5C9: XSync (in /usr/lib/libX11.so.6.2.0)
==12698== by 0x465E211: (within /usr/lib/libXt.so.6.0.0)
==12698== by 0x46618A4: (within /usr/lib/libXt.so.6.0.0)
==12698== by 0x464B394: XtDispatchEventToWidget (in /usr/lib/libXt.so.6.0.0)
==12698== by 0x464BD37: (within /usr/lib/libXt.so.6.0.0)
==12698== by 0x464ACA6: XtDispatchEvent (in /usr/lib/libXt.so.6.0.0)
==12698== by 0x8151C38: xterm_update (os_unix.c:6513)
==12698== by 0x8150103: RealWaitForChar (os_unix.c:4969)
==12698== by 0x814FE7F: WaitForChar (os_unix.c:4642)
==12698== by 0x814BDFF: mch_inchar (os_unix.c:366)
==12698== by 0x81B85AF: ui_inchar (ui.c:193)
==12698== by 0x80D7DBD: inchar (getchar.c:2959)
==12698== by 0x80D79D1: vgetorpeek (getchar.c:2735)
==12698== by 0x80D5E73: vgetc (getchar.c:1552)
==12698== by 0x80D63EE: safe_vgetc (getchar.c:1757)
==12698== by 0x8064184: edit (edit.c:711)
==12698== by 0x81328AB: invoke_edit (normal.c:8885)
==12698== by 0x8132850: nv_edit (normal.c:8858)
==12698== by 0x8125E7A: normal_cmd (normal.c:1184)
==12698== by 0x80E7FD4: main_loop (main.c:1180)
==12698== by 0x80E7B21: main (main.c:939)
So I see those valgrind errors on only 2 out of 3 machines
which is odd. Also strange the fact that I'm on the only one
who can reproduce this.
I tried to checkout with CVS some tags older than 7.1.314
to see whether it was introduced by a patch but I see the
error on all the version I tried to check-out so far:
7.1.200 .... same error
7.1.100 .... same error
7.1.050 .... same error
-- Dominique
Tony Mechelynck
[...]
> But I can simplify the way to reproduce it. It happens whenever
> I do a visual selection in between:
> - selecting text in clipboard with the mouse
> - and pasting with middle click.
>
> Example:
>
> 1/ start vim with valgrind: valgrind 2> valgrind.log vim -u NONE
> 2/ select some text with mouse outside vim (one line is enough)
> 3/ enter INSERT mode in vim and type some text: iThis is a test<Esc>
> 4/ visual select line typed in 3/ with: V
> 5/ click middle mouse to paste text selected in 2/
>
> Observe errors in valgrind.log right after middle mouse click in step 5/
>
> I see this with Vim-7.2.42 (normal or huge, GTK2) on Ubuntu-8.10
> as well as Vim-7.1.314 (GTK2-GNOME) on Ubuntu-8.10
>
> I tried on 2 other machines:
>
> - vim-7.2.42 (huge, GTK2 GUI) on openSUSE 10.3 : no bug
> observed, valgrind does not complain either (I tried several times)
>
> - vim-7.2.42 (huge, GTK2 GUI) on Ubuntu-7.04 : no apparent bug
> but valgrind reports errors as soon as I paste text in step 5/
What do you have 'clipboard' set to? (The default is "autoselect", which
will make Vim try to get ownership of the X11 selection at step 4).
Best regards,
Tony.
--
Microsoft: "Windows NT 4.0 now has the same user-interface as Windows 95"
Windows 95: "Press CTRL-ALT-DEL to reboot"
Windows NT 4.0: "Press CTRL-ALT-DEL to login"
John Little
When I follow this:
> 1/ start vim with valgrind: valgrind 2> valgrind.log vim -u NONE
> 2/ select some text with mouse outside vim (one line is enough)
> 3/ enter INSERT mode in vim and type some text: iThis is a test<Esc>
> 4/ visual select line typed in 3/ with: V
> 5/ click middle mouse to paste text selected in 2/
most of it as commands in "Visual" mode,
Th => back to the h, is => motion inner sentence, and so on, finally
changing the selection with s to get a solitary "t". So, following
your first step 8, it was the text selected by step 5 that was being
inserted at step 8. valgrind reports an error in getpwuid_r during
vim's startup, but no further errors, other than various leaks
reported on exit.
I wonder what mouse support your build has; in principle not relevant
unless one uses set mouse, but I was surprised that my vim build was
silently affected by the presence of gpm. My :ver says
+mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm
+mouse_netterm -mouse_sysmouse +mouse_xterm
Regards, John
Tony Mechelynck
Configure will enable +mouse_gpm if it finds that gpm is installed (and,
of course, you're compiling at least a Normal build, otherwise you get
-mouse). Nothing surprising in that.
gpm is only used by non-X11 terminals such as the Linux console anyway.
(Hit Ctrl-Alt-Fn with 1 <= n <= 6 to switch to a Linux console.
Ctrl-Alt-F7 brings you back to the X11 interface.)
Best regards,
Tony.
--
Fortune's Real-Life Courtroom Quote #3:
Q: When he went, had you gone and had she, if she wanted to and were
able, for the time being excluding all the restraints on her not to
go, gone also, would he have brought you, meaning you and she, with
him to the station?
MR. BROOKS: Objection. That question should be taken out and shot.
Dominique Pelle
'clipboard was set to default, since I run "vim -u NONE", which is...
clipboard=autoselect,exclude:cons\|linux
But if I do... set clipboard=
... then bug no longer happens.
But more interestingly, I just found that it only happen with locale
being set to eo_XX.UTF-8. It always works fine at least with locale
being C or en_US.UTF-8 or fr_FR.UTF-8 for example. But as soon
as I set locale to eo_XX.UTF-8, then I see the problem all the time.
I tried several times to make sure it was really the case. Now I
know why I'm the only one who could reproduce it.
Maybe it's related to this....
http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/b759a75978bc890b
The file /usr/share/X11/locale/locale.dir contains a comment which says....
# Esperato (eo) is not supported by the GNU C Library and neither the
# EO nor XX territories exist in ISO 3166.
# en_US.UTF-8/XLC_LOCALE: eo_EO.UTF-8
# en_US.UTF-8/XLC_LOCALE: eo_XX.UTF-8
Not sure why Esperanto (*Esperato* is a typo in the file by the
way) is not supported by GNU C lib.
I edited my file /usr/share/X11/locale/locale.dir as follows,
just uncommented the lines about Esperanto, and now
everything works fine in vim with eo_XX.UTF-8 locale
pel@pel-laptop:/usr/share/X11/locale$ diff -c locale.dir.orig locale.dir
*** locale.dir.orig 2008-11-19 08:03:48.000000000 +0100
--- locale.dir 2008-11-19 08:00:58.000000000 +0100
***************
*** 353,360 ****
en_US.UTF-8/XLC_LOCALE en_ZW.UTF-8
# Esperato (eo) is not supported by the GNU C Library and neither the
# EO nor XX territories exist in ISO 3166.
! #en_US.UTF-8/XLC_LOCALE: eo_EO.UTF-8
! #en_US.UTF-8/XLC_LOCALE: eo_XX.UTF-8
en_US.UTF-8/XLC_LOCALE es_AR.UTF-8
en_US.UTF-8/XLC_LOCALE es_BO.UTF-8
en_US.UTF-8/XLC_LOCALE es_CL.UTF-8
--- 353,360 ----
en_US.UTF-8/XLC_LOCALE en_ZW.UTF-8
# Esperato (eo) is not supported by the GNU C Library and neither the
# EO nor XX territories exist in ISO 3166.
! en_US.UTF-8/XLC_LOCALE: eo_EO.UTF-8
! en_US.UTF-8/XLC_LOCALE: eo_XX.UTF-8
en_US.UTF-8/XLC_LOCALE es_AR.UTF-8
en_US.UTF-8/XLC_LOCALE es_BO.UTF-8
en_US.UTF-8/XLC_LOCALE es_CL.UTF-8
***************
*** 846,853 ****
en_US.UTF-8/XLC_LOCALE: en_ZW.UTF-8
# Esperato (eo) is not supported by the GNU C Library and neither the
# EO nor XX territories exist in ISO 3166.
! #en_US.UTF-8/XLC_LOCALE: eo_EO.UTF-8
! #en_US.UTF-8/XLC_LOCALE: eo_XX.UTF-8
en_US.UTF-8/XLC_LOCALE: es_AR.UTF-8
en_US.UTF-8/XLC_LOCALE: es_BO.UTF-8
en_US.UTF-8/XLC_LOCALE: es_CL.UTF-8
--- 846,853 ----
en_US.UTF-8/XLC_LOCALE: en_ZW.UTF-8
# Esperato (eo) is not supported by the GNU C Library and neither the
# EO nor XX territories exist in ISO 3166.
! en_US.UTF-8/XLC_LOCALE: eo_EO.UTF-8
! en_US.UTF-8/XLC_LOCALE: eo_XX.UTF-8
en_US.UTF-8/XLC_LOCALE: es_AR.UTF-8
en_US.UTF-8/XLC_LOCALE: es_BO.UTF-8
en_US.UTF-8/XLC_LOCALE: es_CL.UTF-8
But why those lines were commented out in the first place
is not clear? I'll report that as bug in Ubuntu or Debian.
It's not vim's fault after all. In any case, issue is now solved
for me.
-- Dominique
Dominique Pelle
> Dominique
>
> When I follow this:
>
>> 1/ start vim with valgrind: valgrind 2> valgrind.log vim -u NONE
>> 2/ select some text with mouse outside vim (one line is enough)
>> 3/ enter INSERT mode in vim and type some text: iThis is a test<Esc>
>> 4/ visual select line typed in 3/ with: V
>> 5/ click middle mouse to paste text selected in 2/
>
> step 5 attempts to insert the text entered in step 3, but interprets
> most of it as commands in "Visual" mode,
> Th => back to the h, is => motion inner sentence, and so on, finally
> changing the selection with s to get a solitary "t". So, following
> your first step 8, it was the text selected by step 5 that was being
> inserted at step 8. valgrind reports an error in getpwuid_r during
> vim's startup, but no further errors, other than various leaks
> reported on exit.
Right, but bug also happens if I entered insert mode before pasting
text.
Anyway, I found the root cause and a fix. See my previous post:
It only happened with locale being set to eo_XX.UTF-8, and a change
in my /usr/share/X11/locale/locale.dir fixes it.
> I wonder what mouse support your build has; in principle not relevant
> unless one uses set mouse, but I was surprised that my vim build was
> silently affected by the presence of gpm. My :ver says
>
> +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm
> +mouse_netterm -mouse_sysmouse +mouse_xterm
For the record, It happened with:
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path
+float +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand
+jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap
+menu +mksession +modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm
-mouse_jsbterm +mouse_netterm -mouse_sysmouse +mouse_xterm +multi_byte
+multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra -perl +postscript
+printer +profile -python +quickfix +reltime +rightleft -ruby +scrollbind
+signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title
+toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo
+vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim
-- Dominique
Tony Mechelynck
In the locale.dir distributed by SuSE (with openSUSE 11.0):
lines 319-326:
en_US.UTF-8/XLC_LOCALE en_US.UTF-8
en_US.UTF-8/XLC_LOCALE en_ZA.UTF-8
en_US.UTF-8/XLC_LOCALE en_ZW.UTF-8
en_US.UTF-8/XLC_LOCALE eo_EO.UTF-8
en_US.UTF-8/XLC_LOCALE eo_XX.UTF-8
en_US.UTF-8/XLC_LOCALE es_AR.UTF-8
en_US.UTF-8/XLC_LOCALE es_BO.UTF-8
en_US.UTF-8/XLC_LOCALE es_CL.UTF-8
lines 760-767:
en_US.UTF-8/XLC_LOCALE: en_US.UTF-8
en_US.UTF-8/XLC_LOCALE: en_ZA.UTF-8
en_US.UTF-8/XLC_LOCALE: en_ZW.UTF-8
en_US.UTF-8/XLC_LOCALE: eo_EO.UTF-8
en_US.UTF-8/XLC_LOCALE: eo_XX.UTF-8
en_US.UTF-8/XLC_LOCALE: es_AR.UTF-8
en_US.UTF-8/XLC_LOCALE: es_BO.UTF-8
en_US.UTF-8/XLC_LOCALE: es_CL.UTF-8
Note that the second set has colons after XLC_LOCALE, the other not.
The string eo_EO occurs /in toto/ 4 times in the file (the other two are
for ISO8859-3).
Eble la ubuntuestroj kal/aŭ la debianestroj estas tutsimple
kontraŭesperantistoj?
Best regards,
Tony.
--
GOD is applied POWER
which is applied GOVERNMENT
which is applied POLITICS
which is applied ADVERTISING
which is applied SOCIOLOGY
which is applied PSYCHOLOGY
which is applied BIOLOGY
which is applied CHEMISTRY
which is applied PHYSICS
which is applied MATH
which is applied PHILOSOPHY
which is applied BULLSHIT