bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I'm testing Emacs built with Pgtk (with GTK-4.12.5), and I suspect there
may be a memory leak in virtual memory.


Steps to reproduce:

1. Start Emacs with "-Q --bg-daemon=mytest".
2. Connect to the server with 'emacsclient -c -s mytest'. This will create a new frame.
3. Kill the newly created frame with `\C-x\C-c`.
4. Repeat steps 2 & 3, and observe `/proc/pid_of_emacs/maps`.

It seems like there could be a memory leak issue causing the increasing
number of "/memfd:gdk-wayland" entries and ultimately leading to the
crash without a core dump.


Some of my statistics are as follows:


# yyc@tbook in /proc/400602  [18:40:36]
$ cat maps | grep memfd | awk '{print $1}' | awk -F "-" '{sum=strtonum("0x"$2)-strtonum("0x"$1); print sum}' | awk '{sum+=$1} END {print sum}'
42688512
# yyc@tbook in /proc/400602  [18:40:57]
$ cat maps | grep memfd | awk '{print $1}' | awk -F "-" '{sum=strtonum("0x"$2)-strtonum("0x"$1); print sum}' | awk '{sum+=$1} END {print sum}'
51888128
# yyc@tbook in /proc/400602  [18:41:26]
$ cat /proc/400602/maps| grep /memfd: | wc -l
7
# yyc@tbook in /proc/400602  [18:41:41]
$ cat /proc/400602/maps| grep /memfd: | wc -l
9
# yyc@tbook in /proc/400602  [18:41:46]
$ cat /proc/400602/maps| grep /memfd: | wc -l
10
# yyc@tbook in /proc/400602  [18:41:51]
$ cat /proc/400602/maps| grep /memfd: | wc -l
10
# yyc@tbook in /proc/400602  [18:41:56]
$ cat /proc/400602/maps| grep /memfd: | wc -l
12
# yyc@tbook in /proc/400602  [18:42:01]
$ cat /proc/400602/maps| grep /memfd: | wc -l
12
# yyc@tbook in /proc/400602  [18:42:03]
$ cat /proc/400602/maps| grep /memfd:
7f0ca170a000-7f0ca1fd0000 rw-s 00000000 00:01 169719                     /memfd:gdk-wayland (deleted)
7f0ca1fd0000-7f0ca2896000 rw-s 00000000 00:01 169718                     /memfd:gdk-wayland (deleted)
7f0ca2896000-7f0ca315c000 rw-s 00000000 00:01 175557                     /memfd:gdk-wayland (deleted)
7f0ca315c000-7f0ca3a22000 rw-s 00000000 00:01 169709                     /memfd:gdk-wayland (deleted)
7f0ca3a22000-7f0ca42e8000 rw-s 00000000 00:01 169708                     /memfd:gdk-wayland (deleted)
7f0ca42e8000-7f0ca4bae000 rw-s 00000000 00:01 177320                     /memfd:gdk-wayland (deleted)
7f0ca4bae000-7f0ca5474000 rw-s 00000000 00:01 176334                     /memfd:gdk-wayland (deleted)
7f0ca5474000-7f0ca5d3a000 rw-s 00000000 00:01 175525                     /memfd:gdk-wayland (deleted)
7f0ca5d3a000-7f0ca6600000 rw-s 00000000 00:01 175517                     /memfd:gdk-wayland (deleted)
7f0ca773a000-7f0ca8000000 rw-s 00000000 00:01 175524                     /memfd:gdk-wayland (deleted)
7f0cc4381000-7f0cc47ff000 rw-s 00000000 00:01 175518                     /memfd:wayland-cursor (deleted)
7f0cc66da000-7f0cc67fa000 rw-s 00000000 00:01 175514                     /memfd:wayland-cursor (deleted)


Regards
yang

bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Yang Yingchao <yang.yingchao@qq.com> writes:

> I'm testing Emacs built with Pgtk (with GTK-4.12.5), and I suspect there

