Bugzilla – Bug 112930
vim: seqfaults while svn commits
Last modified: 2006-03-20 14:18:42 UTC
vim crashes from time to time while svn commit with errormessage: "... revieved Signal 11 ...". In this case you must reset the console and if you retry the commit it crashes again and again and ... To get vim back you must remove .viminfo from your home. This is more than ugly behavior!
The viminfo file is just corrupted. Nothing we can do about that. See Bug #51666 Bug #53703
What kind of solution is 'remove .viminfo'. If vim creates corrupted viminfo file this must be fixed!
good luck
Was the .viminfo created by earlier distributions, or was it created by the vim in the beta (which one) you were running?
no, this was always from a fresh installation. No changes or updates, clean new user home. This happend on 9.2, 10.0 Preview and Beta 4.
Can I see your .vimrc?
I don't have a .vimrc in my home. I changed only in /etc/vimrc "syntax on" to get syntax highlighting. If you need this one, let me know.
How does subversion invoke vim?
Can you try: 1) add "set viminfo+=c" to /etc/vimrc 2) rm ~/.viminfo And now reproduce.
I will try this. I have stored 2 invalid .viminfo here saved. I mail you the files directly.
Any news? You have to start with a fresh .vimrc after adding the above.
Sorry for the lack ... I test this tomorrow again.
Are you able to reproduce like said in comment #9?
I added this and I could not reproduce this crash currently, but I did currently not so many svn commits as before. I must test more with svn to check if this happen again.
Any news here?
*** Bug 118179 has been marked as a duplicate of this bug. ***
Can people who can reproduce after taking the steps in comment #9 please post their viminfo settings from vimrc?
Created attachment 50627 [details] Newly created ~/.viminfo file after trying to run 'svn co' After trying comment #9, it seems the problem has disappeared. If you need more info, tell me. :)
I had these crashes frequently. Always removed .viminfo to proceed. Now i added set viminfo+=c to my .vimrc. Let's see if it happens again.
If people can reproduce, please try with: ~mmj/Export/vim-10.0-i386 packages
So apparantly these packages seems more stable, could someone else please try them out?
the ~mmj package doesn't seem to segfault here during svn commit anymore. but it only happens rather rarely anyway. but if it happens, then it usually happens 5-10 times in a row.
viminfo+=c did not help. I remove that again and update to vim-6.3.84-2.1.
Immediately after vim update with old .viminfo it happened again. I remove .viminfo now as always.
still happens.. =7457== Conditional jump or move depends on uninitialised value(s) ==7457== at 0x80D3A2E: ??? (mbyte.c:1570) ==7457== by 0x80BF185: ??? (message.c:2840) ==7457== by 0x80B98C9: ??? (memline.c:3733) ==7457== by 0x80B9FA2: ??? (memline.c:495) ==7457== by 0x809962D: ??? (fileio.c:634) ==7457== by 0x804FD13: ??? (buffer.c:131) ==7457== by 0x80AFD5D: ??? (main.c:1792) ==7457== by 0x40A6E97: __libc_start_main (in /lib/libc-2.3.6.so) ==7457== ==7457== Conditional jump or move depends on uninitialised value(s) ==7457== at 0x80D3A2E: ??? (mbyte.c:1570) ==7457== by 0x80BF038: ??? (message.c:2910) ==7457== by 0x80B98C9: ??? (memline.c:3733) ==7457== by 0x80B9FA2: ??? (memline.c:495) ==7457== by 0x809962D: ??? (fileio.c:634) ==7457== by 0x804FD13: ??? (buffer.c:131) ==7457== by 0x80AFD5D: ??? (main.c:1792) ==7457== by 0x40A6E97: __libc_start_main (in /lib/libc-2.3.6.so) ==7457== ==7457== Invalid read of size 1 ==7457== at 0x80D3DEF: ??? (mbyte.c:2349) ==7457== by 0x80D500D: ??? (mbyte.c:2551) ==7457== by 0x80D5075: ??? (mbyte.c:2531) ==7457== by 0x80E0467: ??? (normal.c:1248) ==7457== by 0x80AE956: ??? (main.c:2183) ==7457== by 0x80B00DD: ??? (main.c:2001) ==7457== by 0x40A6E97: __libc_start_main (in /lib/libc-2.3.6.so) ==7457== Address 0x4510BD8 is 8 bytes after a block of size 4,096 alloc'd ==7457== at 0x401B142: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==7457== by 0x80CD0B7: ??? (misc2.c:843) ==7457== by 0x80CD359: ??? (misc2.c:742) ==7457== by 0x80B4F17: ??? (memfile.c:939) ==7457== by 0x80B5445: ??? (memfile.c:382) ==7457== by 0x80B668F: ??? (memline.c:2937) ==7457== by 0x80BA550: ??? (memline.c:329) ==7457== by 0x804FC04: ??? (buffer.c:86) ==7457== by 0x80AFD5D: ??? (main.c:1792) ==7457== by 0x40A6E97: __libc_start_main (in /lib/libc-2.3.6.so) ==7457==
Created attachment 63151 [details] and again valgrind with debuginfo....
Any new debuginfo here from beta2? I've compiled it with stack-protector-all.
*** Bug 148397 has been marked as a duplicate of this bug. ***
*** Bug 149046 has been marked as a duplicate of this bug. ***
I just saw it happen on a 9.1 box: svn runs 'vim -c "set tw=72 et" svn-commit.tmp User presses 'i' to enter insert mode, and vim dies. The user was typing very quickly and fumbled a few times, producing strange utf-8 digraphs which he fixed by backspacing. Then he managed to enter the svn command and vim crashed. Not reproducable.
I have this segfault daily (sometimes even several times a day) when commiting to svn.samba.org. At least on my 10.0 box a simple rm ~/.viminfo* allows to repeat the crashed commit sucessfully.
I can reproduce, and know what is going on. Tricky. A workaround would be: end your commit message with the cursor in the first column :-) don't ask.
Created attachment 73785 [details] suggested fix This patch should fix the problem. Submitted to stable. I am unsure if vim7 needs a similar fix or not. Please investigate.
Created attachment 73786 [details] same patch for 9.1
Thorsten, is this something for SLES9-SP4?
fixed in stable