GNU bug report logs - #35179
[PATCH] Plug memory leak in GTK x-display-monitor-attributes-list

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 35179 in the body.
You can then email your comments to 35179 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Plug memory leak in GTK x-display-monitor-attributes-list
Date: Sat, 06 Apr 2019 23:16:53 -0600

[Message part 1 (text/plain, inline)]

Also declare `name' in MonitorInfo const to satisfy the compiler.

Is it too late to push a memory leak fix like this to emacs-26?

[0001-Plug-memory-leak-in-GTK-x-display-monitor-attributes.patch (text/x-patch, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org,Alex <agrambot <at> gmail.com>,35179 <at> debbugs.gnu.org
Subject: Re: bug#35179: [PATCH] Plug memory leak in
 GTK	x-display-monitor-attributes-list
Date: Sun, 07 Apr 2019 09:37:29 +0300

On April 7, 2019 8:16:53 AM GMT+03:00, Alex <agrambot <at> gmail.com> wrote:
> Also declare `name' in MonitorInfo const to satisfy the compiler.
> 
> Is it too late to push a memory leak fix like this to emacs-26?

Yes, it's too late for such non-trivial changes in Emacs 26.2.

But I have a more fundamental problem with your proposed patch: it looks like you are relying on implementation details of gdk_monitor_get_model that its documentation never advertises?  Otherwise, how did you know that just removing the g_strdup call will plug a memory leak here, and will not create any new problems?

I'd prefer to leave g_strdup intact, and instead explicitly release the storage of previous value.  IOW, plug the leak in our own code, not rely on undocumented features which can easily go away some day.

Thanks.

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org, 35179 <at> debbugs.gnu.org
Subject: Re: bug#35179: [PATCH] Plug memory leak in
 GTK	x-display-monitor-attributes-list
Date: Sun, 07 Apr 2019 08:51:12 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

> But I have a more fundamental problem with your proposed patch: it looks like
> you are relying on implementation details of gdk_monitor_get_model that its
> documentation never advertises? Otherwise, how did you know that just removing
> the g_strdup call will plug a memory leak here, and will not create any new
> problems?
>
> I'd prefer to leave g_strdup intact, and instead explicitly release the storage of previous value.  IOW, plug the leak in our own code, not rely on undocumented features which can easily go away some day.

The documentation of gdk_monitor_get_model[1] specifies that the return
value is "[transfer none]", which has the description "Don't free data
after code is done".

The main memory leak, though, was that the MonitorList array wasn't
being freed. I considered using the free_monitors procedure like the
non-GTK versions do, but I saw no reason to call g_strdup for each name
and free each name almost right after.

Since make_monitor_attribute_list uses make_string on each name, I don't
see any issues that this removal would cause.


[1] https://developer.gnome.org/gdk3/stable/GdkMonitor.html#gdk-monitor-get-model

Message #20 received at 35179 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 35179 <at> debbugs.gnu.org
Subject: Re: bug#35179: [PATCH] Plug memory leak in
 GTK	x-display-monitor-attributes-list
Date: Sun, 07 Apr 2019 19:32:49 +0300

> From: Alex <agrambot <at> gmail.com>
> Cc: bug-gnu-emacs <at> gnu.org, 35179 <at> debbugs.gnu.org
> Date: Sun, 07 Apr 2019 08:51:12 -0600
> 
> > I'd prefer to leave g_strdup intact, and instead explicitly release the storage of previous value.  IOW, plug the leak in our own code, not rely on undocumented features which can easily go away some day.
> 
> The documentation of gdk_monitor_get_model[1] specifies that the return
> value is "[transfer none]", which has the description "Don't free data
> after code is done".

That could mean anything.  The only thing it tells us not to call
'free' on the result, but it could be, for example, that the result is
a pointer to a static buffer that can be changed by a subsequent call
to the function.

> The main memory leak, though, was that the MonitorList array wasn't
> being freed.

Does your patch change that?  If not, why not?

> I considered using the free_monitors procedure like the non-GTK
> versions do, but I saw no reason to call g_strdup for each name and
> free each name almost right after.

