Emergency freeze break request for glib

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.

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:

libqmi
gedit (libgedit-gtksourceview)
gst-plugins-good
localsearch
libgweather4
poppler
gnome-color-manager
libshumate
ostree (SLFS)
gnumeric
gnome-logs
glib-networking
thunar
gtksourceview3
libsecret
appstream-glib
gedit
gvfs
gnome-desktop
xdg-desktop-portal-gtk
glib2.0
gcr4
glibmm2.4
xdg-desktop-portal-gnome
colord
gimp
gtk+3.0
gtk4
librsvg
grilo
exo
libgsf
evolution
gstreamer
gegl
nautilus
gnome-disk-utility
gst-plugins-base
gnome-control-center
seahorse
xfdesktop4
gnome-shell
gtksourceview4
xfce4-panel
udisks2
libgit2-glib (**used in glycin, gst-plugins-rs, loupe)
gtksourceview5
gnome-settings-daemon
rust-glib (**used in glycin, gst-plugins-rs, loupe)
evince
gcr
Transmission
flatpak (in SLFS)
bluefish
accountsservice
modemmanager
libreoffice
balsa
xfce4-screensaver
xfce4-notifyd
evolution-data-server
gnome-terminal
qemu
NetworkManager
xfce4-settings
geoclue
file-roller
rust-glib-0.18 (**used in glycin, gst-plugins-rs, loupe at least)
libsoup3
webkit2gtk
gnome-screenshot
gst-plugins-bad
rofi (in SLFS)
glibmm2.68
libgusb
appstream
rust-glib-sys-0.18 (**used in glycin, gst-plugins-rs, loupe at least)
gobject-introspection
tinysparql
epiphany
librest


I know that list looks massive. Given that 90% of these problem packages 
are in gnome, I'd like to volunteer to take care of the testing and 
implementation for this. Zeckma, I can also take care of the few 
packages in SLFS for you that use it on my test laptop (which is still 
needed to test intel-vaapi-driver, xf86-input-wacom, and 
x86-input-synaptics and possibly LXQt with KF6 if Bruce gets that in 
today). The only package I will not be able to test out of the above 
list at this time is LibreOffice as I need to finish creating the new 
JDK binary for that and that's at least another day down the pipeline on 
pair of VMs. I was able to get the list from Debian's codesearch archive 
again from 
https://codesearch.debian.net/search?q=g_date_time_format&literal=1, but 
the best approach was actually running 'curl -s 
https://codesearch.debian.net/results/b6b0d6ccd04f345a/packages.txt'. 
This gave me a comprehensive list of packages affected (228 in Debian), 
which I then scanned through to find the packages that we carry in *LFS. 
In our case, that is *81* packages.

Currently there are numerous packages in the GNOME chapter which are 
untagged thankfully, but I'd like to request that folks who are working 
on the book today (if this request is approved) do not tag the following 
packages:

- bluefish

- epiphany

- balsa

- transmission

- qemu

- gnumeric

- gedit

- GIMP

As part of this process I will tag and work through those.

Given that the end of the release cycle is approaching extremely 
rapidly, I think this is probably something I'll want/need to finish 
today (with the exception of LibreOffice).

I know this request is a LOT, but we need to get this taken care of.

Thank you,

- Doug

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