View Issue Details

IDProjectCategoryView StatusLast Update
0036076LazarusDebuggerpublic2019-09-18 07:05
ReporterChristo CrauseAssigned ToMartin Friebe 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version2.1 (SVN)Product Build 
Target VersionFixed in Version2.2 
Summary0036076: Close debugging session when remote connection is closed
DescriptionWhen debugging a remote target over a gdbserver connection the connection can unexpectedly drop out for a number of reasons (connection terminated, gdbserver terminated etc.). I want GDBMIDebugger to detect the message &"Remote connection closed\n" which gdb sends when the connection drops out and close the debugging session.

The attached patch looks for this message in DoLogStream and then call SetDebuggerState(dsStop); to terminate the debugging session. Not quite elegant, but it saves me the hassle of pressing Ctrl-F2.
Additional InformationThe gdb/mi output when the remote connecion is lost:
  << TCmdLineDebugger.ReadLn "=thread-group-exited,id="i1""
  << TCmdLineDebugger.ReadLn "&"Remote connection closed\n""
TagsNo tags attached.
Fixed in Revision61886
LazTarget2.2
Widgetset
Attached Files
  • RemoteConnectionClosed.patch (639 bytes)
    diff --git components/lazdebuggergdbmi/gdbmidebugger.pp components/lazdebuggergdbmi/gdbmidebugger.pp
    index dd62f6b0b7..66e0db7b5a 100644
    --- components/lazdebuggergdbmi/gdbmidebugger.pp
    +++ components/lazdebuggergdbmi/gdbmidebugger.pp
    @@ -2941,6 +2941,10 @@ var
           AResult.State := dsStop;
           ForceStop := True;
         end;
    +
    +    // If remote connection terminated then this debugging session is over
    +    if not InLogWarning and (LowerCase(Warning) = 'remote connection closed') then
    +      SetDebuggerState(dsStop);
     (*
     << TCmdLineDebugger.ReadLn "&"Warning:\n""
       << TCmdLineDebugger.ReadLn "&"Cannot insert breakpoint 11.\n""
    

Activities

Christo Crause

2019-09-14 17:34

reporter  

RemoteConnectionClosed.patch (639 bytes)
diff --git components/lazdebuggergdbmi/gdbmidebugger.pp components/lazdebuggergdbmi/gdbmidebugger.pp
index dd62f6b0b7..66e0db7b5a 100644
--- components/lazdebuggergdbmi/gdbmidebugger.pp
+++ components/lazdebuggergdbmi/gdbmidebugger.pp
@@ -2941,6 +2941,10 @@ var
       AResult.State := dsStop;
       ForceStop := True;
     end;
+
+    // If remote connection terminated then this debugging session is over
+    if not InLogWarning and (LowerCase(Warning) = 'remote connection closed') then
+      SetDebuggerState(dsStop);
 (*
 << TCmdLineDebugger.ReadLn "&"Warning:\n""
   << TCmdLineDebugger.ReadLn "&"Cannot insert breakpoint 11.\n""

Martin Friebe

2019-09-15 18:16

manager   ~0118084

Question:
 << TCmdLineDebugger.ReadLn "=thread-group-exited,id="i1""

Is that the last thread? Does that mean that there are zero threads left running?

If so, that might be interesting for an additional check?

Christo Crause

2019-09-15 18:40

reporter   ~0118086

My use case is for embedded AVR, so there is only one process or thread. I also don't know what else can be done if the remote connection is lost, as far as I can see gdb doesn't try to reconnect. In a stand-alone gdb session no further action can be taken (after this message) that needs to be communicated to the target.

Not sure if there are other considerations for remote debugging on another PC for example.

Martin Friebe

2019-09-15 20:09

manager   ~0118087

About the current patch:

I took the liberty to refactor it, so the check can be in the sub-class. Having a hook for processing the data might be useful anyway....

Please look at https://github.com/User4martin/lazarus/commit/f9e6efe98244ba1b513416528cc0cec6374fc2a0

DIFF:
https://github.com/User4martin/lazarus/commit/f9e6efe98244ba1b513416528cc0cec6374fc2a0.diff

If that works for you, then it is ready to go into svn.

----------------------------
About the thread idea:

If you have only one thread, then the message that this thread exited was as good as "application terminated".

This is probably owed the fact that gdb server pre-starts the process. (gdb has to sent a "c" (continue), instead of "r" (run)).
So it also never ends the process, only the thread(s).


The debugger could detect that, since it keeps track of all threads.
This might be useful, if you had a gdbserver that does not disconnect, but instead keeps a connection to allow the/an app to be started (again).

It would be another config optine StopOnThreadExit (actualle last-thread-exit).

But it is not important. Just a thought.

Christo Crause

2019-09-15 20:50

reporter   ~0118088

Thanks Martin, your implementation works for my case. Refactoring so that the check is done in gdbmiserverdebugger is much better than my hack!

Issue History

Date Modified Username Field Change
2019-09-14 17:34 Christo Crause New Issue
2019-09-14 17:34 Christo Crause Status new => assigned
2019-09-14 17:34 Christo Crause Assigned To => Martin Friebe
2019-09-14 17:34 Christo Crause File Added: RemoteConnectionClosed.patch
2019-09-15 18:16 Martin Friebe Note Added: 0118084
2019-09-15 18:40 Christo Crause Note Added: 0118086
2019-09-15 20:09 Martin Friebe Status assigned => feedback
2019-09-15 20:09 Martin Friebe LazTarget => -
2019-09-15 20:09 Martin Friebe Note Added: 0118087
2019-09-15 20:50 Christo Crause Note Added: 0118088
2019-09-15 20:50 Christo Crause Status feedback => assigned
2019-09-16 03:31 Martin Friebe Status assigned => resolved
2019-09-16 03:31 Martin Friebe Resolution open => fixed
2019-09-16 03:31 Martin Friebe Fixed in Version => 2.2
2019-09-16 03:31 Martin Friebe Fixed in Revision => 61886
2019-09-16 03:31 Martin Friebe LazTarget - => 2.2
2019-09-18 07:05 Christo Crause Status resolved => closed