The new instance of QEMU executed on the behalf of the forked process tries to run gdbserver on the same port as its parent.

[cedric-vincent]

Details: https://groups.google.com/forum/?fromgroups#!topic/proot_me/ev2rS7kma30

[cedric-vincent]

For the record, here is how to reproduce the problem:

    host$ proot -Q 'qemu-arm -g 1234' /path/to/arm/rootfs
    # waiting for GDB client ... connected

    guest$ /usr/bin/echo "Hello world"
    bind: Address already in use
    qemu: could not open gdbserver on port 1234

[cedric-vincent]

The following solution works with QEMU 1.0 and later only. First, ask
to each instance of QEMU to unset the QEMU_GDB environment variable:

    proot -Q 'qemu-arm -U QEMU_GDB' ...

Then, set this variable to the expected port number right before
executing the program you want to debug. For examples:

• to debug the first process (parent):

    env QEMU_GDB=1234 proot -Q 'qemu-arm -U QEMU_GDB' ...
    # waiting for GDB client

• to debug a process launched interactively (or in a script):

    host$ proot -Q 'qemu-arm -U QEMU_GDB' ...

    guest$ /usr/bin/echo "Hello world"
    Hello world

    guest$ env QEMU_GDB=1234 /usr/bin/echo "Hello world"
    # waiting for GDB client

• to debug a child process: add a call to setenv() before the call
  to exec(). It's a bit intrusive in this case but it's a reliable
  solution.

It works because QEMU 1.0+ handles options passed through environment
variable before command-line options, thus QEMU_GDB is unset after
being used by QEMU itself. Finally, only the first QEMU instance that
sees this variable is affected. Note that it works with any QEMU
options (see qemu-arm -h).