On Friday, August 21, 2015 at 5:31:12 PM UTC-5, 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.
>
For example: I have not found the full root cause yet, but I think I've
narrowed down this crash to being caused by a --remote-expr call, which issues
a "echomsg" command, occurring while Vim is waiting for input for tag selection:
https://groups.google.com/d/topic/vim_dev/ZSfhmAKL97c/discussion
One of the row variables is set to -1 when trying to display something about
the selected tag, I forget exactly which variable or display call.
I got involved in a different open-source project and haven't gotten back to
working on the issue; I was going to save off the required message variables
before processing a remote event, and restore them after, but making it
re-entrant, or queuing the output from the remote call somehow, might be better.
I had noticed that linked crash on Windows; it looks like your patch only
touches os_unix and os_vms files. Does something similar need doing for Windows
files?
--
--
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.
