unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
@ 2024-04-12 10:56 Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-13  1:55 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 24+ messages in thread
From: Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-12 10:56 UTC (permalink / raw)
  To: 70352, yang.yingchao



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






^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-04-12 10:56 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
@ 2024-04-13  1:55 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-13  7:15   ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-13  1:55 UTC (permalink / raw)
  To: Yang Yingchao; +Cc: 70352

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.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-04-13  1:55 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-13  7:15   ` Eli Zaretskii
  2024-04-13 10:59     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2024-04-13  7:15 UTC (permalink / raw)
  To: Po Lu; +Cc: yang.yingchao, 70352

> 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?





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-04-13  7:15   ` Eli Zaretskii
@ 2024-04-13 10:59     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-13 12:02       ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-13 10:59 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: yang.yingchao, 70352

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





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-04-13 10:59     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-13 12:02       ` Eli Zaretskii
  2024-04-14  0:11         ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
                           ` (2 more replies)
  0 siblings, 3 replies; 24+ messages in thread
From: Eli Zaretskii @ 2024-04-13 12:02 UTC (permalink / raw)
  To: Po Lu; +Cc: yang.yingchao, 70352

> 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?





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-04-13 12:02       ` Eli Zaretskii
@ 2024-04-14  0:11         ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
       [not found]         ` <87sezozttr.fsf@>
  2024-04-14  3:05         ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2 siblings, 0 replies; 24+ messages in thread
From: Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-14  0:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Po Lu, yang.yingchao, 70352

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?





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
       [not found]         ` <87sezozttr.fsf@>
@ 2024-04-14  0:59           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-14  5:48             ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-14  0:59 UTC (permalink / raw)
  To: Björn Bidar; +Cc: yang.yingchao, Eli Zaretskii, 70352

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.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-04-13 12:02       ` Eli Zaretskii
  2024-04-14  0:11         ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
       [not found]         ` <87sezozttr.fsf@>
@ 2024-04-14  3:05         ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2 siblings, 0 replies; 24+ messages in thread
From: Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-14  3:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Po Lu, yang.yingchao, 70352


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.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-04-14  0:59           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-14  5:48             ` Eli Zaretskii
  2024-04-14  6:28               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2024-04-14  5:48 UTC (permalink / raw)
  To: Po Lu; +Cc: yang.yingchao, bjorn.bidar, 70352

> 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?





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-04-14  5:48             ` Eli Zaretskii
@ 2024-04-14  6:28               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-14  7:31                 ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-14  6:28 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: yang.yingchao, bjorn.bidar, 70352

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





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-04-14  6:28               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-14  7:31                 ` Eli Zaretskii
       [not found]                   ` <699acc927ca7decaaac0d06a59c80426bb9ae3059c3eebd7cced56cb021310bf@mu.id>
  0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2024-04-14  7:31 UTC (permalink / raw)
  To: Po Lu; +Cc: yang.yingchao, bjorn.bidar, 70352

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





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
       [not found]                     ` <871q7argry.fsf@qq.com>
@ 2024-04-15  1:36                       ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 24+ messages in thread
From: Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-15  1:36 UTC (permalink / raw)
  To: 70352