I don't see how the short lifetime of the array changes anything
here.  As long as we aren't sure the pointer returned by
gdk_monitor_get_model is a copy that cannot be changed by another
thread, we should ourselves make a copy.  Otherwise, who can ensure us
that some other GTK thread doesn't call this same function during the
short life time of the array?

> Since make_monitor_attribute_list uses make_string on each name, I don't
> see any issues that this removal would cause.

The issue I see is that between the time we call gdk_monitor_get_model
and the time we use the string something could change the string to
which the pointer points.  If you can spot something in the GDK docs
that guarantees this couldn't happen, please point me to that piece of
docs.

Message #23 received at 35179 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 35179 <at> debbugs.gnu.org
Subject: Re: bug#35179: [PATCH] Plug memory leak in
 GTK	x-display-monitor-attributes-list
Date: Sun, 07 Apr 2019 11:34:28 -0600

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> The main memory leak, though, was that the MonitorList array wasn't
>> being freed.
>
> Does your patch change that?  If not, why not?

It did, yes. That was the xfree (monitors) call.

>> I considered using the free_monitors procedure like the non-GTK
>> versions do, but I saw no reason to call g_strdup for each name and
>> free each name almost right after.
>
> I don't see how the short lifetime of the array changes anything
> here.  As long as we aren't sure the pointer returned by
> gdk_monitor_get_model is a copy that cannot be changed by another
> thread, we should ourselves make a copy.  Otherwise, who can ensure us
> that some other GTK thread doesn't call this same function during the
> short life time of the array?

The documentation does state that the name property of the monitor is
read-only.

>> Since make_monitor_attribute_list uses make_string on each name, I don't
>> see any issues that this removal would cause.
>
> The issue I see is that between the time we call gdk_monitor_get_model
> and the time we use the string something could change the string to
> which the pointer points.  If you can spot something in the GDK docs
> that guarantees this couldn't happen, please point me to that piece of
> docs.

Well, I suppose that the monitor could be unplugged in-between, which
presumably would mean that the monitor object is freed. Would that space
be reused in-between, though?

I suppose it doesn't hurt to play it safe, so I updated the patch to use
free_monitors instead:

[0001-Plug-memory-leak-in-GTK-x-display-monitor-attributes.patch (text/x-patch, attachment)]

Message #26 received at 35179 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 35179 <at> debbugs.gnu.org
Subject: Re: bug#35179: [PATCH] Plug memory leak in
 GTK	x-display-monitor-attributes-list
Date: Sun, 07 Apr 2019 11:44:54 -0600

[Message part 1 (text/plain, inline)]

Whoops, I forgot to add a closing parenthesis...

[0001-Plug-memory-leak-in-GTK-x-display-monitor-attributes.patch (text/x-patch, attachment)]

Message #29 received at 35179 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 35179 <at> debbugs.gnu.org
Subject: Re: bug#35179: [PATCH] Plug memory leak in
 GTK	x-display-monitor-attributes-list
Date: Sun, 07 Apr 2019 21:21:20 +0300

> From: Alex <agrambot <at> gmail.com>
> Cc: 35179 <at> debbugs.gnu.org
> Date: Sun, 07 Apr 2019 11:44:54 -0600
> 
> Whoops, I forgot to add a closing parenthesis...

Thanks.  This variant is fine with me, but since we use xfree to free
the name, I think we should use xstrdup, not g_strdup, to copy it, as
the latter is documented to need g_free to free the storage.

Message #32 received at 35179 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 35179 <at> debbugs.gnu.org
Subject: Re: bug#35179: [PATCH] Plug memory leak in
 GTK	x-display-monitor-attributes-list
Date: Sun, 07 Apr 2019 12:52:45 -0600

close 35179
quit

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Alex <agrambot <at> gmail.com>
>> Cc: 35179 <at> debbugs.gnu.org
>> Date: Sun, 07 Apr 2019 11:44:54 -0600
>> 
>> Whoops, I forgot to add a closing parenthesis...
>
> Thanks.  This variant is fine with me, but since we use xfree to free
> the name, I think we should use xstrdup, not g_strdup, to copy it, as
> the latter is documented to need g_free to free the storage.

Okay, I pushed it as a35e06bbe2. I also added in a GTK version check
since `name' isn't used if !GTK_CHECK_VERSION(2, 14, 0).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.