Bug 194402 - vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xAE 0x4 0x24 0x49
Summary: vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xAE 0x4 0x24 0x49
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: 3.4.1
Platform: Compiled Sources Linux
: NOR crash with 21 votes (vote)
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
: 143323 241951 (view as bug list)
Depends on:
Blocks: 253451
  Show dependency treegraph
 
Reported: 2009-05-28 11:37 UTC by Alisdair Owens
Modified: 2011-08-11 10:07 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
patch proposal for fxsave handling (3.69 KB, patch)
2010-08-01 22:28 UTC, pepp
Details
patch proposal for fxrstor handling (8.58 KB, patch)
2010-12-03 12:10 UTC, pepp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alisdair Owens 2009-05-28 11:37:38 UTC
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
Comment 1 Tom Hughes 2009-05-28 12:04:48 UTC
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 ;-)
Comment 2 Michał Pomorski 2010-02-12 20:31:18 UTC
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?
Comment 3 David S 2010-02-21 00:06:41 UTC
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.
Comment 4 Dan 2010-04-29 23:12:00 UTC
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
Comment 5 Tom Hughes 2010-06-17 09:42:42 UTC
*** Bug 241951 has been marked as a duplicate of this bug. ***
Comment 6 Ashutosh 2010-06-18 01:02:54 UTC
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.
Comment 7 Julian Seward 2010-06-25 10:57:09 UTC
(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.
Comment 8 pepp 2010-08-01 22:28:13 UTC
Created attachment 49737 [details]
patch proposal for fxsave handling
Comment 9 pepp 2010-08-01 22:28:54 UTC
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)
Comment 10 Julian Seward 2010-09-01 18:43:43 UTC
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.
Comment 11 Julian Seward 2010-09-28 18:29:48 UTC
(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.
Comment 12 Ashutosh 2010-09-28 19:36:42 UTC
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.
Comment 13 Julian Seward 2010-10-04 22:23:59 UTC
I'm going to push this till after 3.6.0 unless anyone can confirm
that this fixes the JRE problem.
Comment 14 Konstantin Serebryany 2010-12-01 17:23:20 UTC
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!
Comment 15 pepp 2010-12-03 12:09:14 UTC
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.
Comment 16 pepp 2010-12-03 12:10:06 UTC
Created attachment 54029 [details]
patch proposal for fxrstor handling
Comment 17 Konstantin Serebryany 2010-12-06 11:56:37 UTC
Yes!
With these two patches my program passes the point where it failed previously.
Comment 18 james.ravn 2010-12-16 00:15:38 UTC
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.
Comment 19 Julian Seward 2011-01-21 19:11:18 UTC
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.
Comment 20 Tom Hughes 2011-08-11 09:34:09 UTC
*** Bug 143323 has been marked as a duplicate of this bug. ***
Comment 21 Tom Hughes 2011-08-11 10:07:16 UTC
*** Bug 149838 has been marked as a duplicate of this bug. ***