Christian Brabandt wrote:

> > > When working on my plugin SudoEdit[1], I noticed a crash in certain 
> > > circumstances, which I can reproduce currently.
> > > 
> > > Basically, with the plugin installed, you need to do:
> > > :e sudo://etc/fstab
> > > [change something]
> > > :w!
> > > :e!
> > > at this point, Vim crashes. Here is a backtrace:
> > > 
> > > Program received signal SIGABRT, Aborted.
> > > 0x00007ffff63d73a5 in __GI_raise (sig=6) at 
> > > ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> > > 64      ../nptl/sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis 
> > > nicht gefunden.
> > >         in ../nptl/sysdeps/unix/sysv/linux/raise.c
> > > (gdb) bt
> > > #0  0x00007ffff63d73a5 in __GI_raise (sig=6) at 
> > > ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> > > #1  0x00007ffff63dab0b in __GI_abort () at abort.c:92
> > > #2  0x00007ffff6410d63 in __libc_message (do_abort=2, fmt=0x7ffff6501e58 
> > > "*** glibc detected *** %s: %s: 0x%s ***\n")
> > >     at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
> > > #3  0x00007ffff641b6e6 in malloc_printerr (action=3, str=0x7ffff64fee6f 
> > > "free(): invalid pointer", ptr=<optimized out>)
> > >     at malloc.c:6283
> > > #4  0x00007ffff641f9cc in __GI___libc_free (mem=<optimized out>) at 
> > > malloc.c:3738
> > > #5  0x00000000004c5163 in vim_free (x=0x97c888) at misc2.c:1740
> > > #6  0x0000000000550c8b in reset_synblock (wp=0x7f47a0) at syntax.c:3475
> > > #7  0x0000000000405a8f in buf_freeall (buf=0x7f5f80, flags=4) at 
> > > buffer.c:591
> > > #8  0x000000000044ff89 in do_ecmd (fnum=0, ffname=0x94f560 
> > > "sudo://etc/fstab", sfname=0x956ae0 "sudo://etc/fstab", 
> > >     eap=0x7fffffffd630, newlnum=19, flags=9, oldwin=0x7f47a0) at 
> > > ex_cmds.c:3593
> > > #9  0x0000000000467d1f in do_exedit (eap=0x7fffffffd630, old_curwin=0x0) 
> > > at ex_docmd.c:7759
> > > #10 0x00000000004679dc in ex_edit (eap=0x7fffffffd630) at ex_docmd.c:7655
> > > #11 0x000000000045f960 in do_one_cmd (cmdlinep=0x7fffffffd818, 
> > > sourcing=0, cstack=0x7fffffffd8b0, 
> > >     fgetline=0x473ccb <getexline>, cookie=0x0) at ex_docmd.c:2668
> > > #12 0x000000000045cfb3 in do_cmdline (cmdline=0x0, fgetline=0x473ccb 
> > > <getexline>, cookie=0x0, flags=0)
> > >     at ex_docmd.c:1122
> > > #13 0x00000000004d6df8 in nv_colon (cap=0x7fffffffddd0) at normal.c:5404
> > > #14 0x00000000004d08fa in normal_cmd (oap=0x7fffffffde90, toplevel=1) at 
> > > normal.c:1193
> > > #15 0x0000000000583c68 in main_loop (cmdwin=0, noexmode=0) at main.c:1282
> > > #16 0x0000000000583733 in main (argc=1, argv=0x7fffffffe1a8) at main.c:986
> > > 
> > > What happens is, that curwin->w_s differs from curwin->w_buffer->b_s
> > > so both should be the same. The following patch fixes it for me:
> > > 
> > > diff --git a/src/fileio.c b/src/fileio.c
> > > --- a/src/fileio.c
> > > +++ b/src/fileio.c
> > > @@ -8992,6 +8992,7 @@
> > >  
> > >             curwin = aco->save_curwin;
> > >             curbuf = curwin->w_buffer;
> > > +           curwin->w_s = &(curbuf->b_s);
> > >         }
> > >      }
> > >  }
> > 
> > I don't quite understand the solution.  How is it possible that
> > curwin->w_s gets a wrong value?  It was moved aside thus it should not
> > change.  And what if ":ownsyntax" was used, doesn't this leak memory?
> 
> Shouldn't curwin->w_s point to the same value as curwin->w_buffer->b_s? 
> In this case it didn't and since I didn't use :ownsyntax, I figured they 
> should stay the same.  I am not sure, why they differ at all.

Well, we better find out why w_s gets another value without using
:ownsyntax.  I think the way you solve it may break :ownsyntax or leak
memory, if we know the cause of the problem we might see a better
solution.  In gdb you can set a watch point on the variable.  You could
set a breakpoint in aucmd_prepbuf() and then set the watch point once it
has set aco->save_curwin.

-- 
ARTHUR: Did you say shrubberies?
ROGER:  Yes.  Shrubberies are my trade.  I am a shrubber.  My name is Roger
        the Shrubber.  I arrange, design, and sell shrubberies.
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Raspunde prin e-mail lui