This fixes a race condition which frequently caused the
`memory-monitor-dbus.py` test to fail.
The registration of the `LowMemoryMonitor` object on the bus, and the
`GMemoryMonitorDBus`’s connection to the warning signal raced, such that
it was possible for the mock `LowMemoryMonitor` to emit a warning signal
before the `GMemoryMonitorDBus` proxy was listening, and hence the proxy
would never see the signal.
Fix this by explicitly synchronising the two before proceeding to the
tests.
Make the same changes in the `memory-monitor-portal.py` test too, even
though that one was not failing. This should remove the need for a 2s
wait on every test run.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #2887
Otherwise the test can go on to wait for a signal from the service
before it’s actually finished starting up.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #2887
Rather than sleeping and blocking everything, use a timeout source on
the main context so that inputs can continue to be handled while waiting
for a timeout.
This introduces no functional changes to the test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #2887
It should be doing already (or the tests would never work), but make it
clearer in the code that the same `GMainContext` is being iterated as is
being woken up in the rest of the test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #2887
I ran Bustle/dbus-monitor on the session bus while running the full GLib
test suite, and noticed that these tests were causing `Launched` signal
emissions on the main session bus. That suggested they weren’t isolated
properly, which at best causes noise on the bus and at worst could cause
spurious test failures.
Fix that by running those tests in a `GTestDBus` environment, as some of
the other appinfo tests already are.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
As seen in [CI](https://gitlab.gnome.org/GNOME/glib/-/jobs/3436216):
```
==13767== 144 (40 direct, 104 indirect) bytes in 1 blocks are definitely lost in loss record 528 of 562
==13767== at 0x4A18B2C: g_type_create_instance (gtype.c:1928)
==13767== by 0x49F92FF: g_object_new_internal (gobject.c:2235)
==13767== by 0x49FA247: g_object_new_valist (gobject.c:2574)
==13767== by 0x49F8D81: g_object_new (gobject.c:2047)
==13767== by 0x4AE2337: g_inet_socket_address_new (ginetsocketaddress.c:387)
==13767== by 0x4B1DB94: g_socket_address_new_from_native (gsocketaddress.c:230)
==13767== by 0x4B16CC2: g_socket_get_local_address (gsocket.c:2071)
==13767== by 0x40E102: test_receive_bytes_from (socket.c:2469)
==13767== by 0x4901E78: test_case_run (gtestutils.c:2974)
==13767== by 0x49022B2: g_test_run_suite_internal (gtestutils.c:3069)
==13767== by 0x490241A: g_test_run_suite_internal (gtestutils.c:3088)
==13767== by 0x4902690: g_test_run_suite (gtestutils.c:3168)
==13767== by 0x4900C8F: g_test_run (gtestutils.c:2275)
==13767== by 0x40EE8A: main (socket.c:2614)
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3220
There are several reasons why we might not be able to do the test setup
for --external-data: non-Linux platform, missing ld or objcopy,
objcopy doesn't support --add-symbol, or the CPU family is MIPS
(on which cc -r does not necessarily emit the specific MIPS ABI flavour
that we are targeting, for example different functionality levels or
different NaN encodings).
If we can't link in the test data, then obviously this test is not going
to pass. It was already skipped on non-Linux, but not on platforms that
hit one of the other reasons for the test setup to fail.
In particular, this test failed on Debian mips64el since commit 81059169,
which stopped linking the necessary resource on MIPS platforms, but
continued to assert that the resource is present at runtime.
Fixes: 81059169 "GIO/tests: skip test_resources_binary on MIPS platform"
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3226
Signed-off-by: Simon McVittie <smcv@debian.org>
The same struct was reused across multiple tests, but without a shared
way of freeing its members. Refactor to add one.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This is just the result of running `black $(git ls-files '*.py')`.
For some reason, the `sh-and-py-check` CI job didn’t run on merge
request !3751, so this non-standard formatting slipped through onto
`main`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3754#note_1939914
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It can cause failures for shared connection objects.
What can currently happen is this:
1. A user starts to asynchronously create a proxy object
2. A user starts to asynchronously create another proxy object
At this point, the asynchronous initialization for the two proxy objects
share the not yet initialized connection object.
3. While the shared connection objected is created, the user cancels the
creation with the supplied cancellable from the fist proxy object.
4. initable_init caches the canceled error and marks the connection as
initialized.
5. The initialization of the second proxy object fails with the same
canceled error.
To avoid this, clear the error in this case and destroy any member
variables that may have been created before the creation was canceled.
This way, the initialization of the second proxy object will restart the
connection initialization and with probably succeed.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
See the previous commit. These additions were kept in a separate commit
to make the changes to the existing tests in the previous commit
clearer.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3093
Previously, the code only validated the types of *required* message
headers, and did not validate optional ones.
Now, the headers are validated in one step, and a subsequent step checks
whether the required ones are present.
The existing tests have been updated to match the new error message
wording. More tests will be added to test the new behaviour in a
subsequent commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3093
Before checking the properties of `*_proxy`, assert that there were no
errors in constructing the proxy first. Otherwise the property checks
will crash on `NULL` pointer dereferences.
The test is still intermittently buggy somewhere, but at least this
commit will cause a relevant error message to be printed on failure.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
GDBus has always supported matching strings with arg0 matching
(`G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_PATH`). In D-Bus 1.5, support was added
to the spec for also matching object paths. This got forgotten about and
was never added to GDBus, meaning that
`G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_PATH` won’t match against a signal arg0
of type `o`.
Fix that, and add a unit test.
To do so, we need to add a new `g_dbus_message_get_arg0_path()` API to
complement the existing `g_dbus_message_get_arg0()` API. The approach of
letting `g_dbus_message_get_arg0()` return an object-path *or* a string
would not work, as it’s also called in the implementation of
`G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_NAMESPACE`, which must only match
string-typed arg0 values and not object-path-typed ones.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3183
The `g_content_type_guess_for_tree` function segfaults currently when
processing filenames that are not valid unicode strings. Let's use the
`g_filename_to_utf8` and `g_utf8_make_valid` functions before other
processing to prevent that.
Let's also add a test for it to avoid this in future.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/3168
When `--attributes` is specified and doesn’t include `standard::name` in
its list, `gio` would print a critical warning from the (mandatory) call
to `g_file_info_get_name()`.
Fix that by making the call to `g_file_info_get_name()` optional.
Add a unit test too.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3158
It gives nowhere near full coverage, but it’s something we can build on
in future.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3158
Helps: #2950
Modify all the similar Python test wrappers to set
`G_DEBUG=fatal-warnings` in the environment of the program being tested,
so we can catch unexpected warnings/criticals.
Adding this because I noticed it was missing, not because I noticed a
warning/critical was being ignored.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The test only needs a unidirectional channel, and a pipe is sufficient
for that.
This may simplify things when running the test on Hurd; see
https://gitlab.gnome.org/GNOME/glib/-/issues/3148#note_1874198.
Additionally, set `O_NONBLOCK` on the pipe since the test seems to
expect that partial writes will succeed and that writes to a full buffer
will fail rather than block.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3148
Various parts of the build (such as `objectmanager-rst-gen`) depend on
running `gdbus-codegen` after it’s been built, but they currently only
encode a dependency to the main codegen Python file and not the
supporting files. This can cause `gdbus-codegen` to fail with an
`ImportError` if the build races so that `objectmanager-rst-gen` is
built before the codegen supporting files.
Example failure here: https://gitlab.gnome.org/pwithnall/glib/-/jobs/3266471
```
FAILED: gio/tests/gdbus-object-manager-example/objectmanager-rst-gen-org.gtk.GDBus.Example.ObjectManager.Animal.rst gio/tests/gdbus-object-manager-example/objectmanager-rst-gen-org.gtk.GDBus.Example.ObjectManager.Cat.rst
/usr/bin/python3 gio/gdbus-2.0/codegen/gdbus-codegen --interface-prefix org.gtk.GDBus.Example.ObjectManager. --generate-rst objectmanager-rst-gen --output-directory gio/tests/gdbus-object-manager-example ../gio/tests/gdbus-object-manager-example/gdbus-example-objectmanager.xml
Traceback (most recent call last):
File "/builds/pwithnall/glib/_build/gio/gdbus-2.0/codegen/gdbus-codegen", line 53, in <module>
from codegen import codegen_main
File "/builds/pwithnall/glib/_build/gio/gdbus-2.0/codegen/codegen_main.py", line 29, in <module>
from . import dbustypes
File "/builds/pwithnall/glib/_build/gio/gdbus-2.0/codegen/dbustypes.py", line 22, in <module>
from . import utils
ImportError: cannot import name 'utils' from 'codegen' (/builds/pwithnall/glib/_build/gio/gdbus-2.0/codegen/__init__.py)
```
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
