unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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


  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

  List information: https://www.gnu.org/software/emacs/

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