On Thu, 3 Oct 2019 at 18:03, Eli Zaretskii <
eliz@gnu.org> wrote:
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.
>From "objdump -Mintel -d -C -l c:\windows\system32\ntdll.dll":
0x0000000180051f77 <ntdll!RtlRaiseException+615>: callq 0x1800a34c0 <ntdll!__chkstk>
0x00000001800520a4 <ntdll!RtlRaiseException+916>: callq 0x1800a35d0 <ntdll!__chkstk+272>
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.
It's the debug information that is incorrect. In the ntdll.dll on my system, chkstk itself is 77 bytes long. (As you would expect, this function's control flow is extremely simple to follow.) But 3392 bytes, containing several blocks of code which are not reached from chkstk, are attributed to chkstk in the debug information. None of those code blocks crashed. One of them invoked the exception handler.
This is a straightforward backtrace, modulo the deficiencies that an experienced low-level programmer learns to expect. It says that dereferencing d raised an access violation.