Forum > Debugger

FpDebug: Stack updates while "Run" -- Split from: "Help me collect debug-issues"

(1/2) > >>

I am not sure whether to post this here or to better create a new thread. I don't even know how to precisely define the issue as I haven't found how to reproduce it.

With fpdebug I sometimes observe the problem that after a break (halt at a breakpoint or exception), F9 doesn't reliably resume program execution. The program does in fact continue, but the debugger is in some "watch & trace" mode. In this situation, the "call stack" window keeps updating live showing the detailed call stack of every single instruction, just as if I kept pressing F7 over an over again. One might imagine that this makes execution terribly slow. The only way I have found so far is to reset the program and start anew.

I took the liberty to split this out of the "Help me collect debug-issues" @,57737

There is some feedback required here, so this issue is better placed in its own thread (avoid mixing with too many other ideas - the above thread is planed as an "bullet point" style collection of ideas, without any discussion attached to it)

That said, it was totally ok, that you did post this in the thread above. At that point you could not know, this would require more feedback.

About your issue.

Have you already updated to Lazarus 2.2?

I know this issue did happen in 2.0.x. And also in the 2.2RC.
It could happen both during "run", or while "stepping" (mostly "step over").

I did some fixes for that (Well, as far as could tell "I did fix it").
I have to double check, this fixes were merged to 2.2. (Will get back on this asap) -- EDIT: looks like they are merged to 2.2.

If this is 2.2, it would be good to have a small example program to reproduce this. That is, a small program, which can be debugged, and that will trigger FpDebug to misbehave like this.

EDIT: OS / 64 or 32 bit?

If it happens in Lazarus 2.2 you could also provide a log file.

Run lazarus as follows
(either from cmd.exe, or by creating and modifying a "shortcut" to "lazarus.exe"

--- Code: Text  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---lazarus.exe  --debug-log=C:\lazlog.txt  --log-enable=DBG,DBG_STATE,DBG_DATA_MONITORS,DBG_ERRORS,DBG_VERBOSE,DBG_WARNINGS,DBG_BREAKPOINTS,DBG_FPDEBUG_VERBOSE,FPDBG_BREAKPOINT_ERRORS,FPDBG_BREAKPOINTS,FPDBG_COMMANDS,FPDBG_LINUX,FPDBG_WINDOWS
Of course you can specify any path/name for the log, instead of "C:\lazlog.txt"

Thank you, Martin, for moving the topic.

--- Quote ---Have you already updated to Lazarus 2.2?
--- End quote ---


--- Quote ---If this is 2.2, it would be good to have a small example program to reproduce this.
--- End quote ---

Well, this is exactly the problem. I haven't yet found any correlation with what I'm doing or some special point of the program to make this happen. As far as I can tell, it doesn't seem to depend on any particular statement because when I stop and restart the program with the same breakpoint, it doesn't appear again. But maybe later... :)

OS is Windows 8.1, 64 bit. Lazarus is 64bit, too. But the application targets Win32/i386. I tried with debug info both Dwarf2 with sets and Dwarf3, but this doesn't seem to make a difference either.

I will try if I can get a debug log as you explained, but as the issue seems to happen very randomly, I can't tell for sure yet.

Thanks for your help.

And thanks to all Lazarus developers as well! I have seen that Lazarus 2.2 now updates variables in the "evaluate" window when stepping forward. This is a small but very helpful improvement!


--- Quote ---application targets Win32/i386
--- End quote ---
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...


[0] Message Index

[#] Next page

Go to full version