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>
Depending on the operating system, /bin/sh might either be bash (for
example on Fedora or Arch) or dash (for example on Debian or Ubuntu)
or some other POSIX shell.
When bash is asked to run a simple command with no shell keywords or
metacharacters, like this one, it replaces itself with the program
via execve(), but dash does not have that optimization and treats it
like any other program invocation in a larger script: it will fork,
exec the program in the child, and wait for the child in the parent.
This seems like it conflicts with sleep_and_kill() assuming that it can
use the subprocess's process ID as the sleep(1) process ID. Specifically,
if it sends SIGKILL, it will go to the sh(1) process and not the sleep(1)
child, which could result in the sh(1) process being terminated and
its sleep(1) child being leaked.
To get the bash-like behaviour portably, explicitly use the exec builtin
to instruct the shell to replace itself with sleep(1), so that the
process ID previously used for the shell becomes the process ID of the
sleep process.
This appears to resolve an intermittent hang and test timeout on Debian
machines (especially slower ones), although I'm not 100% clear on the
mechanics of how it happens.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3157
Signed-off-by: Simon McVittie <smcv@collabora.com>
`test-generated.txt` is listed in `test.gresource.xml`, so it needs to
be specified as a dependency in the `custom_target()` which uses
`test.gresource.xml`.
Fixes intermittent build failures like:
```
FAILED: gio/tests/test.gresource
/builds/GNOME/glib/_build/gio/glib-compile-resources --compiler=gcc --target=gio/tests/test.gresource --sourcedir=/builds/GNOME/glib/gio/tests --sourcedir=/builds/GNOME/glib/_build/gio/tests --internal ../gio/tests/test.gresource.xml
../gio/tests/test.gresource.xml: Failed to locate test-generated.txt in any source directory.
```
See !3671 and #3163.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
This reverts commit 0b9900e4e7.
The dependency was added in the wrong place: `test-generated.txt` is
needed when compiling `test.gresource`, not when compiling the test
which ultimately uses that gresource.
See !3671 and #3163.
The PTRACE_O_EXITKILL symbol in sys/ptrace.h is an enum member, not
a macro. The #ifdef check added to the GSubprocess test-case in
272ec5dbca will not detect it.
Use cc.has_header_symbol() to properly detect it. According to the
documentation: "Symbols here include function, variable, #define,
type definition, etc.".
Fixes: 272ec5dbca
Closes: https://gitlab.gnome.org/GNOME/glib/-/issues/3156
If `update-desktop-database` or `update-mime-database` are not
installed, there are a few `GAppInfo` methods for modifying file
associations which will print a `g_warning()` when called. Something
like:
```
GLib-GIO-FATAL-WARNING: Failed to execute child process ‘update-desktop-database’ (No such file or directory)
```
(Example: https://gitlab.gnome.org/zamaudio/glib/-/jobs/3190053)
This will cause the appinfo/associations test to fail, as warnings are
fatal.
If that’s going to happen, skip the test. We can’t hard-depend on these
tools as they are external to GLib and only needed for a few operations.
Instead we have a soft runtime dependency on them; that should be
reflected in the tests.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3148
