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
next prev parent 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.