Re: Emergency freeze break request for glib

On 2/23/26 10:43 AM, "Douglas R. Reno" ([email protected] via blfs-dev 
Mailing List) wrote:
> Good morning,
> 
> Throughout this release cycle, we've been running test suites for almost all packages 
> because of some of the changes that glibc-2.43 has come in with, notably the const 
> changes for some C23 functions that can occasionally cause build failures (but can 
> also trigger unexpected behavior at runtime if not fixed). When we got to glib, there 
> was a test failure in it's gdatetime test suite that signaled a serious memory 
> corruption problem when testing the conversion of the date and time to the Thai Solar 
> Calendar.
> 
> During initial research I found a bug report upstream at glibc and contributed to it 
> at https://sourceware.org/bugzilla/show_bug.cgi?id=33899, working with Sam James from 
> Gentoo to help determine the cause of the problem and reproduce the error. The bisect 
> mentioned there was setting the malloc tcache fill count to 16, where it was 7 in 
> previous releases. This pointed towards a caching problem in glib's code being 
> triggered by the malloc change. Pierre also helped me with digging up some 
> documentation to help support this theory.
> 
> Eventually the bug was taken to GNOME's GitLab, since GNOME handles glib. The bug 
> report for that can be found at https://gitlab.gnome.org/GNOME/glib/-/issues/3895. 
> This morning I got a series of emails that the problem was resolved. There is now a 
> fix at https://gitlab.gnome.org/GNOME/glib/-/merge_requests/5035
> 
> Here's some context from the PR which might be helpful:
> 
> "The string pointer returned by setlocale (LC_TIME, NULL) may change if
> other code calls setlocale() again. But because internally glibc
> implements it using strdup(), the pointer value itself may actually
> stay the same even if the string contents change.
> This started happening more commonly in glibc 2.43, due to an internal
> malloc() change which happened to trigger this latent bug.
> In the situations where this happened, it resulted in an outdated cached
> era value being used.
> Fix it by taking a copy of the LC_TIME string. Unfortunately this
> means a reachable (‘leaked’) static string allocation at the end of the
> process’ life, but tooling should ignore that if we mark it with
> g_ignore_leak()."
> 
> Because of the severity of the issue (memory corruption and possible incorrect 
> behavior or crashes from applications), I'd like to request an emergency freeze break 
> to insert this patch.

Please do so.

> I know this will result in a significant amount of retesting being required. When I 
> discussed it with Bruce originally in IRC, we came to the conclusion that only 
> packages which use g_date_time_format() are affected.  The API documentation for that 
> function can be found here at https://docs.gtk.org/glib/method.DateTime.format.html, 
> and searching for date_time_lookup_era in Debian's codesearch engine (https:// 
> sources.debian.org/src/glib2.0/2.87.2-3/glib/gdatetime.c?hl=3383#L3383) points 
> towards the only usage being here. Any application which uses g_date_time_format and 
> uses the E/%E formatting specifier can trigger this problem.
> 
> This change would affect the following packages, based on the fact that they use 
> g_date_time_format:

[deleted]

Lets work on checking packages that are not yet tagged for now.  Looking at the patch 
I'm doubtful that it will change what we've already done.  Actually, we do not need 
to rebuild the packages, but just test that they don't crash.

   -- Bruce

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page