[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Pkg-xfce-devel] Bug#829557: Bug#829557: Bug#829557: firefox: error box at start-up / D-BUS related issue



On Mon, 2016-07-11 at 10:38 +0100, Simon McVittie wrote:
> On Mon, 11 Jul 2016 at 11:07:07 +0200, Yves-Alexis Perez wrote:
> > > Misc error when trying to watch fd 4: Invalid argument
> > > Unable to add reload watch to main loopthis watch should have been
> > > invalidatedMisc error when trying to watch fd 5: Invalid argument
> > > Unable to add reload watch to main loop: (null)
> > 
> > The message above seems to come from socket_set_epoll_add (https://dbus.fr
> > eede
> > sktop.org/doc/api/html/dbus-socket-set-epoll_8c_source.html#l00137) where
> > epoll_ctl sets errno to EINVAL which means self->epfd is not an epoll file
> > descriptor.
> 
> Something like that, yes. I'm really confused by this: it looks like it
> might be a dbus-daemon bug, but so far I can't see why it would happen,
> or how upgrading lightdm could trigger it.

Indeed, that also puzzles me.
> 
> The sequence of events here is:
> 
> * We create the epoll fd in _dbus_socket_set_epoll_new(). To have got
> ? a non-NULL result, we must have epfd != -1; and if we'd got NULL,
> ? we'd have failed already (_dbus_socket_set_new, _dbus_loop_new,
> ? bus_context_new and main all seem to catch errors correctly).
> 
> * dbus-daemon (bus/dir-watch-inotify.c) creates an inotify fd (fd 4)
> ? but then fails to add it to the main loop: _dbus_loop_add_watch()
> ? results in socket_set_epoll_add() which fails with EINVAL. Watching
> ? directories is considered non-critical so this is ignored.
> 
> * dbus-daemon (bus/main.c) creates what should probably have been a
> ? pipe-to-self to catch SIGHUP and SIGTERM from its own signal handler,
> ? but for historical reasons it's a socketpair() instead. The end we
> ? use as the read end is fd 5. socket_set_epoll_add() fails again.
> ? Catching our own SIGHUP and SIGTERM is considered to be critical
> ? (and really shouldn't fail!) so we exit.
> 
> I wonder whether there are other reasons why epoll_ctl can report EINVAL?

The syscall source code is at?http://lxr.free-electrons.com/source/fs/eventpol
l.c#L1849?and it seems EINVAL is used as a default error case at various
places, so maybe.
> 
> I also wonder whether the new lightdm is starting dbus-launch with a
> different value for some arbitrary kernel limit, or whether your previous
> session leaked some fds resulting in dbus-launch coming up with 90% of
> an arbitrary limit already in use, or something like that?

For what it's worth, after closing the first session there's no process
running under my uid. I'll try to check the limits in 75dbus to see if they
differ.
>?

Regards,

-- 

Yves-Alexis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-xfce-devel/attachments/20160711/280f3d72/attachment.sig>



Reply to: