dbus-daemon closing connection?
sith.list at gmail.com
Mon Apr 16 17:12:05 PDT 2007
Ok it turned out to be someone writing to the wrong fd!
Posting this just for making sure the archives have the complete story.
On 4/14/07, Krishna R <sith.list at gmail.com> wrote:
> So indeed this turned out to be true. The daemon is getting something bad
> (an invalid message) from my process B.
> Turning debug verbose on the daemon shows this...
> 289: handling read watch 0xcfe30 flags = 1
> 289: do_reading: fd = 6
> 289: check_read_watch: fd = 6
> 289: setting read watch enabled = 1
> 289: UNLOCK: protected_change_watch
> 289: LOCK: protected_change_watch
> 289: read 844 bytes
> 289: Initial peek at header says we don't have a whole message yet, or
> data broken with invalid code 13
> 289: Corrupted message stream, disconnecting
> 289: _dbus_transport_disconnect start
> 289: socket_disconnect
> Since my process B just handles the filter message and does not send
> anything, i can only think of two things...
> 1. Some thread in my process has a socket descriptor wrong, hence is
> dumping things by mistake into the dbus socket fd.
> 2. There is some bug in dbus code, that is sending this invalid message.
> To rule out 2. i have a question that may be someone can help with.
> If we assume process B just has code to set an addmatch and recv a signal
> If the daemon passes a signal message to B, B does not have to ack or send
> anything back correct?. It should just get the message and handle it and go
> its way. When things work correctly i see this is indeed the case, the
> daemon sends something and does not hear back from Process B.
> The whole thing seems to be very time sensitive w.r.t process B, if
> dbus_verbose is turned on B this does not happen.
> On 4/11/07, Thiago Macieira <thiago at kde.org> wrote:
> > Krishna R wrote:
> > >Further probing lead to disconnect signal being the cause of
> > > do_io_error() in dbus-transport-socket.c, it was called because
> > > do_reading() which reads from the socket and gets bytes_read = 0. That
> > > means the socket was closed on the other end?
> > Yes.
> > >The question i have is why is the dbus-daemon closing the socket? Or is
> > > it?
> > It is and it does so because it received an invalid message. If you
> > strace
> > the daemon or if you run it in debug mode, it should say why it did
> > that.
> > >dbus-daemon, A and B are started one after another at boot in the
> > >foreground. Is there some problem where the session bus is not fully
> > >initialized? That may not be because atleast one signal from A reaches
> > > B.
> > I don't think so.
> > --
> > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> > PGP/GPG: 0x6EF45358; fingerprint:
> > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dbus