dbus-daemon on Windows: Failed to bind socket "localhost:59367": Address already in use
Thomas Sondergaard
ts at medical-insight.com
Fri Jan 2 16:43:14 PST 2015
On 2015-01-02 23:17, Thomas Sondergaard wrote:
> When I run the attached test programs I get a handful or so of cases
> where the dbus-daemon fails to start with a message like
>
> Failed to bind socket "localhost:59367": Address already in use
>
> This surprises me. First I thought it was some kind of race condition
> when starting multiple buses at the same time (dbus-test.cc), but it
> also fails a handful of times out of a thousand when only one process is
> started at a time (dbus-test-nothreads.cc).
>
> This is using D-Bus Message Bus Daemon 1.8.10 on Windows.
>
> Steps to reproduce:
>
> 1. Compile the small test program on Windows
> 2. Make sure dbus-daemon is in the path
> 3. Run the test program
>
> The nothreads version takes about 4 minutes to run.
>
> Regards,
> Thomas
I've digged a little further and I think I see a bug in
_dbus_server_new_for_tcp_socket() in dbus-sysdeps-win.c. If I understand
_dbus_server_new_for_tcp_socket() it is working hard to bind the same
port on both IPv4 and IPv6. If it starts with port=0 it will do a bind
with that and then extract the port number with getsockname(), and then
it will goto redo_lookup_with_port and do the same binds again.
The bug that I'm seeing is that it is not correctly extracting the port
number that the first bind with port=0 produces. It is doing:
snprintf( portbuf, sizeof( portbuf ) - 1, "%d", addr.AddressIn.sin_port);
which fails to account for sin_port being in network byte order. The
effect is that subsequent binds will be to another "arbitrary" port that
may or may not be available.
Just adding ntohs() around addr.AddressIn.sin_port will make the
function find the correct port, but it wont work as the next bind() will
then fail with EADDRINUSE.
I compared the Windows and the Unix version of
_dbus_server_new_for_tcp_socket() and it seems that the two versions of
the functions have grown apart over time. Perhaps the unix version has
some tricks that the Windows version needs to learn?
Regards,
Thomas
More information about the dbus
mailing list