bug#40661: Crash in regex search during redisplay

[Stefan Monnier <monnier@iro.umontreal.ca>]

> I finally succeeded to build a sophisticated enough trap to catch the
> culprit.  It's GC allright.  Which is not surprising: the commit
> pointed out by Richard changed re_match_2_internal to call
> UPDATE_SYNTAX_TABLE_FORWARD, which calls Lisp, and thus can trigger
> GC.  As seen from the backtrace, GC then calls compact_buffer, which
> calls enlarge_buffer_text (to shrink buffer text), and on MS-Windows
> -- and this is the w32-specific part -- we return some memory to the
> OS and relocate buffer text.
>
> Obviously, we cannot allow GC to run while regex routines do their
> work, because they are passed C pointers to buffer text.  The question
> is, where to disable GC?  We could do it inside
> update_syntax_table_forward, but UPDATE_SYNTAX_TABLE_FORWARD is called
> from many places that evidently have no problems with GC.  So my
> suggestion would be to disable GC inside re_match_2_internal instead.
>
> Comments?

Looks fine to me.  I think a better fix is to move the execution of
compact_buffer: there's no reason it has to be done during GC, we just
need to do it "every once in a while" and the GC was a convenient point
for that.  But we could avoid several such problems if we were to run
such background tasks elsewhere.  It could still be linked to GC,
e.g. we could start a timer during the GC so its run at the next
opportunity.


        Stefan