eclipse-cdt-cloud / eclipse-cdt-cloud/cdt-gdb-adapter
`isRunning` unreliable
- Dominant language
- TypeScript
- Stars
- 39
- Forks
- 56
- Avg merge
- 3d 9h
- Merged PRs (30d)
- 2
Description
The `GDBDebugSession` maintains a [state `isRunning`](https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/blob/cd740cd0a72f1be57363ccfe07e21a63a6970dbe/src/GDBDebugSession.ts#L178) and guards various actions depending on that value. However, a synchronous check of that value isn't guaranteed to accurately reflect GDB's state by the time it tries to process an MI command: some other part of the adapter code could have issued a `continue` command without GDB having yet emitted the event indicating that it has continued.
I'd suggest that we implement something like a `tryIfNotRunning` method along the following lines:
```typescript
protected async tryIfNotRunning(
action: () => Promise,
defaultValue: U
): Promise {
if (this.isRunning) {
return defaultValue;
}
try {
return await action();
} catch (err) {
if (
err instanceof Error &&
err.message.includes('target is running')
) {
return defaultValue;
}
throw err;
}
}
```
That would centralize the handling of the error that such and such a command can't be handled while the target is running. I bet we could clean up the types a bit, too, for ergonomics.
Contributor guide
Research direction
Start in src/GDBDebugSession.ts at the isRunning state and inspect the actions that use it to guard MI commands. Trace how the adapter reports the “target is running” error and identify the affected callers before deciding how to centralize handling. Done means those actions handle a race between isRunning and GDB’s actual state without masking unrelated errors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- devtools
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100