bug#37575: 27.0.50; Segfault on redisplay

[Richard Copley <rcopley@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 3807 bytes --]