dbus remaining windows port issues
ralf.habacker at freenet.de
Fri Apr 30 23:19:25 PDT 2010
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
/* Do one blocking wait, since we're expecting data */
_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
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
More information about the dbus