Add tests in which `g_object_run_dispose()` is called on the source or target
of a `GBinding`. After commit a4fa456e67,
the target test caused a failed assertion in `g_weak_ref_set()` that was not
found by the existing tests. Commit 94ba14d542
weakens the assertion to allow the test to succeed.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2676
When weak references are being cleaned up, it is possible for the `qdata` for
both `quark_weak_locations` and `quark_weak_refs` to have been deallocated,
so that `g_datalist_id_get_data()` returns `NULL` for both. This happens
when `g_object_run_dispose()` is called for the target of a `GBinding`,
and is not an error.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2676
It’s failed on a CI machine
(https://gitlab.gnome.org/GNOME/glib/-/jobs/2006694) with log:
```
[unused] => pushed 100 threads onto the idle pool
[unused] stopping unused threads
[unused] waiting ONE second for threads to die
[unused] waiting ONE second for threads to die
[unused] waiting ONE second for threads to die
[unused] waiting ONE second for threads to die
[unused] waiting ONE second for threads to die
[unused] stopped idle threads, 9 remain
Bail out! GLib:ERROR:../glib/tests/thread-pool-slow.c:113:test_thread_stop_unused: assertion failed (g_thread_pool_get_num_unused_threads () == 0): (9 == 0)
```
I can’t reproduce this locally, but it’s possible that it failed because
a one second wait was not enough to enqueue all the jobs (on a heavily
loaded machine), and hence some jobs spawned thread pool threads after
calling `g_thread_pool_stop_unused_threads()`, leading to the assertion
failure.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While `gio_xdgmime` is unlocked, the data which `type` points to in the
xdgmime cache might get invalidated, leaving `type` as a dangling
pointer. That would not bode well for the `g_strdup (type)` call to
insert a new entry into the `type_comment_cache` once `gio_xdgmime` is
re-acquired.
This was spotted using static analysis, and the symptoms have not
knowingly been seen in the wild.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1474702
We should mention glib-mkenums in the documentation for
G_DEFINE_ENUM_TYPE and G_DEFINE_FLAGS_TYPE.
We should also mention the macros in the documentation for glib-mkenums.
This way, developers can choose the most appropriate tool for their use
case.
While you might want to use automated tools like glib-mkenums to
generate enumeration types for your library, it's often not entirely
necessary to complicate your build system in order to handle a couple of
enumerations with few values.
Just like we have G_DEFINE macros for object, interface, pointer, and
boxed types, we should provide macros for defining enum and flags types.
We have fallback in places for GNU's variadic arguments in macros, and
for static inline functions with variadic arguments as an fallback of
last resort, but going forward we are going to depend on `__VA_ARGS__`
for macros that cannot be re-implemented using a static inline function.
Fixes: #2681
Since the macOS CI jobs are run on a machine which isn’t using a
pre-made container image, we can’t ship a cached version of the
subproject, so it has to be pulled as a git submodule.
GitLab doesn’t do that by default unless you set
`GIT_SUBMODULE_STRATEGY` to something other than `none`.
See https://docs.gitlab.com/ee/ci/git_submodules.html
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Some of the CI runners disable ptrace, as they’re running inside a
container and ptrace would allow container escape. On those systems, gdb
can’t work, so skip the gdb test.
Add some additional stderr debug output to make it clear that’s the
case.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This will catch buggy implementations of GProxyResolver before they are
able to return bogus results to higher level code. In particular, if
g_proxy_resolver_lookup() returns NULL, it'd better set an error to
explain why.
It doesn't make sense for a proxy resolver to return NULL without an
error on the first call. Whereas a DNS resolver would do this to
indicate that a query completed successfully but found no results, a
proxy resolver should return "direct://" instead. Therefore, if we are
going to return NULL, we ought to have an error as well. Let's make sure
this actually happens by adding some fallback errors just in case
GProxyResolver feeds us weird results.
Additionally, we should not return any errors except
G_IO_ERROR_CANCELLED after the very first iteration. This is an API
contract of GSocketAddressEnumerator. Let's add some checks to ensure
this.
Note that we have inadequate test coverage for GProxyAddressEnumerator.
It's tested here only via GSocketClient. We could do a bit better by
testing it directly as well. For example, I've added tests to see what
happens when GProxyResolver returns both a valid and an invalid URI, but
it's not so interesting here because GSocketClient always uses the valid
result and ignores the error from GProxyAddressEnumerator.
Fixes#2597
This has no practical impact, since it's only a test, and none of the
test code would have hit this bug, but the GTestProxyResolver's check to
see if the URI scheme is simple:// currently only compares the first
four bytes of the string, so it's actually only checking for the "simp"
and would match anything else after that, e.g. "simpleton://". This is
surely not intended.
This is in preparation for porting `GRegex` to libpcre2, which is
happening in !2529. It’s a big port, though, and specially rebuilding
the CI images to add libpcre2 for it is a pain.
Add libpcre2, and then !2529 can drop the old libpcre dependencies when
the port lands.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1085
This will be useful in general, for manually debugging failures if we
need (without having to rebuild the CI images to do so).
It will also be useful for the `assert-msg-test` test, which is being
reworked in !2767.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1434
This was causing intermittent failures on macOS, depending on whether
the tmpdir ended with a `/` or `/some-dir`. `g_strrstr()` is not the
right function to use to extract a basename from a path, for this
reason.
When it failed, the macOS test was failing with:
```
ok 16 /gsubprocess/env
Bail out! GLib-GIO:ERROR:../gio/tests/gsubprocess.c:1507:test_cwd: assertion failed (basename == tmp_lineend_basename): ("/T\n" == "/\n")
```
The test now passes reliably, which means that it can be removed from
the list of expected failures on macOS.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1392
