Re: dbus-daemon on Windows: Failed to bind socket "localhost:59367": Address already in use
Thomas Sondergaard <ts-2vlBz+Gd9o2sRyR5/[email protected]>
| Newsgroups | gmane.comp.freedesktop.dbus |
|---|---|
| Message-ID | <[email protected]> |
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 _______________________________________________ dbus mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/dbus