bug#37575: 27.0.50; Segfault on redisplay

[Richard Copley]

On Thu, 3 Oct 2019 at 18:03, Eli Zaretskii <eliz@gnu.org> wrote:

[Private email?]

> From: Richard Copley <rcopley@gmail.com>
> Date: Wed, 2 Oct 2019 20:28:40 +0100
>
>  Hmm... I don't see how re_match_2_internal on line 4940 could possibly
>  cause a fatal signal,
>
> Taking the backtrace at face value, clearly d pointed to invalid memory.

Theoretically, yes.  I very much doubt that, but it would be good to
examine the value of d (which I guess we cannot now?).

That's right.

 

>  and that .chkstk in the backtrace is a hint of
>  some stack-related problem.
>
> I don't follow. The entry is after the signal was raised, not before. Calling chkstk doesn't indicate a problem.

chkstk is the function that probes the stack for whether it crossed
the guard page at the end of the stack (a.k.a "stack overflow").  It
is invoked internally by alloca (except that there's no alloca
anywhere in sight near the code that allegedly blew up), and when
allocating stack-based data.

The chktsk call is in ntdll!RtlRaiseException.

 

  However, note that it is chkstk that
ended up in the exception handler, which is at least weird.  IME, this
more often than not happens when the code longjmp's on the wrong
stack, which is why I asked about other threads.

We're nowhere near any longjmp.

> And given that chkstk is a leaf function, how do you deduce anything from its presence, except that there is
> some flaw in GDB's backtrace generation or in its debug information for ntdll.dll?

I deduce that because there should be no reason for chkstk itself to
crash.

Again, the crash is before the chkstk in the backtrace, not after it.

 

>    If you still have this crashed
>  sesion inside GDB, please show the result of
>
>    (gdb) thread apply all bt
>
> I don't have it now.

That's too bad.  And I guess this is not reproducible, either?

Doesn't seem to be.

 

> If it happens again I'll try and get that. (Something in font-lock-keywords-alist, I suppose.)

OK.

OK.