Segfaults with sys-libs/glibc-2.33 on VIA C7 CPUs
I noticed that there are issues with glibc (as far as I see starting from 2.33; currently there was/is =sys-libs/glibc-2.33-r7 installed).
So far I only checked my VIA C7, the bug might occur on similar machines as well (can check SiS 55x, Geode LX, Geode GX, VIA C3 and the likes; a P4-M machine was not affected).
Virtually everything fails on these machines past login (also SEGFAULTs during init). One is locked out of the system entirely.
However, chroot compiling e.g. on a "big" amd64 works like a charm. Segfaults only happen on the x86_32 bare metal machine.
(tried different CFLAFGS, didn't help)
Here's a hint
It seems to be an upstream bug.
I know not to file upstream-related bugs. However, it is fixed upstream, as far as I see definitely for 2.35 and I tested the most recent available 2.34-rXX in portage and the system is fine, again.
So this is more a request: Please update stable glibc on x86(_32) with upstream's backported patches.
Otherwise any sys-libs/glibc-2.33-* so far will lock people out of their systems once installed.
Steps to Reproduce:
1. install glibc 2.33
2. try virtually anything (e.g. emerge -pv something)
3. instant segfault
no segfaults, smooth operation
I think this might classify as "major" or even more severe since it might lock out users entirely. However, the issue seems to be fixed upstream.
It'd help a lot if you could help identify exactly which patches you think solve the issue.
Also, 2.33-rXX is ambiguous. What's the latest version you've tried? We regularly backport new patches, so -rXX could easily include one which fixes this but you haven't tried yet.
And is 2.34 OK (latest -rN in Gentoo)?
Also, we've just started glibc-2.34 stabilisation.
I think this is https://sourceware.org/bugzilla/show_bug.cgi?id=28784
backported with 0076-x86-use-default-cache-size-if-it-cannot-be-determine.patch and all fixed in glibc-2.33-r13
please confirm, thanks
Yes, that should be the patch / fix.
(Sorry for being late. :) )
So far I tried up to 2.33-r7, but I remember that the problem likely occured on an earlier revision state. It was just that I thought it is my fault (though I tend to use rather sane CFLAGs).
Thus, I can't remember exactly when I did the update and on which version exactly the segfaults started.
I simply found the time last week to dig deeper and found out that other people have a similar problem with glibc 2.33 and certain CPUs.
The sys-libs/glibc-2.34-r10 release that I use now seems to work (no deep testing, but no more instant segfaults on calling emerge).
It seems the ebuild refuses any downgrades on glibc so I can't try
=sys-libs/glibc-2.33-r13 right now (just became available as stable in portage), I might try to look for some old hard disk with a generic (i686) Gentoo installation and try that one in the C7 with an upgraded -r13 glibc.
On mobile so I'll reply properly later but if 2.34-r10 is good, no need for any action on your part -- we're stabling 2.34 now and will discontinue the 2.33 branch then, so we're all good!
A fixed version of 2.33 was stabled last night too.
Great to read, thanks!
I confirm that =sys-libs/glibc-2.33-r13 seems to work nicely. Tested on two C7 boards.
(C3 not yet tested, this is i586 and I had only an i686 compiled one at hand, but I assume the error should be gone.)