This is an upstream bug, which apparently showed up for the first time with gcc-4.3.2: http://www.mail-archive.com/freeciv-dev@gna.org/msg06102.html Subject to confirmation of this behavior by others, unless this can be worked around via ebuild-specific CFLAGS or the like, perhaps the package should be masked (for affected architectures) until the bug is fixed? Reproducible: Always Steps to Reproduce: 1. emerge freeciv 2. start a game, end first turn 3. server crashes Actual Results: Server outputs the following: "civserver: cityturn.c:276: auto_arrange_workers: Assertion `cmr.found_a_valid' failed. Aborted." (And the server exits.) Expected Results: Doesn't crash. emerge --info Portage 2.1.6.7 (default/linux/x86/2008.0, gcc-4.3.3, glibc-2.9_p20081201-r1, 2.6.28-gentoo-r1 i686) ================================================================= System uname: Linux-2.6.28-gentoo-r1-i686-Intel-R-_Pentium-R-_4_CPU_1400MHz-with-glibc2.0 Timestamp of tree: Fri, 06 Feb 2009 07:45:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p48 dev-java/java-config: 1.3.7-r1, 2.1.7 dev-lang/python: 2.5.4-r2 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.6.2-r1 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.4.2 sys-apps/sandbox: 1.3.2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.19.1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.28-r1 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -pipe -fforce-addr -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=pentium4 -pipe -fforce-addr -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.gtlib.gatech.edu/pub/gentoo http://gentoo.osuosl.org/ http://open-systems.ufl.edu/mirrors/gentoo " LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1,--hash-style=gnu" LINGUAS="en_US en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X alsa berkdb bzip2 caps cdr cli cracklib crypt dbus dri dvd exif ffmpeg gdbm gif gpm gtk hal iconv java jpeg lcms midi mmx mudflap ncurses nls nptl nptlonly nsplugin opengl openmp pam pcre perl png python readline reflection session spl sse sse2 ssl sysfs tiff truetype unicode win32codecs x86 xorg xulrunner zlib" ALSA_CARDS="emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LINGUAS="en_US en" USERLAND="GNU" VIDEO_CARDS="nv" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Did it crash with gcc 4.3.2 ? If not, could this be a _FORTIFY_SOURCE problem ?
(In reply to comment #1) > Did it crash with gcc 4.3.2 ? > If not, could this be a _FORTIFY_SOURCE problem ? No, it did not crash with 4.3.2.
(In reply to comment #2) > (In reply to comment #1) > > Did it crash with gcc 4.3.2 ? > > If not, could this be a _FORTIFY_SOURCE problem ? > > No, it did not crash with 4.3.2. > In that case, could you see if it's _FORTIFY_SOURCE problem ? To test it, I think 'append-flags -U_FORTIFY_SOURCE' is required. If not, that would be an interesting regression.
Never mind, tested myself and it didn't work. Looks like it is a gcc regression.
I just got around to this, and 'append-flags -U_FORTIFY_SOURCE' didn't make any difference. Thanks for the suggestion, though.
For today: -O2 fails, -O1 works. See you back tomorrow (maybe).
And with a new day, comes following conclusion: -O2 seems to work with -fno-inline-small-functions Now somebody has to figure out if it's a problem with freeciv or with gcc.
It's been awhile since I visited this bug. Upstream has since "fixed" this bug, however it looks like this bug should be reassigned and its severity risen - this seems to be a compiler bug, one reproducible in other apps. If you disagree, reassign it back, but read http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333 first, then http://bugs.winehq.org/show_bug.cgi?id=17406. It may be a coincidence, but if it's not, there's no telling how widespread the problem is by now. If you can confirm it or create a testcase, please, do.
can you try emerging gcc-4.3.3 with USE=vanilla and see if the problem still occurs ?
(In reply to comment #9) > can you try emerging gcc-4.3.3 with USE=vanilla and see if the problem still > occurs ? > If this is aimed at me, I'll think about it. However, the seemingly related wine bug was definitely not Gentoo related.
My problem is that when I first setup my system, I created a bit too small partition and now the space requirements for gcc reemerge are about equal max free space I can acquire, so I only reemerge gcc, when I have a VERY good reason.
One more thing: the person who reported the wine bug seems to be one of the devs of another source-based distro - Source Mage. Maybe you should compare notes ?
Shouldn't a message be added to the freeciv ebuild?
It seems that the gcc problem is fixed in gcc 4.4.0. However, accidentally I discovered a different bug in 4.3.3. If '-fno-guess-branch-probability' is used, src/id.c from coreutils-7.2 gets miscompiled and 'id -u' prints "id: cannot print "only" of more than one choice".
gcc-4.4.x is stable, so not going to spend time on this if there is no fix available for us to drop in