Re: Vim SEGV
2008/12/27 Matt Wozniski wrote: I found a SEGV that I can reproduce reliably, but can't seem to track down. It SEGVs without gdb or valgrind, doesn't SEGV under valgrind, and SEGVs under gdb. The steps that I'm using to reproduce this are complicated, and possibly very specific to the version of the runtime files and such that I'm using, but I'm hoping that a log of the backtrace + valgrind log can help someone to track it down. GDB shows: Program received signal SIGSEGV, Segmentation fault. 0xb8063424 in __kernel_vsyscall () (gdb) bt #0 0xb8063424 in __kernel_vsyscall () #1 0xb7885956 in kill () from /lib/i686/cmov/libc.so.6 #2 0x08137c79 in may_core_dump () at os_unix.c:3070 #3 0x08137c10 in mch_exit (r=1) at os_unix.c:3035 #4 0x080db39c in getout (exitval=1) at main.c:1344 #5 0x08100ea0 in preserve_exit () at misc1.c:8371 #6 0x0813617c in deathtrap (sigarg=11) at os_unix.c:1057 #7 signal handler called #8 0x08079b32 in deref_func_name (name=0x90546a5 netrw#Explore(0,0,0+0,''), lenp=0xbf87d4ec) at eval.c:7833 #9 0x0808b2e5 in trans_function_name (pp=0xbf87d574, skip=0, flags=1, fdp=0xbf87d554) at eval.c:20395 #10 0x0807389e in ex_call (eap=0xbf87d608) at eval.c:3271 #11 0x080a0d5b in do_one_cmd (cmdlinep=0xbf87da44, sourcing=1, cstack=0xbf87d740, fgetline=0, cookie=0x0) at ex_docmd.c:2622 #12 0x0809e834 in do_cmdline (cmdline=0x9126bb0 call netrw#Explore(0,0,0+0,''), getline=0, cookie=0x0, flags=11) at ex_docmd.c:1096 #13 0x080a6562 in do_ucmd (eap=0xbf87db78) at ex_docmd.c:5989 #14 0x080a0d32 in do_one_cmd (cmdlinep=0xbf87dfb4, sourcing=1, cstack=0xbf87dcb0, fgetline=0, cookie=0x0) at ex_docmd.c:2613 #15 0x0809e834 in do_cmdline (cmdline=0x91165c6 E, getline=0, cookie=0x0, flags=11) at ex_docmd.c:1096 #16 0x0809e0f1 in do_cmdline_cmd (cmd=0x91165c6 E) at ex_docmd.c:702 #17 0x080997f0 in ex_debug (eap=0xbf87e0c8) at ex_cmds2.c:301 #18 0x080a0d5b in do_one_cmd (cmdlinep=0xbf87e504, sourcing=0, cstack=0xbf87e200, fgetline=0x80b4047 getexline, cookie=0x0) at ex_docmd.c:2622 #19 0x0809e834 in do_cmdline (cmdline=0x0, getline=0x80b4047 getexline, cookie=0x0, flags=0) at ex_docmd.c:1096 #20 0x081188af in nv_colon (cap=0xbf87e5f0) at normal.c:5233 #21 0x08111f9b in normal_cmd (oap=0xbf87e690, toplevel=1) at normal.c:1200 #22 0x080db0e3 in main_loop (cmdwin=0, noexmode=0) at main.c:1183 #23 0x080dac41 in main (argc=1, argv=0xbf87e894) at main.c:942 Valgrind gives: 1 errors in context 1 of 1: Invalid read of size 4 at 0x8088402: find_var_in_ht (eval.c:18815) by 0x8088277: find_var (eval.c:18769) by 0x8079B16: deref_func_name (eval.c:7831) by 0x808B2E4: trans_function_name (eval.c:20395) by 0x807389D: ex_call (eval.c:3271) by 0x80A0D5A: do_one_cmd (ex_docmd.c:2622) by 0x809E833: do_cmdline (ex_docmd.c:1096) by 0x80A6561: do_ucmd (ex_docmd.c:5989) by 0x80A0D31: do_one_cmd (ex_docmd.c:2613) by 0x809E833: do_cmdline (ex_docmd.c:1096) by 0x809E0F0: do_cmdline_cmd (ex_docmd.c:702) by 0x80997EF: ex_debug (ex_cmds2.c:301) Address 0x4d9ebbc is 916 bytes inside a block of size 2,048 free'd at 0x4022B8A: free (vg_replace_malloc.c:323) by 0x81037B6: vim_free (misc2.c:1625) by 0x80D7F8C: hash_may_resize (hashtab.c:467) by 0x80D7C5C: hash_add_item (hashtab.c:254) by 0x80D7BD4: hash_add (hashtab.c:227) by 0x8088E54: set_var (eval.c:19189) by 0x8072C7F: set_var_lval (eval.c:2787) by 0x80721B1: ex_let_one (eval.c:2403) by 0x80711B2: ex_let_vars (eval.c:1858) by 0x8071163: ex_let (eval.c:1823) by 0x80A0D5A: do_one_cmd (ex_docmd.c:2622) by 0x809E833: do_cmdline (ex_docmd.c:1096) I can give any more information anyone might need. I've been reproducing this by doing :debug Explore, stepping to line 300, then quitting from debug mode - but I would not be at all shocked if that doesn't work for others. I'll keep trying to track it down, but Dominique seems to really have a knack for finding these sorts of problems, so maybe he can shorten the bug-hunting time. :-) ~Matt From the stack trace, a pointer is dereferenced, and points to some invalid (freed) memory, as a result of a previous memory reallocation in hash_may_resize(). I tried to reproduce it but I could not. Which command(s) do you use to step to line 300? Also which version of Vim are you using? I'm asking because the line numbers in the valgrind stack trace are not consistent with the latest eval.c of vim-7.2.75. Maybe compiling with -O0 can help to get better debug information (if not already done?). Cheers -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim SEGV
On Sat, Dec 27, 2008 at 3:15 AM, Dominique Pelle wrote: 2008/12/27 Matt Wozniski wrote: I found a SEGV that I can reproduce reliably, but can't seem to track down. It SEGVs without gdb or valgrind, doesn't SEGV under valgrind, and SEGVs under gdb. The steps that I'm using to reproduce this are complicated, and possibly very specific to the version of the runtime files and such that I'm using, but I'm hoping that a log of the backtrace + valgrind log can help someone to track it down. From the stack trace, a pointer is dereferenced, and points to some invalid (freed) memory, as a result of a previous memory reallocation in hash_may_resize(). Yeah. Looks to me like something got moved, the old memory got freed, and a pointer was held to the old location instead of the new one... I tried to reproduce it but I could not. Yeah, I'm not surprised... the fact that it seems tied to a hash table resizing makes me think that it's very much tied to the number of plugins I have loaded, the number of variables I have defined, and a whole bunch of other, less obvious factors Which command(s) do you use to step to line 300? at the :debug prompt, just pressing sCR and then CR repeatedly until I hit 300. Also which version of Vim are you using? I'm asking because the line numbers in the valgrind stack trace are not consistent with the latest eval.c of vim-7.2.75. Sorry, yeah - 7.2.049, the latest from the debian git repo: git://git.debian.org/git/pkg-vim/vim.git (plus an rsync'ed runtime updated last night). Maybe compiling with -O0 can help to get better debug information (if not already done?). It already is compiled with make CFLAGS='-g -O0'. Thanks for looking into this... I still haven't managed to spot the bug on my own. If you spot any variables you'd like to investigate or some such, let me know and I can try some breakpoints, since I can reproduce it... :-) ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim SEGV
On 27/12/08 09:46, Matt Wozniski wrote: On Sat, Dec 27, 2008 at 3:15 AM, Dominique Pelle wrote: 2008/12/27 Matt Wozniski wrote: I found a SEGV that I can reproduce reliably, but can't seem to track down. It SEGVs without gdb or valgrind, doesn't SEGV under valgrind, and SEGVs under gdb. The steps that I'm using to reproduce this are complicated, and possibly very specific to the version of the runtime files and such that I'm using, but I'm hoping that a log of the backtrace + valgrind log can help someone to track it down. From the stack trace, a pointer is dereferenced, and points to some invalid (freed) memory, as a result of a previous memory reallocation in hash_may_resize(). Yeah. Looks to me like something got moved, the old memory got freed, and a pointer was held to the old location instead of the new one... I tried to reproduce it but I could not. Yeah, I'm not surprised... the fact that it seems tied to a hash table resizing makes me think that it's very much tied to the number of plugins I have loaded, the number of variables I have defined, and a whole bunch of other, less obvious factors Which command(s) do you use to step to line 300? at the :debug prompt, just pressing sCR and thenCR repeatedly until I hit 300. Also which version of Vim are you using? I'm asking because the line numbers in the valgrind stack trace are not consistent with the latest eval.c of vim-7.2.75. Sorry, yeah - 7.2.049, the latest from the debian git repo: git://git.debian.org/git/pkg-vim/vim.git (plus an rsync'ed runtime updated last night). Maybe compiling with -O0 can help to get better debug information (if not already done?). It already is compiled with make CFLAGS='-g -O0'. Thanks for looking into this... I still haven't managed to spot the bug on my own. If you spot any variables you'd like to investigate or some such, let me know and I can try some breakpoints, since I can reproduce it... :-) ~Matt You can compile your own Vim 7.2.075, see http://users.skynet.be/antoine.mechelynck/vim/compunix.htm Before reporting a bug, it is always better to try reproducing it with the latest published bugfixed version. Best regards, Tony. -- CUSTOMER: You're not fooling anyone y'know. Look, isn't there something you can do? DEAD PERSON: I feel happy... I feel happy. [whop] CUSTOMER: Ah, thanks very much. MORTICIAN:Not at all. See you on Thursday. CUSTOMER: Right. The Quest for the Holy Grail (Monty Python) --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [PATCH] Confirmation dialog instead of warning when closing tab with the mouse
On 27/12/08 04:43, Markus Heidelberg wrote: björn, 26.12.2008: Hi, Currently if I use the mouse to close a tab (click the close button on Mac, right-click tab and select close on pop-up menu on Windows) when there is a modified buffer I get the following warning message: E37: No write since last change (add ! to override) This is kind of unhelpful since you can't add ! using the mouse only. Sorry for hijacking the thread, but while playing around I noticed that a tabpage cannot be closed with the menu item File-Close (:close) for me. Typing :close worked, so I looked at runtime/menu.vim: \ :if winheight(2) 0Bar \ confirm enewBar \ elseBar \ confirm closeBar \ endifCR winheight(2) always returns -1 for me, when on a tabpage without vertically or horizontally split windows. Maybe there is something wrong with it, but what's the intention of the :enew in a close item at all? winheight(2) is -1 if there is no 2nd window, i.e., the window isn't split. The purpose is to avoid closing the last window (:close gives an error if attempted on the only window in Vim). This menu is perhaps unchanged since version 6 (which had no tabs). The attached patch fixes this problem by displaying the Save changes dialog instead of the warning message in the above scenario. I think it is as simple as calling conf tabclose instead of tabclose in handle_tabmenu() (at least the comment before that function seems to imply that it is only called when the user interacts with the GUI tabline using the mouse), but correct me if I'm wrong. Works at least with GTK+ 2 on Linux. Markus Best regards, Tony. -- God is real, unless declared integer. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim SEGV
You can compile your own Vim 7.2.075, see http://users.skynet.be/antoine.mechelynck/vim/compunix.htm I'm sure Matt is completely capable of doing this, Tony, and almost certainly needs no assistance. Before reporting a bug, it is always better to try reproducing it with the latest published bugfixed version. That's not strictly true, particularly in a case like this. The bug involves pretty subtle code interactions, and is difficult to reproduce. Checking with a later version may work just fine, but doesn't necessarily indicate the bug has been fixed--it may be that it simply can't be reproduced using the same steps as before. So unless a patch claims to deal with the situation being encountered, there is little point trying a later version, as if anything, this may lull us into a false sense of security. Similar problems exist trying to test subtle bugs like this are fixed, too. It is not uncommon for a developer to 'fix' a bug in their version of the code, then need to do a CVS update (or such) before being able to CVS commit their changes back to the main code repository, and for that update to cause the bug to longer be reproducible, thus meaning that the developer can no longer test whether their change fixes the bug in the current codebase, but only in their older version. Of course, testing with the old version gives some confidence, but not always as much as we'd like! Smiles, Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim SEGV
On 27/12/08 15:45, Ben Schmidt wrote: You can compile your own Vim 7.2.075, see http://users.skynet.be/antoine.mechelynck/vim/compunix.htm I'm sure Matt is completely capable of doing this, Tony, and almost certainly needs no assistance. Before reporting a bug, it is always better to try reproducing it with the latest published bugfixed version. That's not strictly true, particularly in a case like this. The bug involves pretty subtle code interactions, and is difficult to reproduce. Checking with a later version may work just fine, but doesn't necessarily indicate the bug has been fixed--it may be that it simply can't be reproduced using the same steps as before. So unless a patch claims to deal with the situation being encountered, there is little point trying a later version, as if anything, this may lull us into a false sense of security. Similar problems exist trying to test subtle bugs like this are fixed, too. It is not uncommon for a developer to 'fix' a bug in their version of the code, then need to do a CVS update (or such) before being able to CVS commit their changes back to the main code repository, and for that update to cause the bug to longer be reproducible, thus meaning that the developer can no longer test whether their change fixes the bug in the current codebase, but only in their older version. Of course, testing with the old version gives some confidence, but not always as much as we'd like! Smiles, Ben. OTOH, software from third-party distributors, especially of the Debian family, have been reported to include additional code which the original makers of the software have sometimes claimed to decrease stability. I don't want to take a side here, I just note that there have been conflicts, for instance between Debian and Mozilla about the differences between Iceweasel and Firefox, Icedove and Thunderbird, Iceape and SeaMonkey. Best regards, Tony. -- Here is the problem: for many years, the Supreme Court wrestled with the issue of pornography, until finally Associate Justice John Paul Stevens came up with the famous quotation about how he couldn't define pornography, but he knew it when he saw it. So for a while, the court's policy was to have all the suspected pornography trucked to Justice Stevens' house, where he would look it over. Nope, this isn't it, he'd say. Bring some more. This went on until one morning when his housekeeper found him trapped in the recreation room under an enormous mound of rubberized implements, and the court had to issue a ruling stating that it didn't know what the hell pornography was except that it was illegal and everybody should stop badgering the court about it because the court was going to take a nap. -- Dave Barry, Pornography --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim SEGV
Matt Wozniski wrote: I tried to reproduce it but I could not. Yeah, I'm not surprised... the fact that it seems tied to a hash table resizing makes me think that it's very much tied to the number of plugins I have loaded, the number of variables I have defined, and a whole bunch of other, less obvious factors Which command(s) do you use to step to line 300? at the :debug prompt, just pressing sCR and then CR repeatedly until I hit 300. I still have not been able to reproduce it. But as you said, there might be something subtle to trigger the memory reallocation. It'd be nice to have a an automated way to reproduce it. Does the following command for example reproduce the error? (it does not for me). $ yes | tr y s | valgrind vim -D -c ':Explore' 2 valgrind.log If you don't mind, maybe sharing your ~/.vimrc and a tar or your ~/.vim/ directory could help others to reproduce it. Cheers -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.2.072 (extra)
This patch does not apply cleanly against the 7.2 extra tar.gz. The
code release has the following Id line:
* $Id: if_sniff.c,v 1.4 2006/03/06 23:13:51 vimboss Exp $
This makes downloading the source code releases and sequentially
applying the patches difficult to automate as hunk 1 of this patch
fails. Perhaps the Id string could be removed in the next code
release?
On Dec 24, 5:43 am, Bram Moolenaar b...@moolenaar.net wrote:
Patch 7.2.072 (extra)
Problem: Compiler warning in Sniff code.
Solution: Use return value of pipe(). (Dominique Pelle)
Files: src/if_sniff.c
*** ../vim-7.2.071/src/if_sniff.c Sat Nov 15 14:11:10 2008
--- src/if_sniff.c Sat Dec 6 14:01:57 2008
***
*** 2,9
*
* if_sniff.c Interface between Vim and SNiFF+
*
- * $Id: if_sniff.c,v 1.10 2008/11/15 13:11:10 vimboss Exp $
- *
* See README.txt for an overview of the Vim source code.
*/
--- 2,7
***
*** 716,723
#else /* UNIX Version of the Code */
int ToSniffEmacs[2], FromSniffEmacs[2];
! pipe(ToSniffEmacs);
! pipe(FromSniffEmacs);
/* fork */
if ((sniffemacs_pid=fork()) == 0)
--- 714,723
#else /* UNIX Version of the Code */
int ToSniffEmacs[2], FromSniffEmacs[2];
! if (pipe(ToSniffEmacs) != 0)
! return 1;
! if (pipe(FromSniffEmacs) != 0)
! return 1;
/* fork */
if ((sniffemacs_pid=fork()) == 0)
*** ../vim-7.2.071/src/version.c Wed Dec 24 12:20:10 2008
--- src/version.c Wed Dec 24 12:42:13 2008
***
*** 678,679
--- 678,681
{ /* Add new patch number below this line */
+ /**/
+ 72,
/**/
--
SIGIRO -- irony detected (iron core dumped)
/// Bram Moolenaar -- b...@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 ///
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Patch 7.2.072 (extra)
This patch does not apply cleanly due to the Id string. When building using the 7.2 extra tar distribution (ftp://ftp.vim.org/pub/vim/extra/ vim-7.2-extra.tar.gz) the Id string is: * $Id: if_sniff.c,v 1.4 2006/03/06 23:13:51 vimboss Exp $ which corresponds to 7.2.000. It looks like the Id update was left out of the 7.2.041 patch, causing (the first hunk of) this patch to fail. Perhaps the first hunk could be removed and clean up in the next code release? --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
