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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
