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

[Pavel Labath via lldb-commits]

labath 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.

Ok, so if I'm reading this right you're saying you saw no ETXTBSY errors with the current implementation `--server` flag. Is that correct ?

> > * 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).

There are two threads and (at least two execve()s) happening here. I'm referring to the one on thread 2 (specifically, the fork child of thread 2).  Your description describes what happens on one thread (well, one line of execution, corresponding to one e.g.  test). Let me try this again. I'm just going to take your description, copy it twice and interleave it (*italic* is for one line of execution **bold** is for the second one, regular text is my commentary):




1. *`lldb-server platform` (a `thread 1` or just a process) creates, writes* 
2. note that at this point the file remains open in the lldb-platform process. This is going to be our mythical FD
3. **`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.**
4.  **The same `thread 1` launched `gdb server` (fork**
5. note the fork creates a new process. The process is going to have a copy of the mythical FD
6. *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.*
7. note the mythical FD is only closed in the parent process. It still exists in the fork child
8. *The same `thread 1` launched `gdb server` (fork+execve). The FD of the created and closed file cannot be copied any way.*
9. We don't need to make a copy of the fd here. The copy was made earlier.
10. *`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.*
11. We get ETXTBSY because the FD is still open in the process forked on step 4
12. **+execve). The FD of the created and closed file cannot be copied any way.**
13. The mythical fd is fully closed after the execve() call
14. *`gdb server` waits little bit and try to call execve() again. It is successful after several attempts. No one closed the mythical FD during this time.*
15. Yes, they did.


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