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

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Raspunde prin e-mail lui