core dump with vim 1:7.1-138+1ubuntu3
I have been encountering an intermittent coredump using vim 7.1 under Hardy, see the subject for the exact version. Please let me know if this is not the correct forum for this message. I rebuilt vim from source with symbols after I stumbled on a reproduceable test case today. The backtrace from the core dump is as follows. It looks like the field uh_next_alt is being corrupted. Often in the backtrace it also contains the value 0x11. The coredump is sensitive to the value of VIMINIT. I can write up the exact steps to reproduce this error for anyone interested/capable of debugging this error. Frank (gdb) bt #0 0x00587e19 in u_unch_branch (uhp=0xa2d07f4eac59) at undo.c:1576 #1 0x00587e42 in u_unch_branch (uhp=0x8ad450) at undo.c:1578 #2 0x00587def in u_unchanged (buf=0x8151a0) at undo.c:1564 #3 0x004988b4 in buf_write (buf=0x8151a0, fname=0x817200 t, sfname=0x817200 t, start=1, end=47, eap=0x7fffb5727a60, append=0, forceit=0, reset_changed=1, filtering=0) at fileio.c:4517 #4 0x0046724e in do_write (eap=0x7fffb5727a60) at ex_cmds.c: 2687 #5 0x0047e082 in ex_exit (eap=0x7fffb5727a60) at ex_docmd.c: 6590 #6 0x004775cc in do_one_cmd (cmdlinep=0x7fffb5727cc8, sourcing=0, cstack=0x7fffb5727d00, fgetline=0x48acd9 getexline, cookie=0x0) at ex_docmd.c:2621 #7 0x00474dc8 in do_cmdline (cmdline=0x0, getline=0x48acd9 getexline, cookie=0x0, flags=0) at ex_docmd.c:1099 #8 0x004f74b0 in nv_colon (cap=0x7fffb5728250) at normal.c: 5168 #9 0x004f1080 in normal_cmd (oap=0x7fffb5728320, toplevel=1) at normal.c:1141 #10 0x004b5735 in main_loop (cmdwin=0, noexmode=0) at main.c: 1181 #11 0x004b5334 in main (argc=2, argv=0x7fffb57285e8) at main.c: 940 (gdb) f 1 #1 0x00587e42 in u_unch_branch (uhp=0x8ad450) at undo.c:1578 1578u_unch_branch(uh-uh_alt_next); /* recursive */ (gdb) p uh-uh_alt_next $1 = (u_header_T *) 0xa2d07f4eac59 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: core dump with vim 1:7.1-138+1ubuntu3
On Oct 14, 12:13 pm, frankjas [EMAIL PROTECTED] wrote: I have been encountering an intermittent coredump ... I rebuilt vim from source with symbols after I stumbled on a reproduceable test case today... Brilliant. follows. It looks like the field uh_next_alt is being corrupted. Often in the backtrace it also contains the value 0x11. I can write up the exact steps to reproduce this error for anyone interested/capable of debugging this error. Yes, please. An early step will be to try it with an up to date version of vim, which is at 7.2.025, some hundreds of fixes after 7.1.138. Regards, John --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: core dump with vim 1:7.1-138+1ubuntu3
On Mon, Oct 13, 2008 at 8:37 PM, John Little wrote: On Oct 14, 12:13 pm, frankjas wrote: I have been encountering an intermittent coredump ... I rebuilt vim from source with symbols after I stumbled on a reproduceable test case today... Brilliant. follows. It looks like the field uh_next_alt is being corrupted. Often in the backtrace it also contains the value 0x11. I can write up the exact steps to reproduce this error for anyone interested/capable of debugging this error. Yes, please. An early step will be to try it with an up to date version of vim, which is at 7.2.025, some hundreds of fixes after 7.1.138. Regards, John https://bugs.launchpad.net/ubuntu/+source/vim/+bug/219546 In short, Ubuntu Hardy shipped with a seriously buggy version - any vim version between 7.1.127 and 7.1.146 suffers from double-frees leading to crashes. Your best bet is to rebuild from source, either from the package source with the latest 7.1 patches, or from the up-to-date 7.2 sources, or to install the Ubuntu Intrepid vim. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: core dump with vim 1:7.1-138+1ubuntu3
On Oct 13, 6:41 pm, Matt Wozniski [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2008 at 8:37 PM, John Little wrote: On Oct 14, 12:13 pm, frankjas wrote: I have been encountering an intermittent coredump ... I rebuilt vim from source with symbols after I stumbled on a reproduceable test case today... Brilliant. follows. It looks like the field uh_next_alt is being corrupted. Often in the backtrace it also contains the value 0x11. I can write up the exact steps to reproduce this error for anyone interested/capable of debugging this error. Yes, please. An early step will be to try it with an up to date version of vim, which is at 7.2.025, some hundreds of fixes after 7.1.138. Regards, John https://bugs.launchpad.net/ubuntu/+source/vim/+bug/219546 In short, Ubuntu Hardy shipped with a seriously buggy version - any vim version between 7.1.127 and 7.1.146 suffers from double-frees leading to crashes. Your best bet is to rebuild from source, either from the package source with the latest 7.1 patches, or from the up-to-date 7.2 sources, or to install the Ubuntu Intrepid vim. ~Matt I built 7.2 from standard vim sources, with ./configure --with- features=huge --with-gnome and no seg-fault on the test case, so apparently the intermediate patches from 7.1.138 to 7.2 did the trick. Thanks for the info on buggy vim in hardy. I've been googling around for a while, didn't stumble on that one. Frank --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
bad default shellxquote in Widows
I've been playing around with a plugin (http://www.vim.org/scripts/script.php?script_id=2378), trying to specify a path to the _command_ that is passed to system(). Since this command may have spaces in it, it needs to be wrapped in quotes. However, if it is wrapped in quotes, the default settings of shellxquote on win32 do not work. This command will not do what is intended, for example: cmd /c C:\some path\some program.exe an argument If you set shellxquote to \ it does work. The command passed looks funny, but is actually desired: cmd /c C:\some path\some program.exe an argument I think that shellxquote should default to \ on Windows always. I know of no case where it fails. The reason for this behavior: From the help for cmd in Windows: If /C or /K is specified, then the remainder of the command line after the switch is processed as a command line, where the following logic is used to process quote () characters: 1. If all of the following conditions are met, then quote characters on the command line are preserved: - no /S switch - exactly two quote characters - no special characters between the two quote characters, where special is one of: ()@^| - there are one or more whitespace characters between the the two quote characters - the string between the two quote characters is the name of an executable file. 2. Otherwise, old behavior is to see if the first character is a quote character and if so, strip the leading character and remove the last quote character on the command line, preserving any text after the last quote character. Both values of shellxquote, in this case, will fall into category 2. Thus, the current default actually executes the command: C:\some path\some program.exe an argument Whereas, setting shellxquote to \ will execute: C:\some path\some program.exe an argument This is the desired command. Normal commands would still work, for example, the command: echo abc def becomes: cmd /c echo abc def which executes: echo abc def Again, just as desired. This might not always work, because I think some versions of cmd.exe will strip the _closing_ quote instead of the _last_ quote. For the best possible compatibility, it is probably a good idea to also default shellcmdflag to /s\ /c instead of just /c in the same situation that /c currently applies. This will force the 2nd quote behavior given in the quoted cmd help. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
