The race was already acknowledged in the code (via `last_failed`): the
thread pool starts dequeuing jobs as soon as it’s created, so it’s
dequeuing the sorted thread IDs while they’re still being enqueued and
sorted. This can lead to them being dequeued out of the expected order
if new thread IDs are enqueued out of order, which is possible because
they’re randomly generated.
The test tried to handle this by allowing one out-of-order dequeue, but
it looks like the race can race hard enough that multiple out-of-order
dequeues are possible.
Fix that by only starting to dequeue the jobs from the thread pool once
they’ve all been enqueued and put in a total order.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #2810
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>
The GIR files are now built by GLib itself, so they will be in the build
directories of each sub-library, except for GLib-2.0 which is built
alongside GObject-2.0.
All the calls to `usage()` are immediately followed by a `return` from
`main()` which sets an appropriate exit status.
Calling `exit()` early means that running `gio --help` returns exit
status 1, which is incorrect — it should (by convention) return 0.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
If the string of one log domain is contained in
another, it was printing both.
For example, if G_MESSAGES_DEBUG is "Gtkspecial",
it would also keep the logs of the "Gtk" domain
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>
The weak symbol resolution doesn’t seem to work (see
https://gitlab.gnome.org/GNOME/glib/-/jobs/3265405):
```
Undefined symbols for architecture x86_64:
"___lsan_enable", referenced from:
_g_leak_sanitizer_is_supported in gutils.c.o
"___lsan_ignore_object", referenced from:
_g_ignore_leak in gquark.c.o
_g_ignore_leak in gthreadpool.c.o
_g_ignore_leak in gutils.c.o
_g_leak_sanitizer_is_supported in gutils.c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
See !3672
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
`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.
GLib ignores various leaks that we don't consider as such (like the
default gio modules) via the LSAN public interface, however those cases
are always ignored when using a non-ASAN compiled glib is used by an
ASAN-compiled binary.
This makes all the GLib-related programs to fail because of false
positive leaks.
To avoid this, use the gcc extension for weak linking so that we can
control ASAN and LSAN only if the symbols they provide are actually
available at runtime.
