Bug in _dbus_poll() without HAVE_POLL?

[Tor Lillqvist]

Havoc Pennington writes:
 > In applying this I noticed that the same bug appears *after* the
 > call to select()

Yes, that was what I was referring to. Using a copy of the DBusPollFD
array elements in the loop *before* the call to select() isn't a bug,
as there is no attempt to modify the passed-in DBusPollFD array
there. (But for consistency, sure, why not use a pointer instead of a
copy there, too.)

 > Did this now (a bit belated) and it also breaks for me. 

Good to hear ;-)

 > Looks like it could be some pain with dbus-spawn.c; 

Hmm, I obviously use a quite rewritten dbus-spawn-win32.c, that's the
part of D-BUS which was most Unix-specific with all the forking going
on. The child_setup is problematic on Windows, as there is no fork(),
so it would run in the same process.

But if the only use for that is setting up the environment variables
in the child in bus_activation_activate_service(), a workaround is to
add an envp parameter to _dbus_spawn_async_with_babysitter(). One then
manually sets up a modified copy of _environ, and that will be passed
to execve() (spawnve() on Windows), instead of calling putenv() in a
child_setup.

 > I'd be suspicious of cases that involve POLLHUP.

Yes, the handling of POLLHUP might be problematic. If I understand
correctly the select() branch of_dbus_poll() ignores polling for just
_DBUS_POLLHUP, and never sets _DBUS_POLLHUP in revents. Haven't digged
any deeper into the ramifications of that yet.

Last night I got bus-test to run successfully on Windows, as long as
bypassed the check_get_connection_unix_user(). And there is one leaked
malloc block from somewhere in the final test, sigh.

--tml