https://bugs.winehq.org/show_bug.cgi?id=57628
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@gmail.com
--- Comment #4 from Eric Pouech eric.pouech@gmail.com --- I'm not sure it's wrong API usage :-( MSDN documentation for StackWalk64 doesn't explicitly requests that the process has been initialized (whereas it's explicitly stated for most of the others dbghelp's APIs)
this likely requires something like what's done in minidump writing (eg creating a dbghelp context with SymInitialize if none exists) (*)
what's harder is the STACKFRAME64 part...
MSDN states that only the 3 addresses need to be initialized... let's see
when using
memset(&s, 0xA5, sizeof(s));
before the the init of the STACKFRAME64, I get a nice exception thrown from within StackWalk64... it seems to be triggered when the KDHELP64 RetpolineStubFunctionTableSize field is set to 0xA5A5A5A5A5A5A5A5 So not initializing the STACKFRAME can lead so severe impacts!
I see also usage of STACKFRAME64.Reserved fields - after first call, Reserved[0] is set to 0, - after second call, Reserved[2] can be touched - afterwards no Reserved fields are changed
the Far & Virtual fields are only changed when their value is 0 or 1 depending if Far&Virtual are among 0,1 or not, modification on Reserved[2] is different (set to 1 vs decreased by one)
but in any case, native seems to do more work to try to identify if the structure has been initialized or not...
note: builtin dbghelp also requires to distinguish, first call, second call and any other calls on x86_64 (situation is way more complex on i386)
note also that non initialized content on stack can vary between Wine & Windows
is this snipnet derived from a real application? If so, can you share which one? (the observations above are only for x64, and are likely to be different for another machine. current dbghelp code makes the assumption that the Reserved fields are zero:ed upon first call; I'm not sure we can simply detect the uninitialized state without making any assumption on the Reserved fields content)
(*) would require some testing as likely the process handle shall be a live (real) process handle, and whether the context is kept somehow (otherwise would require rewalking the module list at each call, which could be time expansive at the end)