[fpc-devel] Re: [Lazarusdev] gdb driving me nuts => it's starting a 2nd thread for no apparent reason....

Martin fpc at mfriebe.de
Tue Nov 9 11:25:11 CET 2010

On 09/11/2010 08:45, Sven Barth wrote:
> Am 09.11.2010 00:08, schrieb Marc Weustink:
>> :)
>> On windows I create a remote thread to be able to pause execution to
>> enable breakpoints and such while the program is running.
>> See initialisation part of the gdbmi debugger. There I use a few options
>> to pause execution. On the NT platform the remote thread solution is the
>> most reliable.
>> Marc
> Can Martin's problem be somewhat related to what I reported here: 
> http://bugs.freepascal.org/view.php?id=17089

Not direct. TryNt is in an IFDEF Windows block => so not used on Linux.

I did saw a related issue, though. I thought it may be related, and did 
a shorrt linux test.

Sometimes F8 would cause a "sig-int" (on the location it was started).
This would be ok, Lazarus recognizes it as a temporary interruption, and 

=> But Lazarus always auto-continues with -exec-continue
=> Since we are in an -exec-next, we should auto-continue with an -exec-next

Of course that leaves 2 unsolvable issues:
- if the sig-inf would happen in a sub-routine, over which F8 is stepping
- or if a temp interruption is caused by the user setting a breakpoint, 
while stepping with F8 over a long running subroutine
=> then the stop is in the middle of that subroutine (may be nested 
There is no command that will get to the point where the original F8 
would have stopped.
But -exec-continue is the worse choice, since it will run away.
Better to repeat the user-command (-exec-next in this case) which will 
stop early, but may give the user a chance to fix it by hand.

About marks observation:


I haven't checked what is happening in this case.
The (gdb) is fine, but then the "  *running,thread-id="all"" is read as 
stop-reason => and not handled there.

I have added some notes to the bug

More information about the fpc-devel mailing list