all messages for Emacs-related lists mirrored at yhetil.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 08:51:12 -0600	[thread overview]
Message-ID: <871s2dvpgf.fsf@gmail.com> (raw)
In-Reply-To: <BC10A5FB-146F-4F35-9986-F087336B07A2@gnu.org> (Eli Zaretskii's message of "Sun, 07 Apr 2019 09:37:29 +0300")

Eli Zaretskii <eliz@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





  reply	other threads:[~2019-04-07 14:51 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 [this message]
2019-04-07 16:32     ` Eli Zaretskii
2019-04-07 17:34       ` Alex
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=871s2dvpgf.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.