Summary: | Crypto++-5.2 + gcc 3.3.4 + kernel 2.6.7 = DoS? | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Quequero <quequero> |
Component: | New packages | Assignee: | Please assign to toolchain <gcc-porting> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | kernel, rphillips |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://cryptopp.com | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Quequero
2004-07-17 02:39:15 UTC
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 |