Bug#1063937: glibc: Please add workaround to fix posix_spawn() on sparc64
Source: glibc Version: 2.37-15 Severity: important Tags: patch User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org,ker...@mkarcher.dialup.fu-berlin.de,s...@gentoo.org Hello, there is currently a nasty bug on sparc64 that breaks posix_spawn() [1] and potentially any package that uses gcc since libiberty switched to using posix_spawn() with gcc-14. The attached patch comes from Michael Karcher (CC'ed) and unbreaks posix_spawn() so that gcc works again without posix_spawn() failing with "Bad Address". Since this patch is just a workaround and we're not even sure whether the bug is in the kernel or glibc, it's not been pushed upstream yet. Adrian > [1] > https://lore.kernel.org/sparclinux/fe5cc47167430007560501aabb28ba154985b661.ca...@physik.fu-berlin.de -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- glibc-2.37.orig/sysdeps/unix/sysv/linux/sparc/sparc32/clone.S +++ glibc-2.37/sysdeps/unix/sysv/linux/sparc/sparc32/clone.S @@ -28,6 +28,9 @@ .text ENTRY (__clone) save%sp,-96,%sp + save%sp,-96,%sp + flushw + restore cfi_def_cfa_register(%fp) cfi_window_save cfi_register(%o7, %i7) --- glibc-2.37.orig/sysdeps/unix/sysv/linux/sparc/sparc64/clone.S +++ glibc-2.37/sysdeps/unix/sysv/linux/sparc/sparc64/clone.S @@ -32,6 +32,9 @@ ENTRY (__clone) save%sp, -192, %sp + save%sp, -192, %sp + flushw + restore cfi_def_cfa_register(%fp) cfi_window_save cfi_register(%o7, %i7)
Bug#1053717: glibc: Please add build support for loong64
Source: glibc Version: 2.37-12 Severity: normal User: debian-de...@lists.debian.org Usertags: loong64 X-Debbugs-Cc: zhangjial...@loongson.cn,zhangdan...@loongson.cn Hi! Now that Bullseye has been updated to 11.8 which has a dpkg version that supports loong64 [1], we should be all set to be able to upload source packages that have loong64 in their debian/control files. Could you add build support for loong64 to glibc? The changes should be straight- forward but feel free to take a look at the current glibc package in unreleased which was built with loong64 support [2]. Thanks, Adrian > [1] https://www.debian.org/News/2023/2023100702 > [2] > http://ftp.ports.debian.org/debian-ports/pool-loong64/main/g/glibc/glibc_2.37-9+loong64.dsc -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040817: glibc: Please ignore some tests on sparc64
Hi! On Tue, 2023-07-11 at 20:59 +0200, John Paul Adrian Glaubitz wrote: > With the above fix for the audit tests, the tests to ignore should be: > > FAIL: elf/tst-rtld-run-static > FAIL: nptl/tst-cancel24-static > FAIL: socket/tst-socket-timestamp > FAIL: stdlib/isomac Just verified this. With both patches above applied, the failures reduce to the four tests above. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040817: glibc: Please ignore some tests on sparc64
On Tue, 2023-07-11 at 20:57 +0200, Aurelien Jarno wrote: > > Correction: These two tests should be ignored as well: > > > > FAIL: elf/tst-rtld-run-static > > FAIL: nptl/tst-cancel24-static > > Noted. > > > So, it's only this failure that just got fixed today upstream [1]: > > > > FAIL: nptl/tst-cancel30 > > Ok, I see it's also fixed on the 2.37 branch, I'll pull it from there. And there is now a fix for the audit issues: > https://patchwork.sourceware.org/project/glibc/patch/20230711151558.314216-1-adhemerval.zane...@linaro.org/ And re-enable the 32-bit tests then. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040817: glibc: Please ignore some tests on sparc64
Hi! On Tue, 2023-07-11 at 20:52 +0200, Aurelien Jarno wrote: > > According to upstream, the following audit tests are not going to be > > fixed soon since the SPARC ABI makes it more difficult: > > > > FAIL: elf/tst-audit24a > > FAIL: elf/tst-audit24b > > FAIL: elf/tst-audit24c > > FAIL: elf/tst-audit24d > > Ok. It happens that Adhemerval just posted a patch for the audit issue a few hours ago: > https://patchwork.sourceware.org/project/glibc/patch/20230711151558.314216-1-adhemerval.zane...@linaro.org/ So, we might not have the blacklist these as well. > > These are going to be fixed upstream soon, the fixes are supposedly > > trivial: > > > > FAIL: elf/tst-rtld-run-static > > FAIL: nptl/tst-cancel24-static > > FAIL: nptl/tst-cancel30 > > Great. > > > This test is supposedly a kernel issue: > > > > FAIL: socket/tst-socket-timestamp > > > > And this one allegedly not related to sparc64: > > > > FAIL: stdlib/isomac > > What do you mean by "allegedly not related to sparc64"? This failure > only appears on sparc*. The sparc32 has the following comment in > debian/testsuite-xfail-debian.mk to ignore the failure: > > # Even if configured using --with-long-double-128, the biarch32 compiler > # on sparc64 defaults to 64-bit doubles, causing the failure below. This > # should be fixed by the following gcc patch: > # http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00318.html > test-xfail-stdlib/isomac = yes > > Can you please check if there is a similar issue with the GCC > configuration on sparc64? That was the comment by Adhemerval when he looked at the issue. > > So, my suggestion would be to ignore the following tests for now: > > > > FAIL: elf/tst-audit24a > > FAIL: elf/tst-audit24b > > FAIL: elf/tst-audit24c > > FAIL: elf/tst-audit24d > > FAIL: socket/tst-socket-timestamp > > FAIL: stdlib/isomac > > Ok. > > > And looking at the testsuite results with 32-bit tests enabled [1], it > > looks like > > the failures are the same. So, I think we can just ignore the above tests > > and then > > re-enable testing on 32 bit as well. > > It appears that none of those fails on sparc32. Looking at it again, it > even appears that the sparc32 build passed the testsuite without issue, > so there was no need to disable it. Hmm, then I actually mixed up the two testsuites, sorry. You can re-enable it then. With the above fix for the audit tests, the tests to ignore should be: FAIL: elf/tst-rtld-run-static FAIL: nptl/tst-cancel24-static FAIL: socket/tst-socket-timestamp FAIL: stdlib/isomac Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040817: glibc: Please ignore some tests on sparc64
Hi! On Tue, 2023-07-11 at 06:17 +0200, John Paul Adrian Glaubitz wrote: > The list of currently failing tests on sparc64 is: > > FAIL: elf/tst-audit24a > FAIL: elf/tst-audit24b > FAIL: elf/tst-audit24c > FAIL: elf/tst-audit24d > FAIL: elf/tst-rtld-run-static > FAIL: nptl/tst-cancel24-static > FAIL: nptl/tst-cancel30 > FAIL: socket/tst-socket-timestamp > FAIL: stdlib/isomac > > According to upstream, the following audit tests are not going to be > fixed soon since the SPARC ABI makes it more difficult: > > FAIL: elf/tst-audit24a > FAIL: elf/tst-audit24b > FAIL: elf/tst-audit24c > FAIL: elf/tst-audit24d > > These are going to be fixed upstream soon, the fixes are supposedly > trivial: > > FAIL: elf/tst-rtld-run-static > FAIL: nptl/tst-cancel24-static > FAIL: nptl/tst-cancel30 > > This test is supposedly a kernel issue: > > FAIL: socket/tst-socket-timestamp > > And this one allegedly not related to sparc64: > > FAIL: stdlib/isomac > > So, my suggestion would be to ignore the following tests for now: > > FAIL: elf/tst-audit24a > FAIL: elf/tst-audit24b > FAIL: elf/tst-audit24c > FAIL: elf/tst-audit24d > FAIL: socket/tst-socket-timestamp > FAIL: stdlib/isomac Correction: These two tests should be ignored as well: FAIL: elf/tst-rtld-run-static FAIL: nptl/tst-cancel24-static So, it's only this failure that just got fixed today upstream [1]: FAIL: nptl/tst-cancel30 Adrian > [1] > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=260d4b742bc36744aa2282421547f1a7b483d2f8 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040817: glibc: Please ignore some tests on sparc64
Source: glibc Version: 2.37-5 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hi! The list of currently failing tests on sparc64 is: FAIL: elf/tst-audit24a FAIL: elf/tst-audit24b FAIL: elf/tst-audit24c FAIL: elf/tst-audit24d FAIL: elf/tst-rtld-run-static FAIL: nptl/tst-cancel24-static FAIL: nptl/tst-cancel30 FAIL: socket/tst-socket-timestamp FAIL: stdlib/isomac According to upstream, the following audit tests are not going to be fixed soon since the SPARC ABI makes it more difficult: FAIL: elf/tst-audit24a FAIL: elf/tst-audit24b FAIL: elf/tst-audit24c FAIL: elf/tst-audit24d These are going to be fixed upstream soon, the fixes are supposedly trivial: FAIL: elf/tst-rtld-run-static FAIL: nptl/tst-cancel24-static FAIL: nptl/tst-cancel30 This test is supposedly a kernel issue: FAIL: socket/tst-socket-timestamp And this one allegedly not related to sparc64: FAIL: stdlib/isomac So, my suggestion would be to ignore the following tests for now: FAIL: elf/tst-audit24a FAIL: elf/tst-audit24b FAIL: elf/tst-audit24c FAIL: elf/tst-audit24d FAIL: socket/tst-socket-timestamp FAIL: stdlib/isomac And looking at the testsuite results with 32-bit tests enabled [1], it looks like the failures are the same. So, I think we can just ignore the above tests and then re-enable testing on 32 bit as well. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=glibc=sparc64=2.37-1=1684283585=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040462: glibc: Please ignore testsuite failures for 32-bit builds on sparc64
Source: glibc Version: 2.37-3 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello! On sparc64, the following tests for the 32-bit build have been failing for a while now: FAIL: elf/tst-audit24a FAIL: elf/tst-audit24b FAIL: elf/tst-audit24c FAIL: elf/tst-audit24d FAIL: elf/tst-rtld-run-static FAIL: nptl/tst-cancel24-static FAIL: nptl/tst-cancel30 FAIL: socket/tst-socket-timestamp FAIL: stdlib/isomac See: https://buildd.debian.org/status/fetch.php?pkg=glibc=sparc64=2.37-3=1688236651=0 Since we don't care so much about 32-bit SPARC these days, I think it's safe to ignore these testsuite failures. Can you therefore ignore the testsuite failures for 32-bit for the time being? I will report each of the testsuite failures in case this has not happened yet. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1028200: glibc: FTBFS on alpha due to buggy GL(dl_phdr) and GL(dl_phnum) [BZ #29864]
Source: glibc
Version: 2.36-8
Severity: normal
Tags: patch upstream
User: debian-al...@lists.debian.org
Usertags: alpha
X-Debbugs-Cc: debian-al...@lists.debian.org
Hello!
glibc fails to build from source on alpha with many testsuite failures [1]
due to a regression introduced in glibc 2.34 [2].
According to the discussion on the libc-alpha mailing list, this issue
affects multiple architectures for static builds. It just happens that
it causes segmentation faults on alpha [3].
A proposed patch by Adhemveral Zanella has been posted on the list [4]
but not been merged yet. I tested the first version of the patch [3] and
can confirm that it works. I will test the posted version [4] now.
Adhemerval said that he plans to backport the patch down to 2.34, so it
will eventually show up in 2.36 as well. Either way, it might be a good
idea to already carry the patch in Debian but I'm not sure.
Thanks,
Adrian
> [1] https://buildd.debian.org/status/logs.php?pkg=glibc=alpha
> [2] https://sourceware.org/pipermail/libc-alpha/2023-January/15.html
> [3] https://sourceware.org/pipermail/libc-alpha/2023-January/144452.html
> [4] https://sourceware.org/pipermail/libc-alpha/2023-January/144457.html
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--- Begin Message ---
The 73fc4e28b9464f0e refactor did not add the GL(dl_phdr) and
GL(dl_phnum) for static build, relying on the __ehdr_start symbol,
which is always added by the static linker, to get the correct values.
This is problematic in some ways:
- The segment may see its in-memory size differ from its in-file
size (or the binary may have holes). The Linux has fixed is to
provide concise values for both AT_PHDR and AT_PHNUM (commit
0da1d5002745c - "fs/binfmt_elf: Fix AT_PHDR for unusual ELF files")
- Some archs (alpha for instance) the hidden weak reference is not
correctly pulled by the static linker and __ehdr_start address
end up being 0, which makes GL(dl_phdr) and GL(dl_phnum) have both
invalid values (and triggering a segfault later on libc.so while
accessing TLS variables).
The safer fix is to just restore the previous behavior to setup
GL(dl_phdr) and GL(dl_phnum) for static based on kernel auxv. The
__ehdr_start fallback can also be simplified by not assuming weak
linkage (as for PIE).
The libc-static.c auxv init logic is moved to dl-support.c, since
the later is build without SHARED and then GLRO macro is defined
to access the variables directly.
The _dl_phdr is also assumed to be always non NULL, since an invalid
NULL values does not trigger TLS initialization (which is used in
various libc systems).
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu.
---
csu/libc-start.c| 21 --
csu/libc-tls.c | 25 ++--
elf/dl-support.c| 52 -
sysdeps/unix/sysv/linux/dl-parse_auxv.h | 1 +
4 files changed, 46 insertions(+), 53 deletions(-)
diff --git a/csu/libc-start.c b/csu/libc-start.c
index 543560f36c..bfeee6d851 100644
--- a/csu/libc-start.c
+++ b/csu/libc-start.c
@@ -262,28 +262,7 @@ LIBC_START_MAIN (int (*main) (int, char **, char **
MAIN_AUXVEC_DECL),
}
# endif
_dl_aux_init (auxvec);
- if (GL(dl_phdr) == NULL)
# endif
-{
- /* Starting from binutils-2.23, the linker will define the
- magic symbol __ehdr_start to point to our own ELF header
- if it is visible in a segment that also includes the phdrs.
- So we can set up _dl_phdr and _dl_phnum even without any
- information from auxv. */
-
- extern const ElfW(Ehdr) __ehdr_start
-# if BUILD_PIE_DEFAULT
- __attribute__ ((visibility ("hidden")));
-# else
- __attribute__ ((weak, visibility ("hidden")));
- if (&__ehdr_start != NULL)
-# endif
-{
- assert (__ehdr_start.e_phentsize == sizeof *GL(dl_phdr));
- GL(dl_phdr) = (const void *) &__ehdr_start + __ehdr_start.e_phoff;
- GL(dl_phnum) = __ehdr_start.e_phnum;
-}
-}
__tunables_init (__environ);
diff --git a/csu/libc-tls.c b/csu/libc-tls.c
index ca4def2613..51d3cf99bf 100644
--- a/csu/libc-tls.c
+++ b/csu/libc-tls.c
@@ -119,19 +119,18 @@ __libc_setup_tls (void)
__tls_pre_init_tp ();
/* Look through the TLS segment if there is any. */
- if (_dl_phdr != NULL)
-for (phdr = _dl_phdr; phdr < &_dl_phdr[_dl_phnum]; ++phdr)
- if (phdr->p_type == PT_TLS)
- {
- /* Remember the values we need. */
- memsz = phdr->p_memsz;
- filesz = phdr->p_filesz;
- initimage = (void *) phdr->p_vaddr + main_map->l_addr;
- align = phdr->p_align;
- if (phdr->p_align > max_align)
- max_align = phdr->p_align;
- break;
- }
+ for (p
Bug#1023554: glibc: Please build with "--disable-default-pie" on sh3 and sh4 to workaround glibc bug
Source: glibc Version: 2.36-4 Severity: normal User: debian-sup...@lists.debian.org Usertags: sh3 sh4 X-Debbugs-Cc: debian-sup...@lists.debian.org,helm...@debian.org Hello! Similar to sparc64, sh3 and sh4 are affected by the upstream bug #29575 [1] which breaks static builds. This is visible on sh4 when the static busybox binary is being linked which fails with [2]: (...) /usr/bin/ld: /usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(kill.o)(.text+0x3a): unexpected instruction 0XA005 (expected 0xd0??: mov.l) /usr/bin/ld: /usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(kill.o)(.text+0x3c): unexpected instruction 0XE0FF (expected 0x0?12: stc) /usr/bin/ld: /usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(kill.o)(.text+0x3e): unexpected instruction 0X09 (expected 0x0?ce: mov.l) /usr/bin/ld: /usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(uname.o)(.text+0x3a): unexpected instruction 0XA005 (expected 0xd0??: mov.l) /usr/bin/ld: /usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(uname.o)(.text+0x3c): unexpected instruction 0XE0FF (expected 0x0?12: stc) /usr/bin/ld: /usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(uname.o)(.text+0x3e): unexpected instruction 0X09 (expected 0x0?ce: mov.l) /usr/bin/ld: /usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(alarm.o)(.text+0x3a): unexpected instruction 0XA005 (expected 0xd0??: mov.l) /usr/bin/ld: /usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(alarm.o)(.text+0x3c): unexpected instruction 0XE0FF (expected 0x0?12: stc) /usr/bin/ld: /usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(alarm.o)(.text+0x3e): unexpected instruction 0X09 (expected 0x0?ce: mov.l) /usr/bin/ld: /usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(vfork.o)(.text+0x26): unexpected instruction 0XA005 (expected 0xd0??: mov.l) (...) Adding extra_config_options = --disable-default-pie to debian/sysdeps/sh4.mk fixed the problem for me. On sh3, the change should be incorporated as well since sh3 is being bootstrapped regularly in Helmut Grohne's rebootstrap project where this issue has shown as well. Thanks, Adrian > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=29575 > [2] > https://buildd.debian.org/status/fetch.php?pkg=busybox=sh4=1%3A1.35.0-4=1667730661=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1020974: glibc: Please build with --disable-default-pie on sparc64
Source: glibc Version: 2.35-1 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hi! Starting with 2.35, glibc causes segmentation faults in some programs on sparc64, these can also be seen in the build log [1], e.g.: test ! -x /<>/build-tree/sparc64-libc/elf/ldconfig || LC_ALL=C \ /<>/build-tree/sparc64-libc/elf/ldconfig -r /<>/build-tree/sparc64-libc/testroot.pristine \ /lib/sparc64-linux-gnu /usr/lib/sparc64-linux-gnu make[3]: [Makefile:113: install] Segmentation fault (ignored) make[3]: Leaving directory '/<>' Adhemerval from glibc upstream recommended to try a build with "--disable-default-pie" which indeed fixes the problem for me. Can you therefore add "--disable-default-pie" to the configure options on sparc64 for 2.35 and 2.36? In the meantime, Adhemerval said he would be investigating the bug. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=glibc=sparc64=2.35-1=1664309564=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1018881: glibc: iconv not working properly on m68k and sh4
Hello! On 9/2/22 18:43, Aurelien Jarno wrote: I ran a build on mitchy.debian.net and the file is correctly generated. Is there anything different on the buildds? The buildds use qemu-user while mitchy uses qemu-system. The issue might be a result of the getdents issue in glibc [1]. I have uploaded a glibc package with the patch set included to unreleased in any case. Adrian [1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1018881: glibc: iconv not working properly on m68k and sh4
Hi! On 9/1/22 23:59, Aurelien Jarno wrote: The problem is that the /usr/lib/m68k-linux-gnu/gconv/gconv-modules.cache file is somehow truncated for the glibc 2.34 build. Running iconvconfig by hand to generate it fixes the issue. It seems to be the right size for the glibc 2.35 build. Yes, running iconvconfig manually fixes the problem indeed. Now I just need to figure out why the file is truncated in the first place. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1018881: glibc: iconv not working properly on m68k and sh4
Source: glibc
Version: 2.34-7
Severity: normal
User: debian-sup...@lists.debian.org
Usertags: m68k sh4
X-Debbugs-Cc: debian-...@lists.debian.org,debian-sup...@lists.debian.org
Hello!
iconv stopped working on m68k and sh4 starting with glibc 2.34 and
I have no clue why. The issue can be reproduced on real hardware
qemu-user and qemu-system.
The problem becomes visible when the configure script of the gettext
package is being run on the affected architectures:
checking for iconv... yes
checking for working iconv... no
checking for iconv declaration...
extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft,
char * *outbuf, size_t *outbytesleft);
checking for inttypes.h... (cached) yes
checking for limits.h... (cached) yes
The configure script runs a small program which I have extracted and
attached to this bug report as iconv.c.
Running it on amd64 returns a zero exit code:
(sid-amd64-sbuild)root@nofan:/# gcc -o iconv iconv.c -lc
(sid-amd64-sbuild)root@nofan:/# ./iconv
(sid-amd64-sbuild)root@nofan:/# echo $?
0
(sid-amd64-sbuild)root@nofan:/#
On m68k and sh4, the exit code is 16 which is why the above configure
check fails:
glaubitz@tirpitz:~$ uname -a
Linux tirpitz 5.11.0-rc4-00012-g10c03c5bf422 #161 PREEMPT Mon Jan 18 21:10:17
CET 2021 sh4a GNU/Linux
glaubitz@tirpitz:~$ gcc -o iconv iconv.c -lc
glaubitz@tirpitz:~$ ./iconv
glaubitz@tirpitz:~$ echo $?
16
glaubitz@tirpitz:~$
I have run out of ideas why iconv fails, so I was wondering whether this might
be a packaging issue. I have found a similar iconv issue being discussed on a
Fedora mailing list where the cause was iconv data being moved out of the main
glibc packages [1].
Maybe we have a similar problem in Debian which manifests on m68k and sh4 only
due to some reverse dependencies being out of date?
Thanks,
Adrian
> [1]
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/IWAOAD6XXXAPBQZ364OKVBZZXDDHG2KS/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
#include
#include
#define ICONV_CONST
int main() {
int result = 0;
/* Test against AIX 5.1 bug: Failures are not distinguishable from successful
returns. */
{
iconv_t cd_utf8_to_88591 = iconv_open ("ISO8859-1", "UTF-8");
if (cd_utf8_to_88591 != (iconv_t)(-1))
{
static ICONV_CONST char input[] = "\342\202\254"; /* EURO SIGN */
char buf[10];
ICONV_CONST char *inptr = input;
size_t inbytesleft = strlen (input);
char *outptr = buf;
size_t outbytesleft = sizeof (buf);
size_t res = iconv (cd_utf8_to_88591,
, ,
, );
if (res == 0)
result |= 1;
iconv_close (cd_utf8_to_88591);
}
}
/* Test against Solaris 10 bug: Failures are not distinguishable from
successful returns. */
{
iconv_t cd_ascii_to_88591 = iconv_open ("ISO8859-1", "646");
if (cd_ascii_to_88591 != (iconv_t)(-1))
{
static ICONV_CONST char input[] = "\263";
char buf[10];
ICONV_CONST char *inptr = input;
size_t inbytesleft = strlen (input);
char *outptr = buf;
size_t outbytesleft = sizeof (buf);
size_t res = iconv (cd_ascii_to_88591,
, ,
, );
if (res == 0)
result |= 2;
iconv_close (cd_ascii_to_88591);
}
}
/* Test against AIX 6.1..7.1 bug: Buffer overrun. */
{
iconv_t cd_88591_to_utf8 = iconv_open ("UTF-8", "ISO-8859-1");
if (cd_88591_to_utf8 != (iconv_t)(-1))
{
static ICONV_CONST char input[] = "\304";
static char buf[2] = { (char)0xDE, (char)0xAD };
ICONV_CONST char *inptr = input;
size_t inbytesleft = 1;
char *outptr = buf;
size_t outbytesleft = 1;
size_t res = iconv (cd_88591_to_utf8,
, ,
, );
if (res != (size_t)(-1) || outptr - buf > 1 || buf[1] != (char)0xAD)
result |= 4;
iconv_close (cd_88591_to_utf8);
}
}
#if 0 /* This bug could be worked around by the caller. */
/* Test against HP-UX 11.11 bug: Positive return value instead of 0. */
{
iconv_t cd_88591_to_utf8 = iconv_open ("utf8", "iso88591");
if (cd_88591_to_utf8 != (iconv_t)(-1))
{
static ICONV_CONST char input[] = "\304rger mit b\366sen B\374bchen
ohne Augenma\337";
char buf[50];
ICONV_CONST char *inptr = input;
size_t inbytesleft = strlen (input);
char *outptr = buf;
size_t outbytesleft = sizeof (buf);
size_t res = iconv (cd_88591_to_utf8,
, ,
, );
if (
Bug#1002699: libc6: m68k,sh4 readdir not returning filled in dirent pointer
Hello Camm! On 1/28/22 15:48, Camm Maguire wrote: > Greetings, and once again, thanks for all you do for Debian! No rush on > this item at all, needless to say. > > Problem persists. What package versions should I watch for to see that > the fix has been installed? If the current package versions don't address this issue, it's a different bug and needs to be reported against qemu or glibc. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1003847: binutils breaks glibc autopkgtest on ppc64el: unrecognized opcode: `vspltisb' (and others)
Hello! On 1/19/22 22:38, Jeffrey Walton wrote: > On Wed, Jan 19, 2022 at 4:08 PM John Paul Adrian Glaubitz > wrote: >> >> Unfortunately, glibc no longer builds with this change on powerpc and ppc64 >> and kernel builds still fails on both targets: >> >>> https://buildd.debian.org/status/fetch.php?pkg=glibc=powerpc=2.33-3=1642542048=0 >>> https://buildd.debian.org/status/fetch.php?pkg=glibc=ppc64=2.33-3=1642542055=0 >> >>> https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=5.15.15-1=1642579068=0 >>> https://buildd.debian.org/status/fetch.php?pkg=linux=ppc64=5.15.15-1=1642578946=0 > > This seems to be related to the ones stamped 1642542048 and 1642542055 > (the first two): > https://patchwork.sourceware.org/project/glibc/patch/20210925202746.819385-1...@us.ibm.com/ It will be fixed in glibc_2.33-4 [1] which has not been released yet. Adrian > [1] > https://salsa.debian.org/glibc-team/glibc/-/commit/20e02061f900515ebac6ee3872c5cd22ea5801d2 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1003847: binutils breaks glibc autopkgtest on ppc64el: unrecognized opcode: `vspltisb' (and others)
Hi Aurelien! Unfortunately, glibc no longer builds with this change on powerpc and ppc64 and kernel builds still fails on both targets: > https://buildd.debian.org/status/fetch.php?pkg=glibc=powerpc=2.33-3=1642542048=0 > https://buildd.debian.org/status/fetch.php?pkg=glibc=ppc64=2.33-3=1642542055=0 > https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=5.15.15-1=1642579068=0 > https://buildd.debian.org/status/fetch.php?pkg=linux=ppc64=5.15.15-1=1642578946=0 Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1003201: libc6: Upgrading to libc 2.33-1 causes lots of strange crashes
Hello! On 1/6/22 09:13, Aurelien Jarno wrote: >> (I marked this as serious because it's "just" ppc64, but the system is >> permaneantly unusable if this upgrade is installed.) > > I have added the powerpc list in Cc: as the ppc64 porters are the people > who can help you there. > >> I booted my ppc64 VM in qemu 6.1, apt update, apt upgrade, and 20-30 >> packages in, it died horribly >> with Python3 packages erroring out with "Cannot get content of [whatever >> package]". > > Is it a VM running with KVM or is it using QEMU emulation? I haven't seen any such issues on the powerpc/ppc64 buildds, but I will check whether I can reproduce this problem on my iBook G4 which has an older processor in case this is a regression that affects older machines only. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1002699: libc6: m68k,sh4 readdir not returning filled in dirent pointer
On 12/30/21 22:05, John Paul Adrian Glaubitz wrote: > Well, on sh4, it failed with linker errors. Seems to be a different problem > then > what I previously assumed. Not sure what the problem is then. The buildd hasn't picked up the updated glibc package yet [1]: > libc-bin_2.33-1 libc-dev-bin_2.33-1 libc6_2.33-1 libc6-dev_2.33-1 I will regenerate the chroots. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=gcl=m68k=2.6.12-117=1640457045=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1002699: libc6: m68k,sh4 readdir not returning filled in dirent pointer
Hello! On 12/30/21 21:18, Camm Maguire wrote: >> I have uploaded patched versions of glibc for m68k and sh4 and blocked the >> autobuild for glibc on the buildds. > > Greetings! I think you meant blocked autobuild for gcl No, I didn't. I meant glibc such that the autobuilders are not building the glibc package without the patches I mentioned. > In any case, after a delay, gcl just attempted autobuild on sh4 and failed the > same way. Well, on sh4, it failed with linker errors. Seems to be a different problem then what I previously assumed. Not sure what the problem is then. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1002699: libc6: m68k,sh4 readdir not returning filled in dirent pointer
Hi Camm! On 12/28/21 19:52, John Paul Adrian Glaubitz wrote: > On 12/28/21 19:20, Camm Maguire wrote: >> Correction, that is current autobuilders on 68k and sh4. > > That's a known issue, see [1]. I will patch the glibc packages for m68k > and sh4 again to address this issue. I have uploaded patched versions of glibc for m68k and sh4 and blocked the autobuild for glibc on the buildds. You may want to merge the bug with the existing bug report [1] and adjust the severity to normal. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916276 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1002699: libc6: m68k,sh4 readdir not returning filled in dirent pointer
Hello Camm! On 12/28/21 19:20, Camm Maguire wrote: > Correction, that is current autobuilders on 68k and sh4. That's a known issue, see [1]. I will patch the glibc packages for m68k and sh4 again to address this issue. Adrian > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#975421: libc6: Multiple floating point functions defined as stubs only on sh4 since 2.31
Source: glibc Version: 2.31-4 Severity: normal User: debian-sup...@lists.debian.org Usertags: sh4 X-Debbugs-Cc: debian-sup...@lists.debian.org,adhemerval.zane...@linaro.org Hi! Recently firebird3.0 started to fail to build from source on sh4 [1]. After some debugging, it turned out that the problem is that with glibc 2.31, multiple floating point functions, including fegetenv() are no longer available and are henced defined as __stub_ macros. The complete list of missing functions can be seen by diffing the stubs.h header: --- stubs-2.30.h2020-03-20 14:24:22.0 +0100 +++ stubs-2.31.h2020-10-19 16:37:57.0 +0200 @@ -12,10 +12,25 @@ #define __stub___compat_query_module #define __stub_chflags #define __stub_fchflags +#define __stub_feclearexcept +#define __stub_fedisableexcept +#define __stub_feenableexcept +#define __stub_fegetenv +#define __stub_fegetexcept +#define __stub_fegetexceptflag +#define __stub_fegetmode +#define __stub_fegetround +#define __stub_feholdexcept +#define __stub_feraiseexcept +#define __stub_fesetenv +#define __stub_fesetexcept +#define __stub_fesetexceptflag +#define __stub_fesetmode +#define __stub_fesetround +#define __stub_fetestexcept +#define __stub_feupdateenv #define __stub_gtty #define __stub_lchmod -#define __stub_pkey_alloc -#define __stub_pkey_free #define __stub_revoke #define __stub_setlogin #define __stub_sigreturn I have no idea yet what changed in 2.31 that made these functions disappear on sh4 but I hope it's just a configure options that is missing. I'm putting Adhemerval Zanella from upstream in CC. Maybe he knows from the top of his head what the reason is and what needs to be done to get the functions back. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=firebird3.0=sh4=3.0.7.33374.ds4-1=1606001862=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#972510: glibc: Please ignore misc/tst-sbrk and/or misc/tst-sbrk-pie on all archs
Hi! On 10/19/20 9:12 PM, Aurelien Jarno wrote: >> jrtc27 | misc/tst-sbrk and/or misc/tst-sbrk-pie seem to be failing on a >> *lot* of architectures >> jrtc27 | if it were up to me the problem would be solved by just deleting >> sbrk... >> jrtc27 | FreeBSD just took the stance of not implementing them for new >> ports >> jrtc27 | so it's arm64 and riscv64 ports just have no sbrk >> jrtc27 | cbmuser: looks like the tests are Debian-specific >> jrtc27 | added as part of Hurd sbrk reworking to test it didn't break > > This is a bit exaggerated, this test actually passes on more > architectures than it fails. Also this doesn't mean the test is useless, > it means those architectures behaves differently, and that something has > to be fixed. It could be some architecture specific code or the test > itself. Well, but if it's in the end a feature that no one is using and a test that isn't even part of the upstream tests I don't see the point in testing it. >> Can we disable them? With the tests disabled, glibc should pass its >> testsuite on at least alpha and >> sparc64. Not sure what the problem with hppa is at the moment. > > We can definitely ignore it on the affected architectures, do you please > give more details why the test is so wrong that it should be ignored on > *all* architectures? I'm just quoting jrtc27 from IRC. I'm not really an expert on that matter. > Ignoring it on the affected architectures, will indeed fix alpha. Not > sure about hppa, ia64 and sparc64 that have other issues. And there is > no build log for m68k and sh4 to judge. It seems that these two tests are currently the only tests that are not being ignored that are failing unless I'm missing something (I just looked at the build log). As for m68k and sh4, I currently can't enable the builds there as the fixes by Adhemerval Zanella to unbreak glibc >= 2.28 on qemu-user have not been merged yet anywhere (neither in Debian nor upstream). I know that Adhemerval is testing glibc on my SH-7785LCR board regularly and I know that Andreas Schwab is testing internally at SUSE on m68k (his openSUSE port for m68k is unfortunately not public). Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916276 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#972510: (no subject)
Source: glibc Version: 2.31-4 Severity: normal User: debian-sp...@lists.debian.org Usertags: alpha hppa ia64 m68k sh4 sparc64 Hello! The two tests: FAIL: misc/tst-sbrk FAIL: misc/tst-sbrk-pie fail on multiple architectures. According to the discussion in #debian-ports, the tests are broken and not really necessary anyway: jrtc27 | misc/tst-sbrk and/or misc/tst-sbrk-pie seem to be failing on a *lot* of architectures jrtc27 | if it were up to me the problem would be solved by just deleting sbrk... jrtc27 | FreeBSD just took the stance of not implementing them for new ports jrtc27 | so it's arm64 and riscv64 ports just have no sbrk jrtc27 | cbmuser: looks like the tests are Debian-specific jrtc27 | added as part of Hurd sbrk reworking to test it didn't break Can we disable them? With the tests disabled, glibc should pass its testsuite on at least alpha and sparc64. Not sure what the problem with hppa is at the moment. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#636286: eglibc: SIGSEGV in strcoll in UTF-8 locales with certain characters
Hi!
On 8/21/20 9:33 PM, John Paul Adrian Glaubitz wrote:
> Could you check whether this bugs still persists? It's probably been fixed
> long time ago, hasn't it?
Looks like the bug is no longer reproducible:
root@pacman:~# cat sfl.c
#include
#include
#include
#include
const char s1[] = { 0x20, 0xe0, 0xa6, 0xac, 0x00 };
const char s2[] = { 0x20, 0xe0, 0xa6, 0xad, 0x00 };
int
main(void)
{
int r;
if (setlocale(LC_ALL, "") == NULL)
err(4, "setlocale");
r = strcoll(s1, s2);
return (r < 0 ? 1 : r == 0 ? 2 : 3);
}
root@pacman:~# gcc -o sfl sfl.c
root@pacman:~# LC_ALL=C.UTF-8 ./sfl; echo $?
1
root@pacman:~#
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#636286: eglibc: SIGSEGV in strcoll in UTF-8 locales with certain characters
User: debian-68klists.debian.org Usertags: m68k X-Debbugs-CC: debian-...@lists.debian.org Hi Thorsten! Could you check whether this bugs still persists? It's probably been fixed long time ago, hasn't it? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953869: glibc: Please disable nptl/tst-cond8-static and nptl/tst-mutex{,pi}8-static on sparc64
On 3/14/20 11:26 AM, John Paul Adrian Glaubitz wrote: > With glibc 2.31, the number of testsuite failures has dropped to just three > failures on sparc64: > > FAIL: nptl/tst-cond8-static > FAIL: nptl/tst-mutex8-static > FAIL: nptl/tst-mutexpi8-static > > I have reported these failures upstream [1, 2]. > > Since 2.31 seems to be a big improvement on sparc64, can you disable these > three tests so that we can quickly enable 2.31 on sparc64? I have rebuild glibc_2.31 with these tests marked as XFAIL multiple times and the number of failures is reproducible for me. So, can we get this change included? --- debian/testsuite-xfail-debian.mk~ 2020-03-12 00:39:25.0 +0300 +++ debian/testsuite-xfail-debian.mk2020-03-15 14:10:30.480945698 +0300 @@ -985,6 +985,9 @@ test-xfail-XOPEN2K8/pthread.h/conform = yes test-xfail-XOPEN2K8/setjmp.h/conform = yes test-xfail-XPG4/setjmp.h/conform = yes +test-xfail-tst-cond8-static = yes +test-xfail-tst-mutex8-static = yes +test-xfail-tst-mutexpi8-static = yes test-xfail-tst-protected1a = yes test-xfail-tst-protected1b = yes test-xfail-tst-realloc = yes Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953869: glibc: Please disable nptl/tst-cond8-static and nptl/tst-mutex{,pi}8-static on sparc64
Source: glibc Version: 2.31-0experimental0 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 Hello! With glibc 2.31, the number of testsuite failures has dropped to just three failures on sparc64: FAIL: nptl/tst-cond8-static FAIL: nptl/tst-mutex8-static FAIL: nptl/tst-mutexpi8-static I have reported these failures upstream [1, 2]. Since 2.31 seems to be a big improvement on sparc64, can you disable these three tests so that we can quickly enable 2.31 on sparc64? 2.30 seems to be broken on sparc64, unfortunately, as it already causes segfaults during installation: Setting up libc6:sparc64 (2.30-2) ... dpkg: error processing package libc6:sparc64 (--configure): installed libc6:sparc64 package post-installation script subprocess was killed by signal (Segmentation fault) Errors were encountered while processing: libc6:sparc64 E: Sub-process /usr/bin/dpkg returned an error code (1) apt-get failed. E: Package installation failed Thanks, Adrian > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=25671 > [2] https://sourceware.org/bugzilla/show_bug.cgi?id=25672 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#946517: glibc: Unexpected nptl testsuite failures on powerpc/ppc64 in 2.30
Source: glibc Version: 2.29-5 Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc ppc64 Hi! The glibc 2.30 package in experimental has some failures on powerpc/ppc64 that are unexpected [1, 2]: FAIL: nptl/tst-cond11 FAIL: nptl/tst-cond11-static FAIL: nptl/tst-cond27 FAIL: nptl/tst-mutexpi5 FAIL: nptl/tst-mutexpi5a FAIL: nptl/tst-rwlock6 FAIL: nptl/tst-rwlock7 FAIL: nptl/tst-sem5 On openSUSE, these tests pass on both powerpc and ppc64 [3, 4], so there must be an issue either in Debian's glibc package or on the buildd in question. I'll do a give-back in any case and see if the issue persists. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=glibc=powerpc=2.30-0experimental0=1575686700=0 > [2] > https://buildd.debian.org/status/fetch.php?pkg=glibc=ppc64=2.30-0experimental0=1575687728=0 > [3] > https://build.opensuse.org/package/live_build_log/Base:System/glibc:testsuite/openSUSE_Factory_PowerPC/ppc > [4] > https://build.opensuse.org/package/live_build_log/Base:System/glibc:testsuite/openSUSE_Factory_PowerPC/ppc64
Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1
On 9/10/19 11:05 AM, John Paul Adrian Glaubitz wrote: Yes, we have already figured out that this happens when the kernel is too old. According to Aurelien, the problem is that the glibc package has been built against the kernel 5.3 headers which is why users need to upgrade their kernel first before upgrading glibc. Currently fixing tsunami. I have now kernel 5.2.9-1 and glibc 2.29-1 and logging in still doesn't work. I type "root" at the login prompt, press enter and it shortly returns to the login prompt. Logging in through SSH doesn't work either. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1
Hi! On 9/10/19 10:52 AM, Michael Cree wrote: I assume this would also work on qemu-system-alpha although I haven't tried yet. But it should work the same way but without the "--foreign" argument. What kernel are you running? Be aware that recent kernels on alpha (since ecf7e0a4ad15287) now support the getuid and getgid syscalls that the other arches always have had. I wonder if glibc has been updated in anyway for that? If so, it should be checking kernel version as to whether to use OSF1 syscall conventions or Linux syscall conventions. OSF1 calling conventions should work on any kernel, whereas Linux calling conventions only on kernels since v5.1. Yes, we have already figured out that this happens when the kernel is too old. According to Aurelien, the problem is that the glibc package has been built against the kernel 5.3 headers which is why users need to upgrade their kernel first before upgrading glibc. Currently fixing tsunami. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1
Hi! On 9/9/19 10:49 PM, John Paul Adrian Glaubitz wrote: Both on my Alpha XP-1000 as well as inside a qemu-user chroot, upgrading glibc to version 2.29-1 resulted in setuid/getuid breaking in a weird way: To reproduce, one can simply run debootstrap with qemu-user-static installed and enter the chroot: root@epyc:/local_scratch> debootstrap --no-check-gpg --arch=alpha --foreign --variant=minbase unstable sid-alpha-sbuild http://ftp.ports.debian.org/debian-ports (...) root@epyc:/local_scratch> chroot sid-alpha-sbuild bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) I have no name!@epyc:/local_scratch> ./debootstrap/debootstrap --second-stage E: debootstrap can only run as root I have no name!@epyc:/local_scratch> I assume this would also work on qemu-system-alpha although I haven't tried yet. But it should work the same way but without the "--foreign" argument. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1
Source: glibc
Version: 2.29-1
Severity: important
User: debian-al...@lists.debian.org
Usertags: alpha
Hello!
Both on my Alpha XP-1000 as well as inside a qemu-user chroot, upgrading glibc
to version 2.29-1 resulted in setuid/getuid breaking in a weird way:
(sid-alpha-sbuild)root@epyc:/# apt -y upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
bsd-mailx cron exim4-base exim4-config exim4-daemon-light groff-base
libevent-2.1-6 libgnutls-dane0 liblockfile-bin liblockfile1 libpipeline1
libreadline7 libtext-iconv-perl
libuchardet0 libunbound8 man-db psmisc
Use 'apt autoremove' to remove them.
The following packages will be upgraded:
cpp g++ gcc libc-bin libc-dev-bin libc6.1 libc6.1-dev
7 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 6329 kB/6355 kB of archives.
After this operation, 34.8 kB disk space will be freed.
Get:1 http://incoming.ports.debian.org/buildd unstable/main alpha libc6.1-dev
alpha 2.29-1 [2586 kB]
Get:2 http://incoming.ports.debian.org/buildd unstable/main alpha libc-dev-bin
alpha 2.29-1 [277 kB]
Get:3 http://incoming.ports.debian.org/buildd unstable/main alpha libc6.1 alpha
2.29-1 [2677 kB]
Get:4 http://incoming.ports.debian.org/buildd unstable/main alpha libc-bin
alpha 2.29-1 [788 kB]
Fetched 6329 kB in 3s (2509 kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = "en_US.UTF-8",
LC_CTYPE = "en_US.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
/usr/bin/locale: Cannot set LC_CTYPE to default locale: No such file or
directory
/usr/bin/locale: Cannot set LC_MESSAGES to default locale: No such file or
directory
/usr/bin/locale: Cannot set LC_ALL to default locale: No such file or directory
debconf: delaying package configuration, since apt-utils is not installed
E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device)
(Reading database ... 13696 files and directories currently installed.)
Preparing to unpack .../libc6.1-dev_2.29-1_alpha.deb ...
Unpacking libc6.1-dev:alpha (2.29-1) over (2.28-4) ...
Preparing to unpack .../libc-dev-bin_2.29-1_alpha.deb ...
Unpacking libc-dev-bin (2.29-1) over (2.28-4) ...
Preparing to unpack .../libc6.1_2.29-1_alpha.deb ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line
76.)
debconf: falling back to frontend: Readline
Unpacking libc6.1:alpha (2.29-1) over (2.28-4) ...
dpkg: error: requested operation requires superuser privilege
E: Sub-process /usr/bin/dpkg returned an error code (2)
(sid-alpha-sbuild)root@epyc:/#
After that, logging in through SSH no longer works. Running "dpkg --configure
-a" always
results in the same error as shown above. Logging in through serial console
aborts
immediately after typing the username, e.g. "root" and the login prompt is
shown again.
Shortly after typing "root" and pressing enter, the following message is
printed to the
console which seems to be an alpha-specific syscall:
[ 195.414939] do_entUnaUser: 7 callbacks suppressed
I can fix the problem with the chroot, by simply downloading the 2.28-4 version
of the
libc6.1 package and extracting it into the system root:
root@epyc:/local_scratch/sid-alpha-sbuild> wget
http://snapshot.debian.org/archive/debian-ports/20190111T160151Z/pool-alpha/main/g/glibc/libc6.1_2.28-4_alpha.deb
--2019-09-09 22:55:02--
http://snapshot.debian.org/archive/debian-ports/20190111T160151Z/pool-alpha/main/g/glibc/libc6.1_2.28-4_alpha.deb
Resolving snapshot.debian.org (snapshot.debian.org)... 193.62.202.27,
185.17.185.185, 2001:630:206:4000:1a1a:0:c13e:ca1b, ...
Connecting to snapshot.debian.org (snapshot.debian.org)|193.62.202.27|:80...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 2728400 (2.6M)
Saving to: ‘libc6.1_2.28-4_alpha.deb’
libc6.1_2.28-4_alpha.deb
100%[>]
2.60M 12.4MB/sin 0.2s
2019-09-09 22:55:02 (12.4 MB/s) - ‘libc6.1_2.28-4_alpha.deb’ saved
[2728400/2728400]
root@epyc:/local_scratch/sid-alpha-sbuild> dpkg-deb -x libc6.1_2.28-4_alpha.deb
.
root@epyc:/local_scratch/sid-alpha-sbuild> chroot .
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
(sid-alpha-sbuild)root@epyc:/#
I will follow up with more information once I have figured out more.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Deve
Bug#916276: glibc: Please add prelimenary patch to fix regression on qemu-user
Source: glibc
Version: 2.28-2
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k
Hi!
In 298d0e3129c0b5137f4989275b13fe30d0733c4d ("Consolidate Linux getdents{64}
implementation"), upstream made changes to the getdents{64} implementation
which breaks glibc on qemu-user.
The result of that is that applications like dash behave erratically, such that
for example pattern expansion no longer works. This means that "*" is not
expanded
to filenames:
$ ls -l old/
total 148
-rw-r--r-- 1 glaubitz fbedv 16188 Jun 21 2003 chardraw.c
-rw-r--r-- 1 glaubitz fbedv 7922 Jun 21 2003 fillpoly.c
-rw-r--r-- 1 glaubitz fbedv 948 Jun 21 2003 readme
-rw-r--r-- 1 glaubitz fbedv 31860 Jun 21 2003 to_atari.c
-rw-r--r-- 1 glaubitz fbedv 13093 Jun 21 2003 to_eps.c
-rw-r--r-- 1 glaubitz fbedv 6631 Jun 21 2003 to_mf.c
-rw-r--r-- 1 glaubitz fbedv 3261 Jun 21 2003 to_pbm.c
-rw-r--r-- 1 glaubitz fbedv 12854 Jun 21 2003 to_pcx.c
-rw-r--r-- 1 glaubitz fbedv 10657 Jun 21 2003 to_pdf.c
-rw-r--r-- 1 glaubitz fbedv 6697 Jun 21 2003 to_pm.c
-rw-r--r-- 1 glaubitz fbedv 9463 Jun 21 2003 to_x11a.c
-rw-r--r-- 1 glaubitz fbedv 10405 Jun 21 2003 to_x11.c
$ ls -l old/*
/bin/ls: cannot access 'old/*': No such file or directory
$
dash is just one example. Other affected applications are cmake or qmake.
The attached prelimenary patch by James Clarke fixes the problem for me.
Thanks,
Adrian
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: Fix regression of glibc 2.28 on qemu-user
The new getdents{64} implementation in glibc 2.28 breaks
qemu-user making certain applications like dash fail to
work properly.
.
Author: James Clarke
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23960
Last-Update: 2018-12-11
Index: glibc-2.28/sysdeps/unix/sysv/linux/alpha/getdents.c
===
--- glibc-2.28.orig/sysdeps/unix/sysv/linux/alpha/getdents.c
+++ glibc-2.28/sysdeps/unix/sysv/linux/alpha/getdents.c
@@ -1,11 +1,13 @@
/* Although Alpha defines _DIRENT_MATCHES_DIRENT64, 'struct dirent' and
'struct dirent64' have slight different internal layout with d_ino
being a __ino_t on non-LFS version with an extra __pad field which should
- be zeroed. */
+ be zero. */
#include
#undef _DIRENT_MATCHES_DIRENT64
#define _DIRENT_MATCHES_DIRENT64 0
-#define DIRENT_SET_DP_INO(dp, value) \
- do { (dp)->d_ino = (value); (dp)->__pad = 0; } while (0)
+#define DIRENT_CHECK_DP_INO_SIZE(kdp, dp) \
+ (sizeof ((kdp)->d_ino) == sizeof ((dp)->d_ino) + sizeof ((dp)->__pad))
+#define DIRENT_CHECK_DP_INO(dp) \
+ (dp)->__pad == 0
#include
Index: glibc-2.28/sysdeps/unix/sysv/linux/getdents.c
===
--- glibc-2.28.orig/sysdeps/unix/sysv/linux/getdents.c
+++ glibc-2.28/sysdeps/unix/sysv/linux/getdents.c
@@ -24,92 +24,85 @@
# include
# include
-# ifndef DIRENT_SET_DP_INO
-# define DIRENT_SET_DP_INO(dp, value) (dp)->d_ino = (value)
+/* For Linux we need a special version of this file since the
+ definition of `struct dirent' is not the same for the kernel and
+ the libc; the kernel places d_type after the variable-length d_name,
+ but we place it at a fixed offset just before d_name. */
+
+struct kernel_dirent
+ {
+__syscall_ulong_t d_ino;
+__syscall_ulong_t d_off;
+unsigned short d_reclen;
+char d_name[256];
+ };
+
+# ifndef DIRENT_CHECK_DP_INO_SIZE
+# define DIRENT_CHECK_DP_INO_SIZE(kdp, dp) \
+(sizeof ((kdp)->d_ino) == sizeof ((dp)->d_ino))
# endif
-/* Pack the dirent64 struct down into 32-bit offset/inode fields, and
- ensure that no overflow occurs. */
ssize_t
__getdents (int fd, char *buf, size_t nbytes)
{
- union
- {
-/* For !_DIRENT_MATCHES_DIRENT64 kernel 'linux_dirent64' has the same
- layout of 'struct dirent64'. */
-struct dirent64 k;
-struct dirent u;
-char b[1];
- } *kbuf = (void *) buf, *outp, *inp;
- size_t kbytes = nbytes;
- off64_t last_offset = -1;
ssize_t retval;
+# ifdef DIRENT_CHECK_DP_INO
+ off64_t last_offset = -1;
+# endif
-# define size_diff (offsetof (struct dirent64, d_name) \
- - offsetof (struct dirent, d_name))
- char kbuftmp[sizeof (struct dirent) + size_diff];
- if (nbytes <= sizeof (struct dirent))
-kbuf = (void*) kbuftmp;
-
- retval = INLINE_SYSCALL_CALL (getdents64, fd, kbuf, kbytes);
- if (retval == -1)
-return -1;
-
- /* These two pointers might alias the same memory buffer.
- Standard C requires that we always use the same type for them,
- so we must use the union type. */
- inp = kbuf;
- outp = (void *) buf;
-
- while (>b < >b + retval)
+ /* Th
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
Hello! On 12/9/18 3:18 PM, Matthias Klose wrote: > To me it looks sometimes that Debian is used for testing by upstream, and for > that the mips architectures don't need to be release architectures. A note on this: If you decide to move MIPS to Debian Ports, you will make the port unusable to most users as Debian Ports has a rather rudimentary FTP archive setup which has some annoying side effects. There is no support for a testing release, there is no support for cruft and the FTP maintainers will eventually remove any MIPS-only packages from the Debian archive which don't build on other architectures which usually affects packages like boot loaders meaning that it will no longer be easily possible to build the debian-installer package and consequently build installation images. The 32-bit PowerPC port lost quite a number of users because of this change. Not because the port was not healthy but because people want to be able to install a stable release. Debian unfortunately doesn't have really good support for Tier II architectures, it's either release or something based on unstable that requires extra elbow grease from both users and maintainers. Please also keep in mind that removing MIPS from the list of release architectures would mean one less open platform on which Debian is supported. Neither anything based on ARM, x86 or IBM Z provides a true open platform due to the proprietary nature of these architectures. There are some efforts in this regard on IBM POWER, but the hardware is still rather expensive, unfortunately. I do hope that RISC-V will catch up in the future though. I also think that the broad architecture support is one of the selling points of Debian and if we were to limit Debian's architecture support to just ARM, x86, POWER and IBM Z, I fear that Debian would more and more be turned into a mere development project for Ubuntu and other derivatives rather than being an operating system of its own. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#916124: glibc: Please disable or ignore math/test-float64x-float128-mul on sparc64
Source: glibc Version: 2.28-2 Severity: normal Tags: upstream User: debian-sp...@lists.debian.org Usertags: sparc64 The test math/test-float64x-float128-mul is currently known to be broken on sparc64 and it has been reported upstream [1]. Since this single test prevents glibc 2.28 from being built on sparc64, I would like to ask for this test to be disabled or ignored unless there is something that speaks against this. Upstream has a sparc64 porterbox available through the gcc compile farm which can be used for debugging the problem. Thanks, Adrian > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=23886 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#915958: glibc: Please include patch to fix sigaction regression on m68k
Source: glibc
Version: 2.28-2
Severity: important
Tags: patch upstream
User: debian-...@lists.debian.org
Usertags: m68k
Hello!
glibc 2.28 is affected by a regression on m68k which causes some
applications to lock up [1]. A patch has been proposed in the
bug report which fixes the problem for me.
I am attaching the patch. Can you include it in the next upload?
Thanks,
Adrian
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>From 4a3213d0169370930ec338b6221ea1fe2c9d24d2 Mon Sep 17 00:00:00 2001
From: James Clarke
Date: Sat, 8 Dec 2018 14:29:31 +
Subject: [PATCH] m68k: Fix kernel_sigaction definition
To: libc-al...@sourceware.org
The commit b4a5d26d8835d972995f0a0a2f805a8845bafa0b
"linux: Consolidate sigaction implementation" changed the m68k
kernel_sigaction definition to have the field order of the old API which
differ from the current API.
* sysdeps/unix/sysv/linux/m68k/kernel_sigaction.h: Use default
Linux version as base implementation.
---
.../unix/sysv/linux/m68k/kernel_sigaction.h | 22 ---
1 file changed, 4 insertions(+), 18 deletions(-)
diff --git a/sysdeps/unix/sysv/linux/m68k/kernel_sigaction.h
b/sysdeps/unix/sysv/linux/m68k/kernel_sigaction.h
index 54972feb13..94f3e9b082 100644
--- a/sysdeps/unix/sysv/linux/m68k/kernel_sigaction.h
+++ b/sysdeps/unix/sysv/linux/m68k/kernel_sigaction.h
@@ -1,22 +1,8 @@
-#ifndef _KERNEL_SIGACTION_H
-# define _KERNEL_SIGACTION_H
-
-#include
-
+/* m68k uses the generic Linux UAPI but defines SA_RESTORER. */
#define SA_RESTORER 0x0400
+#include
-/* This is the sigaction structure from the Linux 3.2 kernel. */
-struct kernel_sigaction
-{
- __sighandler_t k_sa_handler;
- sigset_t sa_mask;
- unsigned long sa_flags;
- void (*sa_restorer) (void);
-};
-
-#define SET_SA_RESTORER(kact, act) \
+#define SET_SA_RESTORER(kact, act) \
(kact)->sa_restorer = (act)->sa_restorer
-#define RESET_SA_RESTORER(act, kact) \
+#define RESET_SA_RESTORER(act, kact) \
(act)->sa_restorer = (kact)->sa_restorer
-
-#endif
--
2.19.2
Bug#914997: glibc: Please disable or ignore misc/tst-pkey on powerpc/powerpcspe/ppc64
Source: glibc Version: 2.28-1 Severity: normal Tags: upstream User: debian-powe...@lists.debian.org Usertags: powerpc Hello! The misc/tst-pkey currently fails on all big-endian PowerPC targets as the Linux kernel is missing an implementation of pkey_set and pkey_get on these targets [1]. Can you disable or ignore the test misc/tst-pkey on powerpc, powerpcspe and ppc64 so that glibc builds successfully there? On powerpcspe, there is still another issue which I will have a look at. Adrian > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=23202 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: armel/armhf arch qualification for buster: call for DSA, Security, toolchain concernsj
Hi Roger! On 07/23/2018 10:42 AM, Roger Shimizu wrote: > I talked to a few people about keeping armel in buster, during 1st and > 2nd day in debcamp. > Seems the blocker is just the buildd server hardware, and memory size it has. According to my colleague Alex Graf at SUSE, you can definitely build ARMv7 on arm64 using chroots. The only problem with chroots is that "uname -a" shows "armv8" which some userspace applications are stumbling over. openSUSE/SLE builds armv7 packages in OBS/IBS using a fully emulated system using KVM. As for the hardware, you should watch out for hardware with ARM Cortex Cores. Alternatively, X-Gene 1. ThunderX, ThunderX2 and Centriq are definitely not supported. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj
> On Jun 29, 2018, at 9:50 AM, Jonathan Wiltshire wrote: > >> On Fri, Jun 29, 2018 at 11:04:26PM +0900, Roger Shimizu wrote: >> I see armel is already not a candidate for buster [0]. >> So it seems we can discuss armhf, but no armel at all. >> I don't agree with this idea. >> And I think we should treat armel and armhf equally. > > Please review the mail which originated this thread [1] where you will see > that both armel and armhf are affected by DSA's concern. If I understand > correctly, virtualisation of architectures in general is a possible > solution but there are problems in the case of these two. I have just talked to a colleague at SUSE about this and apparently Alex Graf from SUSE’s QEMU/KVM team has fixed many bugs regarding ARM32 on ARM64 virtualization. If I understand correctly, SUSE builds ARMv7 on ARM64 without problems. I have reached out to Alex Graf and asked him for clarification on what possibilities we currently have. Adrian
Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj
On 06/29/2018 10:41 AM, Luke Kenneth Casson Leighton wrote: > On Fri, Jun 29, 2018 at 8:16 AM, Uwe Kleine-König > wrote: > >>> In short, the hardware (development boards) we're currently using to >>> build armel and armhf packages aren't up to our standards, and we >>> really, really want them to go away when stretch goes EOL (expected in >>> 2020). We urge arm porters to find a way to build armhf packages in >>> VMs or chroots on server-class arm64 hardware. > > from what i gather the rule is that the packages have to be built > native. is that a correct understanding or has the policy changed? Native in the sense that the CPU itself is not emulated which is the case when building arm32 packages on arm64. We're also building i386 packages on amd64 and we used to build powerpc packages on ppc64 (and we will continue to do that once the move of powerpc to ports has been completed). I think that building on arm64 after fixing the bug in question is the way to move forward. I'm surprised the bug itself hasn't been fixed yet, doesn't speak for ARM. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#882794: [Debian-ports-devel] Bug#882794: glibc: Please backport fix for assertion failure in posix_spawn()
On 11/26/2017 10:13 PM, John Paul Adrian Glaubitz wrote: > This was introduced with [1] and reported in [2]. A QEMU bug report > has also been opened [3]. I'm currently rebuilding glibc for m68k with > the attached patch which should fix the issue. Would be great if it > could be included in one of the next uploads provided that it fixes > the issue which I am going to find out soon. Hmm, ok, seems that the patch is unrelated. It doesn't help with QEMU. Guess we'll have to wait for QEMU to be fixed then. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#882794: glibc: Please backport fix for assertion failure in posix_spawn()
Source: glibc
Version: 2.24-11+deb9u1
Severity: important
Tags: patch upstream
Hello!
With glibc 2.25, an upstream change was introduced with causes an
assertion failure on current versions of QEMU:
dpkg: warning: ignoring pre-dependency problem!
Preparing to unpack .../archives/bash_4.4-5_m68k.deb ...
preinst: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >=
0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
dpkg: error processing archive /var/cache/apt/archives/bash_4.4-5_m68k.deb
(--unpack):
new bash package pre-installation script subprocess was killed by signal
(Aborted)
Selecting previously unselected package bsdutils.
dpkg: regarding .../bsdutils_1%3a2.30.2-0.1_m68k.deb containing bsdutils,
pre-dependency problem:
bsdutils pre-depends on libsystemd0
libsystemd0 is not installed.
This was introduced with [1] and reported in [2]. A QEMU bug report
has also been opened [3]. I'm currently rebuilding glibc for m68k with
the attached patch which should fix the issue. Would be great if it
could be included in one of the next uploads provided that it fixes
the issue which I am going to find out soon.
Adrian
> [1]
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=4b4d4056bb154603f36c6f8845757c1012758158;hp=8d3bd947483f50b57aee7c35c07dc1927d6e8a27
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=22273
> [3] https://bugs.launchpad.net/qemu/+bug/1673976
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: Fix improper assert in Linux posix_spawn (BZ#22273)
Fixes assertion failure on qemu-user.
.
Origin: upstream
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22273
Last-Update: 2017-11-26
--- glibc-2.25.orig/sysdeps/unix/sysv/linux/spawni.c
+++ glibc-2.25/sysdeps/unix/sysv/linux/spawni.c
@@ -17,7 +17,6 @@
<http://www.gnu.org/licenses/>. */
#include
-#include
#include
#include
#include
@@ -266,7 +265,6 @@ __spawni_child (void *arguments)
__sigprocmask (SIG_SETMASK, (attr->__flags & POSIX_SPAWN_SETSIGMASK)
? >__ss : >oldmask, 0);
- args->err = 0;
args->exec (args->file, args->argv, args->envp);
/* This is compatibility function required to enable posix_spawn run
@@ -337,7 +335,7 @@ __spawnix (pid_t * pid, const char *file
/* Child must set args.err to something non-negative - we rely on
the parent and child sharing VM. */
- args.err = -1;
+ args.err = 0;
args.file = file;
args.exec = exec;
args.fa = file_actions;
@@ -360,12 +358,26 @@ __spawnix (pid_t * pid, const char *file
new_pid = CLONE (__spawni_child, STACK (stack, stack_size), stack_size,
CLONE_VM | CLONE_VFORK | SIGCHLD, );
+ /* It needs to collect the case where the auxiliary process was created
+ but failed to execute the file (due either any preparation step or
+ for execve itself). */
if (new_pid > 0)
{
+ /* Also, it handles the unlikely case where the auxiliary process was
+terminated before calling execve as if it was successfully. The
+args.err is set to 0 as default and changed to a positive value
+only in case of failure, so in case of premature termination
+due a signal args.err will remain zeroed and it will be up to
+caller to actually collect it. */
ec = args.err;
- assert (ec >= 0);
- if (ec != 0)
- __waitpid (new_pid, NULL, 0);
+ if (ec > 0)
+ /* There still an unlikely case where the child is cancelled after
+ setting args.err, due to a positive error value. Also due a
+ possible pid reuse race (where the kernel allocated the same pid
+ to unrelated process) we need not to undefinitely hang expecting
+ an invalid pid. In both cases an error is returned to the
+ caller. */
+ __waitpid (new_pid, NULL, WNOHANG);
}
else
ec = -new_pid;
Bug#857909: [libc6-dev] getpid() in child process created using clone(CLONE_VM) returns parent's pid
Hi Kirill!
On 03/17/2017 10:30 AM, Kirill Tkhai wrote:
> I interpret the below paragraph as the only "stale-cache" case:
>
>>> In particular, if a signal is delivered to the child immediately after
>>> the clone()
>>> call, then a call to getpid(2) in a handler for the signal may return the
>>> PID of the calling
>>> process ("the parent"), if the clone wrapper has not yet had a chance to
>>> update the PID cache in
>>> the child.
No, this is just one example. "In particular" does not mean that this is the
only case
where this applies, just a very noteworthy one. It's not exclusive to this case.
> Also, there is
>
>>> The stale-cache problem also does not occur if the flags argument
>>> includes CLONE_VM.
>
> Isn't it the case of my test program?
Yes, but I'd still argue that the overall statement for getpid() is "We don't
guarantee
that the information provided by getpid() is correct and we therefore recommend
you
to use the syscall." Whether this flag makes a difference to the overall
reliability
of getpid() or not is questionable.
I did a quick check on Jessie and it seems that at least the statement for
CLONE_VM
is true there, although as you can see from the output below, the process
scheduling
from the kernel side seems to be different with the terminal output already
returning
to bash before the child has a chance to print to the terminal:
glaubitz@jessie64:~> ./clone
parent: pid=1320
parent: fork pid=1321
glaubitz@jessie64:~> 1)child: pid=1321
2)child: pid=1321
I would suggest filing a bug report to glibc upstream or posting on their
mailing list
to ask for feedback. I honestly don't know how acceptable the stale cache data
with
CLONE_VM is, but since the documentation already recommends to using the
syscall, I
think its safe to ignore this behavior:
> To get the truth, it may be necessary to use code such as the following:
>
> #include
>
> pid_t mypid;
>
> mypid = syscall(SYS_getpid);
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#857909: [libc6-dev] getpid() in child process created using clone(CLONE_VM) returns parent's pid
Hi Kirill! > My case is not in the list of the cases, described in clone(2), > when wrong pid may be returned, so this is a BUG. Which case in particular do you mean? From the manpage it seems that getpid() is simply not reliable under various circumstances and that one should always use the syscall alternative if possible: > Versions of the GNU C library that include the NPTL threading library > contain a wrapper function for getpid(2) > that performs caching of PIDs. This caching relies on support in the glibc > wrapper for clone(), but as currently > implemented, the cache may not be up to date in some circumstances. Can you elaborate a bit more where your sample code contradicts the clone(2) manpage which documents the buggy behavior? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#855692: glibc: Please backport patch to fix 64-bit atomics on m68k
Source: glibc
Version: 2.24-9
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k
Hi!
glibc upstream recently merged a patch by Andreas Schwab to fix
64-bit atomics on m68k [1]. We have had multiple issues with
atomics on m68k in the past with packages like openjdk-8 and
firebird3.0 which I was able to resolve by downgrading glibc.
I therefore highly suspect that we need this patch to get these
aforementioned packages build properly on m68k again. I'm attaching
the cherry-picked patch for inclusion in the glibc package.
Thanks,
Adrian
> [1]
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=64ae9fe45662c8994b0e56ab469b01967408a154
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: Fix 64-bit atomics on m68k
Author: Andreas Schwab <sch...@linux-m68k.org>
Last-Update: 2017-02-20
--- glibc-2.24.orig/sysdeps/m68k/m680x0/m68020/atomic-machine.h
+++ glibc-2.24/sysdeps/m68k/m680x0/m68020/atomic-machine.h
@@ -73,7 +73,7 @@ typedef uintmax_t uatomic_max_t;
__typeof (mem) __memp = (mem); \
__asm __volatile ("cas2%.l %0:%R0,%1:%R1,(%2):(%3)" \
: "=d" (__ret) \
- : "d" (newval), "r" (__memp), \
+ : "d" ((__typeof (*(mem))) (newval)), "r" (__memp),\
"r" ((char *) __memp + 4), "0" (oldval) \
: "memory"); \
__ret; })
@@ -101,8 +101,9 @@ typedef uintmax_t uatomic_max_t;
__asm __volatile ("1: cas2%.l %0:%R0,%1:%R1,(%2):(%3);" \
" jbne 1b" \
: "=d" (__result) \
- : "d" (newvalue), "r" (__memp),\
-"r" ((char *) __memp + 4), "0" (__result)\
+ : "d" ((__typeof (*(mem))) (newvalue)),\
+"r" (__memp), "r" ((char *) __memp + 4), \
+"0" (__result) \
: "memory"); \
} \
__result; })
@@ -144,7 +145,7 @@ typedef uintmax_t uatomic_max_t;
" cas2%.l %0:%R0,%1:%R1,(%3):(%4);" \
" jbne 1b" \
: "=d" (__result), "=" (__temp) \
- : "d" (value), "r" (__memp), \
+ : "d" ((__typeof (*(mem))) (value)), "r" (__memp), \
"r" ((char *) __memp + 4), "0" (__result)\
: "memory"); \
} \
@@ -175,8 +176,9 @@ typedef uintmax_t uatomic_max_t;
" cas2%.l %0:%R0,%1:%R1,(%3):(%4);" \
" jbne 1b"\
: "=d" (__oldval), "=" (__temp) \
- : "d" (value), "r" (__memp),\
- "r" ((char *) __memp + 4), "0" (__oldval) \
+ : "d" ((__typeof (*(mem))) (value)),\
+ "r" (__memp), "r" ((char *) __memp + 4), \
+ "0" (__oldval)\
: "memory");\
} \
})
Bug#851867: glibc: Please clone sysdeps from sh4 for sh3
Source: glibc Version: 2.24-9 Severity: wishlist Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi! While bootstrapping for sh3 using rebootstrap, I ran into the same problem we previously had with glibc on sh4: /tmp/buildd/glibc2/glibc-2.24/build-tree/sh3-libc/elf/dl-allobjs.os:/tmp/buildd/glibc2/glibc-2.24/elf/dl-open.c:756: first defined here /tmp/buildd/glibc2/glibc-2.24/build-tree/sh3-libc/libc_pic.a(init-first.os):(.data+0x0): multiple definition of `__libc_multiple_libcs' /tmp/buildd/glibc2/glibc-2.24/build-tree/sh3-libc/elf/dl-allobjs.os:/tmp/buildd/glibc2/glibc-2.24/elf/rtld.c:647: first defined here /tmp/buildd/glibc2/glibc-2.24/build-tree/sh3-libc/libc_pic.a(_itoa.os): In function `_itoa': /tmp/buildd/glibc2/glibc-2.24/stdio-common/_itoa.c:196: multiple definition of `_itoa' This is trivially fixed by cloning debian/sysdeps/sh4.mk to debian/sysdeps/sh3.mk which is what the attached patch does. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >From e547ed5acb70dba2d476a32f0f146b1d3c9fe8ff Mon Sep 17 00:00:00 2001 From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> Date: Thu, 19 Jan 2017 14:29:23 +0100 Subject: [PATCH] Clone sysdeps/sh4.mk for sh3. Signed-off-by: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> --- debian/sysdeps/sh3.mk | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 debian/sysdeps/sh3.mk diff --git a/debian/sysdeps/sh3.mk b/debian/sysdeps/sh3.mk new file mode 100644 index ..412008c9 --- /dev/null +++ b/debian/sysdeps/sh3.mk @@ -0,0 +1,7 @@ +# Renesas SH enabled -ffinte-math-only. Some software need -mieee. +extra_cflags = -mieee + +# GCC 5 and later emits calls to abort() when there is no target specific +# __builtin_trap() implementation. This is not possible to do so in ld.so +# so we need to pass the -fno-delete-null-pointer-checks option to GCC. +extra_cflags += -fno-delete-null-pointer-checks -- 2.11.0
Bug#850565: glibc: Please enable architecture support for sh3
Source: glibc Version: 2.24-8 Severity: wishlist User: helm...@debian.org Usertags: rebootstrap Hi! I have recently acquired a Mimas v2 board which allows to run the open source CPU J-Core [1] in an FPGA. J-Core is an open source reimplementation of the SuperH architecture which is currently present as "sh4" in Debian. This year, the J-Core team plans to release the J-3 CPU which is an open source reimplementation of the SH-3 CPU. Since Debian has already partial support for SH-3 (dpkg, openssl, toolchain), it would be nice to have "sh3" added to the list of architectures in the glibc package the same way "nios2" was added in [2]. This way, Helmut Grohne can enable "sh3" for rebootstrap and we see where can go from there to run Debian on J-Core. Thanks, Adrian > [1] http://j-core.org/ > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817944 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#825865: glibc: Testsuite failure on sparc64 due to unaligned access in wcsmbs/test-wcsncmp.c
On 06/03/2016 02:38 PM, John Paul Adrian Glaubitz wrote: > I will verify the configuration again. Ok, so there was indeed one strange issue which was that /dev/shm in the host system was mounted again when invoking any schroot command, so that after running schroot once, mount on the host system showed three mounts of shm: Before calling schroot: root@landau:~# mount |grep shm tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) After calling schroot -c sid1-sparc64-sbuild in a second terminal: root@landau:~# mount |grep shm tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run/schroot/mount/sid1-sparc64-sbuild-134f6ca3-bd12-4b3c-a389-cfacf7bb2c35/dev/shm type tmpfs (rw,relatime) tmpfs on /dev/shm type tmpfs (rw,relatime) Either way, this has been fixed now. Let's try again :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#825865: glibc: Testsuite failure on sparc64 due to unaligned access in wcsmbs/test-wcsncmp.c
Hi! On 06/03/2016 02:26 PM, Aurelien Jarno wrote: > FAIL: rt/tst-shm > original exit status 1 > > It's very likely that /dev/shm (or /run/shm) is not mounted correctly in > the chroot. Hmm, that's odd. I have just verified this again: root@landau:~# schroot -c sid1-sparc64-sbuild (sid1-sparc64-sbuild)root@landau:~# mount /dev/vdiskc1 on / type ext4 (rw,relatime,data=ordered) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=66386376k,nr_inodes=8298297,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /dev/shm type tmpfs (rw,relatime) (sid1-sparc64-sbuild)root@landau:~# Additionally, /etc/schroot/buildd/fstab and /etc/schroot/chroot.d/* look fine, so I'm not sure what else is missing. I have seen gcc-5 and gcc-6 sporadically complain about insufficient ptys, too. So there might be something wrong with the fstab configuration. I will verify the configuration again. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#825865: glibc: Testsuite failure on sparc64 due to unaligned access in wcsmbs/test-wcsncmp.c
On 05/31/2016 04:26 PM, Nick Alcock wrote: >> Hmm, then I'm a bit out of ideas. The idea came from Nick Alcock, so maybe >> he can comment on this as well. > > I was only commenting on how to stop the spurious timeouts. > TIMEOUTFACTOR won't make bus errors go away. :) Oh, no, I wasn't talking about this bus error but remaining test failures I was seeing after applying Jose's patch. I have made a test build with Jose's patch applied as well as setting TIMEOUTFACTOR to 100, the result can be seen in the log in [1]. Adrian > [1] > https://people.debian.org/~glaubitz/glibc_2.22-9+sparc64_sparc64-20160530-2024.build -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#825865: glibc: Testsuite failure on sparc64 due to unaligned access in wcsmbs/test-wcsncmp.c
(Sorry for the confusion, I accidentally used my company email. Please answer to this address). Hi Aurelien! On 05/31/2016 04:13 PM, Aurelien Jarno wrote: >> -- >> XFAIL: wcsmbs/test-wcsncmp >> original exit status 1 >> wcsncmp simple_wcsncmp stupid_wcsncmp >> Didn't expect signal from child: got `Bus error' >> -- > > While the issue is real, this is not the reason while the package fails > to build from source. The test is marked as XFAIL as shown above. Ok, I see. I thought the problem would still trigger due to the unusual failure. > Thanks for submitting the patch upstream. Given the above, I think it is > better to wait for an answer from upstream before applying it. The test comes from Jose Marchesi who I know is gcc upstream, but I'm not sure about glibc. Jose, could you please comment on this? >> Please note: I was still getting some spurious test failures in >> rt/tst-mqueue5 >> due to timeouts. But those could also be a local issue which needs some >> further >> investiogation (might be related to TIMEOUTFACTOR in debian/build.mk). > > TIMEOUTFACTOR just increases the timeout, if you don't specify it, the > test will just fail faster. Hmm, then I'm a bit out of ideas. The idea came from Nick Alcock, so maybe he can comment on this as well. What's more strange is that glibc_2.22-7 actually happened to build fine, with the tests enabled [1]. All later builds failed again. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=glibc=sparc64=2.22-7=1462606555 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#825865: glibc: Testsuite failure on sparc64 due to unaligned access in wcsmbs/test-wcsncmp.c
Source: glibc
Version: 2.22-9
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64
Hi!
glibc currently fails to build from source on sparc64 due at least one test
in the testsuite failing which is due to a bus error (unaligned access):
--
XFAIL: wcsmbs/test-wcsncmp
original exit status 1
wcsncmp simple_wcsncmp stupid_wcsncmp
Didn't expect signal from child: got `Bus error'
--
I have notified glibc upstream of these issue - not in a bug report but by
talking to one of the developers and I have now a patch that fixes the
problem [1].
This patch applies cleanly to glibc 2.22-9 in Debian unstable when dropping
the Changelog part from the upstream patch, so I'm attaching a patch with
this part removed as a suggestion for what to include in the Debian package.
Please note: I was still getting some spurious test failures in rt/tst-mqueue5
due to timeouts. But those could also be a local issue which needs some further
investiogation (might be related to TIMEOUTFACTOR in debian/build.mk).
Cheers,
Adrian
> [1] https://sourceware.org/ml/libc-alpha/2016-05/msg00710.html
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: Fix string/test-strncmp.c to work with wide chars.
wcsmbs/test-wcsncmp.c (i.e. string/test-strncmp with defined WIDE)
triggers a signal in aligment-strict platforms, like sparc*-*-*.
.
This patch fixes string/test-strncmp.c to work properly when the test is
performed on arrays of wide chars. This includes passing align1 and
align2 to do_test as bytes, and to use more meaningful values for middle
chars and large chars.
.
--- glibc-2.22.orig/string/test-strncmp.c
+++ glibc-2.22/string/test-strncmp.c
@@ -38,6 +38,8 @@
# define CHAR wchar_t
# define UCHAR wchar_t
# define CHARBYTES 4
+# define MIDCHAR 0x7fff
+# define LARGECHAR 0xfffe
# define CHAR__MAX WCHAR_MAX
# define CHAR__MIN WCHAR_MIN
@@ -88,6 +90,8 @@ stupid_wcsncmp (const CHAR *s1, const CH
# define CHAR char
# define UCHAR unsigned char
# define CHARBYTES 1
+# define MIDCHAR 0x7f
+# define LARGECHAR 0xfe
# define CHAR__MAX CHAR_MAX
# define CHAR__MIN CHAR_MIN
@@ -414,56 +418,56 @@ test_main (void)
for (i =0; i < 16; ++i)
{
- do_test (0, 0, 8, i, 127, 0);
- do_test (0, 0, 8, i, 127, -1);
- do_test (0, 0, 8, i, 127, 1);
- do_test (i, i, 8, i, 127, 0);
- do_test (i, i, 8, i, 127, 1);
- do_test (i, i, 8, i, 127, -1);
- do_test (i, 2 * i, 8, i, 127, 0);
- do_test (2 * i, i, 8, i, 127, 1);
- do_test (i, 3 * i, 8, i, 127, -1);
- do_test (0, 0, 8, i, 255, 0);
- do_test (0, 0, 8, i, 255, -1);
- do_test (0, 0, 8, i, 255, 1);
- do_test (i, i, 8, i, 255, 0);
- do_test (i, i, 8, i, 255, 1);
- do_test (i, i, 8, i, 255, -1);
- do_test (i, 2 * i, 8, i, 255, 0);
- do_test (2 * i, i, 8, i, 255, 1);
- do_test (i, 3 * i, 8, i, 255, -1);
+ do_test (0, 0, 8, i, MIDCHAR, 0);
+ do_test (0, 0, 8, i, MIDCHAR, -1);
+ do_test (0, 0, 8, i, MIDCHAR, 1);
+ do_test (CHARBYTES * i, CHARBYTES * i, 8, i, MIDCHAR, 0);
+ do_test (CHARBYTES * i, CHARBYTES * i, 8, i, MIDCHAR, 1);
+ do_test (CHARBYTES * i, CHARBYTES * i, 8, i, MIDCHAR, -1);
+ do_test (CHARBYTES * i, 2 * CHARBYTES * i, 8, i, MIDCHAR, 0);
+ do_test (2 * CHARBYTES * i, CHARBYTES * i, 8, i, MIDCHAR, 1);
+ do_test (CHARBYTES * i, 3 * CHARBYTES * i, 8, i, MIDCHAR, -1);
+ do_test (0, 0, 8, i, LARGECHAR, 0);
+ do_test (0, 0, 8, i, LARGECHAR, -1);
+ do_test (0, 0, 8, i, LARGECHAR, 1);
+ do_test (CHARBYTES * i, CHARBYTES * i, 8, i, LARGECHAR, 0);
+ do_test (CHARBYTES * i, CHARBYTES * i, 8, i, LARGECHAR, 1);
+ do_test (CHARBYTES * i, CHARBYTES * i, 8, i, LARGECHAR, -1);
+ do_test (CHARBYTES * i, 2 * CHARBYTES * i, 8, i, LARGECHAR, 0);
+ do_test (2 * CHARBYTES * i, CHARBYTES * i, 8, i, LARGECHAR, 1);
+ do_test (CHARBYTES * i, 3 * CHARBYTES * i, 8, i, LARGECHAR, -1);
}
for (i = 1; i < 8; ++i)
{
- do_test (0, 0, 8 << i, 16 << i, 127, 0);
- do_test (0, 0, 8 << i, 16 << i, 127, 1);
- do_test (0, 0, 8 << i, 16 << i, 127, -1);
- do_test (0, 0, 8 << i, 16 << i, 255, 0);
- do_test (0, 0, 8 << i, 16 << i, 255, 1);
- do_test (0, 0, 8 << i, 16 << i, 255, -1);
- do_test (8 - i, 2 * i, 8 << i, 16 << i, 127, 0);
- do_test (8 - i, 2 * i, 8 << i, 16 << i, 127, 1);
- do_test (2 * i, i, 8 << i, 16 << i, 255, 0);
- do_test (2 * i, i, 8 << i, 16 << i, 255, 1);
-}
-
- do_test_limit (0, 0, 0, 0, 127, 0);
- do_test_limit (4, 0, 21, 20, 127, 0);
- do_test_limit (0, 4, 21, 20, 127, 0);
-
Re: glibc 2.22 testsuite issues on sparc64
Hi Aurelien! On 03/08/2016 07:40 PM, Aurelien Jarno wrote: > The error returned by some of these tests is "Resource temporarily > unavailable". Given they are new issues that don't happen on ravirin > nor on my system, it could be a kernel issue. There was actually a bug in the kernel on sparc64 that made several userspace applications segfault [1]. This bug was fixed with Linux 4.5.0 which I have installed on all running buildds now (raverin is currently down, unfortunately). While the updated kernel fixed several packages which previously failed to build from source, it did not address the issue we have with glibc, unfortunately. > Given I am unable to reproduce the issues, can someone please > investigate them? Maybe Jose Marchesi (CC) could have a look at it? I'm not really an expert when it comes to the glibc. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Re: glibc issues on powerpcspe
On 03/11/2016 01:10 PM, John Paul Adrian Glaubitz wrote: > There must be something I am overlooking which will enable soft-fp > support in glibc. Alright, we just need to pass "--without-fp" when building on powerpcspe, see [1]. I'm surprised this happen by default on powerpcspe. Adrian > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817926 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#817926: glibc: Please build with "--without-fp" on powerpcspe to enable FPU emulation
Source: glibc Version: 2.22-2 Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpcspe Hello! glibc currently fails to build from source on powerpcspe because the configure script defaults to "--with-fp" even when building natively on powerpcspe (e500). Although the glibc build system detects e500 through the non-availability of FPRs in sysdeps/powerpc/preconfigure: case "$machine" in powerpc64*) base_machine=powerpc machine=powerpc/powerpc64 ;; powerpc*) # Check for e500. $CC $CFLAGS $CPPFLAGS -E -dM -xc /dev/null > conftest.i if grep -q __NO_FPRS__ conftest.i && ! grep -q _SOFT_FLOAT conftest.i; then base_machine=powerpc machine=powerpc/powerpc32/e500 else base_machine=powerpc machine=powerpc/powerpc32 fi rm -f conftest.i ;; esac it does not enable the FPU emulation code with the "--without-fp" switch which results in the aforementioned FTBFS [1]. Enabling FPU emulation in glibc is also a requirement to be able to build gcc-5 on powerpcspe since newer versions of gcc have been modified to use the FPU emulation in glibc instead of their own emulation code in libgcc [2]. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=glibc=powerpcspe=2.19-18=1429072945 > [2] https://patchwork.ozlabs.org/patch/405072/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: glibc issues on powerpcspe
On 03/11/2016 08:42 AM, John Paul Adrian Glaubitz wrote: > Now, since gcc-5 relies on the FPU emulation code to be present in > glibc, I tried to force-enable e500 support in glibc: > > case "$machine" in > powerpc) > # $CC $CFLAGS $CPPFLAGS -E -dM -xc /dev/null > conftest.i > # if grep -q __NO_FPRS__ conftest.i && ! grep -q _SOFT_FLOAT > conftest.i; then > base_machine=powerpc machine=powerpc/powerpc32/e500 > # fi > rm -f conftest.i > ;; > esac And surprisingly, that doesn't help to enforce soft-fp emulation to be enabled in glibc. During build, I can change into the build directory and running objdump -t on the libc.so file will actually list on of the required symbols (__unorddf2). However, in the final glibc package, the symbol is missing again. There must be something I am overlooking which will enable soft-fp support in glibc. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
glibc issues on powerpcspe
Hi Aurelien! I have been struggling the past days to get gcc-5 build on powerpcspe. The build failed because gcc-5 relies on FPU emulation functions to be present in the glibc where they are currently missing, unfortunately, despite the fact that upstream glibc ships FPU emulation in the "soft-fp" directory, for that matter. Now, trying to build the glibc package (version 2.21) "as is" also currently fails because the package is being built with the assumption that the host machine support hardware FPU instructions which, of course, fails. Looking through the sources, I found: glibc-2.19/sysdeps/powerpc/preconfigure which triggers e500 support depending on whether gcc ships its own FPU emulation or not. Now, since gcc-5 relies on the FPU emulation code to be present in glibc, I tried to force-enable e500 support in glibc: case "$machine" in powerpc) # $CC $CFLAGS $CPPFLAGS -E -dM -xc /dev/null > conftest.i # if grep -q __NO_FPRS__ conftest.i && ! grep -q _SOFT_FLOAT conftest.i; then base_machine=powerpc machine=powerpc/powerpc32/e500 # fi rm -f conftest.i ;; esac However, the build still fails with the same problem that glibc tries to use hardware FPU instructions: ../sysdeps/powerpc/powerpc32/fpu/s_copysign.S: Assembler messages: ../sysdeps/powerpc/powerpc32/fpu/s_copysign.S:31: Error: unrecognized opcode: `stfd' ../sysdeps/powerpc/powerpc32/fpu/s_copysign.S:37: Error: unrecognized opcode: `fabs' ../sysdeps/powerpc/powerpc32/fpu/s_copysign.S:39: Error: unrecognized opcode: `fnabs' which surprises me given that selecting e500 should actually disable these altogether and use the soft-fp code but apparently that doesn't work. Any idea how I can build glibc with soft-fp enabled so I can finally build gcc-5? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: glibc 2.22 build failure on sh4
Hi Aurelien! (CC'ing Helmut Grohne since he has been seeing this issue in rebootstrap as well as Oleg Endo and Kaz Kojima as they are most likely interested in fixing the issue in gcc being gcc/sh upstream developers) On 03/10/2016 11:02 PM, Aurelien Jarno wrote: > The glibc package in version 2.22 which has been uploaded to sid a few > days ago fails to build on sh4 [1]. I have tracked it down to a missing > target specific implementation of __builtin_trap() in GCC. I have > workarounded the issue by passing the -fno-delete-null-pointer-checks > option to GCC. This will be available in the next upload. Wow, thanks a lot for tracking this down. Helmut Grohne has been seeing this issue in rebootstrap for a long time now and it was not until glibc 2.22 was uploaded when we saw this issue arise for native builds. I (and probably Helmut as well) are very glad this has been debugged now! I owe you a DebConf beer :). > It would be better instead if this can be fixed in GCC. An example of > such a patch (for hppa) is available [3]. Great. Maybe Oleg and Kaz could have a look at that. @Oleg: Should I file a gcc bug report? > [1] > https://buildd.debian.org/status/fetch.php?pkg=glibc=sh4=2.22-1=1457457915 > [2] http://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/?id=eaa3701 > [3] https://gcc.gnu.org/ml/gcc-patches/2014-11/txt1S0Z0gdV3V.txt Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Re: glibc 2.22 testsuite issues on sparc64
Hi Aurelien! On 03/08/2016 07:40 PM, Aurelien Jarno wrote: > The glibc testsuite in version 2.22 which has been uploaded to sid 2 > days ago fails to pass on both ravirin and landau build daemon, while > it passes fine on my system. It also fails on andi which just built glibc with the latest 4.4 kernel release we have in Debian. > The ravirin build was done with glibc 2.22-0experimental3. There was a > single failure: > > FAIL: nptl/tst-dlsym1 > > This test hasn't changed for year, and it is likely due to the fact the > experimental chroot contains a mix of gcc 5 and gcc 6. Ah, yes. This is probably because of an oversight on my side, sorry. I assume, I should set the default target release for APT to "unstable" and just have "experimental" added to the sources.list? I'm not absolutely sure, to be honest, what the proper setup for an experimental chroot is. > The landau buildd tried to build twice glibc version 2.22-1 with both > time exactly the same failures related to threads: > > FAIL: nptl/tst-cond10 > FAIL: nptl/tst-cond16 > FAIL: nptl/tst-cond17 > FAIL: nptl/tst-cond18 > FAIL: nptl/tst-cond25 > FAIL: rt/tst-mqueue5 > > The error returned by some of these tests is "Resource temporarily > unavailable". Given they are new issues that don't happen on ravirin > nor on my system, it could be a kernel issue. Hmm, ok. So raverin was on 4.3.0 at the time of the test while landau was on 4.4.0. So there might be the possibility that this is a problem with the newer kernel, indeed. > Given I am unable to reproduce the issues, can someone please > investigate them? I can try a test build with an older kernel next week. But we should also notify Oracle's userland and kernel developers about the issue. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#752933: src:glibc: FTBFS on Alpha port due to failing tests
Package: src:glibc Version: 2.19-4 Severity: normal Hello! After transitioning back from src:eglibc to src:glibc, building glibc from source fails on the Alpha port due to some tests from the testsuite failing, see the build log here [1]. I'm neither an expert regarding the C libary nor the Alpha architecture, but we happened to have these at work back then and I successfully installed Debian Lenny and earlier versions of Debian on Alpha without any issues, so the problem is apparently a regression in the glibc sources. From the build log linked down below, it seems the following symbol mismatch is mainly responsible for the failing build: diff -p -U 0 ../ports/sysdeps/unix/sysv/linux/alpha/nptl/ld.abilist /«PKGBUILDDIR»/build-tree/alpha-libc/elf/ld.symlist /«PKGBUILDDIR»/build-tree/alpha-libc/elf/ld-linux.so.2 --library-path /«PKGBUILDDIR»/build-tree/alpha-libc:/«PKGBUILDDIR»/build-tree/alpha-libc/math:/«PKGBUILDDIR»/build-tree/alpha-libc/elf:/«PKGBUILDDIR»/build-tree/alpha-libc/dlfcn:/«PKGBUILDDIR»/build-tree/alpha-libc/nss:/«PKGBUILDDIR»/build-tree/alpha-libc/nis:/«PKGBUILDDIR»/build-tree/alpha-libc/rt:/«PKGBUILDDIR»/build-tree/alpha-libc/resolv:/«PKGBUILDDIR»/build-tree/alpha-libc/crypt:/«PKGBUILDDIR»/build-tree/alpha-libc/nptl /«PKGBUILDDIR»/build-tree/alpha-libc/elf/tst-array2 /«PKGBUILDDIR»/build-tree/alpha-libc/elf/tst-array2.out --- ../ports/sysdeps/unix/sysv/linux/alpha/nptl/libc.abilist 2014-02-07 09:04:38.0 + +++ /«PKGBUILDDIR»/build-tree/alpha-libc/libc.symlist 2014-06-27 12:41:19.606854627 + @@ -181,0 +182 @@ GLIBC_2.0 + __multi3 F ../Makerules:1285: recipe for target 'check-abi-libc' failed make[3]: *** [check-abi-libc] Error 1 Cheers, Adrian [1] http://buildd.debian-ports.org/status/fetch.php?pkg=glibcarch=alphaver=2.19-4stamp=1403873117 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140627213214.2683.60479.report...@z6.physik.fu-berlin.de
Bug#709992: eglibc: FTBFS: Assembler messages: Error: bad register expression
Package: src:eglibc Followup-For: Bug #709992 Hi, just a short heads-up. Michael Karcher suggested that the binutils package used on the buildds has been too old. However, as of yesterday, ara5 has compiled the latest version available in Debian. Can you update your binutils package and give it another try? Cheers, Adrian -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130625160115.18765.43808.report...@z6.physik.fu-berlin.de
Bug#709992: eglibc: FTBFS: Assembler messages: Error: bad register expression
Package: src:eglibc Followup-For: Bug #709992 Hi! I have browsed the code a bit and looked at the differences between eglibc 2.13 (which builds on m68k) and 2.17 and it turns out that m68k-helpers.S had two separate versions for Coldfire and real m68k CPUs in 2.13 while the code was merged in 2.17. 2.13: glaubitz@z6:..linux/m68k pwd /home/glaubitz/tmp/eglibc-2.13/ports/sysdeps/unix/sysv/linux/m68k glaubitz@z6:..linux/m68k ls -l */m68k-helpers.S -rw-r--r-- 1 glaubitz glaubitz 3474 Mar 13 2010 coldfire/m68k-helpers.S -rw-r--r-- 1 glaubitz glaubitz 3433 Mar 13 2010 m680x0/m68k-helpers.S glaubitz@z6:..linux/m68k 2.17: glaubitz@z6:..linux/m68k pwd /home/glaubitz/tmp/eglibc-2.17/ports/sysdeps/unix/sysv/linux/m68k glaubitz@z6:..linux/m68k ls -l m68k-helpers.S -rw-r--r-- 1 glaubitz glaubitz 3251 Mar 10 2012 m68k-helpers.S glaubitz@z6:..linux/m68k So it might be worth looking into what has been changed for the original m68k CPUs in m68k-helper.S: glaubitz@z6:~ diff -u /home/glaubitz/tmp/eglibc-2.13/ports/sysdeps/unix/sysv/linux/m68k/m680x0/m68k-helpers.S /home/glaubitz/tmp/eglibc-2.17/ports/sysdeps/unix/sysv/linux/m68k/m68k-helpers.S --- /home/glaubitz/tmp/eglibc-2.13/ports/sysdeps/unix/sysv/linux/m68k/m680x0/m68k-helpers.S 2010-03-13 19:20:12.0 +0100 +++ /home/glaubitz/tmp/eglibc-2.17/ports/sysdeps/unix/sysv/linux/m68k/m68k-helpers.S 2012-03-10 02:14:00.0 +0100 @@ -1,4 +1,4 @@ -/* Copyright (C) 2010 Free Software Foundation, Inc. +/* Copyright (C) 2010, 2012 Free Software Foundation, Inc. This file is part of the GNU C Library. Contributed by Maxim Kuvyrkov ma...@codesourcery.com, 2010. @@ -30,9 +30,8 @@ Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public - License along with the GNU C Library; if not, write to the Free - Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA - 02111-1307 USA. */ + License along with the GNU C Library. If not, see + http://www.gnu.org/licenses/. */ #include sysdep.h #include bits/m68k-vdso.h @@ -41,12 +40,10 @@ .hidden __vdso_read_tp_stub ENTRY (__vdso_read_tp_stub) - cfi_startproc move.l #__NR_get_thread_area, %d0 trap #0 move.l %d0, %a0 rts - cfi_endproc END (__vdso_read_tp_stub) # ifdef SHARED @@ -59,11 +56,10 @@ .hidden __m68k_read_tp # endif ENTRY (__m68k_read_tp) - cfi_startproc - lea _GLOBAL_OFFSET_TABLE_@GOTPC(%pc), %a0 + LOAD_GOT (%a0) move.l M68K_VDSO_SYMBOL (__vdso_read_tp)@GOT(%a0), %a0 - jmp ([%a0]) - cfi_endproc + move.l (%a0), %a0 + jmp (%a0) END (__m68k_read_tp) /* The following two stubs are for macros in atomic.h, they can't @@ -71,7 +67,6 @@ .hidden __vdso_atomic_cmpxchg_32_stub ENTRY (__vdso_atomic_cmpxchg_32_stub) - cfi_startproc move.l %d2, -(%sp) cfi_adjust_cfa_offset (4) cfi_rel_offset (%d2, 0) @@ -82,12 +77,10 @@ cfi_adjust_cfa_offset (-4) cfi_restore (%d2) rts - cfi_endproc END (__vdso_atomic_cmpxchg_32_stub) .hidden __vdso_atomic_barrier_stub ENTRY (__vdso_atomic_barrier_stub) - cfi_startproc move.l %d0, -(%sp) cfi_adjust_cfa_offset (4) move.l#SYS_ify (atomic_barrier), %d0 @@ -95,7 +88,6 @@ move.l (%sp)+, %d0 cfi_adjust_cfa_offset (-4) rts - cfi_endproc END (__vdso_atomic_barrier_stub) # else /* !SHARED */ /* If the vDSO is not available, use a syscall to get TP. */ glaubitz@z6:~ So, 2.17 had the cfi_startproc and cfi_endproc macros removed. Any comment on that? Cheers, Adrian -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130624230024.9263.4203.report...@z6.physik.fu-berlin.de
Bug#688086: Same issue as 634261
On Sun, Jan 13, 2013 at 10:26:36PM +, Jurij Smakov wrote: This is the same issue as in Debian bugs #634261 [1], reassigning to No, this is a completely different bug. Please see my update with analysis. I did. Your problem is the same issue as in Debian bug #674908 [1]. The original bug reporter described a problem with the browser crashing on startup which is identical to #634261 [2] while you are describing a crash when running JavaScript scripts. Those are completely different issues. You hi-jacked this bug report. Please follow up your issue to #674908. Cheers, Adrian [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674908 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634261 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130113223352.ga14...@physik.fu-berlin.de
Bug#634261: Debian #634261: Is it actually a(n RC) bug?
Hi, I am not really an expert on libc internals, but a friend of mine with some more experience did some debugging yesterday and we figured out it might not be a bug but expected behavior. I'll put my points by answering some of the above statements. FYI, I found that it is triggered by the _IO_stdin_used symbol not being exported from the binary, which happened because of a version-script couple with -rdynamic. I still think there is something fishy going on on the libc6 side, but not as bad as originally thought. This seems to be a known and more or less documented behavior of libc to determine which ABI to use for an application software, see [1]. What eventually happens is an unaligned access due to the ABI mismatch. Checking the export list of the current xulrunner binary of Iceweasel 10, this behaviour seems to have been fixed in Firefox. So I expect Firefox to work on SPARC again. What is fishy is that only sparc is affected. So whatever it's doing on sparc, it's doing it differently from other architectures. That's because SPARC CPUs trigger an exception on aligned access [1]. I would expect the same to happen on Alpha [3], but Alpha is no longer a supported architecture for the current Debian release. It would be nice if the original bug reporter could try to reproduce the bug with Iceweasel 10 in Debian Wheezy and unless it's still crashing, this bug should be untagged as being an RC bug for Wheezy. Cheers, Adrian [1] http://lists.gnu.org/archive/html/bug-glibc/2001-12/msg00203.html [2] http://gcc.gnu.org/ml/gcc/2000-10/msg00291.html [3] http://gcc.gnu.org/ml/gcc-help/1999-10n/msg00065.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121222120804.ga16...@physik.fu-berlin.de
Bug#634261: [sparc] iceweasel: Bus Error in setbuf()
On Sat, Dec 22, 2012 at 01:38:44PM -0800, Jonathan Nieder wrote: (culling cc list) Hi Adrian, John Paul Adrian Glaubitz wrote: [Subject: Debian #634261: Is it actually a(n RC) bug?] Please keep in mind that these appear as emails in a crowded inbox, so the subject line can be a good place to put valuable context. I actually thought the subject was quite reasonable ;). Anyway. Mike Hommey wrote: FYI, I found that it is triggered by the _IO_stdin_used symbol not being exported from the binary, which happened because of a version-script couple with -rdynamic. I still think there is something fishy going on on the libc6 side, but not as bad as originally thought. This seems to be a known and more or less documented behavior of libc to determine which ABI to use for an application software, see [1]. What eventually happens is an unaligned access due to the ABI mismatch. I don't completely follow, so I'll just ask: do you mean that this is a case of ABI misuse, with poor error reporting? As far I understand the problem, the Mozilla developers provide a version script to the linker to control which symbols get exported. This helps speeding up the load process of the binary and reduces the memory footprint. What the Mozilla developers didn't seem to put into account is that if you prevent the symbol _IO_stdin_used from being exported from your binary, parts of the ABI of the standard C library will change and it will behave like an older version which causes the unaligned access which results in a CPU trap. Can you describe what iceweasel was doing wrong? Is this documented so future coders know not to make the same mistake? Is the version in squeeze affected? How about the version in wheezy? It seems to have been fixed in Firefox 10 which is part of Wheezy: (sid)glaubitz@smetana:~$ objdump -T /usr/lib/xulrunner-10.0/xulrunner-bin |grep IO 0001ceb8 gDO .rodata0004 Base _IO_stdin_used But, as I said, I am not an expert on the internals of the C library, so I am just speculating from the knowledge I gained from Michael (I put him into CC again). It might be worthful to check whether Mozilla made upstream changes in this regard or whether there was an upstream bug report. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012131322.ga21...@physik.fu-berlin.de
Bug#689315: zic: creates dangling symlink for /etc/localtime
On Fri, Oct 26, 2012 at 10:11:45AM +0200, Aurelien Jarno wrote: I am not able to reproduce this issue. Are you sure that /etc/localtime was not a broken symlink already before running the zic command? Interesting, I cannot reproduce the issue anymore either and I am pretty sure it occurred the way I described it. Strangely, there has been no updated to libc-bin ever since, so this cannot be a bug in zic. However, tzdata has been recently upgraded. I don't know, but maybe it's somehow related? In any case, I can remove the local workaround here and close the bug. Adrian -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026101711.ga28...@physik.fu-berlin.de
Bug#689315: zic: creates dangling symlink for /etc/localtime
Package: libc-bin Version: 2.13-35 Severity: important Hello, the version of 'zic' in 'libc-bin' in Debian Wheezy seems to no longer creates the localtime conversion file correctly. On Debian Squeeze: root@squeeze32:~ zic -l Europe/Berlin root@squeeze32:~ file /etc/localtime /etc/localtime: timezone data, version 2, 8 gmt time flags, 8 std time flags, no leap seconds, 144 transition times, 8 abbreviation chars On Debian Wheezy: root@wheezy32:~ zic -l Europe/Berlin root@wheezy32:~ file /etc/localtime /etc/localtime: broken symbolic link to `../posix/Europe/Berlin' zic obviously tries to create a symbolic link to the correct timezone conversion file. Alas, the symbolic link created is relative and the source directory is obviously a subdirectory of /usr/share/zoneinfo while the localtime conversion file is saved as /etc/localtime, hence a dangling symbolic link is created. Cheers, Adrian -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121001141807.21446.57919.reportbug@localhost.localdomain
