Short call stack inside DLL execution
lazarus / 12-Debugger

----------------------------------------------------------------------
Chronos · 2011-02-01 07:01

It is possible to get full call stack if application is paused inside
execution of DLL?

Example code:
Code: [Select]Sleep(1000000);
If program is manually paused during execution of Sleep than Call
Stack window show only few lines:
Code: [Select]#0 ntdll!LdrAccessResource at :0
#1 ntdll!ZwDelayExecution at :0
#2 SleepEx at :0
#3 ?? at :0

There are no information about real placement of original Sleep
function calling in own source code.

Same apply to other blocking functions as

Code: [Select]Event.WaitFor(1000000);
pausing shows only

Code: [Select]#0 ntdll!LdrAccessResource at :0
#1 ntdll!ZwWaitForSingleObject at :0
#2 WaitForSingleObjectEx at :0
#3 ?? at :0
#4 ?? at :0

----------------------------------------------------------------------
marcov · 2011-02-01 08:35

(afaik this also happens in Delphi btw, so might be systematic)

----------------------------------------------------------------------
Chronos · 2011-02-02 07:54

Unfortunately stepping through assembler code doesn't always work. But
if it does then program continue inside DLL to something like
ReleaseMutex where then context is switched to main thread and call
stack will show proper information. So solution would be implementing
something like "Thread status" window, where all threads will be
listed with their id and running status similarly to Delphi. Ability
to show call stack for every thread will be useful too.

----------------------------------------------------------------------
Chronos · 2011-02-10 06:52

I found out that short call stack is result of not storing compatible
stack frame to the stack. It occurs inside function with incompatible
stack frame or simply by stepping through assembler on instruction
which push or pop something to the stack and thus affect stack frame
chain.

Then solution should be to make more intelligent stack passing with
ability to do alignment of rest of call stack. But as debugger is not
native so far and call stack is read from GDB. So where is no way to
do that now. We have to wait for native debugger.


Another problem is assembler stepping. If program is stopped inside
Sleep procedure then call stack is not completely visible and stepping
is not always successful. Interesting difference is that if Sleep is
called from main thread then stepping doesn't work. But if Sleep is
called form other thread stepping works and I am able to move forward
by few lines where call stack is displayed properly.

This issue need more investigation.