Re: Emergency freeze break request for glib

On 2/23/26 11:57 AM, Bruce Dubbs ([email protected] via blfs-dev 
Mailing List) wrote:
> 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.
Thank you! I will get to work on this right away.
>
>> 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
>
That sounds good. I've got a list together in LibreOffice Calc that 
should be easy for me to work with!

- Doug

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