Summary: | dev-util/valgrind-3.5.0 aborts on AMD Thunderbird-like (i686, cpuid=1) processors | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Petr Pisar <petr.pisar> |
Component: | [OLD] Development | Assignee: | Anthony Basile <blueness> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | ||
Priority: | High | ||
Version: | 10.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Fix for glibc |
Description
Petr Pisar
2010-11-17 11:59:22 UTC
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. |