lldb-server --min/max-gdbserver-port port map is not shared between processes on Linux #47549
Labels
Comments
trevor-m
pushed a commit
to trevor-m/llvm-project
that referenced
this issue
Apr 20, 2023
Until then, this one line fix removes the assert fail with basic block sections with debug info. Bug tracking this: llvm#47549 This fix does not generate loc list or DW_AT_const_value if the argument is mentioned in a different section than the start of the function. Temporarily fixes bugzilla : https://bugs.llvm.org/show_bug.cgi?id=47549 Differential Revision: https://reviews.llvm.org/D87787
|
This issue Linux (or if we're pedantic: posix). #90923 covers Windows which will need some extra changes to fix. |
DavidSpickett
changed the title
DavidSpickett
pushed a commit
that referenced
this issue
May 7, 2024
…8845) 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Extended Description
I have been running tests in a QEMU VM with select ports forwarded to the host machine. To do this I used the --min/max-gdbserver-port options to lldb-server.
This is what the tree looks like when I connect two lldbs to the lldb-server in qemu:
589 pts/0 T 0:01 _ ./build-cross/bin/lldb-server platform --server --listen 0.0.0.0:54321 --min-gdbserver-port 12346 --max-gdbserver-port 12347
590 pts/0 Tl 0:00 | _ ./build-cross/bin/lldb-server platform --server --listen 0.0.0.0:54321 --min-gdbserver-port 12346 --max-gdbserver-port 12347
600 pts/0 T 0:01 | | _ /mnt/virt_root/build-cross/bin/lldb-server gdbserver tcp://10.0.2.2:12346 --native-regs --pipe 6
612 pts/0 t 0:00 | | _ /mnt/virt_root/target
593 pts/0 Tl 0:00 | _ ./build-cross/bin/lldb-server platform --server --listen 0.0.0.0:54321 --min-gdbserver-port 12346 --max-gdbserver-port 12347
602 pts/0 T 0:01 | _ /mnt/virt_root/build-cross/bin/lldb-server gdbserver tcp://10.0.2.2:12346 --native-regs --pipe 6
613 pts/0 t 0:00 | _ /mnt/virt_root/target2
You can see that I'm saying only use port 12346 for spawning gdbservers. (the max is the limit, that port is not included in the range)
The processes are roughly:
the platform
process for connection 1
gdbserver for connection 1
target
process for connection 2
gdbserver for connection 2
target
You can't log out of the per connection process (#23169 ) so I added some prints. The first number is the PID.
589: Set m_port_map
589: Connection established.
589: Set m_port_map
589: Connection established.
589: Set m_port_map
590: Looking for next available port...
590: Port 12346 is free
593: Looking for next available port...
593: Port 12346 is free
590: Associating port 12346 with process 600
593: Associating port 12346 with process 602
Because the per connection process gets a fresh copy of the port map, they always think port 12346 is free and use it. Which defeats the purpose of the
option.
Weirdly, you can debug the two programs just fine. I have no idea how that works, perhaps a human typing commands is just too slow to mess it up.
If you use an API testcase you can get a single connection to spawn two gdbservers and that does fail to find a port the second time, as expected.
(though the error is confusing at best)
The cause of this is the same as #23543 I think. I don't know much about IPC but I assume moving to threads would also help share this port map correctly.
The text was updated successfully, but these errors were encountered: