labath wrote: > > Currently we're creating inheritable (~FD_CLOEXEC) file descriptors in the > > (few) cases where we need to pass an FD to a subprocess. The problem with > > these is that, in a multithreaded application such as lldb, there's > > essentially no way to prevent them from being leaked into processes other > > than the intended one. > > The consequences of this are what exactly? > > That the debugee may see differently numbered descriptors when run via lldb > vs. normally?
Currently, this is unlikely to impact the processes we launch for debugging for two reasons: - lldb-server is single-threaded so the main scenario I'm preventing here (a `~O_CLOEXEC` fd from one launch leaking to a different launch instance) is not possible there. - we currently have [code](https://github.com/llvm/llvm-project/blob/543f112e148a81de290d099f10784dc3ff698aa4/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp#L155) which scrubs the file descriptors for debug launches. One reason why we that code is debug-only (even though there's no reason why LaunchInfo file descriptor actions should behave differently for debug vs. non-debug launches is that we do have places which rely on this silent passing of file descriptor. This allows us to pass those explicitly, which would in theory allow us to make that cone unconditional (although I'm not entirely sure I want to do that, as I'm not particularly fond of that piece of code). In short, this is not for launches of debugged processes, but launches in general. My main inspiration for that was @slydiman's lldb-server platform refactor. (One?) reason that couldn't be done with threads was due to stray file descriptors. In this case, the problem wasn't just "extra FDs", but actual hard breakage. We had code which was waiting for an pipe EOF, but it never got that due to the FD ending up in an unsuspecting (and unrelated) process. Although that's possible to solve in a different way, I think it's still better to declare all of the FDs passed to a process explicitly. https://github.com/llvm/llvm-project/pull/126935 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
