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().
--
To the optimist, the glass is half full.
To the pessimist, the glass is half empty.
To the engineer, the glass is twice as big as it needs to be.
/// Bram Moolenaar -- [email protected] -- 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
