[Lazarus] some workarounds [Re: Debugger problems]

ik idokan at gmail.com
Sat Feb 21 15:03:43 CET 2009


I usually print to log/screen the output of things rather then working
with a debugger.
There are rare cases where I actually find the need to use a debugger,
when you learn how to work with log files.

Ido


On Sat, Feb 21, 2009 at 3:03 PM, Martin Friebe <lazarus at mfriebe.de> wrote:
> Graeme Geldenhuys wrote:
>> On Sat, Feb 21, 2009 at 12:49 AM, Hans-Peter Diettrich
>> <DrDiettrich1 at aol.com> wrote:
>>
>>> In most cases I cannot inspect local variables, due to "no such symbol
>>> in context" errors, even with fully disabled optimizations.
>>>
>>
>> This is exactly the errors I get. I develop under Linux only, so it
>> doesn't seem to be a platform issue. I gave up trying the integrated
>> debugger and simply use Log(..) or Writeln(...) calls now
>>
> It is true that there are cases where GDB does not find Symbols, until
> this can be fixed in a better way, here are a few cases and workarounds
>
> 1) properties
>
> This is apparently the most common case? GDB has no concept of
> properties. Also properties can refer to functions.
> Possible workarounds:
> a) if a property refers to a Variable, use CodeTools to find the
> variable name, and expect the Variable. Usually property abc, will point
> to variable Fabc
> b) if the property refers to a method, there is no workaround, since
> currently you can not force GDB to execute any method. Executing the
> Method could also change the state of the debugged application.
>
> 2) Nested Procedures
>
> GDB does only see the current stack frame.
>
> Procedure SomeObject.ABC
> var x: integer;
>  Procedure Nested
>  begin
>  end
> begin
> end
>
> While in "Nested" gdb can NOT see anything that belongs to ABC. (this is
> it can not see "x", and it can not see "self" (the object), or any
> variable on the object)
>
> Possible Workaround:
> Open the Stack Window, and change the current frame. I know this is a
> bit dull, because you have to change it after each execution step.
>
> 2a)
> The same applies to hints in the source window. *Variables*  will only
> show if the stackframe is correct
>
> 3)
> Sometimes Variables are pointers in GDB, where they are not in Pascal.
>
> if you type SomeObject as a watch it may just say "TSomeClass 0x23ab76"
> => try typing SomeObject^
>
> 4) Dynamic arrays
> See the following post for a workaround (again it is too complex for
> every day use, but it may help for desperate occasions)
> http://forum.lazarus.freepascal.org/index.php/topic,4763.msg22954.html#msg22954
>
>
>
>
> _______________________________________________
> Lazarus mailing list
> Lazarus at lazarus.freepascal.org
> http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
>



More information about the Lazarus mailing list