Hi,

Has anybody actually noticed that it's impossible to debug an application with Lazarus IDE. I normally use tiOPF's Log() methods to debug code or writeln() statements, but today I had a tough problem and wanted to step through a procedure. So I used breakpoints and the Watch List window. Only local declared variables in that method was watchable. Everything else gave errors like "No symbol ?? in current context" or "Syntax error in expression....". Also the tooltip expression evaluation doesn't work either, except again only for local variables.

See the screenshot in the bug report. Oh, and in my projects Compiler Options, I had -g and -gl parameters enabled for GDB debugging. No smart linking or optimization enabled.

How do any of you debug your programs in Lazarus IDE? Is it possible at all? If not, this is a huge missing feature for any IDE and should be considering as critical/blocker priority. Anybody know if MSEide does any better? If so, maybe Lazarus IDE can use some of that code?

Mantis bug report:
http://bugs.freepascal.org/view.php?id=12522

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Did you add -O- to compiler options? FPC optimizations disturb gdb.

[...]

Anybody know if MSEide does any better?

Try it out. ;-)

Martin

Graeme Geldenhuys wrote

See the screenshot in the bug report.

Properties can not be showed by gdb. For FView.RowCount try FView.FRowCount to show the field if it exists. There is no workaround for array properties because a call to the read function would be necessary to get the value which is not supported by the provided FPC debug info. It is dangerous anyway because the getter could have side effects.

Martin

Martin Schreiber pisze:

I can say that I have a lot of "this is not an aggregate" or something like that errors when trying to use watches window.

When we could test native Lazarus debugger ? ;-)

Boguslaw

Martin Schreiber wrote

> Did you add -O- to compiler options? FPC optimizations disturb gdb.

The first thing I thought of. All optimization was disabled in the Lazarus Packages I used and the Project itself. It made no difference.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Bogus?aw Brandys wrote

I can say that I have a lot of "this is not an aggregate" or something like that errors when trying to use watches window.

This is most likely because of missing -O-.

When we could test native Lazarus debugger ? ;-)

gdb is not so bad once the communication by pipes works stable. Another problem is the only partial implemented mi-interface. Many actions must be done by the normal commandline interface where the response is difficult to parse, but it is doable, see MSEide.

Martin

Ah, thanks for that info Martin. I guess it's back to my trusty Log() or writeln() calls again. :-)

Anybody know if Kylix 3 used GDB, or did it have it's own built-in debugger. Because I know those type of use cases worked in Kylix IDE.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Bogus?aw Brandys wrote

When we could test native Lazarus debugger ? ;-)

Is there one in the works?

Anybody know is the text based FP ide included with Free Pascal does any better than Lazarus?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Graeme Geldenhuys wrote

Anybody know if Kylix 3 used GDB, or did it have it's own built-in debugger. Because I know those type of use cases worked in Kylix IDE.

It used its own debugger. And it was one of the first things which stopped working with newer distros and debugging of fork and threads did not work without patching the RTL IIRC.

Martin

FP IDE uses libgdb which is not available for all distros.

Martin Schreiber wrote

It used its own debugger. And it was one of the first things which stopped working with newer distros and debugging of fork and threads did not work without patching the RTL IIRC.

Yes, but debuging was easy to fix in Kylix, with the minor patch. It's still working fine with Ubuntu 7.10

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Martin Schreiber wrote

It used its own debugger.

As a temporary fix, is there any way one can use the Kylix 3 debugger with FPC or Lazarus? Or is the debugger built (compiled) into the Kylix IDE? I know the compiler is stand-alone (called dcc), but I can't see anything obvious for the debugger, so I guess it's built into the IDE. :-(

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Why do you think the Kylix debugger could access FPC properties by getter function calls which gdb can't? For other debugging tasks use MSEide, it has stepping, conditional breakpoints and watchpoints, CPU and disassemble window, displaying and modifying of expressions and variables, memory dump... After you found the bug you can return back to Lazarus. ;-)

Martin

Martin Schreiber wrote

> Why do you think the Kylix debugger could access FPC properties by getter function calls which gdb can't?

I don't know how debuggers work. My thinking is that maybe GDB is specific to C/C++ language and Object Pascal support is simply a afterthought - not fully implemented to support all Object Pascal language features like properties.

I thought of the Kylix debugger because it's written to work with the Object Pascal language. I can run Kylix 3 and debug a program and view a Object's 'property' values without issues.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Ehm... Martin, what is the reason to create another ide for msegui? Just plug everything into lazarus ;)

Best regards,
Paul Ishenin.

Yup, why not? Feel free to do so. The MSEide gdb mi-interface class is a good candidate. Other parts are more difficult because they depend on the MSEgui architecture which is very different from the Lazarus design. If you ask why I developed my own IDE instead to use Lazarus, when I started with the new design of MSEide some years ago, Lazarus was not stable enough. Because of the many widgetsets and platforms Lazarus supports, I didn't expect Lazarus to stabilise fast enough. utf-8 versus utf-16 is another theme...
Again, feel free to use any useful piece of code of MSEide+MSEgui for Lazarus.

Martin

...

Again, feel free to use any useful piece of code of MSEide+MSEgui for Lazarus.

Thanks. Hope we will find a way to merge some useful mseide parts.

Best regards,
Paul Ishenin.

Properties can not be showed by gdb. For FView.RowCount try

FView.FRowCount to

show the field if it exists. There is no workaround for array properties because a call to the read function would be necessary to get the value

which

is not supported by the provided FPC debug info. It is dangerous anyway because the getter could have side effects

Do i understand you right? MSEide cannot resovle properties as well? I've installed MSEide, but after building a project, MSEide did not start debugging for some reason. So could not actually see debugging alive. (It seems like i've missed something with configuration)

