lldb-server --min/max-gdbserver-port port map is not shared between processes on Linux #47549
Description
| Bugzilla Link | 48205 |
| Version | 11.0 |
| OS | Linux |
| CC | @JDevlieghere,@RamNalamothu |
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.