using binutils+rebuilt glibc from version 2.17.50.0.7 or newer and then calling the Java based LetterWizard in OpenOffice writer eats up all memory within a few seconds. also compiling Openoffice eats up the memory when it comes to compiling java stuff. last working version of binutils where this doesn't happen is 2.17.50.0.6. Having binutils >=2.17.50.0.7 installed and i rollback the glibc package to a version compiled against a working former binutils fixes the memory issue. so i guess it's something the binutils link into the glibc pkg. ArchLinux x86_64, gcc4.2.1rc1 + recent gcc-gcj trunk snapshot from 4.3 branch. http://sourceware.org/ml/binutils/2007-07/msg00144.html - thread wasn't very helpful so far.
Please show your the outputs of "readelf -lS --wide" on bad and good /lib64/libc.so.6.
with last working version .06: http://pastebin.archlinux.org/9374 broken recent .17: http://pastebin.archlinux.org/9375
(In reply to comment #2) > with last working version .06: http://pastebin.archlinux.org/9374 > > broken recent .17: http://pastebin.archlinux.org/9375 When you copy /lib64/libc.so.6 from the good machine to the bad machine, does the bad machine work? When you copy /lib64/libc.so.6 from the good machine to the bad machine, does the good machine work?
It is just a guess. It may be related to http://sourceware.org/ml/binutils/2006-11/msg00178.html Can you back it out from 2.17.50.0.7 and give it a try?
both failed here: replacing libc.so.6 breaks the system completly. no command will work anymore. i could revert the patch cleaning out some parts. but now binutils won't build anymore claiming problems with struct cie.
(In reply to comment #5) > both failed here: replacing libc.so.6 breaks the system completly. no command > will work anymore. Were 2 libc.so.6 built from the identical source? Is the ONLY difference binutils 2.17.50.0.6 vs binutils 2.17.50.0.7? > > i could revert the patch cleaning out some parts. but now binutils won't build > anymore claiming problems with struct cie. If you can't provide a small testcase, I suggest you do a binary search on binutils in CVS from 2006-10-20 to 2006-11-27 to find out which check in causes this problem.
yes, the only difference in the glibc pkg is the binutils pkg it is built against. nothing else. http://sourceware.org/cgi-bin/cvsweb.cgi/src/binutils/ChangeLog.diff?r1=1.1111&r2=1.1108&cvsroot=src&f=h is this list complete? then it should be on of the readelf.c changes.
(In reply to comment #7) > yes, the only difference in the glibc pkg is the binutils pkg it is built > against. nothing else. > > http://sourceware.org/cgi-bin/cvsweb.cgi/src/binutils/ChangeLog.diff?r1=1.1111&r2=1.1108&cvsroot=src&f=h > > is this list complete? then it should be on of the readelf.c changes. Please use http://sourceware.org/ml/binutils-cvs/ to identify which check in causes this regression.
hm. too much commits that i could test out each one of them. i checked again and used this time Sun's Java and don't have any problems. So can this also be a bug in GNUjava from gcc-gcj that is introduced when using binutils from 2.17.50.0.7 or higher? with GNUjava i could reproduce it also outside OpenOffice.org when using the gnujava Firefox browser plugin on any website.
(In reply to comment #9) > hm. too much commits that i could test out each one of them. > There are about 200 commits between 2006-10-20 and 2006-11-27. It takes about 8 tries to find which commit causes this regression with binary search. I don't think it is too much.
i know the way you want to show me. is there an easy way to just download/checkout let's say the first 100 commited patches? (compile time isn't an issue, system is really fast but has slow internet connection)
(In reply to comment #11) > i know the way you want to show me. is there an easy way to just > download/checkout let's say the first 100 commited patches? (compile time isn't > an issue, system is really fast but has slow internet connection) From http://sourceware.org/ml/binutils-cvs/2006-10/ it looks like "October 31, 2006 22:59 UTC" hasthe first 100 patches from 2006-10-20 to 2006-11-27. I can do # cvs -z 3 -d :pserver:anoncvs@sources.redhat.com:/cvs/src co -D "October 31, 2006 22:59 UTC" binutils to check it out. You can use the same command with a different time for "-D" to update your tree to a different time, like # cvs -z 3 -d :pserver:anoncvs@sources.redhat.com:/cvs/src co -D "November 27, 2006 22:05 UTC" binutils will update your tree to "November 27, 2006 22:05 UTC". Since you don't need to check out the whole tree after the first check out, incremental check out isn't very slow. Also you can rsync CVS repository: http://sources.redhat.com/sourceware/rsync.html so that you check it out locally.
ok, i could track down the issue due to the commits from 22th Nov. 2006. cvs co from 21st worked well and from 22nd has the memory issues.
(In reply to comment #13) > ok, i could track down the issue due to the commits from 22th Nov. 2006. > > cvs co from 21st worked well and from 22nd has the memory issues. Please use http://sourceware.org/ml/binutils-cvs/2006-11/ to find the exact time for each change made on Nov. 22, 2006 and locate the exact change which causes this regression.
ok, i got it located. it's this commit: http://sourceware.org/ml/binutils-cvs/2006-11/msg00100.html
Jakub, your EH change causes this regression. It looks like EH fails to terminate.
If you get an 8 byte .eh_frame_hdr section in the linked libc.so, then I'd like an reproducer from you, because all my x86_64 glibcs are just fine when compiled with recent (e.g. 2.17.50.0.12) binutils. So, please pack up: elf/ld.so libc.map libc_pic.a libc_pic.os shlib.lds csu/abi-note.o elf/soinit.os elf/sofini.os elf/interp.os in your glibc build directory and your `gcc -print-file-name=libgcc.a` and attach it as a bzip2ed tarball here as attachment. Also mention the exact ld command line that was used to link your libc.so - rerun the gcc -shared -static-libgcc .... -o ..../libc.so .... command from your glibc build log with additional -v and past the collect2 command line here. Thanks.
[andyrtr@workstation64 glibc]$ gcc -print-file-name=libgcc.a /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.1/libgcc.a [andyrtr@workstation64 glibc-build]$ gcc -v -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld-linux-x86-64.so.2 -B/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/csu/ -Wl,--version-script=/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/libc.map -Wl,-soname=libc.so.6 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -nostdlib -nostartfiles -e __libc_main -Wl,-z,now -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/math -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/elf -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/dlfcn -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/nss -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/nis -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/rt -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/resolv -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/crypt -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/nptl -Wl,-rpath-link=/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/math:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/elf:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/dlfcn:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/nss:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/nis:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/rt:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/resolv:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/crypt:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/nptl -o /var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/libc.so -T /var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/shlib.lds /var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/csu/abi-note.o /var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/elf/soinit.os /var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/libc_pic.os /var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/elf/sofini.os /var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/elf/interp.os /var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/elf/ld.so -lgcc Es werden eingebaute Spezifikationen verwendet. Ziel: x86_64-unknown-linux-gnu Konfiguriert mit: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic Thread-Modell: posix gcc-Version 4.2.1 20070704 (prerelease) /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.1/collect2 --eh-frame-hdr -m elf_x86_64 --hash-style=both -shared -o /var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/libc.so -e __libc_main -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/math -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/elf -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/dlfcn -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/nss -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/nis -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/rt -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/resolv -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/crypt -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/nptl -L/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/csu -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.1 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.1 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.1/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.1/../../.. -O1 -z defs -dynamic-linker=/lib/ld-linux-x86-64.so.2 --version-script=/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/libc.map -soname=libc.so.6 -z combreloc -z relro --hash-style=both -z now -rpath-link=/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/math:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/elf:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/dlfcn:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/nss:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/nis:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/rt:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/resolv:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/crypt:/var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/nptl /var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/csu/abi-note.o /var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/elf/soinit.os /var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/libc_pic.os /var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/elf/sofini.os /var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/elf/interp.os /var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/elf/ld.so -lgcc -T /var/abs/chroot/current/var/abs/base/glibc/src/glibc-2.6/glibc-build/shlib.lds hope that helps
due to size limit the files are just going to http://archlinux.org/~andyrtr/wanted_files.tar.bz2
anything missing?
I don't see anything wrong on the generated .eh_frame, it is properly terminated, seems to cover everything it should and .eh_frame_hdr looks sane as well. So this definitely doesn't look like a binutils issue. What I'd try is back out http://sources.redhat.com/ml/glibc-cvs/2006-q4/msg00364.html in glibc sources, see http://gcc.gnu.org/ml/gcc/2006-12/msg00293.html
yes. you have successfully located the issue! reverting the clone.S.diff for x86_64 in glibc fixed it. can you make sure and help that it will be fixed in glibc before 2.6.1 release? you seem to be much more involved there. thanks so far.
HJ suggested this bug should be resolved before 2.18, but that was the day before the glibc patch was identified. Could someone explain to me, in small words, how Jakub's patch could "cause" this if it is not a binutils bug? Is it really a bug in the GCC unwinder that we are now triggering? I don't see anything fundamentally wrong with the glibc patch and I haven't seen any fixes for the unwinder either.
I have posted an unwinder patch in the thread I referenced, see http://gcc.gnu.org/ml/gcc/2006-12/msg00312.html but that was without ChangeLog entry, I got no feedback and forgot about it (because in the meantime I have reverted Jan's glibc patch on fedora-branch and so didn't ever see it again).
Oh, I see. Without that unwinder patch, if the PC wasn't saved we'll end up with a segfault. Since this is coming through Java, I assume we're getting the unwinder re-invoked from the signal handler, and burning out the stack. I still don't get why the binutils patch made a difference, but this is clearly not a binutils bug. If you have a change, it would be nice to get the unwinder fixed.