Bug#1022564: locale related segmentation fault
Package: libc6 Version: 2.35-3 Severity: important I ran into this issue while updating packages on a Debian/sid machine, and the install scripts for "ntpsec" and "tzdata" started failing with segfault. I couldn't find a way to reproduce it on that machine immediately. I started suspecting the machine might be failing. But then I ran into the problem on another machine that runs "bird" routing daemon, as its control program "birdc" also started segfaulting, but started working if I set LC_ALL=C. Then I found I could also get the install scripts on the first machine to work with LC_ALL=C. So, steps to reproduce: root# apt-get install bird root# LC_ALL=asdf birdc I'm sure there's a way to reproduce it without installing new packages, but rather than trying to find one, I thought I'd report the problem as soon as possible, because it smells to me like there might be some overflow involved... Best Regards, -- Aleksi Suhonen () ascii ribbon campaign /\ support plain text e-mail
[Git][glibc-team/glibc][sid] Break gnumach versions which don't have the FPU context switch fix
Samuel Thibault pushed to branch sid at GNU Libc Maintainers / glibc Commits: 13e20c91 by Samuel Thibault at 2022-10-23T21:06:12+02:00 Break gnumach versions which dont have the FPU context switch fix to try to improve upgrading from 2021. * debian/control.in/libc - - - - - 3 changed files: - debian/changelog - debian/control - debian/control.in/libc View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/13e20c91be7339f54e55d2544f6fa4066a47044e -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/13e20c91be7339f54e55d2544f6fa4066a47044e You're receiving this email because of your account on salsa.debian.org.
Re: static pie: confusion between _DYNAMIC, crt1.o, Scrt1.o
Xi Ruoyao, le dim. 23 oct. 2022 10:08:34 +0800, a ecrit:
> On Sat, 2022-10-22 at 16:45 +0200, Samuel Thibault wrote:
> > Is it not possible to make -static -pie get the same behavior? That'd be
> > way more orthogonal for people to understand.
> >
> > As the gnupg example shows, people seem to be expecting it to be
> > static-pie, and I don't think documentation will manage to fix that.
>
> I'm not sure.
It would be really useful to it works, because I see that e.g. on a
pie-by-default distribution such as Debian, when linking with just
-static, we don't get the static-pie benefit, even if the distribution
already enabled pie by default to benefit from ASLR. I.e. we don't
automatically benefit from static-pie's ASLR for static binaries, and
fixing that would be very tedious since it'd mean having to fix each and
every package with static binaries into using -static-pie instead of
-static.
> > That doesn't seem to have been fixed for the hurd case, I will have
> > a look (and that will most probably point me to the piece that makes
> > -static -pie use crt1.o on Linux).
>
[...]
> What does
>
> gcc -dumpspecs | grep 'startfile:' -A1
>
> say on Hurd?
It was
*startfile:
%{!shared:
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}}
crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}
I have now fixed it into
*startfile:
%{!shared:
%{pg|p|profile:%{static-pie:grcrt0.o%s;static:gcrt0.o%s;:gcrt1.o%s};static-pie:rcrt0.o%s;static:crt0.o%s;pie:Scrt1.o%s;:crt1.o%s}}
crti.o%s
%{static:crtbeginT.o%s;shared|pie|static-pie:crtbeginS.o%s;:crtbegin.o%s}
see the patch I have just sent on gcc-patches.
Thanks,
Samuel