The GTK 4 version of the PGTK port was a failed experiment of mine that
I quickly concluded was not feasible to continue maintaining, and is now
effectively abandoned.  It goes without saying that one shouldn't expect
to receive support for it on this list.

bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Eli Zaretskii]

> Cc: 70352@debbugs.gnu.org
> Date: Sat, 13 Apr 2024 09:55:49 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Yang Yingchao <yang.yingchao@qq.com> writes:
> 
> > I'm testing Emacs built with Pgtk (with GTK-4.12.5), and I suspect there
> 
> The GTK 4 version of the PGTK port was a failed experiment of mine that
> I quickly concluded was not feasible to continue maintaining, and is now
> effectively abandoned.  It goes without saying that one shouldn't expect
> to receive support for it on this list.

Can we display a prominent warning to that effect when Emacs is
configured for PGTK to be built with GTK4?

bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 70352@debbugs.gnu.org
>> Date: Sat, 13 Apr 2024 09:55:49 +0800
>> From:  Po Lu via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> Yang Yingchao <yang.yingchao@qq.com> writes:
>> 
>> > I'm testing Emacs built with Pgtk (with GTK-4.12.5), and I suspect there
>> 
>> The GTK 4 version of the PGTK port was a failed experiment of mine that
>> I quickly concluded was not feasible to continue maintaining, and is now
>> effectively abandoned.  It goes without saying that one shouldn't expect
>> to receive support for it on this list.
>
> Can we display a prominent warning to that effect when Emacs is
> configured for PGTK to be built with GTK4?

It's really not "we", just "I"--the code implementing such a
configuration doesn't exist in the Emacs repository on Savannah...

bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: yang.yingchao@qq.com,  70352@debbugs.gnu.org
> Date: Sat, 13 Apr 2024 18:59:49 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Cc: 70352@debbugs.gnu.org
> >> Date: Sat, 13 Apr 2024 09:55:49 +0800
> >> From:  Po Lu via "Bug reports for GNU Emacs,
> >>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >> 
> >> Yang Yingchao <yang.yingchao@qq.com> writes:
> >> 
> >> > I'm testing Emacs built with Pgtk (with GTK-4.12.5), and I suspect there
> >> 
> >> The GTK 4 version of the PGTK port was a failed experiment of mine that
> >> I quickly concluded was not feasible to continue maintaining, and is now
> >> effectively abandoned.  It goes without saying that one shouldn't expect
> >> to receive support for it on this list.
> >
> > Can we display a prominent warning to that effect when Emacs is
> > configured for PGTK to be built with GTK4?
> 
> It's really not "we", just "I"--the code implementing such a
> configuration doesn't exist in the Emacs repository on Savannah...

Maybe I'm confused, but if this code is not in Emacs, how come the OP
bumped into this problem in the first place?  What am I missing?

bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> > configured for PGTK to be built with GTK4?
>> 
>> It's really not "we", just "I"--the code implementing such a
>> configuration doesn't exist in the Emacs repository on Savannah...
>
> Maybe I'm confused, but if this code is not in Emacs, how come the OP
> bumped into this problem in the first place?  What am I missing?

maybe confused the gtk version Emacs was built with?

bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

>> Maybe I'm confused, but if this code is not in Emacs, how come the OP
>> bumped into this problem in the first place?  What am I missing?
>
> maybe confused the gtk version Emacs was built with?

Perhaps, but let's wait for a response from OP.

bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  yang.yingchao@qq.com,  70352@debbugs.gnu.org
> Date: Sun, 14 Apr 2024 08:59:30 +0800
> 
> Björn Bidar <bjorn.bidar@thaodan.de> writes:
> 
> >> Maybe I'm confused, but if this code is not in Emacs, how come the OP
> >> bumped into this problem in the first place?  What am I missing?
> >
> > maybe confused the gtk version Emacs was built with?
> 
> Perhaps, but let's wait for a response from OP.

I thought the question I asked was for you to answer, not for the OP:
how come the OP bumped into a problem that (AFAIU) could only happen
when using code that is not in the Emacs Git repository?

bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> I thought the question I asked was for you to answer, not for the OP:
> how come the OP bumped into a problem that (AFAIU) could only happen
> when using code that is not in the Emacs Git repository?

Because the OP, presumably, built code that I published elsewhere (and,
I had hoped, discreetly enough to avoid the attention of casual Emacs
users).

bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: bjorn.bidar@thaodan.de,  yang.yingchao@qq.com,  70352@debbugs.gnu.org
> Date: Sun, 14 Apr 2024 14:28:33 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I thought the question I asked was for you to answer, not for the OP:
> > how come the OP bumped into a problem that (AFAIU) could only happen
> > when using code that is not in the Emacs Git repository?
> 
> Because the OP, presumably, built code that I published elsewhere (and,
> I had hoped, discreetly enough to avoid the attention of casual Emacs
> users).

If that's what happened, then yes, it explains everything (and means
we don't need to discuss this issue anymore).

bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]


-------------------- Start of forwarded message --------------------
From: Yang Yingchao <yang.yingchao@qq.com>
To: Eli Zaretskii <eliz@gnu.org>
Subject: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
Date: Mon, 15 Apr 2024 09:21:04 +0800


[-- Attachment #2.1: Type: text/plain, Size: 1184 bytes --]

Hi * Eli*,

On Sun, Apr 14 2024, Eli Zaretskii wrote:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: bjorn.bidar@thaodan.de,  yang.yingchao@qq.com,  70352@debbugs.gnu.org
>> Date: Sun, 14 Apr 2024 14:28:33 +0800
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > I thought the question I asked was for you to answer, not for the OP:
>> > how come the OP bumped into a problem that (AFAIU) could only happen
>> > when using code that is not in the Emacs Git repository?
>>
>> Because the OP, presumably, built code that I published elsewhere (and,
>> I had hoped, discreetly enough to avoid the attention of casual Emacs
>> users).
>
> If that's what happened, then yes, it explains everything (and means
> we don't need to discuss this issue anymore).


Sorry for the late response.

And actually, I was wrong about the GTK version. I mistook the GTK version as the GTK+ version...

Here is the actual version related to GTK+:

```

$ ldd emacs | grep gtk
        libgtk-3.so.0 => /usr/lib64/libgtk-3.so.0 (0x00007f1e4ba00000)
```

If any other information is required, please let me know.

Regards,

-- *Yang Yingchao*
-------------------- End of forwarded message --------------------

bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Mon, Apr 15 2024, Yang Yingchao wrote:

> -------------------- Start of forwarded message --------------------
> From: Yang Yingchao <yang.yingchao@qq.com>
> To: Eli Zaretskii <eliz@gnu.org>
> Subject: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
> Date: Mon, 15 Apr 2024 09:21:04 +0800
>
> <#multipart type=mixed>
> <#part type="text/plain" disposition=inline>
> Hi * Eli*,
>
> On Sun, Apr 14 2024, Eli Zaretskii wrote:
>
>>> From: Po Lu <luangruo@yahoo.com>
>>> Cc: bjorn.bidar@thaodan.de,  yang.yingchao@qq.com,  70352@debbugs.gnu.org
>>> Date: Sun, 14 Apr 2024 14:28:33 +0800
>>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>> > I thought the question I asked was for you to answer, not for the OP:
>>> > how come the OP bumped into a problem that (AFAIU) could only happen
>>> > when using code that is not in the Emacs Git repository?
>>>
>>> Because the OP, presumably, built code that I published elsewhere (and,
>>> I had hoped, discreetly enough to avoid the attention of casual Emacs
>>> users).
>>
>> If that's what happened, then yes, it explains everything (and means
>> we don't need to discuss this issue anymore).
>
>
> Sorry for the late response.
>
> And actually, I was wrong about the GTK version. I mistook the GTK version as the GTK+ version...
>
> Here is the actual version related to GTK+:
>
> ```
>
> $ ldd emacs | grep gtk
>         libgtk-3.so.0 => /usr/lib64/libgtk-3.so.0 (0x00007f1e4ba00000)
> ```
>
> If any other information is required, please let me know.
>
> Regards,
>
> -- *Yang Yingchao*
> -------------------- End of forwarded message --------------------
> <#/part>
> <#/multipart>

FYI:
I tested this in two window managers (Hyprland & Sway), and found that the same issue exists.

bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[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=<optimized out>,
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=<optimized out>,
153:Thread 1 "emacs" hit Breakpoint 6, _gdk_wayland_display_create_shm_surface (display=<optimized out>,
181:Thread 1 "emacs" hit Breakpoint 5, gdk_wayland_cairo_surface_destroy (p=0x555b2e33fc40)
```

bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Eli Zaretskii]

> 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" <bug-gnu-emacs@gnu.org>
> 
> 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=<optimized out>,
> 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=<optimized out>,
> 153:Thread 1 "emacs" hit Breakpoint 6, _gdk_wayland_display_create_shm_surface (display=<optimized out>,
> 181:Thread 1 "emacs" hit Breakpoint 5, gdk_wayland_cairo_surface_destroy (p=0x555b2e33fc40)
> ```

Po Lu, any comments or suggestions?

bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 2566 bytes --]

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" <bug-gnu-emacs@gnu.org>
>> 
>> 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=<optimized out>,
>> 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=<optimized out>,
>> 153:Thread 1 "emacs" hit Breakpoint 6, _gdk_wayland_display_create_shm_surface (display=<optimized out>,
>> 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*

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gtk+-3.24.41-virtual-memory-leak.patch --]
[-- Type: text/x-patch, Size: 637 bytes --]

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);
 }
 

bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Yang Yingchao <yang.yingchao@qq.com> writes:

> Could this be an issue with gtk+? I made some changes to gtk+-3.24.41,
> and it seems like the issue has disappeared...

I don't understand.  Aren't you building with GTK 4.x?

> ,----
> | 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.

I'm afraid the GDK Wayland backend is outside my line of country.
Perhaps you ought to take this up with their developers, but be prepared
for weeks of frustration as they presume to tell you how your program
should bend over backwards to accommodate their misdesigns.

bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Mon, Apr 29 2024, Po Lu wrote:

> Yang Yingchao <yang.yingchao@qq.com> writes:
>
>> Could this be an issue with gtk+? I made some changes to gtk+-3.24.41,
>> and it seems like the issue has disappeared...
>
> I don't understand.  Aren't you building with GTK 4.x?

No, I thought I was using GTK 4 initially, but I'm actually using GTK+ 3...


>
>> ,----
>> | 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.
>
> I'm afraid the GDK Wayland backend is outside my line of country.
> Perhaps you ought to take this up with their developers, but be prepared
> for weeks of frustration as they presume to tell you how your program
> should bend over backwards to accommodate their misdesigns.

Sure, I'll file a bug report there.

As a Gentoo user, I can patch the source code on my machine locally,
therefore, it would not be a real issue for me even if they don't fix it.


Thanks for your time.

bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Eli Zaretskii]

> From: Yang Yingchao <yang.yingchao@qq.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  70352@debbugs.gnu.org
> Date: Mon, 29 Apr 2024 20:27:52 +0800
> 
> On Mon, Apr 29 2024, Po Lu wrote:
> 
> > Yang Yingchao <yang.yingchao@qq.com> writes:
> >
> >> Could this be an issue with gtk+? I made some changes to gtk+-3.24.41,
> >> and it seems like the issue has disappeared...
> >
> > I don't understand.  Aren't you building with GTK 4.x?
> 
> No, I thought I was using GTK 4 initially, but I'm actually using GTK+ 3...
> 
> 
> >
> >> ,----
> >> | 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.
> >
> > I'm afraid the GDK Wayland backend is outside my line of country.
> > Perhaps you ought to take this up with their developers, but be prepared
> > for weeks of frustration as they presume to tell you how your program
> > should bend over backwards to accommodate their misdesigns.
> 
> Sure, I'll file a bug report there.
> 
> As a Gentoo user, I can patch the source code on my machine locally,
> therefore, it would not be a real issue for me even if they don't fix it.
> 
> 
> Thanks for your time.

