Bug#1060735: glib2.0/experimental: FTBFS on s390x and other 64-bit BE: gdatetime test fails or crashes
Source: glib2.0
Version: 2.79.0+git20240110~g38f5ba3c-1
Severity: serious
Tags: ftbfs experimental
X-Debbugs-Cc: debian-s390@lists.debian.org, debian-powerpc@lists.debian.org
User: debian-s390@lists.debian.org
Usertags: s390x
I recently uploaded a snapshot of GLib 2.79.x to experimental (in
preparation for NEW processing) and it failed tests on s390x and on
the 64-bit, big-endian ports ppc64 and sparc64. I suspect this means
it's a general problem with 64-bit BE, rather than specifically s390x.
The 32-bit big-endian powerpc and hppa ports seem to pass this test fine,
although hppa had an unrelated failure in a different test.
On the s390x buildd, the test crashed:
https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=s390x&ver=2.79.0%2Bgit20240110%7Eg38f5ba3c-1&stamp=1705088035&raw=0
> 21/369 glib:glib+core+slow / gdatetime RUNNING
> >>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MALLOC_PERTURB_=168 G_TEST_BUILDDIR='/<<PKGBUILDDIR>>/debian/build/deb/glib/tests' G_ENABLE_DIAGNOSTIC=1 G_DEBUG=gc-friendly MALLOC_CHECK_=2 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 G_TEST_SRCDIR='/<<PKGBUILDDIR>>/glib/tests' LD_LIBRARY_PATH='/<<PKGBUILDDIR>>/debian/build/deb/glib' '/<<PKGBUILDDIR>>/debian/build/deb/glib/tests/gdatetime'
> ▶ 21/369 /GDateTime/invalid OK
> ▶ 21/369 /GDateTime/add_days OK
> ▶ 21/369 /GDateTime/add_full OK
> ▶ 21/369 /GDateTime/add_hours OK
> ▶ 21/369 /GDateTime/add_minutes OK
> ▶ 21/369 /GDateTime/add_months OK
> ▶ 21/369 /GDateTime/add_seconds OK
> ▶ 21/369 /GDateTime/add_weeks OK
> ▶ 21/369 /GDateTime/add_years OK
> ▶ 21/369 /GDateTime/compare OK
> ▶ 21/369 /GDateTime/diff OK
> ▶ 21/369 /GDateTime/equal OK
> ▶ 21/369 /GDateTime/get_day_of_week OK
> ▶ 21/369 /GDateTime/get_day_of_month OK
> ▶ 21/369 /GDateTime/get_day_of_year OK
> ▶ 21/369 /GDateTime/get_hour OK
> ▶ 21/369 /GDateTime/get_microsecond OK
> ▶ 21/369 /GDateTime/get_minute OK
> ▶ 21/369 /GDateTime/get_month OK
> ▶ 21/369 /GDateTime/get_second OK
> ▶ 21/369 /GDateTime/get_utc_offset OK
> ▶ 21/369 /GDateTime/get_year OK
> ▶ 21/369 /GDateTime/hash OK
> ▶ 21/369 /GDateTime/new_from_unix OK
> ▶ 21/369 /GDateTime/new_from_unix_utc OK
> ▶ 21/369 /GDateTime/new_from_timeval OK
> ▶ 21/369 /GDateTime/new_from_timeval_utc OK
> ▶ 21/369 /GDateTime/new_from_iso8601 OK
> ▶ 21/369 /GDateTime/new_full OK
> ▶ 21/369 /GDateTime/now OK
> ▶ 21/369 /GDateTime/test-6-days-until-end-of-the-month OK
> ▶ 21/369 /GDateTime/printf OK
> ▶ 21/369 /GDateTime/non_utf8_printf SKIP
> ▶ 21/369 /GDateTime/format_unrepresentable OK
> ▶ 21/369 /GDateTime/format_iso8601 OK
> ▶ 21/369 /GDateTime/strftime OK
> 21/369 glib:glib+core+slow / gdatetime ERROR 0.13s killed by signal 11 SIGSEGV
On ppc64, the same test failed with SIGBUS, but otherwise similar symptoms.
I can sort of reproduce the failure on s390x porterbox zelenka, but instead
of segfaulting, the test failed with an assertion error involving dates with
a Japanese era marker:
> =================================== 21/369 ===================================
> test: glib:glib+core+slow / gdatetime
> start time: 14:58:26
> duration: 1.35s
> result: killed by signal 6 SIGABRT
> command: ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 G_TEST_BUILDDIR=/home/smcv/glib/debian/build/deb/glib/tests G_TEST_SRCDIR=/home/smcv/glib/glib/tests G_ENABLE_DIAGNOSTIC=1 G_DEBUG=gc-friendly UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 LD_LIBRARY_PATH=/home/smcv/glib/debian/build/deb/glib MALLOC_CHECK_=2 MALLOC_PERTURB_=62 /home/smcv/glib/debian/build/deb/glib/tests/gdatetime
> ----------------------------------- stdout -----------------------------------
> TAP version 13
> # random seed: R02S834a1e58ff6107ee5c59fae50e1c6fcc
> 1..68
> # Start of GDateTime tests
> # Bug Reference: http://bugzilla.gnome.org/702674
> ok 1 /GDateTime/invalid
> ok 2 /GDateTime/add_days
[Everything passes, until...]
> # End of format_mixed tests
> # Start of strftime tests
> ok 55 /GDateTime/strftime/error_handling # SKIP Skipping due to running uninstalled. This test can only be run when the translations are installed.
> # End of strftime tests
> # Start of eras tests
> not ok /GDateTime/eras/japan - GLib:ERROR:../../../glib/tests/gdatetime.c:2297:test_date_time_eras_japan: assertion failed (p_casefold == (o_casefold)): ("201904\346\234\21030\346\227\245 00\346\231\20200\345\210\20600\347\247\222" == "\345\271\263\346\210\22031\345\271\26404\346\234\21030\346\227\245 00\346\231\20200\345\210\20600\347\247\222")
> Bail out!
> ----------------------------------- stderr -----------------------------------
> **
> GLib:ERROR:../../../glib/tests/gdatetime.c:2297:test_date_time_eras_japan: assertion failed (p_casefold == (o_casefold)): ("201904\346\234\21030\346\227\245 00\346\231\20200\345\210\20600\347\247\222" == "\345\271\263\346\210\22031\345\271\26404\346\234\21030\346\227\245 00\346\231\20200\345\210\20600\347\247\222")
>
> (test program exited with status code -6)
> ==============================================================================
The sparc64 buildd saw the same assertion failure as on zelenka. I don't
know whether this is related or unrelated: if unrelated, then we can
clone this bug if necessary.
smcv
Reply to: