58f54e8303
When checking that the connection has the expected number of refs, the test would block on a `GMainContext` iteration for up to 3s before waking up and failing (if the refcount was still not as expected). This check was written in the expectation that changing the refcount of the connection would only happen due to dispatching a source on `GMainContext` — hence the `GMainContext` would wake up as the refcount changed. That’s probably not actually true though. It might be the case that the connection’s refcount is changed on from the GDBus worker thread, which would not cause any wakeups on the main thread’s `GMainContext`. In this case, the `GMainContext` iteration in `assert_connection_has_one_ref()` would block for the full 3s, and then wake up and notice the refcount is correct (then the test would proceed). That’s fine, apart from the fact that `test_threaded_singleton()` does this 1000 times. If the slow case is hit on a significant number of those test runs, the test will take around 3000s to complete, which is significantly more than meson’s test timeout of 360s. So the test fails with something like: ``` 220/266 glib:gio+slow / gdbus-threading TIMEOUT 360.07 s --- command --- G_TEST_SRCDIR='/builds/GNOME/glib/gio/tests' GIO_MODULE_DIR='' G_TEST_BUILDDIR='/builds/GNOME/glib/_build/gio/tests' /builds/GNOME/glib/_build/gio/tests/gdbus-threading --- stdout --- \# random seed: R02S83fe8de22db4d4f376e6d179e2bdd601 1..3 \# Start of gdbus tests ok 1 /gdbus/delivery-in-thread ok 2 /gdbus/method-calls-in-thread \# GLib-GIO-DEBUG: refcount of 0x5602de913660 is not right (3 rather than 1) in test_threaded_singleton(), sleeping \# GLib-GIO-DEBUG: refcount of 0x5602de913660 is not right (3 rather than 1) in test_threaded_singleton(), sleeping \# GLib-GIO-DEBUG: refcount of 0x5602de913c60 is not right (3 rather than 1) in test_threaded_singleton(), sleeping \# GLib-GIO-DEBUG: refcount of 0x5602de913c60 is not right (3 rather than 1) in test_threaded_singleton(), sleeping \# GLib-GIO-DEBUG: refcount of 0x5602de913260 is not right (3 rather than 1) in test_threaded_singleton(), sleeping \# GLib-GIO-DEBUG: refcount of 0x5602de913260 is not right (3 rather than 1) in test_threaded_singleton(), sleeping ``` From this log, it can be seen that the sleep is happening on a different `GMainContext` every other time, so the test *is* making progress. Assuming this is a correct diagnosis (it’s a lot of guessing), this commit tries to fix the test by adding a wakeup timeout to the `GMainContext` in `assert_connection_has_one_ref()`, which will wake it up every 50ms to re-check the exit condition. This polling approach has been taken because it doesn’t seem feasible to make sure that every `g_object_ref()`/`g_object_unref()` call on a `GDBusConnection` causes the main context to wake up. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
GLib
GLib is the low-level core library that forms the basis for projects such as GTK and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system.
The official download locations are: https://download.gnome.org/sources/glib
The official web site is: https://www.gtk.org/
Installation
See the file 'INSTALL.in'
Supported versions
Only the most recent unstable and stable release series are supported. All older versions are not supported upstream and may contain bugs, some of which may be exploitable security vulnerabilities.
See SECURITY.md for more details.
Documentation
API documentation is available online for GLib for the:
Discussion
If you have a question about how to use GLib, seek help on GNOME’s Discourse
instance. Alternatively, ask a question
on StackOverflow and tag it glib.
Reporting bugs
Bugs should be reported to the GNOME issue tracking system. You will need to create an account for yourself. You may also submit bugs by e-mail (without an account) by e-mailing incoming+gnome-glib-658-issue-@gitlab.gnome.org, but this will give you a degraded experience.
Bugs are for reporting problems in GLib itself, not for asking questions about how to use it. To ask questions, use one of our discussion forums.
In bug reports please include:
- Information about your system. For instance:
- What operating system and version
- For Linux, what version of the C library
- And anything else you think is relevant.
- How to reproduce the bug.
- If you can reproduce it with one of the test programs that are built
in the
tests/subdirectory, that will be most convenient. Otherwise, please include a short test program that exhibits the behavior. As a last resort, you can also provide a pointer to a larger piece of software that can be downloaded.
- If you can reproduce it with one of the test programs that are built
in the
- If the bug was a crash, the exact text that was printed out when the crash occurred.
- Further information such as stack traces may be useful, but is not necessary.
Contributing to GLib
Please follow the contribution guide to know how to start contributing to GLib.
Patches should be submitted as merge requests to gitlab.gnome.org. If the patch fixes an existing issue, please refer to the issue in your commit message with the following notation (for issue 123):
Closes: #123
Otherwise, create a new merge request that introduces the change. Filing a separate issue is not required.
Default branch renamed to main
The default development branch of GLib has been renamed to main. To update
your local checkout, use:
git checkout master
git branch -m master main
git fetch
git branch --unset-upstream
git branch -u origin/main
git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main