Should we now close this bug report, or is there anything else left to
do here?

bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Thu, May 09 2024, Eli Zaretskii wrote:

>> From: Yang Yingchao <yang.yingchao@qq.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  70352@debbugs.gnu.org
>> Date: Mon, 29 Apr 2024 20:27:52 +0800
>> 
>> On Mon, Apr 29 2024, Po Lu wrote:
>> 
>> > Yang Yingchao <yang.yingchao@qq.com> writes:
>> >
>> >> Could this be an issue with gtk+? I made some changes to gtk+-3.24.41,
>> >> and it seems like the issue has disappeared...
>> >
>> > I don't understand.  Aren't you building with GTK 4.x?
>> 
>> No, I thought I was using GTK 4 initially, but I'm actually using GTK+ 3...
>> 
>> 
>> >
>> >> ,----
>> >> | 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.
>> >
>> > I'm afraid the GDK Wayland backend is outside my line of country.
>> > Perhaps you ought to take this up with their developers, but be prepared
>> > for weeks of frustration as they presume to tell you how your program
>> > should bend over backwards to accommodate their misdesigns.
>> 
>> Sure, I'll file a bug report there.
>> 
>> As a Gentoo user, I can patch the source code on my machine locally,
>> therefore, it would not be a real issue for me even if they don't fix it.
>> 
>> 
>> Thanks for your time.
>
> Should we now close this bug report, or is there anything else left to
> do here?


Yes, please.

Thank you.

bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Eli Zaretskii]

> From: Yang Yingchao <yang.yingchao@qq.com>
> Cc: luangruo@yahoo.com,  70352@debbugs.gnu.org
> Date: Fri, 10 May 2024 08:00:31 +0800
> 
> On Thu, May 09 2024, Eli Zaretskii wrote:
> 
> >> As a Gentoo user, I can patch the source code on my machine locally,
> >> therefore, it would not be a real issue for me even if they don't fix it.
> >> 
> >> 
> >> Thanks for your time.
> >
> > Should we now close this bug report, or is there anything else left to
> > do here?
> 
> 
> Yes, please.

Done.

bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Yang Yingchao <yang.yingchao@qq.com> writes:
>
>> Could this be an issue with gtk+? I made some changes to gtk+-3.24.41,
>> and it seems like the issue has disappeared...
>
> I don't understand.  Aren't you building with GTK 4.x?
>
>> ,----
>> | 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.
>
> I'm afraid the GDK Wayland backend is outside my line of country.
> Perhaps you ought to take this up with their developers, but be prepared
> for weeks of frustration as they presume to tell you how your program
> should bend over backwards to accommodate their misdesigns.

Doesn't seem to go that bad this time:
https://gitlab.gnome.org/GNOME/gtk/-/issues/6675

Luckily mentioning Emacs did not cause any issues.

bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Yang Yingchao <yang.yingchao@qq.com> writes:
>
>> Could this be an issue with gtk+? I made some changes to gtk+-3.24.41,
>> and it seems like the issue has disappeared...
>
> I don't understand.  Aren't you building with GTK 4.x?
>
>> ,----
>> | 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.
>
> I'm afraid the GDK Wayland backend is outside my line of country.
> Perhaps you ought to take this up with their developers, but be prepared
> for weeks of frustration as they presume to tell you how your program
> should bend over backwards to accommodate their misdesigns.

Doesn't seem to go that bad this time:
https://gitlab.gnome.org/GNOME/gtk/-/issues/6675

Luckily mentioning Emacs did not cause any issues.

bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Doesn't seem to go that bad this time:
> https://gitlab.gnome.org/GNOME/gtk/-/issues/6675
>
> Luckily mentioning Emacs did not cause any issues.

Good to hear, and thanks.

bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

It's not possible to built Emacs with GTK4 unless forcing to use GTK4
as GTK is versioned. Emacs requests GTK3/GTK2 during build nothing else,
but I might be wrong that's why I guessed it had maybe be picked up by
accident.