Hi,

I'm running my application via the IDE and get an Exception error. The dialog pops up showing me the exception with two options - Break or Continue. I select Break which takes me to the code in question (well almost). I then use the Call Stack dialog to move further back in the code (say Index = 10 in the Call Stack dialog), but I can't inspect any variables at that point.

Is this by design? Is it a bug with the debugger? If by design and I can't inspect variables at that point, then what's the point of the Exception dialog giving me the option to Break into the code.

Regards,
Graeme

Graeme Geldenhuys wrote

I then use the Call Stack dialog to move further back in the code (say Index = 10 in the Call Stack dialog), but I can't inspect any variables at that point.

I forgot to mention - in case this is of help...

$ gdb --version
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-83.el6)

and Lazarus 1.7 r52715 FPC 2.6.4 x86_64-linux-gtk 2

Regards,
Graeme

it should work.

what does the "locals" window show? Does it change, when you change the stack?

And you need to press the "current" button in the stack. doubleclick does not select it.

Martin Frb wrote

And you need to press the "current" button in the stack. doubleclick does not select it.

Ah, that was the problem. Thanks for help. Amazing I never noticed it before.

A question though:
Why must you click "current" before the stack (an local variables) update? Wouldn't that be the obvious thing to do (desired behaviour) when you double click back into the stack history? The "current" button just seems redundant.

Regards,
Graeme

Graeme Geldenhuys wrote

On 2016-09-08 19:07, Martin Frb wrote:> And you need to press the "current" button in the stack. doubleclick > does not select it. Ah, that was the problem. Thanks for help. Amazing I never noticed itbefore.

Thanks also from me, I'd always assumed there were good reasons for that behaviour (stack destroyed by exception or somesuch) which I think makes Graeme's question pertinent:

A question though:Why must you click "current" before the stack (an local variables)update? Wouldn't that be the obvious thing to do (desired behaviour)when you double click back into the stack history? The "current" buttonjust seems redundant. Regards, Graeme

No idea why, but iirc it always was like this. (that applies to breakpoints too)
double click => jump to code
current => set the frame for inspection

Years ago the debugger would get all watches before it could do any further action, if "current" was changed (and with many watches this could be very slow). So if you would double click, several frames, to find the one you are interested, you would have a lot of waiting time.

Now the debugger, can continue even if there are still watches to inspect, so it would be faster.
Maybe double click can (optionally?) include "current".

------------------------
Not sure, if in case of exception the correct frame is selected (ideally not the one in fpc_except).
This is sometimes one frame off, because some methods in RTL have no stackframe.