Possible resource leak in Weston

[Pekka Paalanen]

On Wed, 29 Apr 2020 09:51:25 +0200
Guillermo Rodriguez <guillerodriguez.dev at gmail.com> wrote:

> Hi Pekka,
> 
> El vie., 24 abr. 2020 a las 12:50, Pekka Paalanen
> (<ppaalanen at gmail.com>) escribió:
> >
> > On Thu, 23 Apr 2020 16:14:43 +0200
> > Guillermo Rodriguez <guillerodriguez.dev at gmail.com> wrote:
> >  
> > > Hi Pekka,
> > >
> > > El jue., 23 abr. 2020 a las 11:43, Pekka Paalanen
> > > (<ppaalanen at gmail.com>) escribió:  
> > > >
> > > > On Wed, 22 Apr 2020 16:45:42 +0200
> > > > Guillermo Rodriguez <guillerodriguez.dev at gmail.com> wrote:
> > > >  
> > > > > Hi all,
> > > > >
> > > > > I am investigating something that looks like a resource leak in
> > > > > Weston. I first saw the problem in an application involving Gstreamer,
> > > > > which would run out of fds after a number of iterations (~1000).
> > > > > However I have also been able to reproduce it without using Gstreamer.
> > > > >
> > > > > This is the scenario:
> > > > >
> > > > > I have a wayland application that uses Gstreamer to display video. The
> > > > > application creates the display connection (wl_display_connect) and a
> > > > > top-level surface; these last for the lifetime of the application.
> > > > > Every time the application needs to show a video fragment, it builds a
> > > > > Gstreamer pipeline, and passes the display and surface handles to
> > > > > Gstreamer's waylandsink.
> > > > >
> > > > > This ends up calling the gst_wl_display_new_existing function [1],
> > > > > which registers a listener for the wayland registry and binds to some
> > > > > interfaces [2]. Binding to the wl_shell interface results in a call to
> > > > > weston_desktop_wl_shell_bind -> weston_desktop_client_create where
> > > > > some resources are created, including, among others, a ping timer.
> > > > >
> > > > > When Gstreamer is done showing the video, it cleans up and releases
> > > > > all resources. As part of this process it calls wl_shell_destroy [3],
> > > > > however this does NOT result in a call to
> > > > > weston_desktop_client_destroy, and so the associated resources are not
> > > > > released. In fact, the resources are only released when the
> > > > > application disconnects (wl_display_disconnect) and exits. At this
> > > > > point, all "pending" calls to weston_desktop_client_destroy are made.
> > > > >
> > > > > The original symptoms (application running out of fds) are only
> > > > > visible with wayland < 1.18.0. This is because up to 1.18.0, one
> > > > > timerfd was being used for each ping timer. This was changed in this
> > > > > commit [4]. However even if the symptoms are less visible, the issue
> > > > > still exists in Weston.
> > > > >
> > > > > Does this make sense?  
> > > >
> > > > Hi,
> > > >
> > > > yes, it does make sense, I think.
> > > >  
> > > > > In case I am not overlooking something and this is indeed a Weston
> > > > > issue, any hints on how to fix it?  
> > > >
> > > > It is mostly a Weston issue, but there are a couple Wayland protocol
> > > > issues as well:
> > > >
> > > > - wl_registry does not have a destroy request defined, hence the
> > > >   compositor cannot know when a client destroys a wl_registry. The
> > > >   compositor side of a wl_registry object can only be reaped when the
> > > >   client disconnects. Fixing this is cumbersome.
> > > >
> > > > - wl_shell interface does not have a destroy request either. However,
> > > >   adding one would be much easier that with wl_registry. OTOH, wl_shell
> > > >   is deprecated, so even if we add one, I doubt the clients still using
> > > >   it would get fixed.
> > > >
> > > > The above are fundamental but relatively minor leaks during a client's
> > > > lifetime in the compositor. Solving them should not be necessary for
> > > > solving your immediate problem, but they would be needed for a complete
> > > > solution rather than just pushing the failure point even further out.  
> > >
> > > The lack of a destroy request for wl_shell seems to be the root of the
> > > problem in my case.
> > > Each time my application needs to show a video fragment it builds a
> > > Gstreamer pipeline, Gstreamer's waylandsink binds to the wl_shell
> > > client, and this results in the creation of a new ping timer. Once the
> > > video stops the timer resources are not released. After a number of
> > > iterations of this process, the application cannot show video anymore.
> > >
> > > You mention that "solving this should not be necessary for solving my
> > > immediate problem", but I am not sure why you say that. If the
> > > wl_shell objects (and associated resources) are being leaked, how do I
> > > work around this issue?  
> >
> > Hi,
> >
> > I say that, because there is no need for a compositor to hang any state
> > on the wl_shell protocol object from the protocol perspective. The only
> > thing it cannot avoid to leak is one wl_resource per bind to wl_shell.
> >
> > All state is related to wl_shell_surface objects instead.  
> 
> I see. You mean that Weston could be modified to solve my (immediate)
> problem without modifying the protocol.

Yes, or at least to push the point of failure further.

> So it looks like there's no way to work around this at the application level...

I'm afraid not, unless you can stop re-binding to wl_shell all the time.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200429/c1869557/attachment.sig>