Anyway. What about OOP debugging? let's say we have 2 classes
TA = class(TObject)
  function Value: Integer;
  procedure Method; virtual;
TB = class(TA)
  procedure Method; override;

If i'm trying to debug B.Method, will debugger be smart enough to evaluate .AValue call inside B.Method correctly?

While Lazarus debugger doesn't have enough debug info, it could use CodeTools to create the proper evaluation expression. -------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20081031/a3af13b6/attachment-0001.html

mitya boyarintsev wrote

Do i understand you right? MSEide cannot resovle properties as well?

Correct. MSEide can not access property values. Fortunately prepending the property name with 'F' usual works because of the naming convention.

Please use NNTP:
news://news.grid-sky.com/public.mseide-msegui.talk for questions about MSEide+MSEgui.

You mean to show the result of TA.Value in the Watch Window? It is possible to call functions in debuggee by gdb. MSEide uses this feature to release the debuggee mouse grab in X11.
Calling a property getter function is dangerous because the function often does more than simply return the value.
If I need access to a property for debugging purpose, I insert an assignment to a "testvar" in code. After the problem has been solved, a "Find in Files" for "testvar" helps to clean up the code.

While Lazarus debugger doesn't have enough debug info, it could use CodeTools to create the proper evaluation expression.

MSEide parses the source code for code navigation and class competion only. The MSEide debugger uses only information which gdb provides, for example to correctly display widestrings and dynamic arrays. This has the advantage to be independent of possible discrepancies between FPC and the imprecise IDE parsing.
Because Lazarus parses the whole code including RTL exactly AFAIK, Lazarus has more possibilities than MSEide to access Pascal specialties. Although I don't suggest it, it seems error prone to me.

Martin

Martin Schreiber wrote

Correct. MSEide can not access property values. Fortunately prepending the property name with 'F' usual works because of the naming convention.

That was a handy trick. I managed to debug my program in Lazarus IDE yesterday, using that method. Thanks.

Calling a property getter function is dangerous because the function often does more than simply return the value.

I do not think that matters much. Properties are a fundamental language feature in Object Pascal and are used often, so the debugger must support it. Plus the code you are debugging doesn't care what's happing in the Getter method, it is only concerned with the result returned. So if the result return is not what you expected in that code location, then debug the Getter method or step into the Getter method. This worked for Delphi and Kylix from the start.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Well, it can become tricky. Suppose you try to debug something in the form creating and initial showing. If you inspect the MyForm.Handle, the handle gets created. Now, the handle is created at another point in the initialization sequence than at normal run time.

Vincent

Vincent Snijders escribi?:

This is a risk, the debugger user shoud be aware of, but viewing and setting property values must work in the debugger, as it does in Delphi. I am with Graeme in this!
I also believe that the Object Pascal Internal Debugger is an important thing missing in this project, but I think I don?t have the skills to contribute on this :-(

Horacio

Vincent _______________________________________________

I absolutely agree. You cannot call it a RAD tool unless this is implemented. Debugging GUI programs with log files is like developing in the 80's. You need to be able to check and change any property of any object when debugging and not just the local basic variables. Same with the disassembler window and the New EIP feature to jump back in the code and repeat some code parts' execution if needed.

I think Graeme's report is the same as
http://bugs.freepascal.org/view.php?id=12111

Horacio Jamilis wrote

Vincent Snijders escribi?: > Graeme Geldenhuys schreef:

...snip

If you can give me a nice way to undo the case vincent described, I'll happily implement that.
Note that Delphi doesn't handle this either. So evaluating properties can modify the state of the debugee.

I am with Graeme in this! I also believe that the Object Pascal Internal Debugger is an important thing missing in this project, but I think I don?t have the skills to contribute on this :-(

Thats one thing, but what is more important is a fully generated debug info. Without this info, a debugger can do nothing. At this moment properties cannot be evaluated using the stabs info. period. When using dwarf it can be possible, however we might need a extention to the dwarf spec to get complete support.

(FYI, stabs and dwarf are the formats fpc uses to write debug info)

Marc

Don't treat developers as idiots! Normally they know the pitfalls in doing potentially dangerous tasks. Usage of raw Pointers is another example. If they don't know how to use it correctly or the know pitfalls, they will learn quickly. ;-)

You have many pitfalls with "Edit and Continue" as well, yet it's an option for developers to use in Visual Studio.

Note that Delphi doesn't handle this either. So evaluating properties can modify the state of the debugee.

Well, if it's good enough for Delphi to include property evaluation without the safety net of an undo - why can't it be good enough for FPC's debugger? For me it's an acceptable risk - like many other things. And the benefits outweigh the risks.

BTW:
Is there a custom written FPC debugger we can try out and test?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Marc Weustink pisze:

Isn't dwarf already implemented in fpc SVN version ?

Boguslaw

It is ok. Why should you warry about undo? One must understand what does it do.

On the other hand if you really want to protect users we can invent an option to prevent evaluation of properties which has getter (if we can detect ofcource props with getters and props linked to fields). Or we can split evaluation process of such properties by 2 steps: ask to evaluate property and confirm that you really want to evaluate a property with getter which can change debugee state.

In the other words - please implement this and we will try to find a way to protect users ;)

Best regards,
Paul Ishenin.

In my experience you really need to know what you are doing and even then you might not know.

I plan to add a option to enable function/procedure evaluation.

In the other words - please implement this and we will try to find a way to protect users ;)

OK, then we have a next problem, to handle this properly, this must be added to the dwarf spec. Sooner or later i'll dive into this again to see if there is a solution.
Problem with properties it that you have different read and write access foar the same symbol.

Marc