From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yang Yingchao via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory Date: Mon, 29 Apr 2024 16:45:16 +0800 Message-ID: References: <87zfty2fh6.fsf@yahoo.com> <86sezprawz.fsf@gnu.org> <87v84l34uy.fsf@yahoo.com> <86bk6dpj2c.fsf@gnu.org> <874jc43gjx.fsf@yahoo.com> <86frvoo5pi.fsf@gnu.org> <87sezo1mr2.fsf@yahoo.com> <867ch0o0wi.fsf@gnu.org> <699acc927ca7decaaac0d06a59c80426bb9ae3059c3eebd7cced56cb021310bf@mu.id> <87wmoz75g4.fsf@qq.com> <86o79vw6ii.fsf@gnu.org> Reply-To: Yang Yingchao Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18753"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.12.4; emacs 29.3.50 Cc: Po Lu , 70352@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 29 10:46:59 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s1Mf4-0004gz-9l for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Apr 2024 10:46:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s1Mex-00030r-6S; Mon, 29 Apr 2024 04:46:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s1Mep-0002zN-6d for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2024 04:46:47 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s1Meo-0005Vb-77 for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2024 04:46:42 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s1Mf8-0004rI-1y for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2024 04:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Yang Yingchao Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Apr 2024 08:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70352 X-GNU-PR-Package: emacs Original-Received: via spool by 70352-submit@debbugs.gnu.org id=B70352.171438038118657 (code B ref 70352); Mon, 29 Apr 2024 08:47:02 +0000 Original-Received: (at 70352) by debbugs.gnu.org; 29 Apr 2024 08:46:21 +0000 Original-Received: from localhost ([127.0.0.1]:55940 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s1MeT-0004qr-2J for submit@debbugs.gnu.org; Mon, 29 Apr 2024 04:46:21 -0400 Original-Received: from out162-62-57-49.mail.qq.com ([162.62.57.49]:36189) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s1MeP-0004ql-FP for 70352@debbugs.gnu.org; Mon, 29 Apr 2024 04:46:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1714380348; bh=iPXYHqdifIo2ML1Iw/DATrmiIOUbtFrnKtH9Nft6nE4=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=CsyipfpEjBQdZ6+zX81Ty2M3VACBz49qV9IQZOqCiOG0hqD34yewk0X9ljZAjh+4B DG3+q4CZSYhSg9qrwm05D629c56oeD5xgIGDRZz2rbbpz+NiOeTTh5IU161ooA9A3N hJjwYd7iUTPF4YysQNg44HTEJ/aoWdbzz3In9Ut8= Original-Received: from tbook ([60.26.151.177]) by newxmesmtplogicsvrszc5-2.qq.com (NewEsmtp) with SMTP id B68ABE05; Mon, 29 Apr 2024 16:45:40 +0800 X-QQ-mid: xmsmtpt1714380340t5yn7k2l9 X-QQ-XMAILINFO: M9eMYcnh67vJNyBs7qxgsGqe98tN2ja3/hPQEzxUIc/9Wy3UF7n6uEgw82rSHx cj4F9Q3pR2rdVz4Qk15yCTLV961/mfBEsYbIuEs8cgtiC/kvkjiX22ijL+vwXJ5XGQ7COLetzM6J Pkcpc25uWpMIO083QWcMl1QNpL3U4Oh3UYDHQYYbgVHsLBDbpWiBxjmht3PoBEy7ZrNvEkwwY4K+ fhx0fu5w4zbugE50sX2BD3Rx3yxlOhmQ7ESqx5whc8UYZaupDLq6B6GXNuo3y/iE/qbNYK4h8V+p UXWl10iGeRW/3S3ZP+xS2XpQq5jMeV8bv78HinrOjNet60pVpSPkhH/UMBjJsvueQyOEMV7qqjUy QKtaIzgpZO7VIM+V++ICRqTWDGUQ99fSF1h2z58m/bp9bRHWKt9qHvr97vHCZsv5hhtqMVu97PD/ K+ja1IRWcCDDartSvY9+2L2jjuSaZ4IQHKnzBs9d9J33S93smiPeSNE5iS7BVinBCsfIMwm/wvbf 2hS9QfEeuZmZM6ixyh/+VfCCDhbZZJfKCxSsbmj9R2eQsZnFjZqoU3RqTJgd5htUeBAdQe0b6yJo RTiE/nVwFaUPlx8BHq9ehv0l2iPxtIJxez2bOwsPhctUOkQSHxVgzAMAZTa4cch5w6wHYroGQ5WK OWebrzGzFKZGQ9eF+inS0AeSsShmv1PBP/Ma5UZwk5+WifdMqhVl0hcyPFToPmGwFYEfh6RF0dxv FYHkpjSP7iwZC5xA2XDjmvS8dgYSTI/ma5yTXXEfsaIMc6I/C+JGFcLy4Z3ZglMeEzKluGY4+D57 48ucjan6ExL+tjnxnVBki/jByehH+bAJGRWwsbRg X-QQ-XMRINFO: Mp0Kj//9VHAxr69bL5MkOOs= In-Reply-To: <86o79vw6ii.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 27 Apr 2024 11:32:05 +0300") Original-Message-ID: <875xw04kwz.fsf@qq.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:284127 --=-=-= Content-Type: text/plain Content-Disposition: inline On Sat, Apr 27 2024, Eli Zaretskii wrote: >> Date: Wed, 17 Apr 2024 15:30:11 +0800 >> From: Yang Yingchao via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> On Mon, Apr 15 2024, Yang Yingchao wrote: >> >> > >> > FYI: >> > I tested this in two window managers (Hyprland & Sway), and found that the same issue exists. >> >> >> I'm not familiar with the GTK toolkit, but it seems that the creation >> and destruction of surfaces are not properly paired. >> >> >> I added breakpoints to `_gdk_wayland_display_create_shm_surface()` and >> `gdk_wayland_cairo_surface_destroy()`, then executed steps 2 and 3. I >> found that `_gdk_wayland_display_create_shm_surface()` is called 3 >> times, but `gdk_wayland_cairo_surface_destroy()` is only called 2 times. >> >> I'm not sure if this is related... >> >> ``` >> 70:Thread 1 "emacs" hit Breakpoint 6, _gdk_wayland_display_create_shm_surface (display=, >> 125:Thread 1 "emacs" hit Breakpoint 5, gdk_wayland_cairo_surface_destroy (p=0x555b2d87c2a0) >> 137:Thread 1 "emacs" hit Breakpoint 6, _gdk_wayland_display_create_shm_surface (display=, >> 153:Thread 1 "emacs" hit Breakpoint 6, _gdk_wayland_display_create_shm_surface (display=, >> 181:Thread 1 "emacs" hit Breakpoint 5, gdk_wayland_cairo_surface_destroy (p=0x555b2e33fc40) >> ``` > > Po Lu, any comments or suggestions? Could this be an issue with gtk+? I made some changes to gtk+-3.24.41, and it seems like the issue has disappeared... ,---- | diff -urNa gtk+-3.24.41.orig/gdk/wayland/gdkwindow-wayland.c gtk+-3.24.41/gdk/wayland/gdkwindow-wayland.c | --- gtk+-3.24.41.orig/gdk/wayland/gdkwindow-wayland.c 2024-01-24 09:14:34.000000000 +0800 | +++ gtk+-3.24.41/gdk/wayland/gdkwindow-wayland.c 2024-04-29 16:41:00.691373426 +0800 | @@ -952,6 +952,11 @@ | /* Release came in, we haven't done any interim updates, so we can just use | * the old committed buffer again. | */ | + | + if (impl->staging_cairo_surface) { | + g_clear_pointer (&impl->staging_cairo_surface, cairo_surface_destroy); | + } | + | impl->staging_cairo_surface = g_steal_pointer (&impl->committed_cairo_surface); | } `---- Actually, I do not understand the logic of the function `buffer_release_callback()', but when debugging this issue with gdb, I noticed that the `impl->staging_cairo_surface' which was created via `_gdk_wayland_display_create_shm_surface' was replaced by `impl->committed_cairo_surface' without being released first. Regards, -- *Yang Yingchao* --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=gtk+-3.24.41-virtual-memory-leak.patch diff -urNa gtk+-3.24.41.orig/gdk/wayland/gdkwindow-wayland.c gtk+-3.24.41/gdk/wayland/gdkwindow-wayland.c --- gtk+-3.24.41.orig/gdk/wayland/gdkwindow-wayland.c 2024-01-24 09:14:34.000000000 +0800 +++ gtk+-3.24.41/gdk/wayland/gdkwindow-wayland.c 2024-04-29 16:41:00.691373426 +0800 @@ -952,6 +952,11 @@ /* Release came in, we haven't done any interim updates, so we can just use * the old committed buffer again. */ + + if (impl->staging_cairo_surface) { + g_clear_pointer (&impl->staging_cairo_surface, cairo_surface_destroy); + } + impl->staging_cairo_surface = g_steal_pointer (&impl->committed_cairo_surface); } --=-=-=--