If a transient worker thread calls it, the allocated memory is
definitely leaked when the thread exits. That’s intentional.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If a transient worker thread calls it, the allocated memory is
definitely leaked when the thread exits. That’s intentional.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It's currently marked only as reachable but Valgrind also finds it as
possible:
==18842== 96 bytes in 1 blocks are possibly lost in loss record 2,029 of 2,284
==18842== at 0x4837B65: calloc (vg_replace_malloc.c:762)
==18842== by 0x49614AD: g_malloc0 (gmem.c:129)
==18842== by 0x4A7013B: type_node_any_new_W (gtype.c:439)
==18842== by 0x4A70609: type_node_fundamental_new_W (gtype.c:550)
==18842== by 0x4A7855A: gobject_init (gtype.c:4406)
==18842== by 0x4A78672: gobject_init_ctor (gtype.c:4493)
Mark all the memcheck leaks as ‘reachable’, so the suppressions will not
apply if that memory is no longer reachable on exit(). This feature was
introduced in Valgrind 3.9, and is documented here:
http://valgrind.org/docs/manual/mc-manual.html#mc-manual.suppfiles
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This suppression is not caught by glib.supp, so add it:
==21145== 32 bytes in 1 blocks are possibly lost in loss record 1,456 of 2,584
==21145== at 0x4837B65: calloc (vg_replace_malloc.c:762)
==21145== by 0x495825E: g_malloc0 (gmem.c:129)
==21145== by 0x4A6B6EB: type_class_init_Wm (gtype.c:2134)
==21145== by 0x4A6D22A: g_type_class_ref (gtype.c:2950)
==21145== by 0x4A6D1DD: g_type_class_ref (gtype.c:2942)
==21145== by 0x4A5C9C6: g_param_spec_enum (gparamspecs.c:2085)
Various memory allocations are still reachable when a process exits, as
they contain type system information which can’t be unloaded. Suppress
those using `glib.supp`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1879
There are some cases where valgrind turns up leaks that are already
suppressed in the file, but with a slight difference at the top of the
stack. Add suppressions for these cases as well.
This is a wrapper around g_private_set() which allocates the desired
amount of memory for the caller and calls g_private_set() on it.
This is intended to make it easier to suppress Valgrind warnings about
leaked memory, since g_private_set() is typically used to make one-time
per-thread allocations. We can now just add a blanket suppression rule
for any allocations inside g_private_set_alloc0().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Add a new internal function, g_set_user_dirs(), which will safely
override the values returned by g_get_user_data_dir() and friends, and
the value returned by g_get_home_dir().
This is intended to be used by unit tests, and will be hooked up to them
in a following commit.
This can be called as many times as needed by the current process. It’s
thread-safe. It does not modify the environment, so none of the changes
are propagated to any subsequently spawned subprocesses.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/538
Split out the code which calculates each XDG variable value from the
code which caches it, so that GLib can internally recalculate the
variables if needed, without necessarily trashing the user-visible
cache.
This will be useful in a following commit to add support for explicitly
reloading the variables.
This commit necessarily reworks how g_get_user_runtime_dir() is
structured, since it was inexplicably structured differently from (but
equivalently to) the other XDG variable functions.
Future refactoring could easily share a lot more code between these
g_build_*() functions.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/538
Sometimes valgrind doesn’t count the calloc() call at the innermost
stack frame, and counts it as g_type_create_instance() instead.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
These were spotted by running the entire test suite under valgrind,
thanks to the magic of Meson: see the build rules in valgrind-x86_64 in
.gitlab-ci.yml.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Valgrind will check that the third argument to ioctl() is a valid
pointer, but some ioctls interpret that argument as an integer, and that
is the case here (it's a file descriptor), so this is a false positive.
https://bugzilla.gnome.org/show_bug.cgi?id=787109
While we cannot get Valgrind to automatically load this suppression file
for applications which link to GLib
(https://bugs.kde.org/show_bug.cgi?id=160905), we can at least install
it on systems in a shared directory, so that developers can use a
standardised (and up-to-date) suppressions file for GLib, rather than
rolling their own.
The file will typically be installed to:
/usr/share/glib-2.0/valgrind/glib.supp
Distributors: it is recommended that this suppression file be installed
as part of the development package for GLib in your distribution.
https://bugzilla.gnome.org/show_bug.cgi?id=666114
