valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] vdsqrt

[Julian S. <js...@ac...>]

> Appreciate any thoughts,

What version of Valgrind is this?

J

[Valgrind-users] vdsqrt

[dave w. <wav...@gm...>]

Hi,

I'm receiving

==1066== valgrind: Unrecognised instruction at address 0x809d6de.
==1066==    at 0x809D6DE: mkl_vml_kernel_dSqrt_E9HAynn (in
/opt/intel/composer_xe_2013_sp1.0.080/mkl/lib/intel64/libmkl_vml_avx.so)
==1066==    by 0x4F51D04: vdSqrt (in /opt/intel/composer_xe_2013_
sp1.0.080/mkl/lib/intel64/libmkl_intel_ilp64.so)

but program runs okay outside and valgrind doesn't complain about similar
functions from mkl (vdInv, vdMul,...)

Appreciate any thoughts,

Dave

Re: [Valgrind-users] Duplicate symbol ___eprintf in libclang_rt.eprintf.a and libclang_rt.osx.a

[Jim <jps...@gm...>]

Hi, I'm still seeing this. Does anyone have any ideas?

On Fri, Aug 5, 2016 at 10:06 PM, jp...@gm... <jp...@gm...> wrote:

> I'm trying to compile valgrind SVN version 15929 using clang 3.8.1 on
> target x86_64-apple-darwin15.6.0. I'm running on OSX 15.6 (El Capitan).
> When tries to link vgpreload_core-x86-darwin.so, it fails with an error
> regarding duplicate ___eprintf symbols.
>
> Anyone see this before? I'm trying to figure out if this is an issue with
> my system, or with the valgrind source. Note that I also tried compiling
> the valgrind-3.11 stable release, but hit the same issue.
>
> Error:
>
> /Users/j/toolchains/llvm-3.8.1/bin/clang  -arch i386 -O2 -g -std=gnu99
> -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes
> -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings
> -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers
> -fno-stack-protector -fno-strict-aliasing -fno-builtin -Wno-cast-align
> -Wno-self-assign -Wno-tautological-compare -mmacosx-version-min=10.5
> -fno-stack-protector -fno-pic -fno-PIC -dynamic -O -g
> -fno-omit-frame-pointer -fno-strict-aliasing -fpic -fPIC -fno-builtin
> -dynamic -dynamiclib -all_load -arch i386   -o vgpreload_core-x86-darwin.so
> vgpreload_core_x86_darwin_so-vg_preloaded.o
>
> duplicate symbol ___eprintf in:
>
>     /Users/j/toolchains/llvm-3.8.1/bin/../lib/clang/3.8.1/lib/
> darwin/libclang_rt.eprintf.a(eprintf.c.o)
>
>     /Users/j/toolchains/llvm-3.8.1/bin/../lib/clang/3.8.1/lib/
> darwin/libclang_rt.osx.a(eprintf.c.o)
>
> ld: 1 duplicate symbol for architecture i386
>
> clang-3.8: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> Makefile:2749: recipe for target 'vgpreload_core-x86-darwin.so' failed
>

Re: [Valgrind-users] running callgrind with JNI (libhdfs) does not work

[Eqbal <eqb...@gm...>]

Thanks for your reply. I am happy to report that adding
--vex-iropt-register-updates=allregs-at-mem-access
option to callgrind worked for me and I am able to run it without any
problems. I think the issue was that JVM generates a lot of SIGSEGV signals
during it's "normal" course of operation and valgrind did not like that. I
have same issue with gdb where I have to handle those signals while
debugging.

Thanks again!

-Eqbal

On Tue, Aug 2, 2016 at 10:16 PM, Julian Seward <js...@ac...> wrote:

> On 02/08/16 22:30, Eqbal wrote:
>
> >> valgrind -v --tool=callgrind --dump-instr=yes --trace-jump=yes
> >> --trace-children=yes --smc-check=all --collect-jumps=yes
> >> --simulate-cache=yes ./example
>
> Try adding --px-default=allregs-at-mem-access.  If that doesn't help
> then try --px-default=allregs-at-each-insn.  You'll take a big performance
> hit though.
>
> It might also be -- looking at the other info in the report -- that this is
> some kind of security sandbox problem, in which the process is denied
> permission to proceed further at some point, because it is Valgrind that
> is running, not the JVM.  In which case the above flags won't help.
>
> J
>
>

[Valgrind-users] Duplicate symbol ___eprintf in libclang_rt.eprintf.a and libclang_rt.osx.a

[Jim <jps...@gm...>]

I'm trying to compile valgrind SVN version 15929 using clang 3.8.1 on
target x86_64-apple-darwin15.6.0. I'm running on OSX 15.6 (El Capitan).
When tries to link vgpreload_core-x86-darwin.so, it fails with an error
regarding duplicate ___eprintf symbols.

Anyone see this before? I'm trying to figure out if this is an issue with
my system, or with the valgrind source. Note that I also tried compiling
the valgrind-3.11 stable release, but hit the same issue.

Error:

/Users/j/toolchains/llvm-3.8.1/bin/clang  -arch i386 -O2 -g -std=gnu99
-Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes
-Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings
-Wempty-body -Wformat -Wformat-security -Wignored-qualifiers
-fno-stack-protector -fno-strict-aliasing -fno-builtin -Wno-cast-align
-Wno-self-assign -Wno-tautological-compare -mmacosx-version-min=10.5
-fno-stack-protector -fno-pic -fno-PIC -dynamic -O -g
-fno-omit-frame-pointer -fno-strict-aliasing -fpic -fPIC -fno-builtin
-dynamic -dynamiclib -all_load -arch i386   -o vgpreload_core-x86-darwin.so
vgpreload_core_x86_darwin_so-vg_preloaded.o

duplicate symbol ___eprintf in:

    /Users/j/toolchains/llvm-3.8.1/bin/../lib/clang/3.8.1/lib/
