-o "process launch" and stdio forwarding

Hi all,

I have noticed that after starting a debug session with -o “process launch”, the standard input does not get forwarded to the debugged process. Is this the indented behavior (not forwarding stdio when debugging with a script), or a bug? I would consider it a bug, because it means I can’t just start the debug session from the command line and wait for the bug to occur if I need to give input to the application for the bug to manifest.


That's clearly a bug, after all process launch has separate settings for stdio/stdout/stderr, which makes no sense if you can't set them independently.


This is a bug. It works on MacOSX, so this will be something we need to fix for Linux. The question is: is this with lldb-server or with the ProcessLinux?


Thanks for the replies.

On Linux, I was testing this with lldb-server. But actually, this does not work on Mac either. That is why I was unsure and wanted to double check the expected behavior. You can reproduce it like this:

labath-macbookair ~/ll/lldb/DerivedData $ cat a.cc


int main() {

std::string s;

std::cin >> s;

std::cout << "Read: " << s << std::endl;


labath-macbookair ~/ll/lldb/DerivedData $ clang++ a.cc

labath-macbookair ~/ll/lldb/DerivedData $ ./a.out


Read: asdf

labath-macbookair ~/ll/lldb/DerivedData $ lldb/Build/Products/Debug/lldb ./a.out -o “process launch”

(lldb) target create “./a.out”

Current executable set to ‘./a.out’ (x86_64).

(lldb) process launch



^CProcess 22694 stopped

  • thread #1: tid = 0x434ef4, 0x00007fff8df928ea libsystem_kernel.dylib`__read_nocancel + 10, queue = ‘com.apple.main-thread’, stop reason = signal SIGSTOP

Since we seem to agree that this is a bug, I will try to find a solution to fix it.



Works fine for me on Mac:

% lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) process launch
Process 22983 launched: '/private/tmp/a.out' (x86_64)
Read: carp
Process 22983 exited with status = 0 (0x00000000)

The trick is that you need to start the process from the command line, via the -o “process launch” argument.


Ahhh, I see this now. The process should be pushing an input reader onto the stack, but it must not do that if we use "-o" for some reason. All commands from "-o" and "-O" as well as any implicit target create from specifying a target from the command line will be put into a pipe and then info a "FILE *" in:

        FILE *commands_file = PrepareCommandsForSourcing (commands_data, commands_size, initial_commands_fds);
        if (commands_file)

Then we run the command interpreter with this "commands_file" as the debugger input, then it exits and we enter again using:


This will exit when all items from the "commands_file" have been consumed. Then later we set the debugger's input file handle to stdin and run again:

    if (go_interactive)
        m_debugger.SetInputFileHandle (stdin, true);
        m_debugger.RunCommandInterpreter(handle_events, spawn_thread);
The one thing I do know about is that when m_debugger.RunCommandInterpreter exits, it always shuts down the event thread and then it restarts it when m_debugger.RunCommandInterpreter is run again. This might be responsible somehow.

The process will push its input reader on top to the IOHandler stack so it can get user input and pass it to the function. This is done in:


Check to see how and if this is being called and also watch for calls to:


This shouldn't be too hard to track down.