Version: 3.4.1 (using KDE 3.5.10) Compiler: GCC 4.1.2 OS: Linux Installed from: Compiled From Sources Running Java apps under cachegrind produces a crash, with the following output: --cut preamble-- vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xAE 0x4 0x24 0x49 ==18442== valgrind: Unrecognised instruction at address 0x54ba986. ==18442== Your program just tried to execute an instruction that Valgrind ==18442== did not recognise. There are two possible reasons for this. ==18442== 1. Your program has a bug and erroneously jumped to a non-code ==18442== location. If you are running Memcheck and you just saw a ==18442== warning about a bad jump, it's probably your program's fault. ==18442== 2. The instruction is legitimate but Valgrind doesn't handle it, ==18442== i.e. it's Valgrind's fault. If you think this is the case or ==18442== you are not sure, please let us know and we'll try to fix it. ==18442== Either way, Valgrind will now raise a SIGILL signal which will ==18442== probably kill your program. # # An unexpected error has been detected by Java Runtime Environment: # # SIGILL (0x4) at pc=0x00000000054ba986, pid=18442, tid=81611072 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b22 mixed mode linux-amd64) # Problematic frame: # v ~SafepointBlob # # An error report file with more information is saved as: # /home/ao/eclipse/java-ws/JavaStructures/build/hs_err_pid18442.log --18442-- REDIR: 0xffffffffff600400 (???) redirected to 0x3801e7ad (vgPlain_amd64_linux_REDIR_FOR_vtime) # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ==18442== ==18442== Process terminating with default action of signal 6 (SIGABRT) ==18442== at 0x3DE4030215: raise (in /lib64/libc-2.5.so) ==18442== by 0x3DE4031CBF: abort (in /lib64/libc-2.5.so) ==18442== by 0x485B376: os::abort(bool) (in /usr/java/jdk1.6.0_06/jre/lib/amd64/server/libjvm.so) ==18442== by 0x49B9B3C: VMError::report_and_die() (in /usr/java/jdk1.6.0_06/jre/lib/amd64/server/libjvm.so) ==18442== by 0x486068B: JVM_handle_linux_signal (in /usr/java/jdk1.6.0_06/jre/lib/amd64/server/libjvm.so) ==18442== by 0x485D4DD: signalHandler(int, siginfo*, void*) (in /usr/java/jdk1.6.0_06/jre/lib/amd64/server/libjvm.so) ==18442== by 0x3DE4C0E4BF: (within /lib64/libpthread-2.5.so) ==18442== by 0x54BA985: ??? ==18442== by 0x5489008: ??? ==18442== by 0x5489008: ??? ==18442== by 0x548963B: ??? ==18442== by 0x548904D: ??? output of uname: Linux cortex.ecs.soton.ac.uk 2.6.29 #1 SMP Thu Mar 26 12:27:36 GMT 2009 x86_64 x86_64 x86_64 GNU/Linux output of cat /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 244 stepping : 10 cpu MHz : 1792.798 cache size : 1024 KB 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 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow rep_good bogomips : 3585.59 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 244 stepping : 10 cpu MHz : 1792.798 cache size : 1024 KB 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 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow rep_good bogomips : 3585.65 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp
That is an FXSAVE instruction with the REX.W prefix bit set which we don't seem to handle at the moment - we do handle normal FXSAVE instructions. There is a comment in the instruction decoder which says: /* 0F AE /0 = FXSAVE m512 -- write x87 and SSE state to memory. Note that REX.W 0F AE /0 writes a slightly different format and we don't handle that here. */ What it doesn't say is that we don't handle it anywhere else either ;-)
I confirm this issue. I run valgrind-3.4.1, and often get vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xAE 0x4 0x24 0x49 when running a more complicated java program (with jni). Running x86_64 with fedora 11 on a Core2Duo laptop. Has this been resolved in later versions? Should I upgrade?
Still happens on SVN r11051. To reproduce run firefox under valgrind and visit this page with an applet: "http://java.com/en/download/help/testvm.xml". Or run jEdit. vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xAE 0x4 0x24 0x49 ==14235== valgrind: Unrecognised instruction at address 0x22eb6c46.
As of svn11120 this still is an issue. I am attempting to add in the bits to VEX/priv/guest_amd64_toIR.c to get it to work , but I can not find any documentation on the internals of Valgrind and how it handles IR Decodes. Any place you could point me to do this would be most helpful
*** Bug 241951 has been marked as a duplicate of this bug. ***
Hi, Is there a workaround? Ashutosh ======================================= Ashutosh Singh ======================================= > From: tom@compton.nu > To: ashutoshvsingh@hotmail.com > Subject: [Bug 194402] vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xAE 0x4 0x24 0x49 > Date: Thu, 17 Jun 2010 09:43:16 +0200 > > https://bugs.kde.org/show_bug.cgi?id=194402 > > > Tom Hughes <tom@compton.nu> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |ashutoshvsingh@hotmail.com > > > > > --- Comment #5 from Tom Hughes <tom compton nu> 2010-06-17 09:42:42 --- > *** Bug 241951 has been marked as a duplicate of this bug. *** > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug.
(In reply to comment #4) > As of svn11120 this still is an issue. I am attempting to add in the bits to > VEX/priv/guest_amd64_toIR.c to get it to work , but I can not find any > documentation on the internals of Valgrind and how it handles IR Decodes. Any > place you could point me to do this would be most helpful Basically what you need to do is make a copy of the existing FXSAVE handling, and modify it. I think the check to identify the insn should be if (haveNo66noF2noF3(pfx) && sz == 8 && insn[0] == 0x0F && insn[1] == 0xAE && !epartIsReg(insn[2]) && gregOfRexRM(pfx,insn[2]) == 0) { This differs from the existing version in the "sz == 8" part, and guarantees that it will only match if a REX.W prefix has been seen. Then, you will need to make a corresponding clone of amd64g_dirtyhelper_FXSAVE which does the actual dirty work of producing the in-memory image. One hint is to write a good test program first. A good test program will tell you if your implementation is correct, and generally makes the problem much more stress-free. Again, the tree contains a test program memcheck/tests/amd64/fxsave-amd64.c for the existing FXSAVE implementation, so you could start by modifying that. The usual way these test programs work is that they must print exactly the same result when running natively and on Valgrind, and the above one is no exception. If someone wants to come up with a patch I'll be happy to give feedback on it.
Created attachment 49737 [details] patch proposal for fxsave handling
Hi, i'm far from being an expert but I'd like to hear your opinion on a simple modification to correct this bug. According to this : http://support.amd.com/us/Embedded_TechDocs/24593.pdf (p. 300) the only difference in 64-bit mode between FXSAVE and FXSAVE + REX.W bit set is that RIP and RDP are stored in a 'sel:offset' format when using 32bit operands. When looking at amd64g_dirtyhelper_FXSAVE, both of these are actually always set to '0' (l. 1545). So maybe one could simply change the test in guest_amd64_toIR to match both versions (and removing the 2 relevant asserts). I have tested this modification on a simple program (copy-paste from fxsave64-amd64.c and using "rex64/fxsave" instead of "fxsave" ) and it seems ok. What do you think ? (I've added a very simple patch which contains these modifcations)
Can anyone confirm that this patch gets rid of the JRE crash? Patch looks good, but I'd like some confirmation first that it solves the original problem.
(In reply to comment #10) > Can anyone confirm that this patch gets rid of the JRE crash? ping! I'd like to commit this _if_ someone can confirm it fixes the JRE crash.
Hi,I do not have the setup anymore to verify it.Ashutosh ======================================= Ashutosh Singh ======================================= > From: jseward@acm.org > To: ashutoshvsingh@hotmail.com > Subject: [Bug 194402] vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xAE 0x4 0x24 0x49 > Date: Tue, 28 Sep 2010 18:30:08 +0200 > > https://bugs.kde.org/show_bug.cgi?id=194402 > > > > > > --- Comment #11 from Julian Seward <jseward acm org> 2010-09-28 18:29:48 --- > (In reply to comment #10) > > Can anyone confirm that this patch gets rid of the JRE crash? > > ping! I'd like to commit this _if_ someone can confirm it fixes > the JRE crash. > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug.
I'm going to push this till after 3.6.0 unless anyone can confirm that this fixes the JRE problem.
My two cents: 1) I can reproduce the bug (unfortunately on a very large app only) 2) The proposed fix does *NOT* eliminate the problem: with the fix I can see the following assert: vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xAE 0xC 0x24 0x48 Note the last byte (was: 0x49) Do you plan to fix this as well? Thanks!
Here's an additional patch : it tries to implement the missing FXRSTOR feature for amd64 guests. Again, it's almost a copy-paste from the x86 code with a few minor modifications. It should address your issue (if I'm correct, the fourth byte going from 0x4 to 0xC means 'FXRSTOR' instead of 'FXSAVE'). Let us know if it works.
Created attachment 54029 [details] patch proposal for fxrstor handling
Yes! With these two patches my program passes the point where it failed previously.
I found this bug because I'm having the identical issue - running 64-bit JVM in valgrind. I applied the patches to the 3.6.0 source (my company firewall blocks svn access) and tried running it. Now the process simply hangs with no information.
Fixed, vex r2084. FXSAVE and FXRSTOR, both REX.W and non-REX.W variants, are now supported. Thanks all for the various patches and how-to-fix suggestions.
*** Bug 143323 has been marked as a duplicate of this bug. ***
*** Bug 149838 has been marked as a duplicate of this bug. ***