[Lldb-commits] [lldb] [lldb-dap] Ensure the IO forwarding threads are managed by the DAP object lifecycle. (PR #120457)

[John Harrison via lldb-commits]

ashgti wrote:

I'm running into an issue on linux with this change that is resulting in 2 instances of the `lldb_private::FileSystem::Instance` being created. 

```
$ lldb lldb-dap
(lldb) break set -f FileSystem.h -l 51
...

Process 1743394 resuming
/usr/bin/../lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/14/optional:475: _Tp &std::_Optional_base_impl<lldb_private::FileSystem, std::_Optional_base<lldb_private::FileSystem, false, false>>::_M_get() [_Tp = lldb_private::FileSystem, _Dp = std::_Optional_base<lldb_private::FileSystem, false, false>]: Assertion 'this->_M_is_engaged()' failed.
Process 1743394 stopped
* thread #1, name = 'lldb-dap', stop reason = signal SIGABRT
    frame #0: 0x00007fffec0a53ac libc.so.6`__pthread_kill_implementation(threadid=<unavailable>, signo=6, no_tid=<unavailable>) at pthread_kill.c:44:76
(lldb) bt
* thread #1, name = 'lldb-dap', stop reason = signal SIGABRT
  * frame #0: 0x00007fffec0a53ac libc.so.6`__pthread_kill_implementation(threadid=<unavailable>, signo=6, no_tid=<unavailable>) at pthread_kill.c:44:76
    frame #1: 0x00007fffec0564f2 libc.so.6`__GI_raise(sig=6) at raise.c:26:13
    frame #2: 0x00007fffec03f4ed libc.so.6`__GI_abort at abort.c:79:7
    frame #3: 0x00007fffec2d501e libstdc++.so.6`std::__glibcxx_assert_fail(char const*, int, char const*, char const*) + 94
    frame #4: 0x00005555555d255d lldb-dap`lldb_private::FileSystem::Instance() [inlined] std::_Optional_base_impl<lldb_private::FileSystem, std::_Optional_base<lldb_private::FileSystem, false, false>>::_M_get(this=<unavailable>) at optional:475:2
    frame #5: 0x00005555555d253e lldb-dap`lldb_private::FileSystem::Instance() [inlined] std::optional<lldb_private::FileSystem>::operator*(this=<unavailable>) & at optional:972:22
    frame #6: 0x00005555555d253e lldb-dap`lldb_private::FileSystem::Instance() at FileSystem.cpp:45:45
    frame #7: 0x000055555558fd7f lldb-dap`lldb_dap::DAP::ConfigureIO(this=<unavailable>, overrideOut=<unavailable>, overrideErr=<unavailable>) at DAP.cpp:183:17
    frame #8: 0x000055555556d479 lldb-dap`main(argc=<unavailable>, argv=<unavailable>) at lldb-dap.cpp:5109:22
    frame #9: 0x00007fffec040c8a libc.so.6`__libc_start_call_main(main=(lldb-dap`main at lldb-dap.cpp:4960), argc=1, argv=0x00007fffffffda98) at libc_start_call_main.h:58:16
    frame #10: 0x00007fffec040d45 libc.so.6`__libc_start_main_impl(main=(lldb-dap`main at lldb-dap.cpp:4960), argc=1, argv=0x00007fffffffda98, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffda88) at libc-start.c:360:3
    frame #11: 0x000055555556c5f1 lldb-dap`_start + 33

(lldb) break list
Current breakpoints:
1: file = 'FileSystem.h', line = 51, exact_match = 0, locations = 3, resolved = 3, hit count = 2
  1.1: where = liblldb.so.20.0git`lldb_private::SystemInitializerCommon::Initialize() + 23 [inlined] void lldb_private::FileSystem::Initialize<>() at FileSystem.h:51:5, address = 0x00007fffed8c6be7, resolved, hit count = 1 
  1.2: where = liblldb.so.20.0git`lldb_private::SystemInitializerCommon::Initialize() + 32 [inlined] void lldb_private::FileSystem::Initialize<>() + 9 at FileSystem.h:51:5, address = 0x00007fffed8c6bf0, resolved, hit count = 1 
  1.3: where = liblldb.so.20.0git`lldb_private::SystemInitializerCommon::Initialize() + 252 [inlined] void lldb_private::FileSystem::Initialize<>() at FileSystem.h:51:5, address = 0x00007fffed8c6ccc, resolved, hit count = 0 
```

I think I've ended up with a second instance of FileSystem.h by referencing it in lldb-dap. I don't see errors like this on macOS, but that may be due to linker differences. I was using the `FileSystem().Fopen()` call to open `/dev/null` for the SBDebugger input handle.

I know in my other pull request we talked about linking against lldb/host for some utilities like the use of Pipe, but is this an issue with the current architecture? Should I avoid that Host/FileSystem API or will I run into this with other APIs potentially?

https://github.com/llvm/llvm-project/pull/120457