Hi Bram! On Sa, 21 Apr 2012, Bram Moolenaar wrote:
> > 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. regards, Christian -- 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
