Possible poll-related problem in dbus-0.92

[Julian Seward]

I've been running a bunch of KDE4 code through Valgrind, hence exercising
dbus-0.92 too.  The following is with KDE4 from svn, dbus-0.92 unmodified,
running on x86-linux, and using the just-about-to-be released
valgrind-3.2.1.  I am running the entire process tree for a KDE session
on valgrind.

Under obscure circumstances, V reports uninitialised value uses in
unix_do_iteration() in dbus-transport-unix.c, line 1053:

              if (need_write && (flags & DBUS_ITERATION_DO_WRITING))
                do_writing (transport);

Upon investigation, it seems to me that dbus is depending on a boundary
case of poll() which is poorly specified by POSIX.  I am not saying that
dbus necessarily has a bug, nor that valgrind is being too strict; but
it does appear that dbus and valgrind disagree, and from reading the POSIX
specification for poll() it's not clear what should happen.  See 
http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html for the POSIX
spec.

The problem case is when poll() (hence _dbus_poll) returns zero.  At 
dbus-transport-unix.c:1032 we have 

      if (poll_res >= 0)
        {
           /* poke around in the .revents field of the pollfd structure */
        }

As currently set up, valgrind's handler for poll() does not mark the .revent
fields as defined in the case where poll returned zero (meaning no file
descriptors were ready).  Is that a bug?  I don't know.  It could be argued
that dbus should not look at the .revents field in this case.

I suspect Valgrind is being too conservative here; but given that this is
a boundary case you could easily ignore - do nothing if poll_res == 0 - and
given that presumably portability is a goal, maybe you'd want to handle this
rather than rely on implementations setting .revents to zero in the case where
poll returns zero.

J