summaryrefslogtreecommitdiffstats
path: root/video
diff options
context:
space:
mode:
authordudemanguy <random342@airmail.cc>2019-08-07 09:26:24 -0500
committerJan Ekström <jeebjp@gmail.com>2019-09-19 00:00:19 +0300
commit80c4aaa2a4e7ada6530ad4f16172283cd82fcc1d (patch)
tree368f9aa72e451b472f2cb84161a5c2a3b5e55ced /video
parente08f235578aa6305a41e7c7132225e58bd191ef0 (diff)
downloadmpv-80c4aaa2a4e7ada6530ad4f16172283cd82fcc1d.tar.bz2
mpv-80c4aaa2a4e7ada6530ad4f16172283cd82fcc1d.tar.xz
wayland: fix wl_proxy leak
This one is probably not terribly obvious from just the valgrind log, but a wayland dev explained it to me just a second ago. Whenever mpv sends events to the screen with wl_display_dispatch, wayland internally allocates memory to a struct wl_proxy object if a new id is found. Quite a few more things happen to that proxy object, but eventually mpv stores the data on the client-side in a wrapper type of struct (struct wl_data_offer). mpv's data_device_listener keeps track of those proxies and frees the memory when appropriate. Of course, mpv is constantly sending events to the screen and does so until the user quits the player. What happens here is that one final wl_display_dispatch is called right before the user quits the player and before mpv's data_device_listener can handle that object. So the result is that you always have one extra dangling proxy that doesn't get properly freed. The solution is to just simply call wl_data_offer_destroy before closing the wl_display to free that final dangling wl_proxy.
Diffstat (limited to 'video')
-rw-r--r--video/out/wayland_common.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/video/out/wayland_common.c b/video/out/wayland_common.c
index f58fbbab3d..ab5594b4e4 100644
--- a/video/out/wayland_common.c
+++ b/video/out/wayland_common.c
@@ -1099,6 +1099,9 @@ void vo_wayland_uninit(struct vo *vo)
if (wl->dnd_devman)
wl_data_device_manager_destroy(wl->dnd_devman);
+ if (wl->dnd_offer)
+ wl_data_offer_destroy(wl->dnd_offer);
+
if (wl->xdg_toplevel_decoration)
zxdg_toplevel_decoration_v1_destroy(wl->xdg_toplevel_decoration);