application targets Win32/i386
Ok, good to know.
The 32 bit version (i.e. debugging a 32bit target, is less well tested, at least by me, as my usual work is 64bit)
But it narrows (a bit) where to look (still a good range...)
Btw, half a workaround.
If you don't wont to stop the current debug session => use the power button on the stack window.
However, that only helps, if you also power off the "history window" (even if that is closed). So you must open it, and power it off, along with the stack / and watches)
Note, the history is not causing it. Powering off is not fixing it. But it reduces the time of those "unwanted pause", as it stops retrieving the stack.
Ok about the stack updates...
This may have to do with exceptions (in the widest possible sense).
- hitting an exception, pause and continue (step or run)
- step/run over an ignored exception
But could also be
- stepping into (or out of) a finally block.
For all of those, the debugger needs to catch specific events (like calls to ntdll RtlUnwing, or fpc_raiseexception). So the debugger sometimes sets breakpoints there.
Those should be handled internally. They should not be noticeable for you.
But for some reason, they are apparently not correctly caught, and forwarded to the front-end => well and then the stack is updated.
So if you happen to get such a log, that would hopefully give me a hint, which of them.
I'll see if I can find some time, to go looking through the involved code...