[-- 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 --------------------

^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
       [not found]                     ` <db6105b7ec2a3d0db0d1741e43bea07e1ca0a8e2e7f360933771f524e9266d13@mu.id>
@ 2024-04-15  1:58                       ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
       [not found]                       ` <87wmoz75g4.fsf@qq.com>
  1 sibling, 0 replies; 24+ messages in thread
From: Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-15  1:58 UTC (permalink / raw)
  To: 70352

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.






^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
       [not found]                       ` <87wmoz75g4.fsf@qq.com>
@ 2024-04-17  7:30                         ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-27  8:32                           ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-17  7:30 UTC (permalink / raw)
  To: 70352

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)
```






^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-04-17  7:30                         ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-27  8:32                           ` Eli Zaretskii
  2024-04-29  8:45                             ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2024-04-27  8:32 UTC (permalink / raw)
  To: Yang Yingchao, Po Lu; +Cc: 70352

> 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?





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-04-27  8:32                           ` Eli Zaretskii
@ 2024-04-29  8:45                             ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-29 11:46                               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 24+ messages in thread
From: Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-29  8:45 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Po Lu, 70352

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-04-29  8:45                             ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-29 11:46                               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-29 12:27                                 ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
                                                   ` (3 more replies)
  0 siblings, 4 replies; 24+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-29 11:46 UTC (permalink / raw)
  To: Yang Yingchao; +Cc: Eli Zaretskii, 70352

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.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-04-29 11:46                               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-29 12:27                                 ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-05-09  7:35                                   ` Eli Zaretskii
  2024-05-10 20:34                                 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
                                                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 24+ messages in thread
From: Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-29 12:27 UTC (permalink / raw)
  To: Po Lu; +Cc: Eli Zaretskii, 70352

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.






^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-04-29 12:27                                 ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-05-09  7:35                                   ` Eli Zaretskii
  2024-05-10  0:00                                     ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2024-05-09  7:35 UTC (permalink / raw)
  To: luangruo, Yang Yingchao; +Cc: 70352

> 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?





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-05-09  7:35                                   ` Eli Zaretskii
@ 2024-05-10  0:00                                     ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-05-10  6:34                                       ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-05-10  0:00 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: luangruo, 70352

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.






^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-05-10  0:00                                     ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-05-10  6:34                                       ` Eli Zaretskii
  0 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2024-05-10  6:34 UTC (permalink / raw)
  To: Yang Yingchao; +Cc: luangruo, 70352-done

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





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-04-29 11:46                               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-29 12:27                                 ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-05-10 20:34                                 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-05-10 20:34                                 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
       [not found]                                 ` <87h6f5h0cw.fsf@>
  3 siblings, 0 replies; 24+ messages in thread
From: Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-05-10 20:34 UTC (permalink / raw)
  To: 70352; +Cc: yang.yingchao, luangruo, eliz

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.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
  2024-04-29 11:46                               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-29 12:27                                 ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-05-10 20:34                                 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-05-10 20:34                                 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
       [not found]                                 ` <87h6f5h0cw.fsf@>
  3 siblings, 0 replies; 24+ messages in thread
From: Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-05-10 20:34 UTC (permalink / raw)
  To: 70352; +Cc: yang.yingchao, luangruo, eliz

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.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#70352: Fwd: Re: bug#70352: 29.3.50; emacs-pgtk: possible leak of virtual memory
       [not found]                                 ` <87h6f5h0cw.fsf@>
@ 2024-05-11  0:23                                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 24+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-05-11  0:23 UTC (permalink / raw)
  To: Björn Bidar; +Cc: yang.yingchao, 70352, eliz

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.





^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2024-05-11  0:23 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-12 10:56 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
2024-04-13  1:55 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-13  7:15   ` Eli Zaretskii
2024-04-13 10:59     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-13 12:02       ` Eli Zaretskii
2024-04-14  0:11         ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]         ` <87sezozttr.fsf@>
2024-04-14  0:59           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-14  5:48             ` Eli Zaretskii
2024-04-14  6:28               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-14  7:31                 ` Eli Zaretskii
     [not found]                   ` <699acc927ca7decaaac0d06a59c80426bb9ae3059c3eebd7cced56cb021310bf@mu.id>
     [not found]                     ` <871q7argry.fsf@qq.com>
2024-04-15  1:36                       ` bug#70352: Fwd: " Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]                     ` <db6105b7ec2a3d0db0d1741e43bea07e1ca0a8e2e7f360933771f524e9266d13@mu.id>
2024-04-15  1:58                       ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]                       ` <87wmoz75g4.fsf@qq.com>
2024-04-17  7:30                         ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-27  8:32                           ` Eli Zaretskii
2024-04-29  8:45                             ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-29 11:46                               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-29 12:27                                 ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-09  7:35                                   ` Eli Zaretskii
2024-05-10  0:00                                     ` Yang Yingchao via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-10  6:34                                       ` Eli Zaretskii
2024-05-10 20:34                                 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-10 20:34                                 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]                                 ` <87h6f5h0cw.fsf@>
2024-05-11  0:23                                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-14  3:05         ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).