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

[Eli Zaretskii <eliz@gnu.org>]

> From: Alex <agrambot@gmail.com>
> Cc: bug-gnu-emacs@gnu.org, 35179@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.