|
From: Keith M. <kei...@ch...> - 2005-12-13 04:42:18
Attachments:
stderr.txt
|
[basilisk: /code/kmange/sources]$ ~/bin/valgrind --tool=3Dmemcheck = --max-stackframe=3D2064864 --trace-children=3Dyes --smc-check=3Dall java = SGIInterface 2> junk.txt =3D=3D25496=3D=3D Memcheck, a memory error detector. =3D=3D25496=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian = Seward et al. =3D=3D25496=3D=3D Using LibVEX rev 1471, a library for dynamic binary = translation. =3D=3D25496=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks = LLP. =3D=3D25496=3D=3D Using valgrind-3.1.0, a dynamic binary instrumentation = framework. =3D=3D25496=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian = Seward et al. =3D=3D25496=3D=3D For more details, rerun with: -v =3D=3D25496=3D=3D =3D=3D25496=3D=3D Memcheck, a memory error detector. =3D=3D25496=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian = Seward et al. =3D=3D25496=3D=3D Using LibVEX rev 1471, a library for dynamic binary = translation. =3D=3D25496=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks = LLP. =3D=3D25496=3D=3D Using valgrind-3.1.0, a dynamic binary instrumentation = framework. =3D=3D25496=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian = Seward et al. =3D=3D25496=3D=3D For more details, rerun with: -v =3D=3D25496=3D=3D =3D=3D25496=3D=3D Warning: client switching stacks? SP change: = 0x7FEE04FF0 --> 0x7FEFFD1E0 =3D=3D25496=3D=3D to suppress, use: --max-stackframe=3D2064880 = or greater =3D=3D25496=3D=3D Warning: set address range perms: large range = 1073741824, a 0, v 0 vex amd64->IR: unhandled instruction bytes: 0xF 0xAE 0x3F 0x48 =3D=3D25496=3D=3D Your program just tried to execute an instruction that = Valgrind =3D=3D25496=3D=3D did not recognise. There are two possible reasons for = this. =3D=3D25496=3D=3D 1. Your program has a bug and erroneously jumped to a = non-code =3D=3D25496=3D=3D location. If you are running Memcheck and you just = saw a =3D=3D25496=3D=3D warning about a bad jump, it's probably your = program's fault. =3D=3D25496=3D=3D 2. The instruction is legitimate but Valgrind doesn't = handle it, =3D=3D25496=3D=3D i.e. it's Valgrind's fault. If you think this is = the case or =3D=3D25496=3D=3D you are not sure, please let us know. =3D=3D25496=3D=3D Either way, Valgrind will now raise a SIGILL signal = which will =3D=3D25496=3D=3D probably kill your program. =3D=3D25496=3D=3D Invalid read of size 8 =3D=3D25496=3D=3D at 0x463658E: frame::print_on_error(outputStream*, = char*, int, int) const (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x49295E0: VMError::report(outputStream*) (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x4929E2C: VMError::report_and_die() (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x484CFD6: JVM_handle_linux_signal (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x484AE1D: signalHandler(int, siginfo*, void*) = (in /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x3CE190C31F: (within = /lib64/tls/libpthread-2.3.4.so) =3D=3D25496=3D=3D by 0x4560EB2: AbstractAssembler::flush() (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x48B91EA: StubCodeMark::~StubCodeMark() (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x49343CA: = VM_Version_StubGenerator::generate_getPsrInfo() (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x49330DD: VM_Version::initialize() (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x49332D8: VM_Version_init() (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x466BBC6: init_globals() (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D Address 0x8 is not stack'd, malloc'd or (recently) = free'd =3D=3D25496=3D=3D =3D=3D25496=3D=3D Process terminating with default action of signal 11 = (SIGSEGV) =3D=3D25496=3D=3D Access not within mapped region at address 0x8 =3D=3D25496=3D=3D at 0x463658E: frame::print_on_error(outputStream*, = char*, int, int) const (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x49295E0: VMError::report(outputStream*) (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x4929E2C: VMError::report_and_die() (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x484CFD6: JVM_handle_linux_signal (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x484AE1D: signalHandler(int, siginfo*, void*) = (in /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x3CE190C31F: (within = /lib64/tls/libpthread-2.3.4.so) =3D=3D25496=3D=3D by 0x4560EB2: AbstractAssembler::flush() (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x48B91EA: StubCodeMark::~StubCodeMark() (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x49343CA: = VM_Version_StubGenerator::generate_getPsrInfo() (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x49330DD: VM_Version::initialize() (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x49332D8: VM_Version_init() (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D by 0x466BBC6: init_globals() (in = /usr/jdk1.5.0_03/jre/lib/amd64/server/libjvm.so) =3D=3D25496=3D=3D =3D=3D25496=3D=3D ERROR SUMMARY: 1 errors from 1 contexts (suppressed: = 24 from 5) =3D=3D25496=3D=3D malloc/free: in use at exit: 506,840 bytes in 376 = blocks. =3D=3D25496=3D=3D malloc/free: 471 allocs, 95 frees, 542,090 bytes = allocated. =3D=3D25496=3D=3D For counts of detected errors, rerun with: -v =3D=3D25496=3D=3D searching for pointers to 376 not-freed blocks. |
|
From: Tom H. <to...@co...> - 2005-12-13 07:25:39
|
In message <4enjqj$1o...@mx...>
"Keith Mange" <kei...@ch...> wrote:
> I'm attempting to valgrind a java application that uses our C++ libraries
> via a JNI interface. According to the valgrind website "in theory Valgrind
> can run any Java program just fine, even those that use JNI and are
> partially implemented in other languages like C and C++.". However, when I
> attempt it I get:
>
> vex amd64->IR: unhandled instruction bytes: 0xF 0xAE 0x3F 0x48
You've found an instruction that valgrind doesn't handle (clflush by
the looks of it). Please raise a bug for this.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-12-13 15:36:31
|
On Mon, 12 Dec 2005, Keith Mange wrote: > I'm a huge fan of valgrind so I'm really hoping to get this to work. I've > tried the smc-check and I've tried the max-stackframe. Is there anything > else I can try to get it to work or to shine more light on the problem? > > > ==25496== Warning: client switching stacks? SP change: 0x7FEE04FF0 --> 0x7FEFFD1E0 > ==25496== to suppress, use: --max-stackframe=2064880 or greater > ==25496== Warning: set address range perms: large range 1073741824, a 0, v 0 > > vex amd64->IR: unhandled instruction bytes: 0xF 0xAE 0x3F 0x48 > ==25496== Your program just tried to execute an instruction that Valgrind > ==25496== did not recognise. There are two possible reasons for this. > ==25496== 1. Your program has a bug and erroneously jumped to a non-code > ==25496== location. If you are running Memcheck and you just saw a > ==25496== warning about a bad jump, it's probably your program's fault. > ==25496== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==25496== i.e. it's Valgrind's fault. If you think this is the case or > ==25496== you are not sure, please let us know. > ==25496== Either way, Valgrind will now raise a SIGILL signal which will > ==25496== probably kill your program. As Tom said, it's an instruction Valgrind doesn't recognise. Is the above message unclear? I tried to make it as understandable as possible. Is it not clear that the long explanation is about the "unhandled instruction bytes" message? Nick |
|
From: Keith M. <kei...@ch...> - 2005-12-13 16:07:39
|
Tom, It was clear to me that the long explanation was about the "unhandled instruction bytes" message. However, given that I was using a java app and using a 64 bit AMD processor, neither of which I've ever tried before, I could have believed either reason 1 or reason 2 that was listed so I posted my question to the group. I am, however, confused by the two warnings before the "unhandled instruction bytes". I had actually thought the unhandled instruction bytes were just a result of those two warnings but it sounds like I am wrong. -Keith -----Original Message----- From: Nicholas Nethercote [mailto:nj...@cs...] Sent: Tuesday, December 13, 2005 9:36 AM To: Keith Mange Cc: val...@li... Subject: Re: [Valgrind-users] valgrind java app using C++ code via JNI gets vex amd64->IR: unhandled instruction bytes: 0xF 0xAE 0x3F 0x48 On Mon, 12 Dec 2005, Keith Mange wrote: > I'm a huge fan of valgrind so I'm really hoping to get this to work. I've > tried the smc-check and I've tried the max-stackframe. Is there anything > else I can try to get it to work or to shine more light on the problem? > > > ==25496== Warning: client switching stacks? SP change: 0x7FEE04FF0 --> 0x7FEFFD1E0 > ==25496== to suppress, use: --max-stackframe=2064880 or greater > ==25496== Warning: set address range perms: large range 1073741824, a 0, v 0 > > vex amd64->IR: unhandled instruction bytes: 0xF 0xAE 0x3F 0x48 > ==25496== Your program just tried to execute an instruction that Valgrind > ==25496== did not recognise. There are two possible reasons for this. > ==25496== 1. Your program has a bug and erroneously jumped to a non-code > ==25496== location. If you are running Memcheck and you just saw a > ==25496== warning about a bad jump, it's probably your program's fault. > ==25496== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==25496== i.e. it's Valgrind's fault. If you think this is the case or > ==25496== you are not sure, please let us know. > ==25496== Either way, Valgrind will now raise a SIGILL signal which will > ==25496== probably kill your program. As Tom said, it's an instruction Valgrind doesn't recognise. Is the above message unclear? I tried to make it as understandable as possible. Is it not clear that the long explanation is about the "unhandled instruction bytes" message? Nick |