<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>88899</bug_id>
          
          <creation_ts>2005-04-12 14:23 0000</creation_ts>
          <short_desc>games-strategy/wesnoth-0.9.0 crashes when compiled with -fstack-protector</short_desc>
          <delta_ts>2005-08-18 23:28:40 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>Games</component>
          <version>unspecified</version>
          <rep_platform>All</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          <bug_file_loc>http://savannah.nongnu.org/bugs/?func=detailitem&amp;item_id=14215</bug_file_loc>
          
          
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>levertond@googlemail.com</reporter>
          <assigned_to>games@gentoo.org</assigned_to>
          

      

      
          <long_desc isprivate="0">
            <who>levertond@googlemail.com</who>
            <bug_when>2005-04-12 14:23:26 0000</bug_when>
            <thetext>When compiled on amd64 with the -fstack-protector flag, wesnoth crashes at the end of a scenario with a stack smashing attack message on the terminal (I forgot to copy down the exact message, but it occurs in the function &quot;LEVEL_RESULT play_level(game_data&amp;, config&amp;, config*, CVideo&amp;, game_state&amp;, std::vector&lt;config*&gt;&amp;)&quot;).  The problem /doesn&apos;t/ occur in a 32bit chroot on the same machine.

Reproducible: Always
Steps to Reproduce:
1. On an amd64 system: CFLAGS=&quot;-fstack-protector ...&quot; emerge wesnoth
2. Run &quot;wesnoth&quot;, choose the &quot;Tutorial&quot; menu item and play through the first scenario.
3.

Actual Results:  
Games crashes with &quot;stack smashing&quot; message.

Expected Results:  
Continue to the next scenario in the tutorial.

Portage 2.0.51.19 (default-linux/amd64/2005.0, gcc-3.4.3,
glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r6 x86_64)
=================================================================
System uname: 2.6.11-gentoo-r6 x86_64 AMD Athlon(tm) 64 Processor 3000+
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#2, Mar  1 2005, 21:38:17)]
ccache version 2.3 [enabled]
dev-lang/python:     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-r7
sys-devel/libtool:   1.5.14
virtual/os-headers:  2.6.8.1-r4
ACCEPT_KEYWORDS=&quot;amd64&quot;
AUTOCLEAN=&quot;yes&quot;
CFLAGS=&quot;-march=athlon64 -pipe -fomit-frame-pointer -O2&quot;
CHOST=&quot;x86_64-pc-linux-gnu&quot;
CONFIG_PROTECT=&quot;/etc /usr/kde/2/share/config /usr/kde/3.3/env
/usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /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&quot;
CONFIG_PROTECT_MASK=&quot;/etc/gconf /etc/terminfo /etc/env.d&quot;
CXXFLAGS=&quot;-march=athlon64 -pipe -fomit-frame-pointer -O2&quot;
DISTDIR=&quot;/usr/portage/distfiles&quot;
FEATURES=&quot;autoaddcvs autoconfig ccache distlocks sandbox&quot;
GENTOO_MIRRORS=&quot;ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/
ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/
http://ftp.du.se/pub/os/gentoo http://ftp.easynet.nl/mirror/gentoo/&quot;
LINGUAS=&quot;en_GB&quot;
MAKEOPTS=&quot;&quot;
PKGDIR=&quot;/usr/portage/packages&quot;
PORTAGE_TMPDIR=&quot;/var/tmp&quot;
PORTDIR=&quot;/usr/portage&quot;
PORTDIR_OVERLAY=&quot;/usr/local/portage&quot;
SYNC=&quot;rsync://rsync.gentoo.org/gentoo-portage&quot;
USE=&quot;amd64 X aalib acl acpi alsa apache2 arts avi berkdb bitmap-fonts cairo cdr
crypt cups curl dvd esd fam flac font-serverfortran gdbm ggi gif gtk gtk2
imagemagick imlib ipv6 java jp2 jpeg junit kde lcms leim libcaca libwww lzw
lzw-tiff mad mikmod mng motif mozilla mp3 mpeg ncurses nls nptl nptlonly ogg
opengl pam pdflib perl png postgres python qt readline samba sdl speex ssl tcltk
tcpd tetex theora tiff timidity truetype truetype-fonts type1-fonts usb
userlocales vorbis xml2 xmms xpm xrandr xv zlib linguas_en_GB&quot;
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>mr_bones_@gentoo.org</who>
            <bug_when>2005-04-12 14:50:24 0000</bug_when>
            <thetext>filtered.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2005-04-12 17:00:00 0000</bug_when>
            <thetext>umm, chances are the game is broken so filtering stack-protector is a dumb idea ...</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>yosefm@gmail.com</who>
            <bug_when>2005-08-18 01:54:42 0000</bug_when>
            <thetext>Not filtered in 0.9.5 on x86 and gives the same problem.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>mr_bones_@gentoo.org</who>
            <bug_when>2005-08-18 09:04:19 0000</bug_when>
            <thetext>linked to the upstream bug.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>mr_bones_@gentoo.org</who>
            <bug_when>2005-08-18 23:28:40 0000</bug_when>
            <thetext>Ok, I confirmed the issue on x86 and talked at length with upstream about this.
 Their take on it is that it is purely a gcc-3 issue and that there is actually
no stack problems.  They say that gcc-4 doesn&apos;t have a problem with the code. 
I&apos;ve filtered out the flag for gcc-3 in CVS.  resync/remerge to get it if you
have -fstack-protector in your CXXFLAGS.  No rev bump to save a compile for all
the rest of the people out there without that flag enabled.

Thanks for the bug report. (and thanks to the upstream devs for their patience)</thetext>
          </long_desc>
      
    </bug>

</bugzilla>