Red Hat Bugzilla – Bug 837081
valgrind-3.6.0-5.el6.x86_64 not usable on RHEL 6.3
Last modified: 2012-08-08 23:03:25 EDT
Trying to use valgrind on RHEL 6.3 x86_64 for local development and I get this error:
==31969== Memcheck, a memory error detector
==31969== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==31969== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==31969== Command: ./distadd -r /peachtree /home/dcantrel/peachtree/release/base/bzip2-1.0.6-4.x86_64.dist
--31969-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x2a
valgrind: m_debuginfo/readdwarf.c:2391 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.
==31969== at 0x3802D247: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux)
Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.
If that doesn't help, please report this bug to: www.valgrind.org
In the bug report, send all the above text, the valgrind
version, and what OS and version you are using. Thanks.
Searching around, it looks like Debian hit this same problem:
And it was subsequently addressed upstream. I took the SRPM from rawhide, built it locally, and then upgraded the valgrind RPM on my system. That gave me valgrind-3.7.0-4 and it's working as expected.
Either backporting the fix for this problem or rebasing valgrind to 3.7.0 would be nice for RHEL 6.4.
For comparison, I did a fresh install of RHEL 6.2 and tested me code there with valgrind. valgrind worked as expected, so it looks like this is a regression.
(In reply to comment #2)
> For comparison, I did a fresh install of RHEL 6.2 and tested me code there
> with valgrind. valgrind worked as expected, so it looks like this is a
I assume you rebuild you code on both RHEL 6.2 and RHEL 6.3? Then it must be GCC generating the newer DW_OP on RHEL 6.3, but not RHEL 6.2. Is your code small enough to share?
Created attachment 598874 [details]
Backport of upstream revisions r11856 and r11904
I haven't found a reproducer yet. But once we have one, then something like the following backport should fix it.
The usual place where you hit this is on ld generated .eh_frame unwind info for PLT slots. But I don't think such a change has been backported to the RHEL 6.3 binutils. Are you very sure you are using the RHEL 6.3 ld and not some other (or not copying libraries from some Fedora box with newer ld)?
Or, weren't you using DTS 1.0 ld?
I just yum installed valgrind from the RHEL-6 repos here:
I'm not copying over libraries from Fedora, it's just RHEL packages as we ship. RHEL 6.3 binutils and valgrind.
(In reply to comment #8)
> I just yum installed valgrind from the RHEL-6 repos here:
> I'm not copying over libraries from Fedora, it's just RHEL packages as we
> ship. RHEL 6.3 binutils and valgrind.
Could you give an example of a program that fails? How did you build it? How do you invoke valgrind?
Sorry, but we are unable to reproduce the problem. Since testing seems to indicate this situation cannot happen with a default RHEL 6.3 install we are inclined to close this bug report.
Are you able to get us a repoducer? Just a list of versions of the installed packages (gcc, binutils, valgrind) and some simple steps how to compile some sources to get a binary that shows the problem reported would be really helpful.
So I did a fresh install of RHEL 6.3 to reproduce the problem there, but valgrind worked fine. My laptop which I yum upgraded from 6.2 to 6.3 shows this problem, so chalk this one up to something odd on my laptop. Closing this one out. Sorry for the alarm.