FPC and Lazarus are great but the GDB is inadequate. Many times in my development, GDB failed or crashed, especially when I am debugging multi thread programs.

Shall we start a fund raising event to raise fund for a new and better debugger for FPC + Lazarus? (provided there are talents out there who would do implement it).

Dennis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20181120/959e7d60/attachment.html>

my donation is safe for that.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20181120/47776410/attachment.html>

That work is already in process (though very slowly / work has started/stopped plenty of times over the past many years). It is called FpDebug.
Donations are still welcome.
Under Windows and Linux you can install the package LazDebuggerFp. (You can do on Mac too, but then you need to codesign the entire IDE). Best use Lazarus trunk (it is already ahead of fixes 2.0 branch, but by very little only)

Support for threaded apps in fpdebug is not yet there. Under Linux only the main thread is debugged. Windows has bare minimum  (and untested) support for dealing with threads.

About using gdb.
- If on windows, test the alternative gdb downloads from our sourceforge site. (Newer is not always better / but there is no generally best version, depends on many factors).
- Do not use dwarf3, this increases the risk of gdb crashes ("dwarf2 with sets" is recommended)
- On win64, there are issues with single stepping. Potential workaround: compile the project (and all packages that have debug info) with -Xe -al (external linker and assemble) => that is slow, but may help
- Always ensure that all packages have the same type of debug info. If you compile the project with "dwarf with sets", then any package (unless it has no debug info) should also use "dwarf with sets" ("dwarf2"  (aka "dwarf"/-gw in the IDE) and "dwarf with sets" are compatible too). You can use "additions and overrides" to ensure this.
- Absolutely stay away from smart linking (for debugging). You can compile the units "smart linkable". But do not actually "smart link" the exe
- Not related to crashes, but stay with "NO optimization" -O-
- (fixes 2.0) On the debugger option (property grid): check and maybe reduce the various memory limits.

If crashes happen while examining values try installing the package LazDebuggerFpGdbmi, and set the debugger type to "gdb (with fpdebug)". All the above still applies.

Though yes, in the end, gdb may still crash. Depends on lots of stuff in your app.

For Mac, we have an LLDB based debugger now. It works on other platform too (if lldb is available and stable). But it is less feature rich.

Also check http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20181120/5301a07e/attachment.html>

Yes, we should, I think.

Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20181120/f3fda57a/attachment.html>

So much this. GDB needs to die in a fire.

(nb: make sure to enable "Reset debugger after every run". That at least works around the absurd amount of memory leaks, and helps with lost breakpoints.)

I cannot find this

"Reset debugger after every run"

option in the Lazarus options.
Is it set by a command switch?
How to set it?

Dennis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20181121/cb03b883/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: hkpaiedfbpapaild.png
Type: image/png
Size: 27584 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20181121/cb03b883/attachment-0001.png>

Its an IDE global option.

Menu: Tools > Options
Page: Debugger > General

That is also where you can set memory limits for gdb (in Lazarus 2.0) -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20181120/697cb968/attachment.html>

Dennis wrote

Shall we start a fund raising event to raise fund for a new and better debugger for FPC + Lazarus?

Indeed, the debugger is the weakest part of FPC/Lazarus development tools.

The problem is not so much funding the idea of implementing a dedicated and improved debugger. There has been many attempts at implementing new debuggers (all without funding) and some of that have now been combined into one Pascal based debugger (fpdebug).

The real problem is man-power - finding someone that can give their full attention to the task until it is complete (and hopefully on par with debuggers like can be seen in Java development). With small open source projects like FPC and Lazarus it is hard to find such dedicated man-power, because most contributors actually have full time jobs, or get bored and work on other areas they find more enjoyable.

Regards,
Graeme

Op 20-11-18 om 12:19 schreef Martin Frb via lazarus:

You do not have to sign the ide. You can use FpDebug as external debugger, then you only have to sigh the FpDebug executable itself.

Support for threaded apps in fpdebug is not yet there. Under Linux only the main thread is debugged. Windows has bare minimum (and untested) support for dealing with threads.

Strange, debugging threads works fine. At least on Linux and OS/X. There were some memory-leaks in the show-threads window, though. I've asked you to who wants to help improving the debugger, should stop working with gdb and install fpdebug. And start filling bugs. Fpdebug is already better in many aspects then gdb, only now and then I have to switch back to gdb.

Regards,

Joost.

Op 21-11-18 om 11:30 schreef Graeme Geldenhuys via lazarus:

On 2018-11-20 10:37 a.m., Dennis via lazarus wrote: Indeed, the debugger is the weakest part of FPC/Lazarus development tools.

I don't agree. The lack of a good (online) package-system is the weakest part. (debugging might be the second)

It is fairly simple: my top priorities are now:

1: Fpmake/Fppkg
2: Fpdebug
3: Attributes / RTTI

I decided to work only on Fpmake and Fppkg. When that works, switch to Fpdebug. And then the attributes.

I hope that someone else can pick up the attributes and RTTI work, though. A lot is already happening in this regard.

And Fpdebug works fine. This is also something that others can help with. Martin does most of the Lazarus-stuff and everything needed to show variables and such. I'm working on the lower-level parts.

But, as Graeme said, all in my spare time.

Regards,

Joost

I wasn't sure if that is fully working...

What class/package is that in the IDE?

stopped.
There was no way to pause the other threads.

Each one of them would stop, if reaching a breakpoint. But then the main thread (and others) would continues running.

If I had a test thread, that loops an a single "a:=1;" (consuming cpu like hell), and I try to set a breakpoint, I got occasional crashes of the debugged exe. (Not verified, I think it pauses the main thread while setting the breakpoint?, but the sub thread in which the breakpoint will be set, is still running...).
Need to dig deeper into that.

So need to check, about pausing all threads.

--------
A good way to find thread issues, is to debug the IDE, and inside the debugged IDE compile your project (uses thread), and then debug your project (does fork processes).

Op 21-11-18 om 13:42 schreef Martin Frb via lazarus:

You have to install lazdebuggerfpdserver.lpk. The host-application can be found in components/fpdebug/app/fpdserver. This is the one that should be signed.

This once was the first version of fpdebug that I've got running. But I'm not sure what it's state is at this moment.

There is no option to choose which thread you want to stop, no?

There was no way to pause the other threads. Each one of them would stop, if reaching a breakpoint. But then the main thread (and others) would continues running.

True. Only one thread stops. (I thought this was neat!) You want all threads to stop when one of them stops? Always?

I'm wondering which layer we should let take care of this. It would be nice if the user can decide which threads should stop or continue. In that case we need to adapt the abstraction-layer and an update of the GUI.

Ah, yes. Offcourse. When you set a breakpoint while the application is running, we have to pause the application. At the moment it will only pause the main thread, which means that when another thread touches the code we want to set the breakpoint on... big trouble.

Issues like these, that's why we need more testing.

Regards,

Joost.

Joost van der Sluis wrote

> When I tested (last week), using "Pause" button, only the main thread > stopped. There is no option to choose which thread you want to stop, no?

Not that I have seen.
I think (just a feeling/ no evidence) the debugger (in linux-classes) will need to loop through all the threads.
Also need to verify if we distinguish, between thread and fork

Hitting the Pause button, usually yes.
Hitting a breakpoint, likely too, at least as default.

Once paused, single stepping should (if OS supports / Linux does; Windows does not) offer to keep other threads paused, or to run them until the step finishes.

I'm wondering which layer we should let take care of this. It would be nice if the user can decide which threads should stop or continue. In that case we need to adapt the abstraction-layer and an update of the GUI.

Afaik, even GDB can do the single stepping choice above. So yes, that needs eventually to go to the GUI