Running valgrind aborts on assertion maxidx >= 2: $ valgrind /usr/bin/uname ==19853== Memcheck, a memory error detector ==19853== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==19853== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==19853== Command: /usr/bin/uname ==19853== uname: ../sysdeps/x86_64/cacheinfo.c:255: handle_intel: Assertion `maxidx >= 2' failed. ==19853== ==19853== HEAP SUMMARY: ==19853== in use at exit: 89 bytes in 1 blocks ==19853== total heap usage: 2 allocs, 1 frees, 189 bytes allocated ==19853== ==19853== LEAK SUMMARY: ==19853== definitely lost: 0 bytes in 0 blocks ==19853== indirectly lost: 0 bytes in 0 blocks ==19853== possibly lost: 0 bytes in 0 blocks ==19853== still reachable: 89 bytes in 1 blocks ==19853== suppressed: 0 bytes in 0 blocks ==19853== Rerun with --leak-check=full to see details of leaked memory ==19853== ==19853== For counts of detected and suppressed errors, rerun with: -v ==19853== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 7) Aborted This bug is described in Debian bug tracking system: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584912 The bug could be closed in valgrind-3.6.0 (released on 2010-10-21, bug in Debian closed on 2010-08-09 with pre-3.6.0 snapshot) that is unstable on x86 currently in Gentoo. I'm going to try it. My CPU is: processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 3 model name : AMD Duron(tm) processor stepping : 1 cpu MHz : 951.751 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips : 1903.50 clflush size : 32 cache_alignment : 32 address sizes : 36 bits physical, 32 bits virtual power management: My system: Portage 2.1.8.3 (default/linux/x86/10.0, gcc-4.4.4, glibc-2.11.2-r3, 2.6.35-gentoo-r10 i686) ================================================================= System Settings ================================================================= System uname: Linux-2.6.35-gentoo-r10-i686-AMD_Duron-tm-_processor-with-gentoo-2.0.1 Timestamp of tree: Wed, 17 Nov 2010 07:15:01 +0000 distcc 3.1 i686-pc-linux-gnu [disabled] app-shells/bash: 4.1_p7 dev-java/java-config: 2.1.11-r1 dev-lang/python: 2.6.5-r3, 3.1.2-r4 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1-r1 sys-apps/openrc: 0.6.4 sys-apps/sandbox: 2.3-r1 sys-devel/autoconf: 2.13, 2.65-r1 sys-devel/automake: 1.5-r1, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 3.4.6-r2, 4.3.4, 4.4.4-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-tbird -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb" 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/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=athlon-tbird -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="ftp://ftp.fi.muni.cz/pub/linux/gentoo/ ftp://gentoo.mirror.dkm.cz/pub/gentoo/" LANG="cs_CZ.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="cs en" 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="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/sunrise /var/lib/layman/lisp /var/lib/layman/zugaina /var/lib/layman/ikelos /var/lib/layman/java-overlay /var/lib/layman/science /usr/local/portage/petr_p" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow a52 aac acl acpi alsa audiofile avi berkdb bzip2 caps cdparanoia cjk cli cracklib crypt custom-cxxflags cxx dri esd ffmpeg flac fortran ftp gd gdbm gif gnutls gpm gtk gtk2 iconv icq idn imagemagick imap imlib ipv6 irc jabber java javascript jpeg jpeg2k lcms live lm_sensors matroska mbox mikmod mime mmap mmx mmxext mng modules motif mp3 mpeg mudflap nas ncurses nls nodrm nptl nptlonly ogg openmp pam pcre pdf perl plotutils png posix ppds pppd python qt3support readline recode rss samba sasl sdl session sharedmem sndfile sockets speex spell ssl svg sysfs sysvipc tcpd tetex theora threads tiff truetype ucs2 ucs4 unicode usb vorbis win32codecs x86 xattr xml xml2 xorg xosd xpm xsl xv xvid zlib" ALSA_CARDS="snd_via82xx" 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" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" 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" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="cs en" PHP_TARGETS="php5-2" QEMU_SOFTMMU_TARGETS="i386 mipsel" QEMU_USER_TARGETS="i386 mipsel" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nv nvidia vesa" 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, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ================================================================= Package Settings ================================================================= dev-util/valgrind-3.5.0 was built with the following: USE="-mpi" CFLAGS="-march=athlon-tbird -O2 -pipe" CXXFLAGS="-march=athlon-tbird -O2 -pipe"
No progress with valgrind-3.6.0.
Valgrind from SVN trunk (11479) suffers from this problem too. More interesting, revision referenced by Debian (11254) is skipped in SVN log.
So even sources from Debian valgrind-3.6.0~svn11254+nmu1 does not work. Probably some fiddle on glibc side is necessary as the assert comes from there> uname: ../sysdeps/x86_64/cacheinfo.c:255: handle_intel: Assertion `maxidx >= 2' failed.
(In reply to comment #3) > So even sources from Debian valgrind-3.6.0~svn11254+nmu1 does not work. > Probably some fiddle on glibc side is necessary as the assert comes from there> > > uname: ../sysdeps/x86_64/cacheinfo.c:255: handle_intel: Assertion `maxidx >= 2' > failed. > I don't understand what's going on with the Debian bug. They seem to think the problem is solved. This is definitely an upstream bug. Did you look through valgrind's bug reports? If its not there, I'll open a bug later.
(In reply to comment #4) > I don't understand what's going on with the Debian bug. The Debian bug describes what's going on. I did not want to repeat their thorough explanation. > They seem to think the problem is solved. > I thought too. Obviously it isn't. > This is definitely an upstream bug. Did you look through valgrind's bug > reports? If its not there, I'll open a bug later. > Whooa! They have bug tracking system. I've just searched mailing list without success. I found <https://bugs.kde.org/show_bug.cgi?id=140729>. It looks related and not yet fixed. I will post a comment there.
(In reply to comment #5) > (In reply to comment #4) > > I don't understand what's going on with the Debian bug. > > The Debian bug describes what's going on. I did not want to repeat their > thorough explanation. > > > They seem to think the problem is solved. > > > I thought too. Obviously it isn't. > > > This is definitely an upstream bug. Did you look through valgrind's bug > > reports? If its not there, I'll open a bug later. > > > Whooa! They have bug tracking system. I've just searched mailing list > without success. > > I found <https://bugs.kde.org/show_bug.cgi?id=140729>. It looks related and > not yet fixed. I will post a comment there. This is an old bug. Petr, did this get resolved?
Unfortunately not. Checked with stable ebuild (dev-util/valgrind-3.6.1-r3, sys-libs/glibc-2.14.1-r3) and unstable one (dev-util/valgrind-3.7.0-r4). Just the line number is different from my previous test because of newer glibc: ../sysdeps/x86_64/cacheinfo.c:308: handle_intel: Assertion `maxidx >= 2' failed. I reread the Debian report again and they claim it fixed because they've modified both glibc (removing the assert) and valgrind (emulating cpuid equaled equaled to the native one). I have not tried to apply their glibc fix.
Created attachment 320104 [details, diff] Fix for glibc This is glibc fix from Debian I successfully tested on my Gentoo with dev-util/valgrind-3.7.0-r4 and sys-libs/glibc-2.14.1-r3. Valgrind can continue and detects leaks so far successfully. I've also not noticed any problems with the glibc. I did not run glibc internal test suite.
(In reply to comment #8) > Created attachment 320104 [details, diff] [details, diff] > Fix for glibc > > This is glibc fix from Debian I successfully tested on my Gentoo with > dev-util/valgrind-3.7.0-r4 and sys-libs/glibc-2.14.1-r3. Valgrind can > continue and detects leaks so far successfully. I've also not noticed any > problems with the glibc. I did not run glibc internal test suite. Okay I'm cc-ing toolchain folk to review the Debian patch. @toolchain. What would you guys like from me as far as testing? I'll do the legwork to lighten your load.
err, that patch says valgrind is broken. shouldn't you fix valgrind instead ?
Valgrind contains ISA emulator. Fixing valgrind would mean to implement new subarchitecture for ten years old CPU. My abilities are low to do it and I believe upstream is not willing to do it either. I think the assert in glibc is just to make things tightened when building generic glibc for variety of subarchitectures with run-time selection of optimized implementations using trampolines. However this use case is not valid on Gentoo where each installation is optimized and specific for a machine. So I think the assert can be safely removed. Actually in this case, glibc is compiled for i686, but valgrind selects to emulate i585, and glibc then hits the assert because it thinks somebody is running the i686 build on i585 machine. The emulated part of ISA is handled in valgrind which is valgrind responsibility and the non-emulated part is handled by real processor which is still i686. So glibc worries expressed by the assert are odd.
(In reply to comment #11) if you're emulating the CPU wrong, then glibc is going to "misbehave" because it relies on cpuid and friends being correct in order to do runtime ISA detection. the fact that you built with -march=foo doesn't matter. recent glibc's have been adding more and more ifunc support which means at runtime, based on cpuid probing, it's going to execute different hand written assembly code. they currently have non-sse code, sse2, ssse3, and sse4 variants. so no, i don't think it's ok to ignore the problem in valgrind as it's only going to get worse.
Ok. Then I'd like to ask for a favor: Please add epach_user() to the glibc ebuild.
(In reply to comment #13) that was already done quite a long time ago: http://sources.gentoo.org/sys-libs/glibc/files/eblits/src_unpack.eblit?r1=1.8&r2=1.9
Doesn't look like we need toolchain's involvement anymore. valgrind is where the true issue lies.
This is an old bug for an old version of valgrind which is now off the tree. I'm going to close it as obsolete. Reopen if it reappears.