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
uname: ../sysdeps/x86_64/cacheinfo.c:255: handle_intel: Assertion `maxidx >= 2' failed.
==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== 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== For counts of detected and suppressed errors, rerun with: -v
==19853== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 7)
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
Portage 18.104.22.168 (default/linux/x86/10.0, gcc-4.4.4, glibc-2.11.2-r3, 2.6.35-gentoo-r10 i686)
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]
dev-lang/python: 2.6.5-r3, 3.1.2-r4
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/gcc: 3.4.6-r2, 4.3.4, 4.4.4-r2
CFLAGS="-march=athlon-tbird -O2 -pipe -fomit-frame-pointer"
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"
FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch userpriv usersandbox"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
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"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
dev-util/valgrind-3.5.0 was built with the following:
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'
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:
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.