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
Reply to: