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

Re: segfault reports

Expand Messages
  • Chas Emerick
    ... I ve been working on putting together a minimal reproducible example; I m not there yet, but I have come across another problem that may be related. I
    Message 1 of 3 , Aug 1, 2013
    • 0 Attachment
      On Jul 25, 2013, at 3:59 PM, björn wrote:

      On Tue, Jul 23, 2013 at 4:57 PM, Chas Emerick wrote:
      I'm working on a plugin that, in certain circumstances, can prompt MacVim to segfault (or otherwise die unexpectedly, SIGABRT, etc).  There appear to be ~3 different "types" of crash logs produced...*maybe* representing different underlying bugs?

      The same (or very similar) failures also occur when using `mvim` within a terminal, but they don't occur when using a terminal-only `vim`.  (The same is true of a non-crashing rendering bug I reported separately here: http://code.google.com/p/macvim/issues/detail?id=464) So, I'm reasonably sure that the problem is in MacVim, and not in vim itself.

      I've attached a couple of representative logs.  Björn, if you'd like issues created for these, I'd be happy to do that; I just figured I'd ping the list first in case you'd prefer to triage them e.g. one at a time, as a group, or otherwise.

       
      What version are you using?  (The first few lines of ":ver" is what I'm after.)

      That it crashes with mvim but not the builtin vim can simply be because the builtin version is most likely old and the bug may be newer than it is, but it is hard to tell.  From the logs you attached I see that the crashes always happen somewhere in the Python interface so that is possibly the culprit, but I can't really tell.

      Do you have a (very) minimal number of steps to reliably reproduce a crash?

      I've been working on putting together a minimal reproducible example; I'm not there yet, but I have come across another problem that may be related.  I believe all of the issues I've had are related to python touching vim from another thread; i.e. if I put units of work on a queue in python land, and drain that queue via e.g. au CursorHold, then nothing bad happens.  So, I think it's not impossible that resolving one of these problems may benefit all the others.

      Anyway, the example:

      """""""""
      function! g:freeze_display ()
        python << EOF
      import vim, time, threading

      def tickle_buffer (msg):
          buf = vim.current.buffer
          buf.append([msg])
          vim.current.window.cursor = (len(buf), 0)

      def loop ():
          for x in range(10):
              tickle_buffer(str(time.time()))
              vim.command(":redraw")
              time.sleep(0.25)
          tickle_buffer("DONE")

      threading.Thread(target=loop).start()
      EOF
      endfunction
      """""""""

      :call g:freeze_display(), and this will spit the current time to the current buffer ten times from a new python thread, :redraw'ing the window each time (without this, the scroll position of the window never updates to follow the cursor position when the amount of output is larger than the available height of the window).  After doing this, the display will be totally unresponsive, and the cursor will appear stuck in the command line on the right side.  You can still type and such, but input and changes will only appear if you issue a manual :redraw.

      This is reproducible in all Vims I have that include python, including the command-line vim I compiled myself from HEAD.  Here's version infos:

      VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 15 2010 22:03:01)
      MacOS X (unix) version
      Compiled by Bjorn Winckler <bjorn.winckler@...>

      VIM - Vi IMproved 7.4b BETA (2013 Jul 28, compiled Jul 28 2013 17:22:03)
      MacOS X (unix) version
      Compiled by Douglas Drumond <douglas@...>  

      VIM - Vi IMproved 7.4a BETA (2013 Jul 6, compiled Jul 25 2013 06:57:01)
      MacOS X (unix) version
      Included patches: 1-39
      Compiled by chas@...

      Two final notes:

      1. When using `mvim -v`, the above example produced the same kinds of error messages I reported in http://code.google.com/p/macvim/issues/detail?id=464 (in addition to the display "freezing")
      2. I *was* eventually able to provoke segfaults similar to the ones I originally reported on this thread using my terminal-only vim (the third version info above).  Not sure if that's a good or bad thing in terms of hunting down the problem.

      Thanks for taking a look,

      - Chas

      --
      --
      You received this message from the "vim_mac" 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
       
      ---
      You received this message because you are subscribed to the Google Groups "vim_mac" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_mac+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
       
       
    Your message has been successfully submitted and would be delivered to recipients shortly.