Clients seeing EPIPE, dbus-daemon 1.8.16, how to debug?

[Andrey Sidorov]

In node-dbus I buffer all outgoing messages until underlying transport
stream is established and then send them all at once. My guess was that
EPIPE is caused by not checking backpressure properly

On Wed, Jun 3, 2015 at 9:48 AM, Chris Morgan <chmorgan at gmail.com> wrote:

> On Tue, Jun 2, 2015 at 4:37 PM, Thiago Macieira <thiago at kde.org> wrote:
> > On Monday 01 June 2015 21:21:16 Chris Morgan wrote:
> >> Hello.
> >>
> >> I'm using dbus-daemon on a systemd distro built under yocto on an arm
> >> system, a BBB (1GHz Arm), 512MB ram, emmc.
> >>
> >> At startup we've got two clients, one c# using dbus-sharp, and another
> >> nodejs using node-dbus (https://github.com/sidorares/node-dbus) that
> >> are both seeing EPIPE from the dbus client socket as reported via
> >> strace.
> >
> > For real pipes, EPIPE indicates that you're writing while there's no pipe
> > reader. For sockets, that happens only when a connected socket's peer
> has shut
> > down reception. In other words, the socket has disconnected.
> >
> > dbus-daemon only disconnects you if you send invalid stuff. So I advise
> you to
> > check those two bindings for protocol correctness.
> >
> >> I'm guessing that the high cpu and io load at startup may be the cause
> >> of the issue. Those clients are relatively heavy to startup, one being
> >> mono, the other node. This particular issue isn't seen on the desktop
> >> under F21 or Arch with the same software.
> >
> > No, that can't be it. If the socket never connected, you'd get ENOTCONN,
> not
> > EPIPE.
> >
> >> Is there some way to debug the reason behind the EPIPE from the
> >> dbus-daemon side? I tried compiling with the --enable-verbose-tracing
> >> and enabling DBUS_VERBOSE=1 but that produces a ton of output that
> >> seems unrelated to the EPIPE issue.
> >
> > The message failed to parse. Use strace on your application and capture
> the
> > all the messages sent after the last time the bus sent anything to you.
> One of
> > those messages is invalid.
> >
> > --
> > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> >    Software Architect - Intel Open Source Technology Center
> >       PGP/GPG: 0x6EF45358; fingerprint:
> >       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
> >
> > _______________________________________________
> > dbus mailing list
> > dbus at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dbus
>
>
> I'll do this and see if I can't get a working and non-working case. We
> did that before but I don't have it handy, I'll reproduce and report.
>
> Interestingly, same sw never has the issue running on the desktop
> environment. That would be the identical node-dbus and dbushsarp
> modules and code. And it appears to be related to system load.
>
> Is there anything that the comes to mind that the clients might not be
> handling in those particular cases? We looked into the gdbus code and
> didn't see any retries etc but if it is a protocol issue I'm wondering
> if its related to the high load and something not being handled in a
> corner case of the protocol.
>
> Chris
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20150603/7945f352/attachment.html>