Source: glib2.0 Version: 2.79.0+git20240110~g38f5ba3c-1 Severity: serious Tags: ftbfs experimental X-Debbugs-Cc: debian-s...@lists.debian.org, debian-powerpc@lists.debian.org User: debian-s...@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
