Re: Gvim crashes with ABRT & SEGV under AwesomeWM

[Dominique Pellé]

Jeroen Budts  wrote:

> Hi All,
>
> (First off, I hope this is the correct mailinglist to report this. I first 
> tried
> vim_use but didn't get any response, sorry if I'm wrong here.)
>
> A few days ago I started using AwesomeWM (running as the WM inside
> XFCE) and started seeing Gvim crashes (SEGV & ABRT) when I resize
> the Gvim window (by changing the size of the master pane in the
> tile-layout and by switching layouts). From what I understand these
> indicate bugs?
> I have been using Gvim for a few years now without much problems
> under XFCE + XFWM (default Xubuntu). I also used Xmonad for one
> week without problems.
>
> I tried running Gvim without any of my own configuration [1] and can't
> seem to replicate the crashes, so I guess it's either a specific setting
> in my .vimrc or a plugin (or combination of) in combination with
> Awesome. I'm not sure however how I can find the culprit other then
> commenting my entire Vimrc and disabling all plugins and one-by-one
> disable everything again, which seems a rather tedious task... So
> any guidance on how I can find the real problem would be very helpful.

I suggest that you compile your own vim from the latest version
from github, and you can build with symbols, so the stack trace
will be more meaningful. Since you use xubuntu, it's quite easy:

$ sudo apt-get build-dep vim-gnome
$ sudo apt-get install git
$ git clone https://github.com/vim/vim.git

Apply the follow diff to vim/src/Makefile to build
it with symbols and without optimizations:

$ git diff Makefile
diff --git a/src/Makefile b/src/Makefile
index b3b8daf..6986e88 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -583,7 +583,7 @@ CClink = $(CC)

 # Use this with GCC to check for mistakes, unused arguments, etc.
 #CFLAGS = -g -Wall -Wextra -Wmissing-prototypes -Wunreachable-code
-U_FORTIFY_SOURCE -D_FORTIFY_SOUR
-#CFLAGS = -g -O2 -Wall -Wextra -Wmissing-prototypes -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1 -DU_DEBUG
+CFLAGS = -g -O0 -Wall -Wextra -Wmissing-prototypes -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1 -DU_DEBUG
 #PYTHON_CFLAGS_EXTRA = -Wno-missing-field-initializers
 #MZSCHEME_CFLAGS_EXTRA = -Wno-unreachable-code -Wno-unused-parameter

@@ -2122,7 +2122,7 @@ installvimbin: $(VIMTARGET)
$(DESTDIR)$(exec_prefix) $(DEST_BIN)
  rm -f $(DEST_BIN)/$(VIMNAME).rm; \
fi
$(INSTALL_PROG) $(VIMTARGET) $(DEST_BIN)
-   $(STRIP) $(DEST_BIN)/$(VIMTARGET)
+   #$(STRIP) $(DEST_BIN)/$(VIMTARGET)
chmod $(BINMOD) $(DEST_BIN)/$(VIMTARGET)
 # may create a link to the new executable from /usr/bin/vi
-$(LINKIT)
@@ -2273,7 +2273,7 @@ installtools: $(TOOLS) $(DESTDIR)$(exec_prefix)
$(DEST_BIN) \
  rm -f $(DEST_BIN)/xxd.rm; \
fi
$(INSTALL_PROG) xxd/xxd$(EXEEXT) $(DEST_BIN)
-   $(STRIP) $(DEST_BIN)/xxd$(EXEEXT)
+   #$(STRIP) $(DEST_BIN)/xxd$(EXEEXT)
chmod $(BINMOD) $(DEST_BIN)/xxd$(EXEEXT)
-$(SHELL) ./installman.sh xxd $(DEST_MAN) "" $(INSTALLMANARGS)


Then build vim with:

$ cd vim
$ ./configure --with-features=huge --enable-gui=gtk2
$ make -j4
$ sudo make install

Then try to reproduce the problem.
I also suggest to try running vim with valgrind
with something like this:

$ valgrind --log-file=vg.log --check-origins=yes --num-callers=50 vim

It will be slow, but it will give plenty of useful information in log
file vg.log in case  vim has memory bugs.

Regards
Dominique

-- 
-- 
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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Gvim crashes with ABRT & SEGV under AwesomeWM

