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 is copied from the GTK source tree to put into our builds so that
we can generate a manifest file to pacify UAC on Windows for 32-bit
builds, as UAC will kill any 32-bit processes that it believes will
be an installer or will alter the system in any ways.
This will be used to fix running the custom-dispatch test program on
32-bit Windows builds.
Various projects are running tests under valgrind, and they are using
the GLib suppresions to avoid false-positive results.
While this is stored in a well-known path for some years, and easy to
figure out from the GLib prefix, it's better to expose it through a
proper pkgconfig variable so that it's easy to get it from any build
system.
It hasn’t been used for years, and isn’t really needed since we changed
to explicitly exporting symbols (using `GLIB_AVAILABLE_IN_*`) rather than
implicitly exporting them unless they were hidden.
Signed-off-by: Philip Withnall <pwithnall@endlessos.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.
It contains a lot of C templates, and line wrapping them to satisfy
`flake8` would make them unreadable.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
There is currently no `dllimport` attribute on any of our function,
which prevents MSVC to optimize function calls.
To fix that issue, we need to redeclare all our visibility macros for
each of our libraries, because when compiling e.g. GIO code, we need
dllimport in GLIB headers and dllexport in GIO headers. That means they
cannot use the same GLIB_AVAILABLE_* macro.
Since that's a lot of boilerplate to copy/paste after each version bump,
this MR generate all those macros using a python script.
Also simplify the meson side by using `gnu_symbol_visibility : 'hidden'`
keyword argument instead of passing the cflag manually.
This leaves only API index to add manually into glib-docs.xml when
bumping GLib version. That file cannot be generated because Meson does
not allow passing a buit file to gnome.gtkdoc()'s main_xml kwarg
unfortunately.
We need to perform multiple actions on unicode updates, so let's handle
all the commands in a single script so that we don't have to remember
all the details each time.
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
Those tools are not needed at runtime for typical applications,
distributions typically package them separately.
This makes `meson install --tag runtime` skip installation of those
tools. Omitting `--tag` argument will still install them, as well as
with `--tag bin,bin-devel`.
See https://mesonbuild.com/Installing.html#installation-tags.
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>
As a developer tool, it’s licensed under GPL-2.0-or-later (as per the
existing license comment in the file).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
