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

[Sven Barth]

Am 09.11.2010 11:25, schrieb Martin:
> 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
> auto-continues.
>
> => 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
> subroutine)
> 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:
>
> (gdb)
> -exec-next
> ^running
> *running,thread-id="1"
> (gdb)
> *running,thread-id="all"
>
> 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 thought that those two could be related, because both involve 
threading somehow. In your case two threads are really running and in 
mine only one is, but GDB outputs text after the prompt is shown which 
results in incorrect behavior

> ------------------
> I have added some notes to the bug

I'll try to test your fix when I find the time (and remember it ^^).

Regards,
Sven