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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Processing control commands:

forwarded -1 https://gitlab.gnome.org/GNOME/glib/-/issues/3225

Bug #1060735 [src:glib2.0] glib2.0/experimental: FTBFS on s390x and other 64-bit BE: gdatetime test fails or crashes
Set Bug forwarded-to-address to 'https://gitlab.gnome.org/GNOME/glib/-/issues/3225'.

tags -1 + help

Bug #1060735 [src:glib2.0] glib2.0/experimental: FTBFS on s390x and other 64-bit BE: gdatetime test fails or crashes
Added tag(s) help.

--
1060735: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060735
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Control: severity -1 important

On Sat, 13 Jan 2024 at 19:32:58 +0000, Simon McVittie wrote:

On Sat, 13 Jan 2024 at 16:21:46 +0000, Simon McVittie wrote:

On Sat, 13 Jan 2024 at 15:21:02 +0000, Simon McVittie wrote:

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.

git bisect says commit df4aea76 "gdatetime: Add support for %E modifier
to g_date_time_format()" is the first bad commit, which would be consistent with it being...

instead
of segfaulting, the test failed with an assertion error involving dates with
a Japanese era marker:

... something to do with Japanese and Thai eras, and the %E modifier.

I can't see anything in the relevant commit[1] that looks like it would be affected by endianness. Could there be an endianness problem in one of the glibc APIs that it's calling into, or something like that?

I have successfully worked around this by disabling support for era-based
dates with the %E modifier (used in Japan and Thailand) on big-endian
64-bit, which reduces the severity of this bug to non-RC.

It looks as though:

- glibc documents nl_langinfo(ERA) as returning a semicolon-delimited list
of eras

- but in fact it returns a NUL-delimited, double-NUL-terminated list of
eras, such that parsing the list cannot be done without risking a read
overrun, unless you either assume that the undocumented
double-NUL-termination will be present or use the undocumented
nl_langinfo(_NL_TIME_ERA_NUM_ENTRIES). GLib currently does the latter.

- GLib has, at least for now, prioritized its own usability for Japanese
and Thai users higher than the design principle that it should not rely
on undocumented APIs

- this is OK on 32-bit and on little-endian, but glibc's
nl_langinfo(_NL_TIME_ERA_NUM_ENTRIES) returns what appears to be a
wrong result on 64-bit big-endian architectures

Discussion in GLib: https://gitlab.gnome.org/GNOME/glib/-/issues/3225

Workaround in GLib: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3820

Related glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31030

If there is a safe way to get this information from glibc, then GLib should
use that, but I don't know what that safe way would be.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Processing control commands:

severity -1 important

Bug #1060735 [src:glib2.0] glib2.0/experimental: FTBFS on s390x and other 64-bit BE: gdatetime test fails or crashes
Severity set to 'important' from 'serious'

--
1060735: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060735
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)