darwin/libclang_rt.eprintf.a(eprintf.c.o)

    /Users/j/toolchains/llvm-3.8.1/bin/../lib/clang/3.8.1/lib/
darwin/libclang_rt.osx.a(eprintf.c.o)

ld: 1 duplicate symbol for architecture i386

clang-3.8: error: linker command failed with exit code 1 (use -v to see
invocation)

Makefile:2749: recipe for target 'vgpreload_core-x86-darwin.so' failed

Re: [Valgrind-users] running callgrind with JNI (libhdfs) does not work

[<do...@ma...>]

> I am trying to profile an application with callgrind. The application
> uses hadoop's libhdfs api which in turn makes JNI calls to a JVM. This
> causes a crash in the JVM. When running normally the application seems
> to work fine.
> 
> I am running on Centos 6.7 with Valgrind 3.11.0. Java is 1.8 Oracle JDK
> (I have also tried open jdk without much luck).
> Here is my commandline:
> 
> valgrind -v --tool=callgrind --dump-instr=yes --trace-jump=yes
> --trace-children=yes --smc-check=all --collect-jumps=yes
> --simulate-cache=yes ./example
> 
>  Below are some of the output from valgrind:
<snip>
I've never programmed for hadoop or the jvm.
That said, here's my ideas.
First off, if you or the jvm are using jit compilation you could be
running into a permissions problem. For example, mmap requires PROT_EXEC
in order to execute mmap'ed pages. On a few arches, the implementation is
flawed so it is not so, but with valgrind the said bug will manifest
itself.

