Summary: | Executables using glibc-2.3.5-r1 + NPTL (with TLS) hang | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | darkgrave |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED NEEDINFO | ||
Severity: | critical | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Test c code using pthreads and TLS |
Description
darkgrave
2005-08-13 16:44:15 UTC
Created attachment 65884 [details]
Test c code using pthreads and TLS
Mmm... I made two errors, sorry. First, in steps to reproduce: 1.gcc -Wall -o thread.test tread.test.c -lpthread 2../thread.test Second (but obvious), system is installed from stage1. worksforme with the same gcc and binutils... Plus: $ ldd /lib/tls/libc.so.6 /lib/ld-linux.so.2 (0x55555000) linux-gate.so.1 => (0xffffe000) I'm wondering if it's a problem with your system. Are you with a similar microprocessor? It's all being compiled with the -march=k6-2 ... Can be gcc generating invalid instructions for this micro? The system is apparently OK (I'm talking about hardware), as half a year ago we discovered some hardware problem in the memory bootstraping Gentoo and memory was changed. That time the rest of the system was tested and everything seemed to be OK. System memory should be OK, as after your reply we made a memtest (6 hours running) and no apparently problems appear. SMART says discs are OK, no other errors showed by the kernel and the system is stable. As we have said it's the second time we try to install gentoo from stage1 with the same final behaviour of the NPTL libpthread library, while the linuxthreads one without TLS is working perfectly. That's what surprised us. Is there something we can try to find if gcc or binutils is generating broken code? We have another slower K6-2 system, and we'll try compiling Gentoo from stage 1 the same way we're doing in this system with the NTPL + TLS problem to see if it's reproducible. Have you tried -march=i586? Confirmed in my own system. K6-2 400 MHz on an Asus P5A. I'm seeing the same behaviour as the reporter. Today I decided to test if this was happening to my computer, and decided to test it doing a chroot in a file test partition under my current Gentoo install in that system (is from January this year). The steps I made to reproduce: 1.- Created a 4 GByte file to gave it format with mkfs.ext3 2.- Mounted with loop in /mnt/gentoo 3.- Started a clean Gentoo install 4.- Following Gentoo guide (...) 5.- Bootstrapped 6.- JUST after bootstrapping tested execution of /lib/libc.so.6 and /lib/tls/libc.so.6, as the glibc installed during bootstrap seemed to be compiled with linuxthreads and NPTL (the later with TLS). Guess what? Same behaviour! /lib/libc.so.6 works but /lib/tls/libc.so.6 has problem with reloc!! I haven't continued during the full emerge -e system, as I think this just confirms the problem. Binutils? Gcc? Glibc? Here is my emerge info: Gentoo Base System version 1.12.0_pre5 Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r1, 2.6.12-gentoo-r7 i586) ================================================================= System uname: 2.6.12-gentoo-r7 i586 AMD-K6(tm) 3D processor dev-lang/python: 2.3.4-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: [Not Present] sys-devel/automake: [Not Present] sys-devel/binutils: 2.16.1 sys-devel/libtool: [Not Present] virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i586-pc-linux-gnu" CFLAGS="-O2 -march=k6-2 -fomit-frame-pointer -pipe" CHOST="i586-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=k6-2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" LC_ALL="es_ES.UTF-8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://192.168.0.2/gentoo-portage" USE="x86 ncurses nls nptl pam pic unicode userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LDFLAGS, LINGUAS, PORTDIR_OVERLAY This system is syncing to a local mirror. It was updated one day ago, so this is the age of the portage tree from what this test install was done. Recompiled this afternoon glibc with make.conf cflags="-pipe". No optimizations, no march, no fomit-frame-pointer. Nothing. Result? Same behaviour. So ... I think we can rule out gcc as the problem here. What more can I test? try doing this: *WARNING: when i say 'cp' i mean 'cp' and when i say 'mv' i mean 'mv' ... using 'cp' instead of 'mv' can break your box # rm -rf /var/tmp/portage # FEATURES=keepwork emerge glibc # cp -a /lib/ld-linux.so.2 /lib/ld-linux.so.2.old # cp -a /var/tmp/portage/glibc-*/work/build*nptl/elf/ld.so \ /lib/ld-linux.so.2.new # mv /lib/ld-linux.so.2.new /lib/ld-linux.so.2 if your system blows up at this point, you can recover by doing: # bb # mv /lib/ld-linux.so.2.old /lib/ld-linux.so.2 if your system doesnt blow up, see if you can now run /lib/tls/libc.so.6 btw, your test of trying to run any lib in /lib other than libc.so.6 is invalid as libc.so has certain magic added to it so that you can execute it and see the pretty version output well get back to us please |