Target process not properly created when using `--source <file>`

[godfriedt]

When selecting a target process and selecting a script to use with lldb <executable> -s <script>, lldb will create a target process with the file descriptors 0u, 1u, and 2u. This means that the input and output operations from the executable cannot be interacted with from the lldb debugging session (scanf will not work). This differs from lldb <executable> where the file descriptors created for the process are 0r, 1w, 2w, allowing functions like scanf to read input from the lldb session.

platform: macOS Sequoia 15.0.1 (24A348)
os: Darwin 24.0.0
kernel: xnu-11215.1.12~1/RELEASE_ARM64_T6020
architecture: arm64
lldb --version: lldb-1600.0.36.3, Apple Swift version 6.0 (swiftlang-6.0.0.9.10 clang-1600.0.26.2)

[llvmbot]

@llvm/issue-subscribers-lldb

Author: godfriedt (godfriedt)

When selecting a target process and selecting a script to use with `lldb <executable> -s <script>`, lldb will create a target process with the file descriptors 0u, 1u, and 2u. This means that the input and output operations from the executable cannot be interacted with from the lldb debugging session (scanf will not work). This differs from `lldb <executable>` where the file descriptors created for the process are 0r, 1w, 2w, allowing functions like scanf to read input from the lldb session.

platform: macOS Sequoia 15.0.1 (24A348)
os: Darwin 24.0.0
kernel: xnu-11215.1.12~1/RELEASE_ARM64_T6020
architecture: arm64
lldb --version: lldb-1600.0.36.3, Apple Swift version 6.0 (swiftlang-6.0.0.9.10 clang-1600.0.26.2)

[godfriedt]

On further debugging, the problems seems to be running the run command from within a script. Additionally, I can no longer recreate errors relating to file descriptors, however, user input still isn't working.

Consider the program:

#include <stdio.h>

int main(int argc, char* argv[]) {
    int num;
    scanf("%d", &num);
    printf("num: %d\n", num);
    return 0;
}

and the following compilation and execution:

> gcc -g main.c
> lldb a.out
(lldb) run
(lldb) target create "a.out"
Current executable set to '/Users/user/sandbox/a.out' (arm64).
Process 9793 launched: '/Users/user/sandbox/a.out' (arm64)

Looking into /dev/ will show a new ttys00* file, an lsof of this file will show:

COMMAND  PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
a.out   9793 user    0r   CHR   16,3      0t0 1275 ttys003
a.out   9793 user    1w   CHR   16,3      0t0 1275 ttys003
a.out   9793 user    2w   CHR   16,3      0t0 1275 ttys003

and running ps on the a.out process shows:

  PID   TT  STAT      TIME COMMAND
 9846 s001  SX     0:00.00 /Users/user/sandbox/a.out

Now, performing the same operations on a process spawned with -s <script file> shows:

> lldb a.out -s script
(lldb) target create "a.out"
Current executable set to '/Users/user/sandbox/a.out' (arm64).
(lldb) command source -s 0 'script'
Executing commands in '/Users/user/sandbox/script'.
(lldb) run

Notice that we are not given any notification that a process was launched, however, the process does exist:

> ps aux | grep lldb
user           9934   0.0  0.5 411251088  89600 s001  S+    5:37PM   0:00.25 /Applications/Xcode.app/Contents/Developer/usr/bin/lldb a.out -s script
> pgrep -P 9934
9937
> pgrep -P 9937
9936
> ps 9936
  PID   TT  STAT      TIME COMMAND
 9936 s001  SX     0:00.00 /Users/user/sandbox/a.out

There is also still a ttys00* file in the /dev directory, performing an lsof on it will produce results similar to the previous process:

COMMAND  PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
a.out   9936 user    0r   CHR   16,3      0t0 1279 ttys003
a.out   9936 user    1w   CHR   16,3      0t0 1279 ttys003
a.out   9936 user    2w   CHR   16,3      0t0 1279 ttys003

Everything at this point seems to be the same except for the fact that the debug session will not accept any input.

[jimingham]

There's two issues here. The first one is that all the commands in a sourced command file are run in "Synchronous" mode. That means that any command that causes the target to run won't return till the target stops again. That's what you need for command files in general. If the commands were asynchronous, then you couldn't do:

step
frame var
step

since the first step in async mode will complete when the target STARTS running, so the frame var is very likely to fail with a "target is running" error.

You want async behavior for your run command, however, since you want to get I/O control before the process ever stops in the debugger. For these purposes, you can put:

script old_mode = lldb.debugger.GetAsync()
script lldb.debugger.SetAsync(True)
run
script lldb.debugger.SetAsync(old_mode)

in your command file instead.

I stepped thorough this a little bit, and we are calling {Push,Pop}ProcessIOHandler when the process starts and stops, but that doesn't seem to do anything. The other funny business that goes on when you have a sourced command file is that the CommandInterpreter switches to a "FromAFile" IOHandler and lets that handle sourcing the command file, then switches back to the interactive IOHandlerEditline after that's done. It might be that the ProcessIOHandler is getting lost in that shuffle, since it's IOHandler is made while the "FromAFile" main IOHandler is in force?

[jimingham]

BTW, it might be nice to add a --sync-mode to process launch that will let you do the little two-step I did above with just a flag.

[godfriedt]

the method described above did not work as expected.

contents of command file:

script old_mode = lldb.debugger.GetAsync()
script lldb.debugger.SetAsync(True)
run
script lldb.debugger.SetAsync(old_mode)

lldb output attempting to enter number '2':

[dokytdq@mac] sandbox % lldb a.out -s sfile
(lldb) target create "a.out"
Current executable set to '/Users/dokytdq/sandbox/a.out' (arm64).
(lldb) command source -s 0 'sfile'
Executing commands in '/Users/dokytdq/sandbox/sfile'.
(lldb) script old_mode = lldb.debugger.GetAsync()
(lldb) script lldb.debugger.SetAsync(True)
(lldb) run
Process 2841 launched: '/Users/dokytdq/sandbox/a.out' (arm64)
(lldb) script lldb.debugger.SetAsync(old_mode)
(lldb) 2
error: '2' is not a valid command.
(lldb) continue
error: Process is running.  Use 'process interrupt' to pause execution.
(lldb) process interrupt 
Process 2841 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x0000000183fa7d40 libsystem_kernel.dylib`__read_nocancel + 8
libsystem_kernel.dylib`__read_nocancel:
->  0x183fa7d40 <+8>:  b.lo   0x183fa7d60    ; <+40>
    0x183fa7d44 <+12>: pacibsp 
    0x183fa7d48 <+16>: stp    x29, x30, [sp, #-0x10]!
    0x183fa7d4c <+20>: mov    x29, sp
Target 0: (a.out) stopped.
(lldb) continue
Process 2841 resuming
num: 1
Process 2841 exited with status = 0 (0x00000000) 

not sure where num = 1 is coming from, perhaps the default value given at variable assignment, or somehow the value passed to scanf.