When running twinstall.sh, after I enter the passphrase twice: Enter the site keyfile passphrase: Verify the site keyfile passphrase: Generating key (this may take several minutes)... it will just sit there stating that it is generating the key - it will sit there for hours on end. Now this should take a few minutes, maybe 10 on a slow machine. I am able to replicate this on three different machines (none of which are slow), but it doesn't matter if I let it run all night, it will just sit there with twadmin trying to do something (infinite loop?), taking up 99% of my cpu. Reproducible: Always Steps to Reproduce: 1. emerge tripwire 2. /etc/tripwire/twinstall.sh 3. enter the site keyfile passphrase 4. verify the site keyfile passphrase Actual Results: Nothing - the twinstall.sh script does not return, cpu load approaches 1 with twadmin taking up 99% of my cpu. Expected Results: the twinstall.sh script should have run (maybe fore a few minutes on a slower machine), asking me for another passphrase for a second key, then asked me for the passphrase to sign the configuration file, then asked me for the passphrase to sign the policy file. Portage 2.0.51-r15 (default-linux/x86/2004.3, gcc-3.4.3, glibc-2.3.4.20050125-r0, 2.6.10-gentoo-r6 i686) ================================================================= System uname: 2.6.10-gentoo-r6 i686 Pentium III (Katmai) Gentoo Base System version 1.6.9 Python: dev-lang/python-2.2.3-r5,dev-lang/python-2.3.4-r1 [2.3.4 (#2, Feb 9 2005, 14:38:33)] ccache version 2.3 [enabled] dev-lang/python: 2.2.3-r5, 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r3 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium3 -mmmx -msse -fomit-frame-pointer -pipe" CHOST="i686-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="-O3 -march=pentium3 -mmmx -msse -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aalib alsa apm avi berkdb bitmap-fonts cdr crypt cups curl directfb divx4linux doc dvd emboss encode esd f77 fam fbcon font-server foomaticdb fortran gdbm gif gnustep gpm gtk gtk2 guile imlib ipv6 ithreads java jce jpeg junit libg++ libwww mad mbox mikmod mmx motif mpeg mysql ncurses nls objc oggvorbis opengl oss pam pdflib perl png pnp python qt quicktime readline sdk sdl slang spell sse ssl svga tcpd tetex threads tiff truetype truetype-fonts type1-fonts xml xml2 xmms xv zlib video_cards_i740" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
*** Bug 82857 has been marked as a duplicate of this bug. ***
Created attachment 51827 [details] bug in -fstrict-aliasing ok...i can reproduce...what on earth is going on in there?!?! looks like the code is breaking gcc's strict aliasing, try the source code attached like this: $ gcc -O gcc-bug.c -o test1 $ gcc -O -fstrict-aliasing gcc-bug.c -o test2 and compare the output of the test1 and test2 programs... anyway, easily solved, i'll turn off strict aliasing in the ebuild. fixed in cvs, thanks for the good report!
RESOLVED -> FIXED.
