[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

[Pavel Labath via lldb-commits]

labath wrote:

That *may* be how things works on windows(*), but I'm pretty sure it's not how things work on linux. A much more likely scenario is:
1. thread 1 opens a file for writing (file descriptor A) and starts writing it
2. thread 2 starts launching a gdb server. It calls fork(), which creates another process with a copy of fd A (the fd has the CLOEXEC flag set, but not CLOFORK (the flag doesn't exist))
3. thread 1 finishes writing, closes fd A (in its/parent process)
4. thread 1launches gdb-server, gdb-server tries to launch the file it has just written, gets ETXTBSY because the fd is still open in the child process

This isn't "operating system keeping the file open longer", this is us doing it (to be fair, the operating system is making it pretty hard to avoid doing that). And while this isn't an absolute thing (the workaround isn't as bad as the `select` thing, and it may also be possible to implement this in a way that the workaround isn't needed), I think this is a good reason to prefer a multiprocess implementation (where this situation does not occur because the fd cannot leak into another process).

> All tests are green with the current (single thread) lldb-server.

Does this refer the the forking implementation you get with the `--server` flag, or the serial implementation which only handles one connection at a time (without the flag)? Because if it's the former, this is a good proof that the scenario above is the (only) problem here.

(*) I just don't know enough about the system to have an informed opinion. This isn't the first time I've heard about the antivirus hypothesis, but I find that somewhat surprising, as that could mean that something like `$CC hello.cc && ./a.out` could fail (what we're doing here isn't fundamentally different than that).

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