|
From: | Richard Copley |
Subject: | bug#37575: 27.0.50; Segfault on redisplay |
Date: | Thu, 3 Oct 2019 19:04:49 +0100 |
[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?).
> 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.
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.
> 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.
> 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?
> If it happens again I'll try and get that. (Something in font-lock-keywords-alist, I suppose.)
OK.
[Prev in Thread] | Current Thread | [Next in Thread] |