yes, the issue is AI generated, i already used 4h of my life battling it.
Environment
- Eclipse CDT 2026-03 (4.39.0)
- Eclipse Docker Tooling 5.22.0
- org.eclipse.cdt.docker.launcher 2.1.700
- org.mandas.docker-client 10.0.0
- Docker Engine 29.5.0 (API 1.52)
- Linux (Ubuntu 24.04)
Problem
The "C/C++ Docker Container Launch" debug configuration hangs indefinitely after gdbserver starts in the container. GDB is never launched on the host.
Root Cause
ContainerLaunchConfigurationDelegate$StartGdbServerJob.getIpAddress() reads the container IP from IDockerContainerInfo.networkSettings().ipAddress(), which maps to the top-level NetworkSettings.IPAddress field in Docker's inspect response.
Docker Engine 29.0.0 removed this field (deprecated since Docker 1.13 via moby/moby#28437, removed in moby/moby#50846). The IP address is now only available in NetworkSettings.Networks.<network_name>.IPAddress.
Since the top-level field returns null, the StartGdbServerJob polling loop never terminates, and GDB is never started.
Reproduction
- Install Docker Engine 29+
- Create a C/C++ Docker Container Launch debug config
- Launch debug → gdbserver starts, output shows "Listening on port 2345"
- Eclipse hangs forever — no GDB process is started
Verification
# Docker 29 returns null for top-level IPAddress:
docker run -d --rm --name test alpine sleep 60
docker inspect test | python3 -c "
import json,sys
ns=json.load(sys.stdin)[0]['NetworkSettings']
print('Top-level:', repr(ns.get('IPAddress'))) # None
print('Networks.bridge:', repr(ns['Networks']['bridge']['IPAddress'])) # '172.17.0.2'
"
docker rm -f test
Suggested Fix
In DockerNetworkSettings, fallback to Networks map when ipAddress() is null:
public String ipAddress() {
if (this.ipAddress != null && !this.ipAddress.isEmpty()) {
return this.ipAddress;
}
// Fallback for Docker Engine 29+ where top-level field was removed
if (this.networks != null) {
for (var entry : this.networks.entrySet()) {
String ip = entry.getValue().ipAddress();
if (ip != null && !ip.isEmpty()) {
return ip;
}
}
}
return this.ipAddress;
}
Workaround
Use a Unix socket proxy that forces API version 1.43, which makes Docker return the legacy format with the top-level IPAddress field populated:
# Proxy rewrites requests to /v1.43/... forcing Docker to respond with legacy format
# Listen on /var/run/docker-eclipse.sock, forward to /var/run/docker.sock
# Then configure Eclipse Docker connection to use the proxy socket
Related
- moby/moby#28437 — deprecate top-level network info (Docker 1.13, 2016)
- moby/moby#50846 — remove
NetworkSettingsBase and DefaultNetworkSettings (Docker 29.0.0)
- moby/moby#50848 — deprecate
NetworkSettingsBase.Bridge and DefaultNetworkSettings fields
yes, the issue is AI generated, i already used 4h of my life battling it.
Environment
Problem
The "C/C++ Docker Container Launch" debug configuration hangs indefinitely after gdbserver starts in the container. GDB is never launched on the host.
Root Cause
ContainerLaunchConfigurationDelegate$StartGdbServerJob.getIpAddress()reads the container IP fromIDockerContainerInfo.networkSettings().ipAddress(), which maps to the top-levelNetworkSettings.IPAddressfield in Docker's inspect response.Docker Engine 29.0.0 removed this field (deprecated since Docker 1.13 via moby/moby#28437, removed in moby/moby#50846). The IP address is now only available in
NetworkSettings.Networks.<network_name>.IPAddress.Since the top-level field returns
null, theStartGdbServerJobpolling loop never terminates, and GDB is never started.Reproduction
Verification
Suggested Fix
In
DockerNetworkSettings, fallback toNetworksmap whenipAddress()is null:Workaround
Use a Unix socket proxy that forces API version 1.43, which makes Docker return the legacy format with the top-level
IPAddressfield populated:Related
NetworkSettingsBaseandDefaultNetworkSettings(Docker 29.0.0)NetworkSettingsBase.BridgeandDefaultNetworkSettingsfields