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.
This should catch regressions in the critical warning fixed in the
previous commit.
The launch has to have several conditions:
- Session bus is running (to avoid the launch happening via the spawn
codepath)
- Use a non-existent D-Bus name (to trigger a launch error)
- Use a launch context (to hit the critical warning code path)
- Not have a startup ID specified in the platform data — this implies
having an empty launch context
- Use an async launch, as that provides an error handling path
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s possible for the startup ID to be `NULL` if one wasn’t provided in
the platform data passed to `launch_uris_with_dbus()`.
Passing `NULL` to `g_app_launch_context_launch_failed()` causes a
critical warning.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The timeout runs for the entire duration of the test, which is a
function that Meson’s test harness already provides for us.
Meson’s timeout can be easily adjusted by a factor to allow for running
tests more slowly under valgrind. The timeout in the code cannot, which
leads to spurious failures like
https://gitlab.gnome.org/GNOME/glib/-/jobs/2645271.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If the timeout callback was executed, it would remove the timeout
source, leaving the `g_source_remove()` call in the main function with a
dangling source ID.
Fixes commit 73205b8bbd.
Spotted in https://gitlab.gnome.org/GNOME/glib/-/jobs/2645271.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The current comparison has been seen to fail on vs2017-x86
(https://gitlab.gnome.org/pwithnall/glib/-/jobs/2643197):
```
not ok /bookmarks/deprecated - GLib:ERROR:../glib/tests/bookmarkfile.c:921:test_deprecated: assertion failed (t >= now): (1678122080 >= 1678122081)
```
I guess this is caused by a mismatch between the system clock as used by
`time (NULL)` and `g_get_real_time ()` (which is ultimately what
`g_bookmark_file_set_added()` uses) on Windows.
Attempt to fix that by using `g_get_real_time()` in the test harness
too, so the clock being used is consistent.
If that doesn’t work, my next guess is that some of the code in
`test_deprecated()` is being reordered by the compiler. But that
shouldn’t happen, because the `time()` call has side-effects, and
`g_bookmark_file_set_added()` has side-effects, so they shouldn’t be
reordered with respect to each other. And certainly not so that the
latter one (in code order) ends up being called 1s after the other.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Previously it was only being set on non-Windows platforms. For
consistency, always set it on Windows too.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2934
Following on from #2907, set various boolean attributes if they have
been requested, or are known for sure, and their value is `FALSE`.
Previously the `FALSE` value would have been implicitly returned by the
getter function, but now doing that without the attribute being
explicitly set will trigger a critical warning.
*Don’t* set these attributes if their value is unknown or there was an
error querying it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2934
The `is-backup` attribute isn't currently set on Windows. It would
be nice to set such basic attributes on all platforms. Let's set
the attribute to `FALSE` there.
Currently, the `G_FILE_ATTRIBUTE_STANDARD_IS_BACKUP` attribute is set
only when its value is `TRUE`. This is wrong with the latest changes as
the `GLib-GIO-CRITICAL **: 00:54:07.260: GFileInfo created without
standard::is-backup` errors are printed now from the
`g_file_info_get_is_backup` function among others. Let's set this
aattribute also when it is `FALSE`.
Related: https://gitlab.gnome.org/GNOME/glib/-/issues/2934
The lost+found dir isn't detected as hidden currently. This is regression
caused by the commit 728ad64b. Let's change the code a bit to be sure that
the lost+found dir is marked as hidden again.
When the `g_file_copy` function is used with files on BTRFS, the
`GLib-GIO-FATAL-CRITICAL: GFileInfo created without standard::size`
error is printed. This is because the `g_file_get_size` function
is used to obtain the file size for the progress callback, but it uses
the wrong `GFileInfo` object that is meant for attributes to be copied
with the file. The file size attribute is missing there obviously. Let's
obtain the file size over the `fstat` call the same way as it is done in
the `splice_stream_with_progress` function to get rid of those errors
and to fix the progress reporting.
Similar to commit 6e44151bf7, skip the test if gdb is unable to read
/proc/PID/mem, which gdb does as a fallback if ptrace is unavailable.
This allows the test to skip when run under Gentoo's sandbox.
