Recent

Author Topic: Exclude LCL source when debugging  (Read 452 times)

adderthorn

  • New member
  • *
  • Posts: 6
Exclude LCL source when debugging
« on: March 09, 2020, 07:34:54 pm »
I am working on debugging an issue in my project. The debugger fails on a method inside the Grids unit from the LCL. I know that, based on the stack trace, the culprit is something in one of my units. Is there a way to force Lazarus not to include foreign/LCL libraries when debugging? I realize this may seem like a stupid question but I am unable to find anything by searching.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6374
    • wiki
Re: Exclude LCL source when debugging
« Reply #1 on: March 09, 2020, 07:55:54 pm »
Switch off debug info for those packages. (And make sure to recompile them)

Open the package LCL, go to its options and disable the debug info. Also check in custom options. Often they include the IDE build options, and that in turn may include debug info.

It will still be on the stack (address only, no line number). But it should not step into it.

-------------------
What exactly do you mean by:
Quote
The debugger fails on a method inside the Grids unit from the LCL.
?

The debugger says that grids raised an error?
Or the debugger ends the debug session "oops"?

adderthorn

  • New member
  • *
  • Posts: 6
Re: Exclude LCL source when debugging
« Reply #2 on: March 09, 2020, 08:20:24 pm »
Thanks Martin,

Is there a project that contains the LCL in its entirety? I can't seem to find a package in the default install of Lazarus on Windows.

In regards to your second question, I should have been more clear. The debugger catches an exception on some line of the Grids unit, with an index out of range. The debugger is working fine, just catching in the LCL whereas I'd rather it catch on only my code.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6374
    • wiki
Re: Exclude LCL source when debugging
« Reply #3 on: March 09, 2020, 09:23:19 pm »
Open the Project Inspector and look at the packages used.

In some cases LCL may be used indirectly. That is you use Package FooBar, which uses LCL. Then you need to click through... The package graph (menu package) can help.

If an exception is thrown it will be caught. If there is a "range error" in the the LCL thrown it will be caught always.

The LCL may be on top of the stack window, but your code should be further down, and you can select the stackframe with your code.

If the LCL does not have debug info, the debugger still stops. But it will try to auto locate the first frame with debug info. Which then should be your call to the LCL.

----------------------------
Quote
index out of range
I assume, such as T....List would throw if called "SomeList[Count+1]"?

If it is a range check error (-Cr) then you need to disable this for the LCL. But then there either is still a bug in your code (same rules as above).
Or a bug in the LCL, which should be reported.


-----------------
To be exact:

If any code (with or without debug info throws an Exception, then this is caught (well in dynamic libraries it might not, but ...).

And if so, the execution is always in the RTL. The debugger catches it in the internal fpc function "fpc_raiseException" (or similar).

If possible the debugger adjusts the stack.

Also, if possible the debugger will single step to the next except/finally block. (Win 64 only in Lazarus trunk / fpc experimental SEH for 32 bit, not at all).

------------
You can tell the debugger to ignore exception by class. Eg all EListError exceptions. (but then that includes any EListError thrown by you)
« Last Edit: March 09, 2020, 09:25:48 pm by Martin_fr »

 

TinyPortal © 2005-2018