> # JRE version: Java(TM) SE Runtime Environment (8.0_92-b14) (build
> 1.8.0_92-b14)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.92-b14 mixed mode
> linux-amd64 compressed oops)
<snip>
Having experimented, and having had to run the the authorities on the
subject of java I can say that Hotspot is an evil thing. It gave me
much headache when compiling the openjdk on Gentoo (that's when I
asked, and learned about java's buggy history).

My recommendation is to find a java without hotspot, zero, or other old
stuff and try again. Here in Gentoo world the openjdk is build with
icedtea.
I hope this helps.
If it does not you aught to go to the openjdk/hadoop folks and ask them
for help and perhaps we can work together to find and fix this. Try to
create a minimal use case to submit.

BTW: Yes, I'm just now caching up on a month of email.

Sincerely,
David

Re: [Valgrind-users] Suppression not working on some systems

[Julian S. <js...@ac...>]

On 03/08/16 13:31, John Spray wrote:
> Ah, that makes sense, thanks.  I guess we could also use creatively
> wildcarded strings like *boost*detail*get_once_per_thread_epoch*?

Yes, that might also work.

J

Re: [Valgrind-users] Suppression not working on some systems

[John S. <js...@re...>]

On Wed, Aug 3, 2016 at 12:15 PM, Julian Seward <js...@ac...> wrote:
>
>> The suppression file we use is:
>> https://github.com/ceph/teuthology/blob/master/teuthology/task/valgrind.supp#L303
>
> That has demangled symbol names in it.  They should be non-demangled,
> and that's why it doesn't match.  The easiest way to get the non-demangled
> names is to run with --gen-suppressions=all and copy what you get from
> there.  Or you can play games trying to correlate the output of "nm" and
> "nm | c++filt" for the binary, and try to figure out the names from that.
>
> You can see mangled names in other parts of the same file, for example at
> https://github.com/ceph/teuthology/blob/master/teuthology/task/valgrind.supp#L142

Ah, that makes sense, thanks.  I guess we could also use creatively
wildcarded strings like *boost*detail*get_once_per_thread_epoch*?

John

Re: [Valgrind-users] Suppression not working on some systems

[Julian S. <js...@ac...>]

> The suppression file we use is:
> https://github.com/ceph/teuthology/blob/master/teuthology/task/valgrind.supp#L303

That has demangled symbol names in it.  They should be non-demangled,
and that's why it doesn't match.  The easiest way to get the non-demangled
names is to run with --gen-suppressions=all and copy what you get from
there.  Or you can play games trying to correlate the output of "nm" and
"nm | c++filt" for the binary, and try to figure out the names from that.

You can see mangled names in other parts of the same file, for example at
https://github.com/ceph/teuthology/blob/master/teuthology/task/valgrind.supp#L142

J

[Valgrind-users] Suppression not working on some systems

[John S. <js...@re...>]

Hi,

We use valgrind in our automated testing of Ceph.  There is a false
positive[1] in the boost library we link with, and we use a
suppression file to silence it (along with other things).  However,
when we run our tests across both CentOS7 and Ubuntu Trusty servers,
the suppression is only working on CentOS, and not on Ubuntu.

The suppression file we use is:
https://github.com/ceph/teuthology/blob/master/teuthology/task/valgrind.supp#L303

The error we're trying to suppress is shown in this ticket:
http://tracker.ceph.com/issues/15356

Any advice would be much appreciated, I don't really know how to drill
into this to work out why our suppression isn't working.

Thanks,
John


1. https://svn.boost.org/trac/boost/ticket/3296

Re: [Valgrind-users] running callgrind with JNI (libhdfs) does not work

[Julian S. <js...@ac...>]

On 02/08/16 22:30, Eqbal wrote:

>> valgrind -v --tool=callgrind --dump-instr=yes --trace-jump=yes
>> --trace-children=yes --smc-check=all --collect-jumps=yes
>> --simulate-cache=yes ./example

Try adding --px-default=allregs-at-mem-access.  If that doesn't help
then try --px-default=allregs-at-each-insn.  You'll take a big performance
hit though.

It might also be -- looking at the other info in the report -- that this is
some kind of security sandbox problem, in which the process is denied
permission to proceed further at some point, because it is Valgrind that
is running, not the JVM.  In which case the above flags won't help.

J

Re: [Valgrind-users] running callgrind with JNI (libhdfs) does not work

[Eqbal <eqb...@gm...>]

Hi,

I haven't got a response to this. I am a new to Valgrind. Any pointers
would be greatly appreciated.

Thanks.

On Sun, Jul 10, 2016 at 6:18 PM, Eqbal <eqb...@gm...> wrote:

> I am trying to profile an application with callgrind. The application uses
> hadoop's libhdfs api which in turn makes JNI calls to a JVM. This causes a
> crash in the JVM. When running normally the application seems to work fine.
>
> I am running on Centos 6.7 with Valgrind 3.11.0. Java is 1.8 Oracle JDK (I
> have also tried open jdk without much luck).
> Here is my commandline:
>
> valgrind -v --tool=callgrind --dump-instr=yes --trace-jump=yes
> --trace-children=yes --smc-check=all --collect-jumps=yes
> --simulate-cache=yes ./example
>
>  Below are some of the output from valgrind:
>
> [CodeBlob (0x00000000064d8f50)]
> Framesize: 84
> SafepointBlob
> Could not load hsdis-amd64.so; library not loadable; PrintAssembly is
> disabled
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (sharedRuntime.cpp:834), pid=37623,
> tid=0x0000000005c138e0
> #  fatal error: exception happened outside interpreter, nmethods and
> vtable stubs at pc 0x00000000064d9007
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_92-b14) (build
> 1.8.0_92-b14)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.92-b14 mixed mode
> linux-amd64 compressed oops)
> # Core dump written. Default location: /home/myuser/libhdfs/core or
> core.37623
> #
> # An error report file with more information is saved as:
> # /home/myuser/libhdfs/hs_err_pid37623.log
> ==37623== brk segment overflow in thread #1: can't grow to 0x4900000
> ==37623== brk segment overflow in thread #1: can't grow to 0x49a7000
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.java.com/bugreport/crash.jsp
> #
> ==37623==
> ==37623== Process terminating with default action of signal 6 (SIGABRT):
> dumping core
> ==37623==    at 0x3127032625: raise (in /lib64/libc-2.12.so)
> ==37623==    by 0x3127033E04: abort (in /lib64/libc-2.12.so)
> ==37623==    by 0x554A604: os::abort(bool) (in
> /usr/java/jdk1.8.0_92/jre/lib/amd64/server/libjvm.so)
> ==37623==    by 0x56E9A62: VMError::report_and_die() (in
> /usr/java/jdk1.8.0_92/jre/lib/amd64/server/libjvm.so)
> ==37623==    by 0x5127098: report_fatal(char const*, int, char const*) (in
> /usr/java/jdk1.8.0_92/jre/lib/amd64/server/libjvm.so)
> ==37623==    by 0x55E7479:
> SharedRuntime::continuation_for_implicit_exception(JavaThread*, unsigned
> char*, SharedRuntime::ImplicitExceptionKind) (in /usr/java/jdk1.8.0_92
> /jre/lib/amd64/server/libjvm.so)
> ==37623==    by 0x5550169: JVM_handle_linux_signal (in
> /usr/java/jdk1.8.0_92/jre/lib/amd64/server/libjvm.so)
> ==37623==    by 0x55465C2: signalHandler(int, siginfo*, void*) (in
> /usr/java/jdk1.8.0_92/jre/lib/amd64/server/libjvm.so)
> ==37623==    by 0x312703269F: ??? (in /lib64/libc-2.12.so)
> ==37623==    by 0x64D9006: ???
> ==37623==    by 0x44: ???
> ==37623==    by 0x649A03F: ???
>
> ----------
> Here is the stack trace from jvm error log:
>
> Current thread (0x0000000004022800):  JavaThread "main" [_thread_in_Java,
> id=37623, stack(0x0000000ffef01000,0x0000000fff001000)]
>
> Stack: [0x0000000ffef01000,0x0000000fff001000],  sp=0x0000000ffeff1ae0,
>  free space=962k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V  [libjvm.so+0xabd65a]  VMError::report_and_die()+0x2ba
> V  [libjvm.so+0x4fb099]  report_fatal(char const*, int, char const*)+0x59
> V  [libjvm.so+0x9bb47a]
>  SharedRuntime::continuation_for_implicit_exception(JavaThread*, unsigned
> char*, SharedRuntime::ImplicitExceptionKind)+0x33a
> V  [libjvm.so+0x92416a]  JVM_handle_linux_signal+0x48a
> V  [libjvm.so+0x91a5c3]  signalHandler(int, siginfo*, void*)+0x43
> C  [libc.so.6+0x326a0]
> C  0x0000000000000045
> j  java.net.URLClassLoader$1.run()Ljava/lang/Object;+1
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0x68e746]  JavaCalls::call_helper(JavaValue*, methodHandle*,
> JavaCallArguments*, Thread*)+0x1056
> V  [libjvm.so+0x7275bc]  JVM_DoPrivileged+0x27c
> j
>  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0
> j
>  java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13
> J 327 C1
> java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class; (122
> bytes) @ 0x000000000663a8e4 [0x0000000006639f80+0x964]
> j
>  sun.misc.Launcher$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+81
> j  java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0x68e746]  JavaCalls::call_helper(JavaValue*, methodHandle*,
> JavaCallArguments*, Thread*)+0x1056
> V  [libjvm.so+0x68ec51]  JavaCalls::call_virtual(JavaValue*, KlassHandle,
> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x321
> V  [libjvm.so+0x68f0a6]  JavaCalls::call_virtual(JavaValue*, Handle,
> KlassHandle, Symbol*, Symbol*, Handle, Thread*)+0x56
> V  [libjvm.so+0xa349a0]  SystemDictionary::load_instance_class(Symbol*,
> Handle, Thread*)+0x3f0
> V  [libjvm.so+0xa3388c]
>  SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle,
> Thread*)+0x7cc
> V  [libjvm.so+0xa34dc3]  SystemDictionary::resolve_or_fail(Symbol*,
> Handle, Handle, bool, Thread*)+0x33
> V  [libjvm.so+0x70cd6e]  find_class_from_class_loader(JNIEnv_*, Symbol*,
> unsigned char, Handle, Handle, unsigned char, Thread*)+0x3e
> V  [libjvm.so+0x7142b1]  JVM_FindClassFromCaller+0x2e1
> C  [libjava.so+0xe2d0]  Java_java_lang_Class_forName0+0x130
> j
>  java.lang.Class.forName0(Ljava/lang/String;ZLjava/lang/ClassLoader;Ljava/lang/Class;)Ljava/lang/Class;+0
> j
>  java.lang.Class.forName(Ljava/lang/String;ZLjava/lang/ClassLoader;)Ljava/lang/Class;+49
> j
>  com.sun.beans.finder.ClassFinder.findClass(Ljava/lang/String;Ljava/lang/ClassLoader;)Ljava/lang/Class;+11
> j
>  com.sun.beans.finder.InstanceFinder.instantiate(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Object;+13
> j
>  com.sun.beans.finder.InstanceFinder.find(Ljava/lang/Class;)Ljava/lang/Object;+34
> j
>  java.beans.Introspector.findExplicitBeanInfo(Ljava/lang/Class;)Ljava/beans/BeanInfo;+7
> j  java.beans.Introspector.<init>(Ljava/lang/Class;Ljava/lang/Class;I)V+121
> j
>  java.beans.Introspector.getBeanInfo(Ljava/lang/Class;)Ljava/beans/BeanInfo;+60
> j
>  java.beans.Introspector.getBeanInfo(Ljava/lang/Class;Ljava/lang/Class;I)Ljava/beans/BeanInfo;+10
> j  java.beans.Introspector.<init>(Ljava/lang/Class;Ljava/lang/Class;I)V+157
> j
>  java.beans.Introspector.getBeanInfo(Ljava/lang/Class;)Ljava/beans/BeanInfo;+60
> j
>  java.beans.Introspector.getBeanInfo(Ljava/lang/Class;Ljava/lang/Class;I)Ljava/beans/BeanInfo;+10
> j  java.beans.Introspector.<init>(Ljava/lang/Class;Ljava/lang/Class;I)V+157
> j
>  java.beans.Introspector.getBeanInfo(Ljava/lang/Class;)Ljava/beans/BeanInfo;+60
> j  org.apache.log4j.config.PropertySetter.introspect()V+7
> j
>  org.apache.log4j.config.PropertySetter.getPropertyDescriptor(Ljava/lang/String;)Ljava/beans/PropertyDescriptor;+8
> j
>  org.apache.log4j.config.PropertySetter.setProperties(Ljava/util/Properties;Ljava/lang/String;)V+113
> j
>  org.apache.log4j.config.PropertySetter.setProperties(Ljava/lang/Object;Ljava/util/Properties;Ljava/lang/String;)V+10
> j
>  org.apache.log4j.PropertyConfigurator.parseAppender(Ljava/util/Properties;Ljava/lang/String;)Lorg/apache/log4j/Appender;+694
> j
>  org.apache.log4j.PropertyConfigurator.parseCategory(Ljava/util/Properties;Lorg/apache/log4j/Logger;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)V+280
> j
>  org.apache.log4j.PropertyConfigurator.configureRootCategory(Ljava/util/Properties;Lorg/apache/log4j/spi/LoggerRepository;)V+63
> j
>  org.apache.log4j.PropertyConfigurator.doConfigure(Ljava/util/Properties;Lorg/apache/log4j/spi/LoggerRepository;)V+134
> j
>  org.apache.log4j.PropertyConfigurator.doConfigure(Ljava/net/URL;Lorg/apache/log4j/spi/LoggerRepository;)V+246
> j
>  org.apache.log4j.helpers.OptionConverter.selectAndConfigure(Ljava/net/URL;Ljava/lang/String;Lorg/apache/log4j/spi/LoggerRepository;)V+129
> j  org.apache.log4j.LogManager.<clinit>()V+156
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0x68e746]  JavaCalls::call_helper(JavaValue*, methodHandle*,
> JavaCallArguments*, Thread*)+0x1056
> V  [libjvm.so+0x640807]
>  InstanceKlass::call_class_initializer_impl(instanceKlassHandle,
> Thread*)+0xd7
> V  [libjvm.so+0x642cfc]
>  InstanceKlass::initialize_impl(instanceKlassHandle, Thread*)+0x1ac
> V  [libjvm.so+0x6430c1]  InstanceKlass::initialize(Thread*)+0x41
> V  [libjvm.so+0x7f7df6]  LinkResolver::resolve_static_call(CallInfo&,
> KlassHandle&, Symbol*, Symbol*, KlassHandle, bool, bool, Thread*)+0x246
> V  [libjvm.so+0x7f807f]  LinkResolver::resolve_invokestatic(CallInfo&,
> constantPoolHandle, int, Thread*)+0x23f
> V  [libjvm.so+0x7f9131]  LinkResolver::resolve_invoke(CallInfo&, Handle,
> constantPoolHandle, int, Bytecodes::Code, Thread*)+0x4f1
> V  [libjvm.so+0x687cc2]  InterpreterRuntime::resolve_invoke(JavaThread*,
> Bytecodes::Code)+0x1b2
> j
>  org.apache.log4j.Logger.getLogger(Ljava/lang/String;)Lorg/apache/log4j/Logger;+1
> j
>  org.apache.commons.logging.impl.Log4JLogger.getLogger()Lorg/apache/log4j/Logger;+27
> j
>  org.apache.commons.logging.impl.Log4JLogger.<init>(Ljava/lang/String;)V+16
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0x68e746]  JavaCalls::call_helper(JavaValue*, methodHandle*,
> JavaCallArguments*, Thread*)+0x1056
> V  [libjvm.so+0x995797]  Reflection::invoke(instanceKlassHandle,
> methodHandle, Handle, bool, objArrayHandle, BasicType, objArrayHandle,
> bool, Thread*)+0x5d7
> V  [libjvm.so+0x996413]  Reflection::invoke_constructor(oopDesc*,
> objArrayHandle, Thread*)+0x313
> V  [libjvm.so+0x71cf5a]  JVM_NewInstanceFromConstructor+0x10a
> j
>  sun.reflect.NativeConstructorAccessorImpl.newInstance0(Ljava/lang/reflect/Constructor;[Ljava/lang/Object;)Ljava/lang/Object;+0
> j
>  sun.reflect.NativeConstructorAccessorImpl.newInstance([Ljava/lang/Object;)Ljava/lang/Object;+85
> j
>  sun.reflect.DelegatingConstructorAccessorImpl.newInstance([Ljava/lang/Object;)Ljava/lang/Object;+5
> j
>  java.lang.reflect.Constructor.newInstance([Ljava/lang/Object;)Ljava/lang/Object;+79
> j
>  org.apache.commons.logging.impl.LogFactoryImpl.createLogFromClass(Ljava/lang/String;Ljava/lang/String;Z)Lorg/apache/commons/logging/Log;+397
> j
>  org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(Ljava/lang/String;)Lorg/apache/commons/logging/Log;+187
> j
>  org.apache.commons.logging.impl.LogFactoryImpl.newInstance(Ljava/lang/String;)Lorg/apache/commons/logging/Log;+9
> j
>  org.apache.commons.logging.impl.LogFactoryImpl.getInstance(Ljava/lang/String;)Lorg/apache/commons/logging/Log;+18
> j
>  org.apache.commons.logging.impl.LogFactoryImpl.getInstance(Ljava/lang/Class;)Lorg/apache/commons/logging/Log;+5
> j
>  org.apache.commons.logging.LogFactory.getLog(Ljava/lang/Class;)Lorg/apache/commons/logging/Log;+4
> j  org.apache.hadoop.fs.FileSystem.<clinit>()V+3
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0x68e746]  JavaCalls::call_helper(JavaValue*, methodHandle*,
> JavaCallArguments*, Thread*)+0x1056
> V  [libjvm.so+0x640807]
>  InstanceKlass::call_class_initializer_impl(instanceKlassHandle,
> Thread*)+0xd7
> V  [libjvm.so+0x642cfc]
>  InstanceKlass::initialize_impl(instanceKlassHandle, Thread*)+0x1ac
> V  [libjvm.so+0x6430c1]  InstanceKlass::initialize(Thread*)+0x41
> V  [libjvm.so+0x70cdab]  find_class_from_class_loader(JNIEnv_*, Symbol*,
> unsigned char, Handle, Handle, unsigned char, Thread*)+0x7b
> V  [libjvm.so+0x6e4874]  jni_FindClass+0x424
> C  [libhdfs.so.0.0.0+0x364c]  globalClassReference+0xac
> ----
>
> Any pointers on how I can make this work?
>

Re: [Valgrind-users] Building from sources and "warning: switch -mcpu=cortex-a8 conflicts with -march=armv8-a+crc switch"

[Rob B. <ro...@da...>]

Generic Autotools Advice:

 1)  modern autotools (last 10 years or more) support setting variables
like (CXX) on the command line, after any arguments.  This is superior to
using the environment because the settings get stored in the logs, which
makes for easier debugging.  Something like:  ../goodie-source/configure
—prefix=/opt/goodies CC=“g++ -m64” CFLAGS=“-Wall”

 2) Build outside the source tree.  Unless the build is broken this will
work and keep you from mixing build products with sources.


If you want to do that, and pastebin config.log & config.status I’d be
happy to look.

Another thing you can try is to define the compilers as:

CXX=“g++ -march=pentium4 -mtune=i686”  (but of course with your ARMish
values instead)

This will keep things consistent if the CXXFLAGS aren’t added in all the
places where they’re needed.

On 8/2/16, 9:42 AM, "Jeffrey Walton" <nol...@gm...> wrote:

>On Tue, Aug 2, 2016 at 10:28 AM, Rob Boehne <ro...@da...> wrote:
>> If so, read config.guess - it will tell you how to contribute your
>> architecture to that project.
>> Also, you should be able to work around it by specifying the
>>architecture
>> instead of letting it guess.
>> Look up the ‹build and ‹target flags to configure.
>
>Thanks. Here's what I see:
>
>$ ./configure --help
>`configure' configures Valgrind 3.12.0.SVN to adapt to many kinds of
>systems.
>...
>
>Some influential environment variables:
>  CC          C compiler command
>  CXX         C++ compiler command
>  CFLAGS      C compiler flags
>  CXXFLAGS    C++ compiler flags
>...
>
>Use these variables to override the choices made by `configure' or to help
>it to find libraries and programs with nonstandard names/locations.
>...
>
>I also tried --target=armv8-a with no joy (even though its a native
>compile).
>
>The flags seem to be ignored by Autotools.
>
>Jeff

Re: [Valgrind-users] Building from sources and "warning: switch -mcpu=cortex-a8 conflicts with -march=armv8-a+crc switch"

[Julian S. <js...@ac...>]

> I'm not sure what I should do at the moment. Is this a problem that
> needs attention? Or am I OK to make install?

Remove the custom CFLAGS and let the build system do its own thing.

The binaries it creates do hardware capability autodetection at startup,
so all the build system really cares about is whether you're building for
arm32 or arm64.  The precise variant is irrelevant at build time.

J

Re: [Valgrind-users] Building from sources and "warning: switch -mcpu=cortex-a8 conflicts with -march=armv8-a+crc switch"

[Rob B. <ro...@da...>]

If so, read config.guess - it will tell you how to contribute your
architecture to that project.
Also, you should be able to work around it by specifying the architecture
instead of letting it guess.
Look up the ‹build and ‹target flags to configure.

On 8/1/16, 4:51 PM, "Jeffrey Walton" <nol...@gm...> wrote:

>On Mon, Aug 1, 2016 at 5:35 PM, Jeffrey Walton <nol...@gm...> wrote:
>> Hi Everyone,
>>
>> I'm testing a Raspberry Pi 3. Its ARMv8 using Boradcom A53-based SoC.
>> The SoC is lower end, so its got ASIMD and CRC32, but it lacks PMULL
>> and other Crypto extensions. The gadget ships with a 32-bit Raspbian
>> OS, so its effectively in 32-bit mode.
>>
>> My shell exports CFLAGS and CXXFLAGS, which are tuned for Aarch32:
>>
>> $  echo $CXXFLAGS
>> -DNDEBUG -g2 -O3 -march=armv8-a+crc -mtune=cortex-a53
>> -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
>> $ echo $CFLAGS
>> -DNDEBUG -g2 -O3 -march=armv8-a+crc -mtune=cortex-a53
>> -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
>>
>> Valgrind appears to have configured successfully:
>>http://pastebin.com/nrenFK1f .
>>
>> Make'ing results in the following.
>>
>> I'm not sure what I should do at the moment. Is this a problem that
>> needs attention? Or am I OK to make install?
>
>For what its worth, it looks like a problem with Autotools:
>
>$ ./config.guess
>armv7l-unknown-linux-gnueabihf
>
>Jeff
>
>--------------------------------------------------------------------------
>----
>_______________________________________________
>Valgrind-users mailing list
>Val...@li...
>https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Building from sources and "warning: switch -mcpu=cortex-a8 conflicts with -march=armv8-a+crc switch"

[Jeffrey W. <nol...@gm...>]

On Tue, Aug 2, 2016 at 10:28 AM, Rob Boehne <ro...@da...> wrote:
> If so, read config.guess - it will tell you how to contribute your
> architecture to that project.
> Also, you should be able to work around it by specifying the architecture
> instead of letting it guess.
> Look up the ‹build and ‹target flags to configure.

Thanks. Here's what I see:

$ ./configure --help
`configure' configures Valgrind 3.12.0.SVN to adapt to many kinds of systems.
...

Some influential environment variables:
  CC          C compiler command
  CXX         C++ compiler command
  CFLAGS      C compiler flags
  CXXFLAGS    C++ compiler flags
...

Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.
...

I also tried --target=armv8-a with no joy (even though its a native compile).

The flags seem to be ignored by Autotools.

Jeff

Re: [Valgrind-users] trace function calls from individual objects in callgrind

[Josef W. <Jos...@gm...>]

Am 29.07.2016 um 13:03 schrieb Patrick Bos:
>> I can search for the patch and send it to you.
>
> If it's not too much trouble, that would be wonderful! Looking forward to receiving it. I'm not too concerned about scaling, so anything you have would be great.

Attached. It should apply to current SVN version (probably also last VG 
release).

Note that this patch only uses "Int v = sp[sep->parnum];" (search for it 
in the patch)
to access the parnum'th (4-byte) integer parameter of a function, with 
sp being the
stack pointer at function entry.

This only works with x86 (32bit). Look up the C ABI calling conventions 
to see how to
get at parameters for amd64. amd64 uses registers to pass 1st 6 integer 
values.
Register values can be found in the architecture state struct 
"ThreadArchState arch",
which can be accessed via "VG_(threads)[tid].arch" in tool functions, 
tid is the
current thread ID. For example, for amd64 and register RDI, which holds 
the first
integer parameter (I would assume this to map to the "this" pointer with 
C++), this
should be
    VG_(threads)[tid].arch.vex.guest_RDI

This should make it very easy to accomplish what you want.

Cheers,
Josef

Re: [Valgrind-users] Building from sources and "warning: switch -mcpu=cortex-a8 conflicts with -march=armv8-a+crc switch"

[Jeffrey W. <nol...@gm...>]

On Mon, Aug 1, 2016 at 5:35 PM, Jeffrey Walton <nol...@gm...> wrote:
> Hi Everyone,
>
> I'm testing a Raspberry Pi 3. Its ARMv8 using Boradcom A53-based SoC.
> The SoC is lower end, so its got ASIMD and CRC32, but it lacks PMULL
> and other Crypto extensions. The gadget ships with a 32-bit Raspbian
> OS, so its effectively in 32-bit mode.
>
> My shell exports CFLAGS and CXXFLAGS, which are tuned for Aarch32:
>
> $  echo $CXXFLAGS
> -DNDEBUG -g2 -O3 -march=armv8-a+crc -mtune=cortex-a53
> -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
> $ echo $CFLAGS
> -DNDEBUG -g2 -O3 -march=armv8-a+crc -mtune=cortex-a53
> -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
>
> Valgrind appears to have configured successfully: http://pastebin.com/nrenFK1f .
>
> Make'ing results in the following.
>
> I'm not sure what I should do at the moment. Is this a problem that
> needs attention? Or am I OK to make install?

For what its worth, it looks like a problem with Autotools:

$ ./config.guess
armv7l-unknown-linux-gnueabihf

Jeff

[Valgrind-users] Building from sources and "warning: switch -mcpu=cortex-a8 conflicts with -march=armv8-a+crc switch"

[Jeffrey W. <nol...@gm...>]

Hi Everyone,

I'm testing a Raspberry Pi 3. Its ARMv8 using Boradcom A53-based SoC.
The SoC is lower end, so its got ASIMD and CRC32, but it lacks PMULL
and other Crypto extensions. The gadget ships with a 32-bit Raspbian
OS, so its effectively in 32-bit mode.

My shell exports CFLAGS and CXXFLAGS, which are tuned for Aarch32:

$  echo $CXXFLAGS
-DNDEBUG -g2 -O3 -march=armv8-a+crc -mtune=cortex-a53
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
$ echo $CFLAGS
-DNDEBUG -g2 -O3 -march=armv8-a+crc -mtune=cortex-a53
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard

Valgrind appears to have configured successfully: http://pastebin.com/nrenFK1f .

Make'ing results in the following.

I'm not sure what I should do at the moment. Is this a problem that
needs attention? Or am I OK to make install?

Thanks in advance.

**********

$ make
...
Making all in VEX
make[2]: Entering directory '/home/valgrind-3.11.0/VEX'
make  all-am
make[3]: Entering directory '/home/valgrind-3.11.0/VEX'
gcc -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../VEX/pub
-I../VEX/pub -DVGA_arm=1 -DVGO_linux=1 -DVGP_arm_linux=1
-DVGPV_arm_linux_vanilla=1 -Ipriv  -O2 -g -std=gnu99 -Wall
-Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes
-Wmissing-declarations -Wcast-qual -Wwrite-strings -Wempty-body
-Wformat -Wformat-security -Wignored-qualifiers
-Wmissing-parameter-type -Wold-style-declaration -fno-stack-protector
-fno-strict-aliasing -fno-builtin  -marm -mcpu=cortex-a8
-Wbad-function-cast -fstrict-aliasing -DNDEBUG -g2 -O3
-march=armv8-a+crc -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8
-mfloat-abi=hard -MT priv/libvex_arm_linux_a-main_globals.o -MD -MP
-MF priv/.deps/libvex_arm_linux_a-main_globals.Tpo -c -o
priv/libvex_arm_linux_a-main_globals.o `test -f 'priv/main_globals.c'
|| echo './'`priv/main_globals.c
priv/main_globals.c:1:0: warning: switch -mcpu=cortex-a8 conflicts
with -march=armv8-a+crc switch

 ^
...

Re: [Valgrind-users] Using Valgrind (helgrind/drd) to detect data races in Inter-Process Communications

[Alexander P. <gl...@go...>]

On Mon, Aug 1, 2016 at 1:45 PM, CJ YAMIGOS <cjy...@gm...> wrote:
> Hi everyone,
>
> I started recently using Valgrind (Helgrind and DRD), and I mainly want to
> detect data races in my program composed of two processes that communicate
> via a POSIX shared memory object. I found quite a lot of examples showing
> how Valgrind can detect data races in multithreaded applications (where all
> threads belong to the same process). However, this is not the case I am
> interested in.
>
> Basically, my program is composed of two processes, namely Server and
> Client. The Server is responsible of creating a named shared memory object
> with "shm_open", sets the size with "ftruncate" and maps the shared memory
> object to Server's virtual address space with "mmap". On the other hand, the
> Client opens/gets this shared memory object with "shm_open" and then maps it
> to Client's virtual address space with "mmap". Both Server and Client
> processes have Read & Write access to this shared memory object. There is a
> nice example in:
> https://www.softprayog.in/programming/interprocess-communication-using-posix-shared-memory-in-linux;
> the main difference between this example and my program is I am not using
> any semaphore (i.e., any kind of protection mechanism neither) at all.
>
> When running my program with Valgrind (v 3.7.0) in Linux, I am getting no
> warnings about potential data races in my program. In fact, when both Server
> and Client processes are running in parallel (i.e., each in a different
> processor core) and there is not a mechanism protecting the access to the
> shared memory object (e.g., a data structure), I expect somehow to see some
> data races warnings.
Neither Helgrind nor DRD are able to detect data races between shared
memory pages.
This is hard, because the tool needs to track the happens-before
relation between threads belonging to different processes.
Because Valgrind itself is single-threaded (i.e. it serializes the
threads of the inspected program), synchronizing the states of two
Valgrind processes that have just a common shared memory page is going
to be quite painful.

> So, I wonder whether I am missing something here or Valgrind just does not
> support data race detection in Inter-Process Communications (like the one I
> have in my program). Many thanks in advance for your helps!
>
> Best,
>
> Carlos H.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

[Valgrind-users] Using Valgrind (helgrind/drd) to detect data races in Inter-Process Communications

[CJ Y. <cjy...@gm...>]

Hi everyone,

I started recently using Valgrind (Helgrind and DRD), and I mainly want to
detect data races in my program composed of two processes that communicate
via a POSIX shared memory object. I found quite a lot of examples showing
how Valgrind can detect data races in multithreaded applications (where all
threads belong to the same process). However, this is not the case I am
interested in.

Basically, my program is composed of two processes, namely Server and
Client. The Server is responsible of creating a named shared memory object
with "shm_open", sets the size with "ftruncate" and maps the shared memory
object to Server's virtual address space with "mmap". On the other hand,
the Client opens/gets this shared memory object with "shm_open" and then
maps it to Client's virtual address space with "mmap". Both Server and
Client processes have Read & Write access to this shared memory object.
There is a nice example in:
https://www.softprayog.in/programming/interprocess-communication-using-posix-shared-memory-in-linux;
the main difference between this example and my program is I am not using
any semaphore (i.e., any kind of protection mechanism neither) at all.

When running my program with Valgrind (v 3.7.0) in Linux, I am getting no
warnings about potential data races in my program. In fact, when both
Server and Client processes are running in parallel (i.e., each in a
different processor core) and there is not a mechanism protecting the
access to the shared memory object (e.g., a data structure), I expect
somehow to see some data races warnings.
So, I wonder whether I am missing something here or Valgrind just does not
support data race detection in Inter-Process Communications (like the one I
have in my program). Many thanks in advance for your helps!

Best,

Carlos H.

Re: [Valgrind-users] trace function calls from individual objects in callgrind

[Patrick B. <p....@es...>]

Op 29 jul. 2016, om 10:41 heeft Josef Weidendorfer <Jos...@gm...> het volgende geschreven:

> Am 07.07.2016 um 14:59 schrieb E. G. Patrick Bos:
>> I'm using callgrind to analyse a c++ program (roofit) which builds a
>> large tree of many interdependent objects of a few classes. Ideally, I
>> would like to track not only the function calls, but also from (and to)
>> which object they are called, so for instance including the address of
>> the passed `this` pointer.
>> 
>> Is such a thing possible and/or has it been tried before? And if not,
>> would it be difficult to implement?
> 
> Not really.
> 
> When a new function is called, you can make up a new fn_node struct
> whose name can embed the address of the 'this' pointer. However, you
> would get a separate function called for every object. Not sure this
> scales well.
> 
> Quite some time ago I had a patch doing similar stuff, but looking
> up the stack or registers for parameter values depends on the calling
> convention/ABI which is architecture/OS specific. I only did this for
> amd64, and it was working nice, but it never went in.
> 
> I can search for the patch and send it to you.

If it's not too much trouble, that would be wonderful! Looking forward to receiving it. I'm not too concerned about scaling, so anything you have would be great.

Cheers,
Patrick

> 
> Josef
> 
> 
>> The alternative would be to build some kind of accounting system into
>> the base classes in my code itself, but if it's easy in valgrind, that
>> would be far preferable, since others can then also use it and I
>> wouldn't have to mess up my own code :)
>> 
>> Without having any knowledge of the valgrind source, I would imagine
>> that it could be implemented similarly or as a generalization of the
>> seperate-callers options.
>> 
>> Cheers,
>> Patrick
>> 
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] trace function calls from individual objects in callgrind

[Josef W. <Jos...@gm...>]

Am 07.07.2016 um 14:59 schrieb E. G. Patrick Bos:
> I'm using callgrind to analyse a c++ program (roofit) which builds a
> large tree of many interdependent objects of a few classes. Ideally, I
> would like to track not only the function calls, but also from (and to)
> which object they are called, so for instance including the address of
> the passed `this` pointer.
>
> Is such a thing possible and/or has it been tried before? And if not,
> would it be difficult to implement?

Not really.

When a new function is called, you can make up a new fn_node struct
whose name can embed the address of the 'this' pointer. However, you
would get a separate function called for every object. Not sure this
scales well.

Quite some time ago I had a patch doing similar stuff, but looking
up the stack or registers for parameter values depends on the calling
convention/ABI which is architecture/OS specific. I only did this for
amd64, and it was working nice, but it never went in.

I can search for the patch and send it to you.

Josef


> The alternative would be to build some kind of accounting system into
> the base classes in my code itself, but if it's easy in valgrind, that
> would be far preferable, since others can then also use it and I
> wouldn't have to mess up my own code :)
>
> Without having any knowledge of the valgrind source, I would imagine
> that it could be implemented similarly or as a generalization of the
> seperate-callers options.
>
> Cheers,
> Patrick
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Sparc port status

[Ivo R. <iv...@iv...>]

2016-07-26 15:53 GMT+02:00 Rob Boehne <ro...@da...>:

> As I’ve found valgrind quite useful on x86/Linux for many years, I was
> very excited to see a project to support Solaris Sparc, and I’d love to
> have this available, as I maintain a large, old codebase with a pool
> allocator (Electric Fence doesn’t deal well with it, and isn’t useful for
> leak checking, or the other things valgrind can do).
>
> Where can I find information on how to build, what versions of Solaris are
> supported on what hardware, and what works?
>
> I’m happy to contribute to the effort as well.
>
>
Hello Robert,

Thank you for your interest in sparcv9/Solaris port.
The port currently lives here: https://bitbucket.org/iraisr/valgrind-solaris
and is also linked from http://valgrind.org/info/platforms.html
It is under active development and still far from complete.

As with x86+amd64/Solaris, we aim at Solaris 11 and illumos (or higher).
We have no intention to spend effort on Solaris 10 as this OS is now over
10 years old and will become unsupported soon.

With sparcv9/Solaris, we obviously target 64-bit programs. Area of 32-bit
programs with sparcv8+ is quite murky.
We might add sparv8+ later, when sparcv9 is largely finished.
We aim to support all sparcv9 hardware, that is starting from T1 up to
currently T7, ... and their M-series equivalents.
Currently we are implementing Oracle Sparc Architecture 2015 [1] features
(which correspond to T7/M7).

For instructions how to build please follow README.solaris and generic
README.
We actively develop on Solaris 12, and Solaris 11 should also work ok.

Any contributions are welcome. We maintain a list of issues:
https://bitbucket.org/iraisr/valgrind-solaris/issues?status=new&status=open
and you are free to take any. The main development work is now focused on
fixing last few failing tests
under none/tests (only 10 failing out of 474 total) and then we will focus
on enabling memcheck.

Happy Valgrind'ing!
I.

[1]
http://www.oracle.com/technetwork/server-storage/sun-sparc-enterprise/documentation/sparc-servers-documentation-163529.html

Re: [Valgrind-users] Difference in Behaviour between 3.10 and 3.11

[<sim...@do...>]

Hi Julian

Thanks for the pointer - I managed to coax Yocto into not stripping the libraries in my filesystem and then everything worked as expected.

Regards and Thanks
Simon 

-----Julian Seward <js...@ac...> wrote: -----
To: sim...@do...
From: Julian Seward <js...@ac...>
Date: 07/22/2016 11:27AM
Cc: val...@li...
Subject: Re: [Valgrind-users] Difference in Behaviour between 3.10 and 3.11

> The output from readelf is below, as you'll see there is a .eh_frame section.
> Is there any dependency on how the Valgrind applications and libraries are compiled?

Well yes, but in this case it can't even unwind out of a library that is
provided as part of Valgrind itself.  So I don't think that is relevant.

Are you absolutely sure that the vgpreload_memcheck-arm-linux.so that runs
on your target hasn't been stripped on the way there?  And also that the
compile flags used to build Valgrind haven't been changed from their
defaults?

J