The problem is that resetting the environment of a
proccess is not safe, this is mentioned in the man
pages of the setenv, and also by the concept:
when we get a constant string returned by the getenv,
we need to be guaranteed that this string will exist
during all that time we are using it. While setting
the same env var to another value destroys this string
inside of libc.
Now looking at the should_drop_message(), we can see
that it just gets the environment on every call. Getting
the environment is safe, but however there's no safe way
to switch the logging domains selection: setenv can't be
used because of the reasons listed above.
That is why g_log_writer_default_set_debug_domains() is
needed: it's just a safe replacement for the setenv in this case.
Now should_drop_message() still reads the environment, but
does so only on the first call, after that the domains are
stored internally, and can only be changed by
g_log_writer_default_set_debug_domains().
This also means that now resetting G_MESSAGES_DEBUG env
var in runtime has no effect. But in any case this is not
what the user should do, because resetting the environment
in runtime is not correct.
These are one-time leaks, and happen if the util dir paths are built via
these code paths, and then subsequently overwritten using
`g_set_user_dirs()` (typically as part of a unit test).
The additions to `glib.supp` correspond to the `g_ignore_leak()` calls
in `gutils.c`. Unfortunately `g_ignore_leak()` only affects asan, not
valgrind.
See https://gitlab.gnome.org/GNOME/glib/-/jobs/3294034
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
These are one-time allocations which are still reachable at the end of
the process. They cause warnings like this in valgrind:
```
==14408== 128 bytes in 1 blocks are definitely lost in loss record 1,287 of 1,403
==14408== at 0x4847A40: realloc (vg_replace_malloc.c:1649)
==14408== by 0x48CCD6E: g_realloc (gmem.c:201)
==14408== by 0x48F4CB1: g_string_expand (gstring.c:82)
==14408== by 0x48F4D59: g_string_sized_new (gstring.c:113)
==14408== by 0x48F4D91: g_string_new (gstring.c:134)
==14408== by 0x48A5805: g_build_path_va (gfileutils.c:1929)
==14408== by 0x48A62D1: g_build_filename_va (gfileutils.c:2222)
==14408== by 0x48A63FE: g_build_filename (gfileutils.c:2316)
==14408== by 0x491CD89: g_build_user_data_dir (gutils.c:1879)
==14408== by 0x491CDCF: g_get_user_data_dir (gutils.c:1920)
==14408== by 0x4B51E53: _g_content_type_set_mime_dirs_locked (gcontenttype.c:145)
==14408== by 0x4B51F33: g_content_type_set_mime_dirs (gcontenttype.c:194)
==14408== by 0x40C222: main (desktop-app-info.c:1880)
```
For example in https://gitlab.gnome.org/GNOME/glib/-/jobs/3278564
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This should stop the following valgrind error:
```
==14506== 80 bytes in 1 blocks are definitely lost in loss record 1,098 of 1,463
==14506== at 0x484086F: malloc (vg_replace_malloc.c:381)
==14506== by 0x48C5D83: g_malloc (gmem.c:130)
==14506== by 0x48E7911: g_slice_alloc (gslice.c:1074)
==14506== by 0x48E7951: g_slice_alloc0 (gslice.c:1100)
==14506== by 0x493617D: g_system_thread_new (gthread-posix.c:1188)
==14506== by 0x48F9EAA: g_thread_new_internal (gthread.c:935)
==14506== by 0x48F9E29: g_thread_try_new (gthread.c:919)
==14506== by 0x48FA351: g_thread_pool_spawn_thread (gthreadpool.c:312)
==14506== by 0x48F9D2C: g_thread_proxy (gthread.c:831)
==14506== by 0x4EFA2A4: start_thread (in /usr/lib64/libpthread-2.33.so)
==14506== by 0x4D89322: clone (in /usr/lib64/libc-2.33.so)
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We may need to avoid using a cached temp directory for testing purposes,
so let's provide an internal API to perform such task.
This implies removing GOnce and going with mutex-based version, but
that's still using atomic logic in most unix implementations anyways.
These leaks happens "by design" in case that the private API
g_set_user_dirs() is used to replace directories during some tests.
And we've to leak the previously set values (if any) not to free strings
that may be used by other user code before.
In fact we're already ignoring LSAN reports for the very same reason
here.
We could create a private suppression file too, but I don't think we've to
bother with that, given that user code should never hit this path
anyways.
It's the only leak we have, sooo:
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/333
xdgmime makes some one-off allocations when being set up. Ignore them in
the suppression file, since they’re not really a leak.
This should fix the contenttype test running under valgrind.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