[Jeroen Budts]

Hi All,

(First off, I hope this is the correct mailinglist to report this. I first 
tried vim_use but didn't get any response, sorry if I'm wrong here.)

A few days ago I started using AwesomeWM (running as the WM inside XFCE) and 
started seeing Gvim crashes (SEGV & ABRT) when I resize the Gvim window (by 
changing the size of the master pane in the tile-layout and by switching 
layouts). From what I understand these indicate bugs?
I have been using Gvim for a few years now without much problems under XFCE + 
XFWM (default Xubuntu). I also used Xmonad for one week without problems.

I tried running Gvim without any of my own configuration [1] and can't seem to 
replicate the crashes, so I guess it's either a specific setting in my .vimrc 
or a plugin (or combination of) in combination with Awesome. I'm not sure 
however how I can find the culprit other then commenting my entire Vimrc and 
disabling all plugins and one-by-one disable everything again, which seems a 
rather tedious task... So any guidance on how I can find the real problem would 
be very helpful.

[1] https://github.com/teranex/dotvim

I'm running Gvim 7.4.1689 (default from Xubuntu 16.04, vim-gnome package)
Below are some errors I could capture.

This is what I saw in the Ubuntu crash-submit tool (apport):
 vim.gnome crashed with sigsegv in get_syntax_atttr()

When starting gvim with `strace gvim -V9log.txt file.tex > stdout.txt 2> 
stderr.txt` I got the following in stdout.txt:
RenderBadPicture (invalid Picture parameter)
Vim: Got X error
Vim: Finished.

I also saw these errors in the terminal:
*** Error in `gvim': free(): corrupted unsorted chunks: 0x560557c7a430 ***
Vim: Caught deadly signal ABRT
*** Error in `gvim': malloc(): memory corruption: 0x560557c811e0 ***
Vim: Double signal, exiting


*** Error in `gvim': free(): invalid next size (normal): 0x563fe6820ab0 ***
Vim: Caught deadly signal ABRT
Vim: Finished.
Saved session "vimwiki"
Press ENTER or type command to continuePress ENTER or type command to 
continuePress ENTER or type command to continuePress ENTER or type command to 
continuePress ENTER or type command to continuePress ENTER or type command to 
continuePress ENTER or type command to continuePress ENTER or type command to 
continuePress ENTER or type command to continuePress ENTER or type command to 
continuePress ENTER or type command to continuePress ENTER or type command to 
continuePress ENTER or type command to continue


*** Error in `gvim': free(): invalid next size (normal): 0x555f75ac0d30 ***
Vim: Caught deadly signal ABRT
Vim: Finished.
Saved session "vimwiki"


