Source: glib2.0
Version: 2.86.0-3
Severity: serious
Tags: experimental ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: [email protected]
User: [email protected]
Usertags: s390x
Control: block 1115340 by -1
After uploading glib2.0_2.86.0-3 I'm seeing a test regression on s390x,
which appears to be reproducible:
>328/405 glib:gio / gdbus-connection-slow
>RUNNING
>>>> G_ENABLE_DIAGNOSTIC=1 MALLOC_CHECK_=2
>>>> MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>>>>
>>>> LD_LIBRARY_PATH=/build/reproducible-path/glib2.0-2.86.0/debian/build/deb/gmodule:/build/reproducible-path/glib2.0-2.86.0/debian/build/deb/gobject:/build/reproducible-path/glib2.0-2.86.0/debian/build/deb/glib:/build/reproducible-path/glib2.0-2.86.0/debian/build/deb/gio
>>>> G_DEBUG=gc-friendly
>>>> G_TEST_BUILDDIR=/build/reproducible-path/glib2.0-2.86.0/debian/build/deb/gio/tests
>>>> MESON_TEST_ITERATION=1 GIO_MODULE_DIR=''
>>>> G_TEST_SRCDIR=/build/reproducible-path/glib2.0-2.86.0/gio/tests
>>>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>>>> MALLOC_PERTURB_=225
>>>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1
>>>> GIO_LAUNCH_DESKTOP=/build/reproducible-path/glib2.0-2.86.0/debian/build/deb/gio/gio-launch-desktop
>>>>
>>>> /build/reproducible-path/glib2.0-2.86.0/debian/build/deb/gio/tests/gdbus-connection-slow
>▶ 325/405 /gdbus/close-pending
>OK
>▶ 328/405 /gdbus/connection/flush -
>GLib-GIO:ERROR:../../../gio/tests/gdbus-connection-slow.c:53:test_connection_flush_on_timeout:
> code should not be reached FAIL
>▶ 328/405
>ERROR
>328/405 glib:gio / gdbus-connection-slow
>ERROR 1.04s killed by signal 6 SIGABRT
>――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――
>stderr:
>Timeout waiting 1000 msec on iteration 0
>**
>GLib-GIO:ERROR:../../../gio/tests/gdbus-connection-slow.c:53:test_connection_flush_on_timeout:
> code should not be reached
>cleaning up pid 51567
This is asserting that when a subprocess sends a D-Bus signal, calls
g_dbus_connection_flush_sync(), and immediately exits, the parent
process receives the signal within 1 second. Presumably this arbitrary
timeout is too short for a mainframe designed for batch processing, or
something.
I don't know why 2.86.0-3 fails this when 2.86.0-2 succeeded.
smcv
