Hello all, compiling crypto++ on my laptop make it unusable, hard disk usage is total and cpu usage is 100%. System become totally locked (only terminal switching is possible but logging goes timeout after 60 seconds). I don't know if it's a kernel bug or a gcc bug, btw the result is a complete DoS from where I can't recover without an hardware reset. Since I have preemption enabled, this shouldn't happen in any way, here it is my settings: Portage 2.0.50-r9 (default-x86-1.4, gcc-3.3.4, glibc-2.3.4.20040619-r0, 2.6.7) ================================================================= System uname: 2.6.7 i686 Intel(R) Pentium(R) M processor 1400MHz Gentoo Base System version 1.5.1 distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -mcpu=pentium4 -msse2 -mmmx -O3 -pipe -fforce-addr -fomit-frame-pointer -ftracer -fprefetch-loop-arrays" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -mcpu=pentium4 -msse2 -mmmx -O3 -pipe -fforce-addr -fomit-frame-pointer -ftracer -fprefetch-loop-arrays" DISTDIR="/usr/portage/distfiles" FEATURES="buildpkg fixpackages userpriv usersandbox" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3ds X acl acpi acpi4linux alsa apache2 arts avi berkdb bindist cdr crypt curl dga directfb dnd dv dvd dvdr encode esd ethereal fbcon ffmpeg freetype fs gd gdbm gif gmttria gpm gtk gtk2 i8x0 imagemagick imlib imlib2 ipv6 irda j-nojud j-nomsn j-nomuconf j-noyahoo java jikes jpeg justify kde lcd libg++ libwww lids lirc mad maildir md5sum mikmod mmx motif moznocompose moznoirc moznomail mpeg mysql ncurses nls nodod objc oggvorbis opengl openssh oss pam pcmcia pdflib perl php png pnp python qt quicktime readline ruby samba sdl skey slang snmp spell sse ssl stencil-buffer svga tcltk tcpd tetex tiff transcode truetype trusted usb vanilla vim-with-x wxwindows x86 xml xml2 xmms xosd xv xvid zlib". Thanx a lot to everyone, bye :) Que
Are any OOPSes / critical messages from the kernel written to the console or logs? Try compiling on tty0 and see if anything comes out.
I tried to compile it on tty and I wasn't able to reproduce the bug, dunno if it's due to the fact that yesterday I did an emerge -Du world, syslog is clean (i mean without warning) but compiling it under X DoS me again :). Plz let me know what you need, have a nice week end. Que
Well, it does use a lot of memory - at one stage it used about 1.2gb over here. I can see 3 things that might help here: 1) take out the -pipe from CXXFLAGS 2) take out the -g from CXXFLAGS 3) use make instead of emake to only schedule one gcc at a time. Ryan, any special reason why it does not use CXXFLAGS from make.conf?
Yep it uses a lot of memory, probably together with X it become the cause of this "DoS", anyway -g should be filtered in the ebuild, there's no point to enable it if you don't need debug info. :) Que
Crypto++ is quite finiky... It doesn't use the default CXX FLAGS because with standard flags the validation suite will not pass... (Atleast on my P4 box, and on my Athlon XP machine). I have kept the validation suite in because of this. I was thinking of a 'test' USE var to enable the validation suite or skip over it. If anyone else has any suggestions, I'm all for it, but the package doesn't like optimizations and would fail on anything I tried except for its own. It isn't a DoS (in that sense), it just is CPU intensive during the tests and also the compile (due to the heavy C++ templating system it uses).
I know it's cpu intensive but if I try to compile it under X I can't recover my system, I waited 3 hours but hdd and cpu usage was total and the only solution I found was to compile it under tty shutting down X. This is happening on a computer with 512mb of ram, that's not so much but this behavior it's pretty strange anyway :)... I haven't had the same problem upgrading kde or other cpu intensive packages :/ (including gcc)
Here is my `emerge info` dump. The compile seems to run fine under Konsole for me. I am running gcc-3.3.2 though. Portage 2.0.50-r9 (default-x86-2004.0, gcc-3.3.2, glibc-2.3.2-r9, 2.6.7) ================================================================= System uname: 2.6.7 i686 Mobile Intel(R) Pentium(R) 4 CPU 3.06GHz Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /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=pentium4 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://sunsite.ualberta.ca/pub/unix/Linux/gentoo/ http://csociety-ftp.ecn.purdue.edu/pub/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa apm arts avi berkdb cdr crypt cups encode esd foomaticdb gdbm gif gnome gpm gtk gtk2 imlib jpeg kde ldap libg++ libwww mad mikmod motif mozilla mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline ruby sdl slang spell ssl svga tcltk tcpd tetex truetype x86 xml2 xmms xv zlib"
Quequero, can you try with this patch: ---- Index: crypto++-5.2.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/dev-libs/crypto++/crypto++-5.2.ebuild,v retrieving revision 1.2 diff -u -r1.2 crypto++-5.2.ebuild --- crypto++-5.2.ebuild 14 Jul 2004 22:01:03 -0000 1.2 +++ crypto++-5.2.ebuild 20 Jul 2004 18:25:48 -0000 @@ -20,7 +20,8 @@ src_compile() { - emake -f GNUmakefile || die + sed -i -e 's:-g::g; s:-pipe::g' GNUmakefile + make -f GNUmakefile || die if ! ./cryptest.exe v then eerror "crypto++ self-tests failed"
Sure, I did it. Removing -g and -pipe solve the problem and all tests passed without problems. Anyway I must investigate, it's not normal to have a totally unresponsive pc only because of an high memory requirement at compiling time :) Que
5.2.1 uses CXXFLAGS now *** This bug has been marked as a duplicate of 57846 ***
I tested it with a number of g++ flags using crypto++-5.2.ebuild. (Yes, I commented out the 03-to-02 convert in the ebuild.) I get: BlumBlumShub validation suite running... CryptoPP::Exception caught: Integer: division by zero ONLY when using -fomit-frame-pointer. I get it when using it alone or with other flags, such as -O3, -O2, -pipe, -march=athlon. I know the gcc man page says that using the -O flags turns on -fomit-frame-pointer, but apparently it's only LIKE turning on -fomit-frame-pointer. I'm using: ~x86 g++ (GCC) 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6). GNU ld version 2.14.90.0.8 20040114
-fomit-frame-ponter breaks it. works with: CXXFLAGS="-march=athlon-xp -mtune=athlon-xp -O2 -pipe -ftracer -frename-registers -fvisibility-inlines-hidden" on Athlon-XP