Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 345873 - dev-util/valgrind-3.5.0 aborts on AMD Thunderbird-like (i686, cpuid=1) processors
Summary: dev-util/valgrind-3.5.0 aborts on AMD Thunderbird-like (i686, cpuid=1) proces...
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Anthony Basile
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-17 11:59 UTC by Petr Pisar
Modified: 2016-02-12 01:29 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
Fix for glibc (glibc-2.11.3-valgrind_on_cpuid1.patch,842 bytes, patch)
2012-08-02 18:03 UTC, Petr Pisar
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Pisar 2010-11-17 11:59:22 UTC
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"
Comment 1 Petr Pisar 2010-11-17 12:20:41 UTC
No progress with valgrind-3.6.0.
Comment 2 Petr Pisar 2010-11-17 13:17:45 UTC
Valgrind from SVN trunk (11479) suffers from this problem too. More interesting, revision referenced by Debian (11254) is skipped in SVN log.
Comment 3 Petr Pisar 2010-11-17 14:15:18 UTC
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.
Comment 4 Anthony Basile gentoo-dev 2010-11-17 20:46:23 UTC
(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.

Comment 5 Petr Pisar 2010-11-17 21:25:03 UTC
(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.
Comment 6 Anthony Basile gentoo-dev 2012-07-25 13:21:42 UTC
(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?
Comment 7 Petr Pisar 2012-08-01 18:57:46 UTC
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.
Comment 8 Petr Pisar 2012-08-02 18:03:37 UTC
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.
Comment 9 Anthony Basile gentoo-dev 2012-08-02 18:09:27 UTC
(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.
Comment 10 SpanKY gentoo-dev 2012-08-02 21:44:44 UTC
err, that patch says valgrind is broken.  shouldn't you fix valgrind instead ?
Comment 11 Petr Pisar 2012-08-03 06:01:07 UTC
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.
Comment 12 SpanKY gentoo-dev 2012-08-03 16:15:22 UTC
(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.
Comment 13 Petr Pisar 2012-08-06 19:57:03 UTC
Ok. Then I'd like to ask for a favor: Please add epach_user() to the glibc ebuild.
Comment 14 SpanKY gentoo-dev 2012-08-07 17:24:15 UTC
(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
Comment 15 Mark Loeser (RETIRED) gentoo-dev 2013-02-22 22:02:36 UTC
Doesn't look like we need toolchain's involvement anymore.  valgrind is where the true issue lies.
Comment 16 Anthony Basile gentoo-dev 2016-02-12 01:29:10 UTC
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.