Loading ...
Sorry, an error occurred while loading the content.

Re: Crash in Vim

Expand Messages
  • Bram Moolenaar
    ... Well, we better find out why w_s gets another value without using ... memory, if we know the cause of the problem we might see a better solution. In gdb
    Message 1 of 4 , Apr 22, 2012
    • 0 Attachment
      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 -- Bram@... -- 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
    Your message has been successfully submitted and would be delivered to recipients shortly.