On Wed, 29 Apr 2020 09:51:25 +0200 Guillermo Rodriguez <guillerodriguez....@gmail.com> wrote:
> Hi Pekka, > > El vie., 24 abr. 2020 a las 12:50, Pekka Paalanen > (<ppaala...@gmail.com>) escribió: > > > > On Thu, 23 Apr 2020 16:14:43 +0200 > > Guillermo Rodriguez <guillerodriguez....@gmail.com> wrote: > > > > > Hi Pekka, > > > > > > El jue., 23 abr. 2020 a las 11:43, Pekka Paalanen > > > (<ppaala...@gmail.com>) escribió: > > > > > > > > On Wed, 22 Apr 2020 16:45:42 +0200 > > > > Guillermo Rodriguez <guillerodriguez....@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
pgpPGz78YNkVv.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
