StackTrace returns next line of execution (with code) not the current

[SoLaRGit]

call to following code can return several lines below actual line:
if (SymGetLineFromAddr64(this->m_hProcess, s.AddrPC.Offset, &(csEntry.offsetFromLine), &Line) != FALSE)

but if we try following before above code:

if (SymGetLineFromAddr64(this->m_hProcess, s.AddrPC.Offset - 1, &(csEntry.offsetFromLine), &Line) != FALSE)

We can get actual line of execution in stacktrace.
Only column offset (offsetFromLine) is incorrect, not sure how to fix that one.

[JochenKalmbach]

I have no influence on the dbghelp.dll.... if there is a bug, the bug is also propagated...
Can you open a support case at MS?

[SoLaRGit]

Changed code to not use obsolete SymGetSymFromAddr64 function but SymFromAddr function from original header, and changed accordingly all structures and pointers to original header.
if (SymFromAddr(this->m_hProcess, s.AddrPC.Offset, &(csEntry.offsetFromSmybol), pSym) != FALSE)
But the results were the same regardless, SymGetLineFromAddr64 was returning invalid lines.

After careful reading the code actually it's not problem in dbghelp.dll, we are taking stacktrace frames, where we use address from PC (Program Counter) for each stack trace frame to locate actual position within the current execution context. And if I recall assembly correctly PC is incremented each time once instruction decoding is performed. So PC is incremented before code is actually executed (please correct me If I am wrong, it was 2 decades ago since I've programmed anything in assembly). Which actually means we are taking address of next line (instruction) actually, instead of currently executing line (instruction). Which was still helpful, but simply wrong. I even haven't noticed this offset of lines until I placed test function and behind it closed several code blocks, and noticed that line was offset-ed by those closed blocks (in my case by 5 lines), pointing to next line that should be executed after test function.

My tweak with -1 helped return correct line, probably due fact that dbghelp.dll has smart enough logic to conclude that byte belongs to previous instruction, and not the current. Think also that there are no implications in cases of instructions that are conditional jump and branching, due fact that PC is updated before call to printing callstack, also result from call stack needs to be evaluated before any branching so we are safe there. But still not sure have I covered all cases, can't think one top of my head to break the code right now.

But the problem doesn't end there. Test code uses Exception Filter, and first Frame actually returns correct line, but incorrect offsetFromLine. Not sure is this due fact that Instruction Decoder have raised error (was testing simple Division by Zero to throw exception in code and capture stacktrace). But all other frames lines are offset-ed, where offsetFromLine is correct for those offset-ed lines.

If I use tweak (-1) all lines are correct but offsetFromLine is now correct for the first frame, but incorrect for all other frames, problem could be the fact that -1 is actually not pointing to start of instruction and is making all offsetFromLine to be incorrect. But to write full reverse instruction decoder would require little more time than few tweaks now and there, unless we have somewhere else address of previous instruction?

[JochenKalmbach]

This is normal behavior. It gets even worse if you use release builds instead of debug builds..

[JochenKalmbach]

This is normal behavior... if your code is optimized, it gets even worser....