From: Alex <agrambot@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 35179@debbugs.gnu.org
Subject: bug#35179: [PATCH] Plug memory leak in GTK x-display-monitor-attributes-list
Date: Sun, 07 Apr 2019 11:34:28 -0600 [thread overview]
Message-ID: <87wok5u3bv.fsf@gmail.com> (raw)
In-Reply-To: <83wok593ny.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 07 Apr 2019 19:32:49 +0300")
[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]
Eli Zaretskii <eliz@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:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: v2 --]
[-- Type: text/x-patch, Size: 1931 bytes --]
From 490ec531943540cb882b46624a4b7b3b1463a4b8 Mon Sep 17 00:00:00 2001
From: Alexander Gramiak <agrambot@gmail.com>
Date: Sat, 6 Apr 2019 23:02:24 -0600
Subject: [PATCH] Plug memory leak in GTK x-display-monitor-attributes-list
* src/frame.c (free_monitors) [USE_GTK]: Define in the GTK case as
well.
* src/xfns.c (x-display-monitor-attributes-list) [USE_GTK]: Plug
memory leak.
* src/frame.h (MonitorInfo): Declare name as pointing to const char.
---
src/frame.c | 4 ++--
src/frame.h | 2 +-
src/xfns.c | 1 +
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/frame.c b/src/frame.c
index d0c77149ba..e57f17ded4 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -5662,8 +5662,8 @@ selected frame. This is useful when `make-pointer-invisible' is set. */)
#ifdef HAVE_WINDOW_SYSTEM
-# if (defined HAVE_NS \
- || (!defined USE_GTK && (defined HAVE_XINERAMA || defined HAVE_XRANDR)))
+# if (defined USE_GTK || defined HAVE_NS || defined HAVE_XINERAMA \
+ || defined HAVE_XRANDR
void
free_monitors (struct MonitorInfo *monitors, int n_monitors)
{
diff --git a/src/frame.h b/src/frame.h
index ed62e7ace0..b1eedf36a3 100644
--- a/src/frame.h
+++ b/src/frame.h
@@ -1648,7 +1648,7 @@ flush_frame (struct frame *f)
struct MonitorInfo {
XRectangle geom, work;
int mm_width, mm_height;
- char *name;
+ const char *name;
};
extern void free_monitors (struct MonitorInfo *monitors, int n_monitors);
diff --git a/src/xfns.c b/src/xfns.c
index f238a3daa1..33595afc1e 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -5041,6 +5041,7 @@ Internal use only, use `display-monitor-attributes-list' instead. */)
primary_monitor,
monitor_frames,
source);
+ free_monitors (monitors, n_monitors);
unblock_input ();
#else /* not USE_GTK */
--
2.21.0
next prev parent reply other threads:[~2019-04-07 17:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-07 5:16 bug#35179: [PATCH] Plug memory leak in GTK x-display-monitor-attributes-list Alex
2019-04-07 6:37 ` Eli Zaretskii
2019-04-07 14:51 ` Alex
2019-04-07 16:32 ` Eli Zaretskii
2019-04-07 17:34 ` Alex [this message]
2019-04-07 17:44 ` Alex
2019-04-07 18:21 ` Eli Zaretskii
2019-04-07 18:52 ` Alex
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wok5u3bv.fsf@gmail.com \
--to=agrambot@gmail.com \
--cc=35179@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.