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