| Issue |
175652
|
| Summary |
[LLDB] Prompt not shown after breakpoint is hit on Windows
|
| Labels |
lldb,
platform:windows
|
| Assignees |
|
| Reporter |
Nerixyz
|
When a breakpoint is hit, LLDB doesn't show the prompt if there was previous input on the console (previous LLDB commands have been executed).
You can reproduce this as follows:
Pick any executable you want to debug (with a `main` function).
Then, create a breakpoint at `main` and run the program with LLDB. Most importantly, the `r` must be typed in LLDB (not through `-o`):
```console
> lldb test.exe
(lldb) target create "test.exe"
Current executable set to 'F:\Dev\dump\test.exe' (x86_64).
(lldb) b main
Breakpoint 1: where = test.exe`main + 9 at test.cpp:2, address = 0x0000000140001009
(lldb) r
Process 23876 launched: 'F:\Dev\dump\test.exe' (x86_64)
Process 23876 stopped
* thread #1, stop reason = breakpoint 1.1
frame #0: 0x00007ff767231009 test.exe`main at test.cpp:2
1 int main() {
-> 2 return 0;
3 }
bt
(lldb) error: 'thread select' takes exactly one thread index argument, or a thread ID option:
Usage: thread select <thread-index> (or -t <thread-id>)
(lldb)
```
There are two issues here:
- There's no prompt after the breakpoint is hit
- The first character of the prompt is eaten (`t` was executed above)
Both have the same cause. When the process is running, we're forwarding the stdin of LLDB to the process. For Windows, this is done in [`IOHandlerProcessSTDIOWindows`](https://github.com/llvm/llvm-project/blob/5334c5148637dc58ae0e527b7b2c7c0569542271/lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp#L951). It reads from the stdin handle and writes to the ConPTY input. The stdin handle is a console handle.
If there was previous input on the console that was handled by other IOHandlers (namely `IOHandlerEditline`) and C functions like `fgets`, then the stdin handle still has pending console input (at least one key-up event). This causes the `WaitForMultipleObjects` [here](https://github.com/llvm/llvm-project/blob/5334c5148637dc58ae0e527b7b2c7c0569542271/lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp#L991) to return immediately with `WAIT_OBJECT_0`. We then do a `ReadFile` on the stdin handle [here](https://github.com/llvm/llvm-project/blob/5334c5148637dc58ae0e527b7b2c7c0569542271/lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp#L998). This will block, because there isn't any _text_ input.
In the above example, the `ReadFile` call will block the prompt from being shown, and it will eat the first character of the command.
I'm not sure what the proper way of forwarding the host stdin to the ConPTY is. [Microsoft's example uses `ReadFile` and `WriteFile` too](https://github.com/microsoft/terminal/blob/673d4eb4971f0d14d5c7470a828fa940cb192af4/samples/ConPTY/EchoCon/EchoCon/EchoCon.cpp#L167-L189). But they don't wait on the stdin handle. If I understand correctly, then we can't just use `WriteConsoleInput` on the ConPTY input (we'd also need to take out initial key-up events).
cc @charles-zablit
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
