dbus-daemon closing connection?

[Krishna R]

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
and
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.

Thanks.
-K


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
>
>


-- 
P.R.Krishna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20070414/775a9ffa/attachment.html