Description of problem: when cutting and pasting ">>> text....text " lines into an email using vim as the editor I get a segv in vim. Only happens with >>> text and does not happen if I save the email as a text file and perform the same task. Version-Release number of selected component (if applicable): How reproducible:[gartim@genepi1 ~]$ mutt -v Mutt 1.5.21 (2010-09-15) Copyright (C) 1996-2009 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 3.4.4-5.fc17.x86_64 (x86_64) ncurses: ncurses 5.9.20120204 (compiled with 5.9) libidn: 1.24 (compiled with 1.24) hcache backend: tokyocabinet 1.4.47 Compile options: -DOMAIN -DEBUG -HOMESPOOL -USE_SETGID -USE_DOTLOCK -DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP +USE_SMTP -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE ISPELL="/usr/bin/hunspell" SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/share/mutt" SYSCONFDIR="/etc" EXECSHELL="/bin/sh" -MIXMASTER To contact the developers, please mail to <mutt-dev>. To report a bug, please visit http://bugs.mutt.org/. [gartim@genepi1 ~]$ vim --version VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Jun 18 2012 09:17:13) Included patches: 1-415, 417-556 Modified by <bugzilla> Compiled by <bugzilla> Huge version without GUI. Features included (+) or not (-): +arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent -clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con +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 -lua +menu +mksession +modify_fname +mouse -mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm -mouse_sysmouse +mouse_xterm +mouse_urxvt +multi_byte +multi_lang -mzscheme +netbeans_intg +path_extra +perl +persistent_undo +postscript +printer +profile +python -python3 +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent -sniff +startuptime +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 -xsmp -xterm_clipboard -xterm_save system vimrc file: "/etc/vimrc" user vimrc file: "$HOME/.vimrc" user exrc file: "$HOME/.exrc" fall-back for $VIM: "/etc" f-b for $VIMRUNTIME: "/usr/share/vim/vim73" Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -I/usr/local/include -O2 -g -pipe -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 Linking: gcc -L. -Wl,-z,relro -rdynamic -Wl,-export-dynamic -Wl,--enable-new-dtags -Wl,-rpath,/usr/lib64/perl5/CORE -Wl,-z,relro -L/usr/local/lib -Wl,--as-needed -o vim -lm -lnsl -lselinux -lncurses -lacl -lattr -lgpm -ldl -Wl,--enable-new-dtags -Wl,-rpath,/usr/lib64/perl5/CORE -fstack-protector -L/usr/lib64/perl5/CORE -lperl -lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc -L/usr/lib64/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic -lruby -lpthread -lrt -ldl -lcrypt -lm Steps to Reproduce: 1.select group of previous email text with leading >>>'s 2. (vim) a 3. click center mouse button to paste text Actual results: segv Expected results: paste Additional info:
seem the auto sometihing that keep adding to the >>> is having the problem, and could be a config option within mutt or vim. It only happens if mark several line with save ">>>" on each and then append them within mutt. If I do the same function outside of mutt vim works, not segv. hope this helps.
i said cutting and pasting and ment to say marking and pasting into an email. g.
Thanks for the report. If you could include a backtrace of the segfault with hidden sensitive fields if there are any, it could help a lot. Since you say vim actually segfaults, I'm re-assigning to vim component. Also, if you can try anything to let alone vim crash without being executed from mutt, it'd support my theory, that a problem is in vim component. However I haven't manage to reproduce such failure yet, while trying the following builds: $ rpm -q mutt vim-enhanced mutt-1.5.21-11.fc17.x86_64 vim-enhanced-7.3.515-1.fc17.x86_64
tried mutt -d 2 and got: [gartim@genepi1 ~]$ mutt -d 2 DEBUG was not defined during compilation. Ignored. Vim: Caught deadly signal SEGV Vim: preserving files... tried gdb with set logging file backtrace.log set logging on run got nothing in the log, but terminal recvd below, maybe you could advise on how I could get a back trace, see below, again only happens when the mark/paste strings have multiple '>' symbols..seem like something continually increasing the number of '>' and maybe blowing a buffer? >> >>>>These 2 are for something different. This is for a staff member >>>>>>that just begun. Separate from Gary's job. >>>>>>>> >>>>>>>>>>Stewart >>>>>>>>>>>> >>On >>>>>>>>>>>> >>7/18/2012 >>>>>>>>>>>> >>9:16 >>>>>>>>>>>> >>AM, >>>>>>>>>>>> >>Justin >>>>>>>>>>>> >>Tipton >>>>>>>>>>>> >>wrote: >>>>>>>>>>>> >>>>>Hi >>>>>>>>>>>> >>>>>Gary, >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>Do >>>>>>>>>>>> >>>>>>>>>>>you >>>>>>>>>>>> >>>>>>>>>>>have >>>>>>>>>>>> >>>>>>>>>>>info >>>>>>>>>>>> >>>>>>>>>>>on >>>>>>>>>>>> >>>>>>>>>>>these?: *** glibc detected *** vim: free(): invalid next size (fast): 0x00000000008e9db0 *** ~ ~ ~ ~ ~ ~
Vim catches SIGSEGV so the coredump/backtrace is not generated. You can patch vim temporarily to not hanlde SIGSEGV (and having vim-debuginfo installed you should get the backtrace: diff -up vim73/src/os_unix.c.sigsegv vim73/src/os_unix.c --- vim73/src/os_unix.c.sigsegv 2012-07-27 08:43:41.291488517 +0200 +++ vim73/src/os_unix.c 2012-07-27 08:43:58.219537188 +0200 @@ -278,9 +278,6 @@ static struct signalinfo #ifdef SIGBUS {SIGBUS, "BUS", TRUE}, #endif -#ifdef SIGSEGV - {SIGSEGV, "SEGV", TRUE}, -#endif #ifdef SIGSYS {SIGSYS, "SYS", TRUE}, #endif Looking at the code quickly I don't see any other way, maybe vim maintainer knows some tricks?
did the patch and download the rpm, for vim-debuginfo, but it doesnt produce a backtrace -- probably need to turn something on? where would the backtrace go? some result testing: if I cut into a vim / input running mutt with progressive ">, >>, >>>" (without the patch): *** glibc detected *** vim: free(): invalid next size (fast): 0x0000000001c17a40 *** *** glibc detected *** vim: malloc(): memory corruption: 0x0000000001c17a70 *** __with_the_patch__ and vim-debuginfo-7.3.556-1.fc17.x86_64.rpm : Error running "/bin/vim '/tmp/mutt-genepi1-500-1947-1673226401180139601'"! [gartim@genepi1 ~]$ mutt 2>1 Vim: Caught deadly signal ABRT Vim: preserving files... Vim: Finished. Mailbox is unchanged. If I remove my .vimrc, no error: syntax on set bg=dark "colorscheme elflord ""hi Normal cterm=underline ctermbg=Blue ctermfg=White "hi Constant ctermfg=Green ""hi Normal ctermfg=Black "hi NonText ctermfg=Black ""hi Special ctermfg=Green "hi Cursor ctermfg=Green "" "hi Comment ctermfg=DarkBlue guifg=Blue ""hi Statement ctermfg=DarkRed guifg=Brown "hi Identifier ctermfg=Blue guifg=DarkCyan """hi PreProc ctermfg=Magenta guifg=Purple hi PreProc ctermfg=Green guifg=Green "hi Constant ctermfg=Black guifg=Magenta ""hi Special ctermfg=DarkMagenta guifg=SlateBlue "hi Type ctermfg=DarkCyan guifg=SeaGreen ""hi Ignore ctermfg=Gray guifg=bg set fo=tcrq
Starting program: /usr/bin/mutt [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Detaching after fork from child process 21407. Detaching after fork from child process 21412. Detaching after fork from child process 21415. Detaching after fork from child process 21418. Program received signal SIGHUP, Hangup. 0x00007ffff5f725da in waitpid () from /lib64/libc.so.6 Starting program: /usr/bin/mutt [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Detaching after fork from child process 2042. Detaching after fork from child process 2044. [Inferior 1 (process 2039) exited normally] No stack. using gdb like so, not very versed in it yet: gdb mutt /mutt...(no debugging symbols found)...done. Missing separate debuginfos, use: debuginfo-install mutt-1.5.21-12.fc17.x86_64 t: (gdb) set logging file backtrace.log (gdb) set logging on (gdb) run ...did my cut/paste of >, >>, >>> with full lines of text, whole page (gdb) bt (gdb) no backtrace available (gdb) quit think in need a detailed log of how to install the debugging info and steps to run, seem I'm not getting a trace...thanks, g.
(In reply to comment #6) > did the patch and download the rpm, for vim-debuginfo, but it doesnt produce > a backtrace -- probably need to turn something on? where would the backtrace > go? If you mean generation of coredump file, you should have "ulimit -c" set to some sane value, usually "unlimited". The core file is then generated in the working directory usually. > some result testing: > > if I cut into a vim / input running mutt with progressive ">, >>, >>>" > (without the patch): > > *** glibc detected *** vim: free(): invalid next size (fast): > 0x0000000001c17a40 *** > *** glibc detected *** vim: malloc(): memory corruption: 0x0000000001c17a70 > *** > > __with_the_patch__ and vim-debuginfo-7.3.556-1.fc17.x86_64.rpm : > > Error running "/bin/vim '/tmp/mutt-genepi1-500-1947-1673226401180139601'"! For tracking memory issues you can use: valgrind -v --trace-children=yes --log-file=vim.txt /usr/bin/mutt (In reply to comment #7) > think in need a detailed log of how to install the debugging info and steps > to run, seem I'm not getting a trace...thanks, g. If you built your own vim rpm, then installing vim-debuginfo package built at the same time should be enough.
vim-7.3.638-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/vim-7.3.638-2.fc17
Package vim-7.3.638-2.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing vim-7.3.638-2.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-12869/vim-7.3.638-2.fc17 then log in and leave karma (feedback).
vim-7.3.638-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
hi! I have fresh fedora 17 install and I've updated yum and installed vim. When I'm trying to run it I've got: Vim: Caught deadly signal SEGV Vim: Finished. [1] 10759 segmentation fault (core dumped) vim when running as root it works.