My goal is stated in the title. However, I think there is a fundamental issue with gdbserver. In particular, I create an aarch64 alpine docker container on a x86_64 Ubuntu 16.04 host using

sudo docker run --rm -it -p 12345:12345 -v /host_dir:/container_dir --privileged arm64v8/alpine /bin/ash

I then proceed to install gdb in the container using apk add gdb. Subsequently I run ps aux just to get a list of the processes running in the container in order to test gdbserver --attach COMM...PID command in the container. Interestingly absolutely no output no matter how much time goes on. As a result, I switch to the host and simply do the same exercise on the Ubuntu machine, i.e., I attach to a random process with pid 23056. The output to gdbserver --attach :12344 23056 is Attached; pid = 23056 Listening on port 12344, which is what I expected to happen with gdbserver in the container. Any help as to why gdbserver in the container doesn't behave properly is appreciated!


I tried again and first ran sudo docker run --rm -it --privileged -p 7777:7777 -v home_dir:container_dir arm64v8/alpine and then ran gdbserver localhost:7777 ./binary and then as suggested in the comments I used netstat -l in the container and got tcp 0 0* LISTEN. So it seems that clearly gdbserver is listening for a tcp connection. Then I use gdb-multiarch binary on the host machine and then (gdb) target remote localhost:7777 to get:

Remote debugging using localhost:7777

Ignoring packet error, continuing...

warning: unrecognized item "timeout" in "qSupported" response

Ignoring packet error, continuing...

Remote replied unexpectedly to 'vMustReplyEmpty': timeout

Any idea?!


I ran the docker container without the --publish or -p attribute and clearly no matter what IP:PORT I use, gdb-multiarch says the Connection timed out.

  • Have you confirmed that it is indeed not listening on the port? I seem to recall not always having output. Have you tried debugging the debugger? Maybe try strace on gdbserver? – multithr3at3d Dec 3 '20 at 0:30
  • @multithr3at3d Thank you for the comment. Did you also run gdbserver in a docker? As my name says, I'm a newbie and I haven't yet made sure that in fact it is listening or not. I'm thinking maybe I set the docker wrong or I'm just not passing the correct IP:PORT to the target remote command of gdb-multiarch to connect to gdbserver. Basically, I don't feel sure about the connection between the container and the host. Can you comment on that. Also, do you see anything wrong with the docker command? – Newbie Dec 3 '20 at 0:36
  • Haven't used it in Docker, no. In the container, try ss or netstat with -l to see if it's listening on that port. What args are you passing to target remote? – multithr3at3d Dec 3 '20 at 0:45
  • So this is what I just did inside the docker: gdbserver :7778 binary and in another terminal (still in container) I did netstat -l and I got Proto Recv-Q Send-Q Local Address Foreign Address State: tcp 0 0* LISTEN. So I guess gdbserver is actually listening! On the host I have gdb-multiarch binary and then (gdb) target remote localhost:7778 and after a few seconds I get localhost:7778: Connection timed out. It seems that I have the connection between the host and the docker messed up! Right? – Newbie Dec 3 '20 at 0:55
  • Well that's good news! Are there firewall rules that would block inbound connections to loopback? Alternatively, if you don't use --privileged, you could maybe specify the address of the container itself. – multithr3at3d Dec 3 '20 at 0:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.