# eix Received SEGSEGV - you probably have found a bug in eix. Backtrace obtained as requested: Starting program: /usr/bin/eix Program received signal SIGSEGV, Segmentation fault. AnsiMarker::calc_string (this=0xbfffe758) at eixTk/ansicolor.cc:101 101 AnsiMarker::calc_string() #0 AnsiMarker::calc_string (this=0xbfffe758) at eixTk/ansicolor.cc:101 #1 0xb7e812ed in AnsiMarker::initmarker (this=0xbfffe758, markers_string=...) at eixTk/ansicolor.cc:97 #2 0xb7e816ba in AnsiColor::AnsiColor (this=0xbfffe748, color_name=...) at eixTk/ansicolor.cc:155 #3 0xb7f3d33f in FormatParser::state_COLOR (this=0xb80024d4) at output/formatstring.cc:439 #4 0xb7f3d9f1 in FormatParser::start (this=0xb80024d4, fmt=0xb8035964 "{installed}[{!*r}{upgrade}{*r}(cyan,1;inverse)U(){}{downgrade}{*r}(blue,1;inverse)D(){}{!$r}(green,1;inverse)I(){}]{else}(green)*{} {system}{systempure}(yellow){else}(yellow;underline){}{else}{world}{"..., colors=true, parse_only_colors=false) at output/formatstring.cc:698 #5 0xb7f5af56 in PrintFormat::parseFormat (this=0xb80024a0, fmt=0xb8035964 "{installed}[{!*r}{upgrade}{*r}(cyan,1;inverse)U(){}{downgrade}{*r}(blue,1;inverse)D(){}{!$r}(green,1;inverse)I(){}]{else}(green)*{} {system}{systempure}(yellow){else}(yellow;underline){}{else}{world}{"...) at ./output/formatstring.h:316 #6 0xb7f5af9d in PrintFormat::setFormat (this=0xb80024a0, fmt=0xb8035964 "{installed}[{!*r}{upgrade}{*r}(cyan,1;inverse)U(){}{downgrade}{*r}(blue,1;inverse)D(){}{!$r}(green,1;inverse)I(){}]{else}(green)*{} {system}{systempure}(yellow){else}(yellow;underline){}{else}{world}{"...) at ./output/formatstring.h:319 #7 0xb7f5214a in set_format () at eix.cc:477 #8 0xb7f53ab1 in run_eix (argc=1, argv=0xbffff614) at eix.cc:555 #9 0xb7faa494 in run_program (argc=1, argv=0xbffff614) at main/main.cc:151 #10 0xb7faa5fe in main (argc=1, argv=0xbffff614) at main/main.cc:182 Portage 2.1.10.3 (uclibc/x86/hardened, gcc-4.3.4, uclibc-0.9.30.1-r1, 2.6.39-hardened-r8-main i686) ================================================================= System uname: Linux-2.6.39-hardened-r8-main-i686-Intel-R-_Core-TM-2_Duo_CPU_T8100_@_2.10GHz-with-gentoo-2.0.3 Timestamp of tree: Thu, 18 Aug 2011 07:15:01 +0000 app-shells/bash: 4.1_p9 dev-lang/python: 2.7.1-r1 dev-util/pkgconfig: 0.25-r2 sys-apps/baselayout: 2.0.3 sys-apps/openrc: 0.8.3-r1 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.68 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.3.4 sys-devel/gcc-config: 1.4.1-r1 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82 sys-kernel/linux-headers: 2.6.36.1 (virtual/os-headers) sys-libs/uclibc: 0.9.30.1-r1 Repositories: gentoo ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i586-gentoo-linux-uclibc" CFLAGS="-march=i586 -Os -pipe -fomit-frame-pointer -mmmx" CHOST="i586-gentoo-linux-uclibc" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=i586 -Os -pipe -fomit-frame-pointer -mmmx" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--ask --autounmask=n" FEATURES="assume-digests binpkg-logs buildpkg collision-protect distlocks ebuild-locks fixlafiles fixpackages news nodoc noinfo noman parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox" FFLAGS="" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,relro,-z,now" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" 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="/mnt/nfs_portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="cli cracklib crypt cxx dri hardened minimal mmx modules mudflap openmp pcre pic session ssl syslog uclibc x86 xorg zlib" 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 cgi cgid 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" CALLIGRA_FEATURES="braindump flow karbon kexi kpresenter krita tables words" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="uclibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="chips" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 283809 [details, diff] Print debuginfo for AnsiMarker::calc_string() to stderr My first guess is that this is a bug in uclibc snprintf() implementation. Since I do not have uclibc installed, I cannot reproduce here, so I would appreciate if you could help me debugging: Please post what eix outputs to stderr after applying the attached patch (you can redirect standard output to /dev/null, and the last 4 lines before the segfault should be sufficient informatino). The patch is against eix-0.22.11; please use also that version if possible.
(In reply to comment #1) > Created attachment 283809 [details, diff] > Print debuginfo for AnsiMarker::calc_string() to stderr > > My first guess is that this is a bug in uclibc snprintf() implementation. > > Since I do not have uclibc installed, I cannot reproduce here, so I would > appreciate if you could help me debugging: > Please post what eix outputs to stderr after applying the attached patch > (you can redirect standard output to /dev/null, and the last 4 lines before > the segfault should be sufficient informatino). > > The patch is against eix-0.22.11; please use also that version if possible. I applied the patch and installed eix. If I do # eix Received SIGSEV.... and so on. Nothing more. Same with #eix 2>&1
Created attachment 283949 [details, diff] avoid assign and output messages around assumed segfault Thanks for testing. The result is rather unexpected to me: eix seems to segfault when accessing a vector by a const_iterator immediately after the vector was re-initialized with assign(). I cannot imagine what goes wrong here. Perhaps your hardened kernel prevents something and causes the segfault (should be visible with dmesg or in other logs)? Maybe the assign() implementation is broken, although this is rather unlikely. The attached patch avoids to call assign() (and still outputs some info to stderr so that we can guess where the segfault happens). If after the patch the segfault does not happen between the output of BEGIN and END (with e.g. eix -e eix >/dev/null), please check by the backtrace in gdb whether it happens still in calc_string(): if really assign() was the problem, we might run into the next error with a completely different cause. Another possibility is that your hardened gcc really produces broken code: Does the same happen with vanilla gcc and -O2 instead of -Os?
(In reply to comment #3) > Perhaps your hardened kernel prevents something and causes the segfault > (should be visible with dmesg or in other logs)? Nothing in dmesg or other logs... > Maybe the assign() implementation is broken, although this is rather > unlikely. The attached patch avoids to call assign() (and still outputs > some info to stderr so that we can guess where the segfault happens). > If after the patch the segfault does not happen between the output > of BEGIN and END (with e.g. eix -e eix >/dev/null), No output as well. > please check > by the backtrace in gdb whether it happens still in calc_string(): > if really assign() was the problem, we might run into the next error > with a completely different cause. Still in calc_string() > Another possibility is that your hardened gcc really produces broken > code: Does the same happen with vanilla gcc and -O2 instead of -Os? Switching to vanilla gcc segfaults, too. Cannot convince to build with -O2, any hints appreciated.
Created attachment 283991 [details, diff] Print a message before every command Surprises after surprises. So it is not the only command in calc_string() which I might imagine as the cause. I am rather lost. It looks more and more as if gcc produced broken code. I attach now a patch which outputs a message before every command so that we can find out exactly at which command the segfault occurs. When switching to vanilla, please also set USE=-hardened so that eix does not add things like -fstack-protector > Cannot convince to build with -O2, any hints appreciated. Ah, you are still compiling with USE=debug; then eix will ignore your CXXFLAGS/LDFLAGS. Then we can exclude -Os as the cause anyway.
(In reply to comment #5) > Created attachment 283991 [details, diff] > Print a message before every command > > Surprises after surprises. So it is not the only command in calc_string() > which I might imagine as the cause. I am rather lost. > It looks more and more as if gcc produced broken code. > > I attach now a patch which outputs a message before every command > so that we can find out exactly at which command the segfault occurs. > > When switching to vanilla, please also set USE=-hardened so that > eix does not add things like -fstack-protector > > > Cannot convince to build with -O2, any hints appreciated. > > Ah, you are still compiling with USE=debug; then eix will ignore > your CXXFLAGS/LDFLAGS. Then we can exclude -Os as the cause anyway. Hmm... That's strange. Now with USE="debug -hardened" on gcc vanilla, eix works properly without segfault. Thought, I had tested with -hardened tehn already, but well... With USE="debug" on gcc hardened, the following is printed before segfault: before calc_string
(In reply to comment #6) > Now with USE="debug -hardened" on gcc vanilla, > eix works properly without segfault. Does compiling eix with USE="-hardened" also avoid the segfault on hardened gcc? > With USE="debug" on gcc hardened, the following is printed before segfault: > before calc_string This means that the problem is not in the C++ sources of eix: The function is called, but the segfault happens even before the first C++ command in that function is executed. Probably it has to do with the stack protection mechanism: Since the function uses a local array, this machanism should become active. Therefore I hope that USE="-hardened" even on hardened gcc will "fix" the problem.
(In reply to comment #7) > Does compiling eix with USE="-hardened" also avoid the segfault on > hardened gcc? Yes. Works fine. > > With USE="debug" on gcc hardened, the following is printed before segfault: > > before calc_string > > This means that the problem is not in the C++ sources of eix: > The function is called, but the segfault happens even > before the first C++ command in that function is executed. > Probably it has to do with the stack protection mechanism: Since the > function uses a local array, this machanism should become active. > Therefore I hope that USE="-hardened" even on hardened gcc > will "fix" the problem. It does.
Thanks for testing. Let me try to summarize what probably happened: Due to USE=hardened, eix passed -fstack-protector to CXXFLAGS and LDFLAGS, and these let gcc on your system produce broken code. In eix svn trunk (>=eix-0.22.12), I tried to improve the check whether adding -fstack-protector really produces workable code. Moreover, I will suggest to rename the USE=hardened of eix into USE=security (or something similar) since this was somewhat a misnomer anyway after the new global usage of USE=hardened. Both is of course only a workaround for the real problem: Namely that gcc -fstack-protector seems to produce broken code on your system (if a function is called with a sufficiently large local array). Probably no other package will run into this problem since AFAIK no other package tries to add -fstack-protector manually. I consider this bug fixed on the eix side, and I will probably close it once the USE-flag is renamed: I do not feel responsible for the other bug and do not have the means to debug it. If you want that the other bug (due to gcc or hardened or uclibc - I don't know) is fixed, please open a new bug for it.
(In reply to comment #9) > Thanks for testing. No problem :-) > Let me try to summarize what probably happened: > Due to USE=hardened, eix passed -fstack-protector to CXXFLAGS and LDFLAGS, > and these let gcc on your system produce broken code. > > In eix svn trunk (>=eix-0.22.12), I tried to improve the check whether > adding -fstack-protector really produces workable code. > > Moreover, I will suggest to rename the USE=hardened of eix into > USE=security (or something similar) since this was somewhat a misnomer > anyway after the new global usage of USE=hardened. > > Both is of course only a workaround for the real problem: > Namely that gcc -fstack-protector seems to produce broken code on your system > (if a function is called with a sufficiently large local array). > Probably no other package will run into this problem since AFAIK no other > package tries to add -fstack-protector manually. > > I consider this bug fixed on the eix side, and I will probably close it > once the USE-flag is renamed: I do not feel responsible for the other bug > and do not have the means to debug it. > If you want that the other bug (due to gcc or hardened or uclibc - > I don't know) is fixed, please open a new bug for it. Well, for me it's okay if eix works again. Maybe CC hardened and/or toolchain and let them decide. Thanks
I think this bug is completed, Martin. Close at will.
Closing as fixed, although I know that the solution is not completely satisfactory.
