James Kolb wrote:
> > James Kolb wrote:
> >
> > > On Friday, August 21, 2015 at 1:39:10 PM UTC-4, Bram Moolenaar wrote:
> > > > James Kolb wrote:
> > > >
> > > > > The current regex code may call mch_breakcheck which can process X
> > events.
> > > > > One of these events could be a remote_expr that makes its own call
> > into the
> > > > > regex engine. This usually crashes because the regex engine isn't
> > > > > reentrant. This is probably also a problem for anything else that
> > runs long
> > > > > enough to make breakchecks and isn't reentrant.
> > > > >
> > > > > This crash can usually be reproduced in linux by running vim with a
> > > > > --servername argument and typing the command:
> > > > > :call system("sleep 1 && vim --servername ".v:servername."
> > --remote-expr
> > > > > 'substitute(string(range(5000)), \"a\", \"b\", \"g\")' &") | call
> > > > > substitute(string(range(5000)), '\(,.*\)\@<!,', '', 'g')
> > > > >
> > > > > The attached patch fixes the problem by preventing RealWaitForChar
> > from
> > > > > processing X events if it is called from mch_breakcheck.
> > > >
> > > > Thanks for the patch. However, I think the proper solution would be to
> > > > make the regexp code reentrant. That means getting rid of the global
> > > > variables. It's been messy like that for a long time.
> > > >
> > > > I think your patch fixes one specific situation, but it can happen in
> > > > other situations as well.
> > >
> > > I agree that the regexp code should be reentrant, but I think regexes
> > > are just one mine in a larger breakchecks-can-run-arbitrary-code
> > > minefield.
> > >
> > > Most of the places that call breakchecks don't seem to assume that
> > > they can call arbitrary vim commands. Commonly run functions like
> > > buflist_list() or searchit(), for example, can read-after-free if
> > > somebody deletes a buffer using remote-expr. Anything that calls the
> > > regex engine will have the same problem that the regex engine can call
> > > arbitrary commands, even if the regex engine were reentrant.
> >
> > OK, thus even though your patch refers to regexp, it has a wider target.
> >
> > I'm not sure if your patch also introduces a problem. If we don't
> > handle X events while busy doing something, the application becomes
> > unresponsive from an X server point of view. E.g. for releasing the
> > selection.
> >
> > If we are calling breakcheck, then we do not expect all kinds of things
> > to happen. Some kind of global lock, or a queue to put postponed
> > commands on would work better. The netbeans feature already does this,
> > we could build on top of it. Specifically netbeans_parse_messages().
>
> I wrote a new patch that adds queuing for clientserver similar to the
> netbeans queue.
Thanks. I'll look into it later.
--
This message contains 78% recycled characters.
/// 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.
