Ok, anyone with an idea..

Attached is a simple program (appologies for the many commented lines, but all logs refer to the lines as in this source, and I didn't want to recreate the log yet another time)
Tested with various versions of gdb dwarf debug info (and IIRc (it's been a lot of trying) also stabs). Mainly used todays triunk of fpc, but the same with 2.4.0 (again IIRC)

In the log:
- lines with ">>" written to the debugger
- lines with "<<" read from the debugger

debugger started with this options:
gdb -silent -i mi -nx

the app pasically is
   Program Foo;
   procedure Test; begin writeln(); end;
   begin
     Test;
     Test;
     Test;
   end;

- the output of writeln has no significance, and can even be commented away
- breakpoint is set on the first call to "Test"

then hit F8 (step-over) twice
- the first F8 stops (but for the wrong reason (should be "*stopped,reason="end-stepping-range"..."
- the 2nd F8 cause a sigill

they apparently stop half into an instruction, which may be part of the issue..

The biggest riddle is, why gdb says it's starting a 2nd thread? (btw using gdb directly, same options, but piccking only the most relevant commands from the log => not reproducible)

Below is the communication of the first "F8 step-over", before that the breakpoint was hit, and some info queried (stack, etc). All that is send is a single "-exec-next", yet a 2nd thread seems to get started.
Strange too, the address at which it does hit the sig-trap...

> TCmdLineDebugger.SendCmdLn "-exec-next"

<< TCmdLineDebugger.ReadLn "^running"
<< TCmdLineDebugger.ReadLn "*running,thread-id="1"" << TCmdLineDebugger.ReadLn "(gdb) "
<< TCmdLineDebugger.ReadLn "=thread-created,id="2",group-id="1032"" [Debugger] Notify output: =thread-created,id="2",group-id="1032" << TCmdLineDebugger.ReadLn "~"[New Thread 1032.0x1774]\n"" [Debugger] Console output: ~"[New Thread 1032.0x1774]\n" << TCmdLineDebugger.ReadLn "*running,thread-id="all"" [DBGTGT] *
[DBGTGT] running,thread-id="all"
<< TCmdLineDebugger.ReadLn "~"[Switching to Thread 1032.0x1774]\n"" [Debugger] Console output: ~"[Switching to Thread 1032.0x1774]\n" << TCmdLineDebugger.ReadLn
"*stopped,reason="signal-received",signal-name="SIGTRAP",signal-meaning="Trace/breakpoint trap",frame={addr="0x
771d8b2f",func="??",args=[]},thread-id="2",stopped-threads="all"" << TCmdLineDebugger.ReadLn "=thread-selected,id="2"" [Debugger] Notify output: =thread-selected,id="2"
<< TCmdLineDebugger.ReadLn "(gdb) "

:)

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

Regards,
Sven

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 have added some notes to the bug

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

It's not a fix => it's added debug info, to see if I can fix it....

forget it, I know what it is

<-exec-next>
^running
*running,thread-id="1"
(gdb)
*stopped,reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",frame={addr="0x080480e8",func="main",args=[],file="dbgtest.lpr",fullname="/home/sven/projects/tests/dbgtest/dbgtest.lpr",line="20"},thread-id="1",stopped-threads="all",core="0" (gdb)
<-exec-continue>
^running
*running,thread-id="1"
(gdb)

it's the signal issue....

I know how to fix, only matter of time

So I was right with my assumption that both problems are related?

Regards,
Sven

Ok, I've found your other mail in Lazarus list (and to me as well) now ^^

Regards,
Sven