[lldb] python API SBDebugger.GetOutputFileHandle() returns a file handle with the wrong mode for stdout/stderr

[ashgti]

It looks like when lldb initializes the default OutputFileHandle and ErrorFileHandle on a new debugger instance it is not setting the handles as writable (mode='w').

Here is a simple python script using the lldb module to illustrate this:

import lldb

dbg = lldb.SBDebugger.Create()

print("output", dbg.GetOutputFileHandle()) #> output <_io.TextIOWrapper name=1 mode='r' encoding='UTF-8'>
print("error", dbg.GetErrorFileHandle()) #> error <_io.TextIOWrapper name=2 mode='r' encoding='UTF-8'>

I think this is happening because:

• Debugger initializes with a FILE*

  llvm-project/lldb/source/Core/Debugger.cpp

  Line 878 in ba704d5

  m_output_stream_sp(std::make_shared<StreamFile>(stdout, false)),

• Calling into this StreamFile constructor https://github.com/llvm/llvm-project/blob/ba704d59569151f1b8b6552ed22a7b840f5e6256/lldb/include/lldb/Host/StreamFile.h#L31C3-L31C13
• That calls into NativeFile

  llvm-project/lldb/source/Host/common/StreamFile.cpp

  Line 30 in ba704d5

  m_file_sp = std::make_shared<NativeFile>(fh, transfer_ownership);

• That sets the options to options()

  llvm-project/lldb/include/lldb/Host/File.h

  Line 384 in ba704d5

  m_options(), m_own_stream(transfer_ownership) {}

• That is initialized to 'r' mode by default

  llvm-project/lldb/include/lldb/Host/File.h

  Line 51 in ba704d5

  eOpenOptionReadOnly = 0x0, // Open file for reading (only)

However, stdout and stderr should be set to mode='w' by default.

[llvmbot]

@llvm/issue-subscribers-lldb

Author: John Harrison (ashgti)

Details

It looks like when lldb initializes the default OutputFileHandle and ErrorFileHandle on a new debugger instance it is not setting the handles as writable (mode='w').

Here is a simple python script using the lldb module to illustrate this:

import lldb

dbg = lldb.SBDebugger.Create()

print("output", dbg.GetOutputFileHandle()) #> output <_io.TextIOWrapper name=1 mode='r' encoding='UTF-8'>
print("error", dbg.GetErrorFileHandle()) #> error <_io.TextIOWrapper name=2 mode='r' encoding='UTF-8'>

I think this is happening because:

• Debugger initializes with a FILE*

  llvm-project/lldb/source/Core/Debugger.cpp

  Line 878 in ba704d5

  m_output_stream_sp(std::make_shared<StreamFile>(stdout, false)),

• Calling into this StreamFile constructor https://github.com/llvm/llvm-project/blob/ba704d59569151f1b8b6552ed22a7b840f5e6256/lldb/include/lldb/Host/StreamFile.h#L31C3-L31C13
• That calls into NativeFile

  llvm-project/lldb/source/Host/common/StreamFile.cpp

  Line 30 in ba704d5

  m_file_sp = std::make_shared<NativeFile>(fh, transfer_ownership);

• That sets the options to options()

  llvm-project/lldb/include/lldb/Host/File.h

  Line 384 in ba704d5

  m_options(), m_own_stream(transfer_ownership) {}

• That is initialized to 'r' mode by default

  llvm-project/lldb/include/lldb/Host/File.h

  Line 51 in ba704d5

  eOpenOptionReadOnly = 0x0, // Open file for reading (only)

However, stdout and stderr should be set to mode='w' by default.

[DavidSpickett]

These handles are to the stdout/stderr of the debugger instance, rather than the program being debugged, right?

(as it would make sense that the debugee's output streams are read only)

[ashgti]

Correct, this is where the debugger is writing output.

The reason this might be an issue is if you have a python script component and try to do something like:

print("Hello world", file=debugger.GetOutputFileHandle())

If the debugger is using the default stdout / stderr then the file handle is considered 'r' not 'w' so the print fails.

[jimingham]

Sadly, all our tests do SetOutputFileHandle first (because it's a pain to grub the test binary's stdout) so this wasn't noticed. And unless you change it programmatically, the Python script interpreter is going the same place as the debugger output, so I bet very few people go specifically to the debugger's output. Still, someone should fix this and add a test for the default file handle from the debugger.

As a side note, if you are writing lldb commands in Python, you should be writing to the command's return object not to the debugger stdout.

[ashgti]

I have some scripts that are running some operations in a background thread, I'm mostly using the debugger.GetErrorFileHandle() to be able to write an error message if something fails in the background. I think by that point the result: lldb.SBCommandReturnObject object would have been cleaned up.