Re: 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 +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