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

[Dmitry Vasilyev via lldb-commits]

slydiman wrote:

> 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)?

I mean the `--server` flag. It is very hard to reproduce this issue with the serial implementation because it is much slower.

> - thread 1 opens a file for writing (file descriptor A) and starts writing it
> - 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))
> - thread 1 finishes writing, closes fd A (in its/parent process)
> - 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

> In this scenario, waiting does make the exec succeed, because the FD in the forked process will not stay open very long. It will get closed as soon as the process runs execve (due to CLOEXEC).

Your scenario is impossible. How FD will be closed by execve() if execve() failed with ETXTBSY?

- `lldb-server platform` (a `thread 1` or just a process) creates, writes and closes the file. The FD is closed and may be reused by the system. The client lldb received the response OK for `vFile:close` request.
- The same `thread 1` launched `gdb server` (fork+execve). The FD of a created and closed file cannot be copied any way.
- The client lldb connects to `gdb server` and send the request `vRun`
- `gdb server` did not create or write the executable. It never had the FD of this file and did not inherit it. `gdb server` just fork a child process and try to call execve(), but it failed with ETXTBSY.

> `$CC hello.cc && ./a.out` could fail

May it work? How is it possible?


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