dbus remaining windows port issues

[Ralf Habacker]

Romain Pokrzywka schrieb:
> Hi Ralf,
>
> Thanks a lot for those. I've had another look at the hanging issue and I've isolated it to be the call to select() in 
> dbus-sysdeps-win.c :
>
>   ready = select (max_fd + 1, &read_set, &write_set, &err_set,
>                   timeout_milliseconds < 0 ? NULL : &tv);
>
> Since there's no timeout the function hangs forever. However the no timeout isn't really the problem, as the socket 
> should eventually have something but doesn't for some reason. And as you observed the hanging is random, and varies from 
> one run of bus-test to another, but usually during the iteration tests, when connections are repeatedly created.
>   
There is code which let select block, see below. 
> I'm wondering if that's a bug in Winsock or if we're exhausting a system resource, or something else. There's only one 
> thread during the test so we can rule out race conditions at least. I'll try to google for similar issues with winsock 
> and select() during the weekend, maybe somebody else hit that issue and hopefully has a workaround.
>
> For the interested, here's a sample backtrace taken during one of the hangs :
>
>  	bus-test.exe!_dbus_poll(DBusPollFD * fds=0x00f1fb74, int n_fds=4, int timeout_milliseconds=-1)  Line 1135 + 0x3c bytes	C
>  	bus-test.exe!_dbus_loop_iterate(DBusLoop * loop=0x000ea1d0, unsigned int block=1)  Line 708 + 0x17 bytes	Cbus-test.exe!bus_test_run_bus_loop(BusContext * context=0x000e4d50, unsigned int block_once=1)  Line 275 + 0x14 bytes	C
>
>   
Sometime it helped to set block_once=0  in bus_test_run_bus_loop () 
before the following block and/or at the same place in 
bus_test_run_clients_loop().

  /* Do one blocking wait, since we're expecting data */
  if (block_once)
    {
      _dbus_verbose ("---> blocking on \"server side\"\n");
      _dbus_loop_iterate (bus_context_get_loop (context), TRUE);
    }

My assumption is that there are some tcp data sent by either the server 
or the client, but they did not arrive on the other side and select 
blocks. From my imagination i can think about one or more of the 
following reasons:
1. There may be a timing problem - it may help to identify to set 
DBUS_VERBOSE and to redirect error log to a file
2. There may be an winsock issue because the two ends of the socket are 
in the same application.
3. There may be a buffer related problem, which results in holding back 
tcp data

Regards
 Ralf