Processed: Re: Bug#1060735: glib2.0/experimental: FTBFS on s390x and other 64-bit BE: gdatetime test fails or crashes
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 ow...@bugs.debian.org with problems
Bug#1060735: glib2.0/experimental: FTBFS on s390x and other 64-bit BE: gdatetime test fails or crashes
Control: severity -1 important On Sat, 13 Jan 2024 at 19:32:58 +, Simon McVittie wrote: > On Sat, 13 Jan 2024 at 16:21:46 +, Simon McVittie wrote: > > On Sat, 13 Jan 2024 at 15:21:02 +, 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
Processed: Re: Bug#1060735: glib2.0/experimental: FTBFS on s390x and other 64-bit BE: gdatetime test fails or crashes
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 ow...@bugs.debian.org with problems
Bug#1060735: glib2.0/experimental: FTBFS on s390x and other 64-bit BE: gdatetime test fails or crashes
Control: forwarded -1 https://gitlab.gnome.org/GNOME/glib/-/issues/3225 Control: tags -1 + help On Sat, 13 Jan 2024 at 16:21:46 +, Simon McVittie wrote: > On Sat, 13 Jan 2024 at 15:21:02 +, 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? smcv [1] https://gitlab.gnome.org/GNOME/glib/-/commit/df4aea76204090f770a8fd90c2b68b51c2cfc2a3
Bug#1060735: glib2.0/experimental: FTBFS on s390x and other 64-bit BE: gdatetime test fails or crashes
On Sat, 13 Jan 2024 at 15:21:02 +, 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. smcv
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-s...@lists.debian.org, debian-powe...@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=s390x=2.79.0%2Bgit20240110%7Eg38f5ba3c-1=1705088035=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='/<>/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='/<>/glib/tests' > >>> LD_LIBRARY_PATH='/<>/debian/build/deb/glib' > >>> '/<>/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
