[Lazarus] what can we do to get a better debugger

[Joost van der Sluis]

Op 21-11-18 om 13:42 schreef Martin Frb via lazarus:
> On 21/11/2018 13:08, Joost van der Sluis via lazarus wrote:
>> Op 20-11-18 om 12:19 schreef Martin Frb via lazarus:
>>>
>>> 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)
>>
>> 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.
> I wasn't sure if that is fully working...
> 
> What class/package is that in the IDE?

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.

>>
>>> 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 look at it.
> 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?

> 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.

> 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...).

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.