I've been away for a few days, so I just updated to portage 2.0.47-r7, did the usual etc-update to fix things in /etc. Then updated cccache to ccache-2.2 to speed up the rest of the builds and etc-update again for good measure. Now nothing else will build. Traced it down to the fact that ccache is enabled in make.globals (not enabled in my config). Turned it off there and things work perfectly. The compile line of /usr/lib/ccache/bin/gcc -c -march=pentium3 -O3 -pipe ztest8937.c in the zlib directory works fine, so I suspected something with portage directly. I even tried with all of the enviroment settings that existed in the build enviroment (attached in env.out), but I can't reproduce it running manually. Only inside the configure script does the ccache call freeze up. I'll attach a stack trace of it in a moment as well. Reproducible: Always Steps to Reproduce: 1. emerge ANY build 2. 3. Actual Results: server1 root # emerge sys-libs/zlib Calculating dependencies ...done! >>> emerge (1 of 1) sys-libs/zlib-1.1.4-r1 to / >>> md5 ;-) zlib-1.1.4.tar.bz2 >>> Unpacking source... >>> Unpacking zlib-1.1.4.tar.bz2 to /var/tmp/portage/zlib-1.1.4-r1/work * Applying zlib-1.1.4-gentoo.security.patch... [ ok ] >>> Source unpacked. (hangs here) I hacked up the zlib configure file for debugging output and ran: server1 root # ebuild /usr/portage/sys-libs/zlib/zlib-1.1.4-r1.ebuild compile >>> md5 ;-) zlib-1.1.4.tar.bz2 >>> Checking zlib-1.1.4.tar.bz2's mtime... >>> WORKDIR is up-to-date, keeping... which gcc = /usr/lib/ccache/bin/gcc gcc -c -march=pentium3 -O3 -pipe ztest8937.c This is part of the very first compiler test. Expected Results: should have merged the software properly. Emerge info output: Portage 2.0.47-r7 (default-x86-1.4, gcc-3.2.2, glibc-2.3.2_pre1-r0) ================================================================= System uname: 2.4.20-gentoo-r1 i686 Pentium III (Katmai) GENTOO_MIRRORS="http://gentoo.oregonstate.edu " CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/afs/C /etc/afs/afsws /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 libg++ -3dfx -3dnow aalib acl acpi afs alsa apache2 apm arts avi berkdb bonobo canna cdr cjk crypt cups dga directfb doc dvd encode esd ethereal evo fbcon flash freewnn gb gd ggi gif -gnome gphoto2 gps gtk gtk2 gtkhtml guile imap imlib innodb ipv6 java jikes jpeg junit kde -kerberos lcms ldap leim libgda libwww maildir -matrox mbox mikmod motif mozilla mpeg -mule mysql nas nls oav -oci8 oggvorbis opengl oss -pcmcia -pda pdflib plotutils png pnp -postgres qt -qtmt quicktime ruby samba sasl scanner sdl slp snmp socks5 spell sse svga tcltk tcpd tetex tiff truetype trusted usb -voodoo3 wavelan wmf X xface xml xml2 xmms xv gdbm gpm mmx ncurses pam perl pic python readline slang ssl zlib mozsvg mozcalender mozaccess mozinterfaceinfo mozp3p mozxmlterm" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O3 -pipe" CXXFLAGS="-march=pentium3 -O3 -pipe" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j4" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache buildpkg"
Created attachment 8848 [details] Enviroment settings enviroment output right before the call to /usr/lib/ccache/bin/gcc
Created attachment 8849 [details] Strace output of ccache call Output of strace directly on the ccache command
tracing it more (via strace -ff), it seems that ccache goes into an infinite loop with calling 'gcc', but actually looping somewhere. More debug output: server1 root # ebuild /usr/portage/sys-libs/zlib/zlib-1.1.4-r1.ebuild compile >>> md5 ;-) zlib-1.1.4.tar.bz2 >>> Checking zlib-1.1.4.tar.bz2's mtime... >>> WORKDIR is up-to-date, keeping... ----- ----- gcc -c -march=pentium3 -O3 -pipe ztest28057.c which gcc = /usr/lib/ccache/bin/gcc Process 11643 attached (waiting for parent) Process 11643 resumed (parent 19555 ready) Process 19555 suspended More stack traces to follow.
Created attachment 8850 [details] Direct trace of the ccache call from the configure script see also trace.11643 which is the trace of the forked process from this one.
Created attachment 8851 [details] LARGE strace from forked process started by ccache this file is 32mb when extracted. Judging by the compression alone, there is a LOT of repition involved in the file. briefly glancing at the content it seems that ccache is looping infinitely on some calls.
For a temporary workaround, remove 'ccache' from FEATURES in make.global
Another report of this surfaced recently in bug 15100. It is real. My instincts tell me that ccache enters an infinite chain of execs with itself. I'll try to figure out a solution this weekend.
Have you tried clearing you /root/.ccache directory? This seems to be the present workaround that works and allows you to continue using ccache. also, you might use ccache to set the maximum to something reasonable: ccache -M 1G seems to be fairly safe and prevents these lockups.
I've tried clearing out the entire ccache with 'ccache -C', as well as setting the max cache size to 1gb, without any success.
if you are running ccache to clear the cache be sure to try prefixing the command like the following: CCACHE_DIR=/root/.ccache ccache -C or use the sure-fire approach: rm -rf /root/.ccache
Zach: your new suggestions don't resolve it either. I'm just about to upgrade the box to sys-devel/binutils-2.13.90.0.18-r1, sys-libs/glibc-2.3.2 and downgrade to sys-devel/gcc-3.2.2-r1.
your last comment says 'downgrade' to gcc-3.2.2-r1... what where you using? Otherwise, have you made progress on this issue? Any further information that you might be able to provide?
was running gcc-3.2.2-r3 previously, then it got masked. The machine still has the problem. The best details I can offer, is that when portage runs the configure script, it used this PATH spec (gained using printenv to a file during the configure) PATH=/usr/lib/ccache/bin:/sbin:/usr/sbin:/usr/lib/portage/bin:/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/afsws/bin:/etc/afs/afsws:/usr/afs/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.2:/opt/Acrobat5:/usr/X11R6/bin:/opt/blackdown-jre-1.4.1/bin:/usr/qt/3/bin:/var/qmail/bin I had left the box alone for a while. I'm trying a few more things now.
Found the eventual cause of the bug. I had sys-devel/cc-config installed, and it had overwritten sys-devel/gcc-config. Both of them contain /usr/bin/gcc... I remerge gcc-config, and everything works now. Should cc-config even exist?, see the output below: pestilence root # emerge -s cc-config Searching... [ Results for search key : cc-config ] [ Applications found : 2 ] * sys-devel/cc-config Latest version available: 1.2.8 Latest version installed: [ Not Installed ] Size of downloaded files: 0 kB Homepage: http://www.gentoo.org/ Description: Utility to change the gcc compiler being used. * sys-devel/gcc-config Latest version available: 1.3.1 Latest version installed: 1.3.1 Size of downloaded files: 0 kB Homepage: http://www.gentoo.org/ Description: Utility to change the gcc compiler being used.
Thanks for digging on this. I'll look into killing off cc-config soon.
