Reproducible: always in my environment Several applications crashed with SIGSEGV when linking with the debug libraries of Qt4.1.1. I reduced the problem to the following testcase: test.pro OPTIONS+= debug SOURCES = main.cpp main.cpp #include <QHash> int main ( int , char ** ) { QHash<int, int> * hash = new QHash<int,int>(); hash->insert(5,6); QHash<int,int>::iterator ff = hash->find(5); if ( ff != hash->end() ) { hash->erase(ff); } return 0; } This crashes in line 9 (hash->erase(ff)). The problem occurs with the emerged x11-libs/qt-4.1.1 as well as with a "hand built" Qt without patches. Both, release and debug versions of the libraries are affected. It seems to me that the parameters supplied to the method 'erase' are corrupted. When adding -fno-stack-protector to the CFLAGS/CXXFLAGS everything went ok. # emerge info Portage 2.0.54 (default-linux/x86/2005.0, gcc-3.4.5, glibc-2.3.5-r2, 2.6.13-rsbac-rsbac-udev i686) ================================================================= System uname: 2.6.13-rsbac-rsbac-udev i686 AMD Athlon(tm) XP 2000+ Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/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.4/env /usr/kde/3.4/share/config /usr/kde/3.4/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" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="en_US.iso885915" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow X aalib alsa apm arts audiofile avi berkdb bitmap-fonts bzip2 cdr crypt cups curl doc dri dts eds emboss encode esd ethereal exif expat fam ffmpeg firebird flac foomaticdb fortran gd gdbm gif glut gmp gnome gphoto2 gpm gstreamer gtk gtk2 hardened idn imagemagick imlib ipv6 java jpeg junit kde lcms libg++ libwww mad mikmod mmx mng motif mozilla mp3 mpeg mysql ncurses nls odbc ogg oggvorbis opengl oss pam pcre pdflib perl pic pie png postgres python qt quicktime readline recode sdl slang spell ssl svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales vorbis wmf xine xml2 xmms xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY Is anyone able to reproduce this behavior?
I can indeed reproduce the behavior on an x86 system. I don't have much experience with hardened compilers, so I can't suggest a recourse. I'll let the hardened team speak up with their experience here. You can email a bug report to qt-bugs@trolltech.com, but they may consider it to be a result of using a hardened compiler unless we have good evidence for how to fix the problem.
I've run into this bug, too. It is not Qt bug, it is ssp's bug. When the hash->erase(ff) (line 9) is called, inside the QHash::erase 'this' address is replaced by ff.i. Since the QHash::erase method frees the memory chunk pointed to by ff.i in call to freeNode(), next access to the object 'this' accesses unallocated memory, thus causing SIGSEGV. I've checked it with Qt 4.1.1, 4.1.2 and 4.1.3, with hardened gcc-3.4.5-r1 and gcc-3.4.6-r1. Both versions of gcc use ssp-3.4.5-1.0. I don't know whom to send the bug report about ssp, though. Possible workarounds: -compiling Qt and the programs with -fno-stack-protector -choosing a non-ssp configuration of gcc with gcc-config, e.g. gcc-config i686-pc-linux-gnu-3.4.5-hardenednossp
Due to SSP having issues with C++ code, I just placed a -fno-stack-protector in the x11-libs/qt ebuilds. Thus, you should no longer see those issues when emerging anything qt-based or QT itself.
