Re: crash when pasting clipboard from mouse
Dominique Pelle 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). 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: Esc1GVGgq 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? 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 -- [EMAIL PROTECTED] -- 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/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
2008/11/18 Bram Moolenaar [EMAIL PROTECTED]: Dominique Pelle 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). 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: Esc1GVGgq 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? Perhaps you can trigger it earlier, when it's caused, by setting the 'writedelay' option to some value. 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 testEsc 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:
Re: crash when pasting clipboard from mouse
On 18/11/08 22:29, Dominique Pelle wrote: [...] 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 testEsc 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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
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 testEsc 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. 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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
On 19/11/08 06:40, John Little wrote: 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 testEsc 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. 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 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. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
2008/11/19 Tony Mechelynck [EMAIL PROTECTED]: On 18/11/08 22:29, Dominique Pelle wrote: [...] 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 testEsc 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. '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 [EMAIL PROTECTED]:/usr/share/X11/locale$ diff -c locale.dir.orig locale.dir *** locale.dir.orig 2008-11-19 08:03:48.0 +0100 --- locale.dir 2008-11-19 08:00:58.0 +0100 *** *** 353,360 en_US.UTF-8/XLC_LOCALEen_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_LOCALEes_AR.UTF-8 en_US.UTF-8/XLC_LOCALEes_BO.UTF-8 en_US.UTF-8/XLC_LOCALEes_CL.UTF-8 --- 353,360 en_US.UTF-8/XLC_LOCALEen_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_LOCALEes_AR.UTF-8 en_US.UTF-8/XLC_LOCALEes_BO.UTF-8 en_US.UTF-8/XLC_LOCALEes_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 --~--~-~--~~~---~--~~ You received
Re: crash when pasting clipboard from mouse
2008/11/19 John Little [EMAIL PROTECTED]: 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 testEsc 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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
On 19/11/08 08:13, Dominique Pelle wrote: 2008/11/19 Tony Mechelynck[EMAIL PROTECTED]: On 18/11/08 22:29, Dominique Pelle wrote: [...] 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 testEsc 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. '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 [EMAIL PROTECTED]:/usr/share/X11/locale$ diff -c locale.dir.orig locale.dir *** locale.dir.orig 2008-11-19 08:03:48.0 +0100 --- locale.dir2008-11-19 08:00:58.0 +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. --
crash when pasting clipboard from mouse
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: 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: Esc1GVGgq 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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
2008/11/17 Dominique Pelle [EMAIL PROTECTED]: 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: 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: Esc1GVGgq 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 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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
On Mon, Nov 17, 2008 at 6:02 PM, Dominique Pelle wrote: 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? 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. I'm not having any luck at all reproducing this, with 7.2.025 and +xterm_clipboard... ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
Hi Does anybody else see that bug too? No. Ubuntu 8.04, x86_64, vim 7.2.042, huge including +xterm_clipboard. Regards, John --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
On Mon, 17 Nov 2008 22:18:23 +0100 Dominique Pelle [EMAIL PROTECTED] 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? --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- vim-version.txt Description: Binary data
Re: crash when pasting clipboard from mouse
On Mon, Nov 17, 2008 at 22:18, Dominique Pelle [EMAIL PROTECTED] 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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
