On Thu, 3 Oct 2019 at 18:03, Eli Zaretskii wrote: > [Private email?] > > From: Richard Copley > > 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.