>From the Awesome log:
*** Error in `gvim': corrupted double-linked list: 0x55fcbf148b00 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7fb4fc81c725]
/lib/x86_64-linux-gnu/libc.so.6(+0x80679)[0x7fb4fc825679]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fb4fc828abc]
gvim(free_screenlines+0x38)[0x55fcbcb2d8c8]
gvim(screenalloc+0x371)[0x55fcbcb2dc91]
gvim(screenclear+0x12)[0x55fcbcb2e382]
gvim(set_shellsize+0xbc)[0x55fcbcb794bc]
gvim(gui_resize_shell+0x65)[0x55fcbcb96105]
gvim(+0x20146f)[0x55fcbcb9e46f]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x132afc)[0x7fb5011deafc]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x145)[0x7fb5003bdfa5]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x21fc1)[0x7fb5003cffc1]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xa59)[0x7fb5003d87f9]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7fb5003d908f]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x24a8cc)[0x7fb5012f68cc]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main_do_event+0x4a3)[0x7fb5011dd823]
gvim(+0x208dfc)[0x55fcbcba5dfc]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_cclosure_marshal_VOID__BOXEDv+0x7e)[0x7fb5003c0dbe]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x10122)[0x7fb5003be122]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xc06)[0x7fb5003d89a6]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7fb5003d908f]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_widget_size_allocate+0x145)[0x7fb5012fa8d5]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x8382b)[0x7fb50112f82b]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_cclosure_marshal_VOID__BOXEDv+0x7e)[0x7fb5003c0dbe]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x10122)[0x7fb5003be122]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xc06)[0x7fb5003d89a6]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7fb5003d908f]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_widget_size_allocate+0x145)[0x7fb5012fa8d5]
/usr/lib/x86_64-linux-gnu/libbonoboui-2.so.0(+0x1c67b)[0x7fb4ff78b67b]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_cclosure_marshal_VOID__BOXEDv+0x7e)[0x7fb5003c0dbe]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x10122)[0x7fb5003be122]

gvim movement is very slow when enabling cursorline at windows 64

[驼峰]

In Wow64 mode of Windows amd64, the gvim.exe(launched by 
C:\Windows\SysWOW64\cmd.exe) movement will be very slow if I enable cursorline. 

On another hand, the slow issues will gone if I start gvim by 
"C:\windows\system32\cmd.exe".

Is the slow related to Wow64 mode? must I used 64 vim to fix this issue?

Thanks,
-Mike Guo

-- 
-- 
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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: RFE: support POSIX standard and developing RE's

[L. A. Walsh]

Ben Fritz wrote:

I wonder if a different approach might help.
Vim already has :perldo, :pydo, etc. Perhaps a :perlmatch, :pymatch, etc. could 
be added for basic searching in those languages?

There is also a patch in the todo list for :bvimgrep. Maybe a :bgrep command 
could also be added. I think that would allow searching the current buffer 
using whatever tool you like.
  


   the perldo/pydo approaches seem (from what earlier folks said),
to be too limited and perhaps be too slow to be that useful.  Those
commands don't work on the actual text, but on an internal form w/o
the EOL that doesn't allow for splitting or combining lines.

   Another ugly Q comes up -- what is the internal form of the chars?
I.e. UTF-8?.  If so, that's at least good from a perl-compat point of
view, but if not that could be another whole mess.  Even in perl -- 
depends on what I'm doing, but I'll often localize the 'end-of-line' char

to 'null', and allow a single 'read' to read in an entire file into a
single scalar.  Sometimes it's faster to do manipulations on the whole
buffer than try to use multiple manipulations on each line. 

Ex: a mail message which has an empty line at the end of the header. 
It's easier for mail processing to combine header lines that have been

split over multiple lines into 1 line.  Trying to special case the
indents each time you pass over the headers for something really slows 
down the traversal.  But its usually necessary (at least for sanity's 
sake) to make more than one pass over the header lines for sorting and

routing, but at the end of the header processing, the rest of the text
can be dumped out w/1 write statement -- a big win over writing things
out a line at a time, especially when writing over a network. 


I still feel 'pain' in older mailers that use a 4K r/W size on network
I/O that is positively painful with modern networks that use Jumbo
packets of 9k or more.  You are literally throwing away 55% of the
bandwidth on 1G or faster networks, and that's just the loss from the
low end.  By the time you've progressed up the network stack, a multi-meg
email with a few pics attached and I'll see 30-60s send-times --- most
of it between sendmail and local client over a dedicated 10gb connection,
whereas using SMB, I've seen (*past tense*, w/all the new win10 updates
being forced upon Win7 users) file transfer speeds range between
400-600MB/s (w/a mostly cpu-bound limit).  As MS has changed their 
network stack to allow multi-cores to use more than one connection to a 
server, that, I'm told, will only benefit win8 and above, they've really 
done harm

to win7, which has the multi-streaming code put in its stack, but
is administratively prohibited from using it. 


I'm not sure what would be faster -- trying to split file mods by line, or
handing back a huge array of pointers to text blocks (where each text 
block would have to be marked as line-delineated, or 'raw').  That

sounds more like something where a tunable heuristic would be the most
flexible route -- not something likely to be seen in the near future, I'm
guessing. 


Sigh.

--
--
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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Add silent install option to gvim.nsi (#751)

[Bram Moolenaar]

KF Leong wrote:

> > I am currently using his code with some changes for my own use, and
> > it is working as expected. Better looking also! :D
> > 
> Oops, forgot to add the installer that I made using Guopeng's code:
> https://dl.dropboxusercontent.com/u/21119576/%5B_Utils_%5D/gvim74-1816.exe
> 
> Please have a try.

Do you really expect someone to download an executable from dropbox and
run it?  Anybody was knows a little bit about security knows you must
never do that.

We should see the source code.

-- 
SIGIRO -- irony detected (iron core dumped)

 /// Bram Moolenaar -- b...@moolenaar.net -- 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Patch 7.4.1817

[Bram Moolenaar]

Patch 7.4.1817
Problem:The screen is not updated if a callback is invoked when closing a
channel.
Solution:   Invoke redraw_after_callback().
Files:  src/channel.c


*** ../vim-7.4.1816/src/channel.c   2016-05-01 14:22:12.363965120 +0200
--- src/channel.c   2016-05-04 21:21:00.511455759 +0200
***
*** 2494,2499 
--- 2494,2500 
   , 1, argv, 0L, 0L, , TRUE,
   channel->ch_close_partial, NULL);
  clear_tv();
+ channel_need_redraw = TRUE;
  }
  --channel->ch_refcount;
  
***
*** 2503,2508 
--- 2504,2515 
  partial_unref(channel->ch_close_partial);
  channel->ch_close_partial = NULL;
  
+ if (channel_need_redraw)
+ {
+ channel_need_redraw = FALSE;
+ redraw_after_callback();
+ }
+ 
  /* any remaining messages are useless now */
  for (part = PART_SOCK; part <= PART_ERR; ++part)
  drop_messages(channel, part);
*** ../vim-7.4.1816/src/version.c   2016-05-01 23:05:49.674360477 +0200
--- src/version.c   2016-05-04 21:22:01.286802107 +0200
***
*** 755,756 
--- 755,758 
  {   /* Add new patch number below this line */
+ /**/
+ 1817,
  /**/

-- 
Living on Earth includes an annual free trip around the Sun.

 /// Bram Moolenaar -- b...@moolenaar.net -- 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to run a job asynchronously?

[Bram Moolenaar]

boss wrote:

> On Sunday, 1 May 2016 21:37:13 UTC+1, Bram Moolenaar  wrote:
> 
> > Note that adding "DETACH" was removed, so you can drop this check.
> [snip]
> > A couple of problems have been fixed.  Please give it another try and
> > report back if you still see a problem.
> [snip]
> > > I also implemented my job_start using an out_cb handler again instead
> > > of a close_cb handler.  The occasional-missing-callback problem has
> > > disappeared and it all worked perfectly.  Thanks!
> > 
> > That is the preferred way.  Reading the output in the close callback
> > might only work if there isn't much to read.
> 
> I upgraded from Vim 7.4.1795 to 7.4.1816 and found DETACH was no longer sent 
> to the `out_cb` handler to demarcate the end of my job's output on stdout.
> 
> So I added a `close_cb` handler which does what my `out_cb` handler used to 
> do on receiving DETACH: it gathers together all the preceding job output and 
> then processes it.
> 
> When I edit a file my job runs.  When I trigger a second run, Vim
> always crashes with a segfault:
> 
> Vim: Caught deadly signal SEGV
> Vim: Finished.
> Segmentation fault: 11
> 
> Here's my code:

Thanks for the description.  I'll try to reproduce.

> let job = job_start([, , a:cmd], {
>   \ 'out_cb':   'OutHandler',
>   \ 'close_cb': 'CloseHandler'
>   \ })
> 
> " Channel is in NL mode.
> function! OutHandler(channel, line)
>   let channel_id = matchstr(a:channel, '\d\+')
>   call s:accumulate_job_output(channel_id, a:line)
> endfunction
> 
> function! CloseHandler(channel)
>   let channel_id = matchstr(a:channel, '\d\+')
>   call ProcessOutput(s:job_output(channel_id))
>   call s:job_finished(channel_id)
>   " redraw!
> endfunction
> 
> function! s:job_started(id)
>   let s:jobs[a:id] = 1
> endfunction
> 
> function! s:is_job_started(id)
>   return has_key(s:jobs, a:id)
> endfunction
> 
> function! s:accumulate_job_output(id, line)
>   if has_key(s:jobs, a:id)
> let s:jobs[a:id] = add(s:jobs[a:id], a:line)
>   else
> let s:jobs[a:id] = [a:line]
>   endif
> endfunction
> 
> " Returns a string
> function! s:job_output(id)
>   if has_key(s:jobs, a:id)
> return join(s:jobs[a:id], "\n")."\n"
>   else
> return ""
>   endif
> endfunction
> 
> function! s:job_finished(id)
>   if has_key(s:jobs, a:id)
> unlet s:jobs[a:id]
>   endif
> endfunction
> 
> Regarding redrawing: adding a redraw! as the last line of my close
> handler doesn't redraw the screen.  Should I be doing this somewhere
> else?

Hmm, does it redraw the moment you type something?
It looks like the function to redraw after a callback is not invoked
after using the close_cb.  I'll make a patch for that.

-- 
No children may attend school with their breath smelling of "wild onions."
[real standing law in West Virginia, United States of America]

 /// Bram Moolenaar -- b...@moolenaar.net -- 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] propose vim as manpager that syntax highlights and follows symlinks (#491)

[Charles E Campbell]

Enno wrote:
> Dear Charles, 
>
> Does this mean that ManPageView overrides Vim's built-in :Man? Then :MANPAGER 
> would use it, once ManPageView installed. 
>
> You should propose to SungHyun Nam, the maintainer of :Man, to merge 
> :ManPageView into :Man. 
>
> As an aside, perhaps worth thinking about including your :Info command, 
> turning Vim into an info reader. 
>
ManPageView's :Man does override the :Man command provided by the
runtime, and ManPageView doesn't provide :Info, but it does provide :Man
topic.i, which currently  provides vim with an info reader, too.   It
also provides :VMan, :Oman, and more (including :HEMan for you body
building types! :)  ).

Merging it -- well, its completely different from SungHyun Nam's
version, so it would either be a replacement or Nam would have to
duplicate functionality -- and there's a lot of extra functionality.

Regards,
Chip Campbell

-- 
-- 
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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to run a job asynchronously?

[boss]

On Sunday, 1 May 2016 21:37:13 UTC+1, Bram Moolenaar  wrote:

> Note that adding "DETACH" was removed, so you can drop this check.
[snip]
> A couple of problems have been fixed.  Please give it another try and
> report back if you still see a problem.
[snip]
> > I also implemented my job_start using an out_cb handler again instead
> > of a close_cb handler.  The occasional-missing-callback problem has
> > disappeared and it all worked perfectly.  Thanks!
> 
> That is the preferred way.  Reading the output in the close callback
> might only work if there isn't much to read.

I upgraded from Vim 7.4.1795 to 7.4.1816 and found DETACH was no longer sent to 
the `out_cb` handler to demarcate the end of my job's output on stdout.

So I added a `close_cb` handler which does what my `out_cb` handler used to do 
on receiving DETACH: it gathers together all the preceding job output and then 
processes it.

When I edit a file my job runs.  When I trigger a second run, Vim always 
crashes with a segfault:

Vim: Caught deadly signal SEGV
Vim: Finished.
Segmentation fault: 11

Here's my code:

let job = job_start([, , a:cmd], {
  \ 'out_cb':   'OutHandler',
  \ 'close_cb': 'CloseHandler'
  \ })

" Channel is in NL mode.
function! OutHandler(channel, line)
  let channel_id = matchstr(a:channel, '\d\+')
  call s:accumulate_job_output(channel_id, a:line)
endfunction

function! CloseHandler(channel)
  let channel_id = matchstr(a:channel, '\d\+')
  call ProcessOutput(s:job_output(channel_id))
  call s:job_finished(channel_id)
  " redraw!
endfunction

function! s:job_started(id)
  let s:jobs[a:id] = 1
endfunction

function! s:is_job_started(id)
  return has_key(s:jobs, a:id)
endfunction

function! s:accumulate_job_output(id, line)
  if has_key(s:jobs, a:id)
let s:jobs[a:id] = add(s:jobs[a:id], a:line)
  else
let s:jobs[a:id] = [a:line]
  endif
endfunction

" Returns a string
function! s:job_output(id)
  if has_key(s:jobs, a:id)
return join(s:jobs[a:id], "\n")."\n"
  else
return ""
  endif
endfunction

function! s:job_finished(id)
  if has_key(s:jobs, a:id)
unlet s:jobs[a:id]
  endif
endfunction

Regarding redrawing: adding a redraw! as the last line of my close handler 
doesn't redraw the screen.  Should I be doing this somewhere else?

-- 
-- 
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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.