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 -~----------~----~----~----~------~----~------~--~---
