mirror of
https://github.com/llvm/llvm-project.git
synced 2025-04-25 06:16:05 +00:00
6aed0ab654
Fixes #47549 `lldb-server`'s platform mode seems to have an issue with its `--min-gdbserver-port` `--max-gdbserver-port` flags (and probably the `--gdbserver-port` flag, but I didn't test it). How the platform code seems to work is that it listens on a port, and whenever there's an incoming connection, it forks the process to handle the connection. To handle the port flags, the main process uses an instance of the helper class `GDBRemoteCommunicationServerPlatform::PortMap`, that can be configured and track usages of ports. The child process handling the platform connection, can then use the port map to allocate a port for the gdb-server connection it will make (this is another process it spawns). However, in the current code, this works only once. After the first connection is handled by forking a child process, the main platform listener code loops around, and then 'forgets' about the port map. This is because this code: ```cpp GDBRemoteCommunicationServerPlatform platform( acceptor_up->GetSocketProtocol(), acceptor_up->GetSocketScheme()); if (!gdbserver_portmap.empty()) { platform.SetPortMap(std::move(gdbserver_portmap)); } ``` is within the connection listening loop. This results in the `gdbserver_portmap` being moved into the platform object at the beginning of the first iteration of the loop, but on the second iteration, after the first fork, the next instance of the platform object will not have its platform port mapped. The result of this bug is that subsequent connections to the platform, when spawning the gdb-remote connection, will be supplied a random port - which isn't bounded by the `--min-gdbserver-port` and `--max-gdbserver--port` parameters passed in by the user. This PR fixes this issue by having the port map be maintained by the parent platform listener process. On connection, the listener allocates a single available port from the port map, associates the child process pid with the port, and lets the connection handling child use that single port number. Additionally, when cleaning up child processes, the main listener process tracks the child that exited to deallocate the previously associated port, so it can be reused for a new connection.