| Summary: | vex amd64->IR: unhandled instruction bytes: 0x66 0x48 0xF 0x38 0x17 0xC0 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andreas Girgensohn <andreasg123> | ||||
| Component: | valgrind | Assignee: | Jakub Jelinek <jakub> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 15 | CC: | aph, caolanm, dodji, jakub, mjw | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-08-07 16:25:20 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
f3 0f 6f 04 0f movdqu (%rdi,%rcx,1),%xmm0 f3 0f 6f 0c 0e movdqu (%rsi,%rcx,1),%xmm1 66 0f ef c1 pxor %xmm1,%xmm0 66 48 0f 38 17 c0 rex.W ptest %xmm0,%xmm0 75 5c jne ... 48 83 c1 10 add $0x10,%rcx 75 e4 jne ... rex.W ptest %xmm0, %xmm0 is nonsensical insn, apparently at least SandyBridge ignore the rex.W prefix there, but it doesn't make the instruction sensible. So the question is where that insn comes from - some shared library (which one?), or JIT generated code (then a bug would be in the JIT)? Andrew, any ideas where rex.W comes from here? If it is on purpose and has some explanation why the JVM or its libraries use such non-sensical insns, perhaps valgrind upstream might agree on supporting that. But generally they haven't been adding support for insns that don't make any sense at all. This is the code that does it:
void Assembler::ptest(XMMRegister dst, XMMRegister src) {
assert(VM_Version::supports_sse4_1(), "");
emit_byte(0x66);
int encode = prefixq_and_encode(dst->encoding(), src->encoding());
emit_byte(0x0F);
emit_byte(0x38);
emit_byte(0x17);
emit_byte(0xC0 | encode);
}
int Assembler::prefixq_and_encode(int dst_enc, int src_enc) {
if (dst_enc < 8) {
if (src_enc < 8) {
prefix(REX_W);
} else {
prefix(REX_WB);
src_enc -= 8;
}
} else {
if (src_enc < 8) {
prefix(REX_WR);
} else {
prefix(REX_WRB);
src_enc -= 8;
}
dst_enc -= 8;
}
return dst_enc << 3 | src_enc;
}
I'm not sure where the bug is, exactly.
In that case you don't want to use prefixq_and_encode, but instead a similar function which doesn't set the REX.W bit, just the other bits. i.e. you don't want to emit any prefix if both dst_enc and src_enc are < 8, otherwise REX_B, REX_R resp. REX_RB. From SSE4.{1,2} insns, REX.W is only meaningful for EXTRACTPS, PEXTRB, PEXTRQ, PEXTRW, PINSRQ, POPCNT and CRC32 instructions.
,
Isn't that what prefix_and_encode would do with byteinst=false?
There are several other methods in hotspot/src/cpu/x86/vm/assembler_x86.cpp that call prefixq_and_encode, too (e.g., movdqa, pcmpestri, addq). I suppose that calling them would produce code that would be equally unacceptable for valgrind.
int Assembler::prefix_and_encode(int dst_enc, int src_enc, bool byteinst) {
if (dst_enc < 8) {
if (src_enc >= 8) {
prefix(REX_B);
src_enc -= 8;
} else if (byteinst && src_enc >= 4) {
prefix(REX);
}
} else {
if (src_enc < 8) {
prefix(REX_R);
} else {
prefix(REX_RB);
src_enc -= 8;
}
dst_enc -= 8;
}
return dst_enc << 3 | src_enc;
}
Yeah, I guess for PTEST int encode = prefix_and_encode(dst_enc, src_enc, false); is the right call. For other instructions, it really depends on the instructions. Generally, if the instruction has some general register argument and it is 64-bit (%rax, %r10, etc.), REX.W should be used, if it is 32-bit (%eax, %r10d, etc.), REX.W shouldn't be used. And then a few instructions use REX.W for different purposes. PCMPESTRI/PCMPISTRI/PCMPESTRM/PCMPISTRM shouldn't use REX.W either, like PTEST, MOVDQA as well. If by ADDQ you mean general register addition in 64-bits, like addq $5, %rax or addq %rdx, %r10, then that instruction obviously needs the REX.W bit - otherwise it would be addl $5, %eax resp. addl %edx, %r10d. Always consult Intel or AMD ISA manuals, or try to assemble the instruction with various arguments in the assembler and objdump -d it. I submitted bug 727656 for java-1.6.0-openjdk listing instructions such as PTEST that do not take REX.W according to the Intel manual. While I agree that Java should emit correct instructions, I would prefer if valgrind were as permissive as the CPU and would just ignore a nonsensical prefix. Clearly the instructions run without causing an exception. This is an Intel Core 2 CPU and not Sandy Bridge. It supports SSE4.1 but not 4.2. Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |
Created attachment 512544 [details] Java error report Description of problem: When trying to launch Tomcat 6 from valgrind, it crashes during launch. Version-Release number of selected component (if applicable): valgrind-3.6.1-4.fc15.x86_64 tomcat6-6.0.30-6.fc15.noarch java-1.6.0-openjdk-1.6.0.0-58.1.10.2.fc15.x86_64 How reproducible: Always Steps to Reproduce: 1. Launch tomcat6 from valgrind (see options below) Actual results: valgrind raises a SIGILL signal Expected results: valgrind and tomcat would run Additional info: In /usr/sbin/tomcat6: JAVACMD="/usr/bin/valgrind --smc-check=all --trace-children=yes --log-file=/var/log/tomcat6/valgrind.out --leak-check=yes --tool=memcheck ${JAVACMD}" ---------------------------------------------------------------------- # # A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=0x000000000687b026, pid=32333, tid=100091648 # # JRE version: 6.0_22-b22 # Java VM: OpenJDK 64-Bit Server VM (20.0-b11 mixed mode linux-amd64 compressed oops) # Derivative: IcedTea6 1.10.2 # Distribution: Fedora release 15 (Lovelock), package fedora-58.1.10.2.fc15-x86_64 # Problematic frame: # J org.apache.tomcat.util.IntrospectionUtils.setProperty(Ljava/lang/Object;Ljava/lang/String;Ljava/lang/String;Z)Z # # An error report file with more information is saved as: # /usr/share/tomcat6/hs_err_pid32333.log Jul 12, 2011 6:04:41 PM org.apache.catalina.core.AprLifecycleListener init INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/share/tomcat6/lib # # A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=0x0000000006878690, pid=32510, tid=100091648 # # JRE version: 6.0_22-b22 # Java VM: OpenJDK 64-Bit Server VM (20.0-b11 mixed mode linux-amd64 compressed oops) # Derivative: IcedTea6 1.10.2 # Distribution: Fedora release 15 (Lovelock), package fedora-58.1.10.2.fc15-x86_64 # Problematic frame: # J org.apache.tomcat.util.IntrospectionUtils.setProperty(Ljava/lang/Object;Ljava/lang/String;Ljava/lang/String;Z)Z # # An error report file with more information is saved as: # /usr/share/tomcat6/hs_err_pid32510.log ---------------------------------------------------------------------- vex amd64->IR: unhandled instruction bytes: 0x66 0x48 0xF 0x38 0x17 0xC0 ==32510== valgrind: Unrecognised instruction at address 0x6878690. ==32510== Your program just tried to execute an instruction that Valgrind ==32510== did not recognise. There are two possible reasons for this. ==32510== 1. Your program has a bug and erroneously jumped to a non-code ==32510== location. If you are running Memcheck and you just saw a ==32510== warning about a bad jump, it's probably your program's fault. ==32510== 2. The instruction is legitimate but Valgrind doesn't handle it, ==32510== i.e. it's Valgrind's fault. If you think this is the case or ==32510== you are not sure, please let us know and we'll try to fix it. ==32510== Either way, Valgrind will now raise a SIGILL signal which will ==32510== probably kill your program. ==32510== Use of uninitialised value of size 8 ==32510== at 0x33AB046384: _itoa_word (_itoa.c:196) ==32510== by 0x33AB048E06: vfprintf (vfprintf.c:1567) ==32510== by 0x33AB06FDA1: vsnprintf (vsnprintf.c:120) ==32510== by 0x567B4D5: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x567B683: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x5670300: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x567A853: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x57AB67B: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x57AC208: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x5679E77: JVM_handle_linux_signal (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x33AB40EEAF: ??? (in /lib64/libpthread-2.14.so) ==32510== by 0x687868F: ??? ==32510== ==32510== Conditional jump or move depends on uninitialised value(s) ==32510== at 0x33AB04638C: _itoa_word (_itoa.c:196) ==32510== by 0x33AB048E06: vfprintf (vfprintf.c:1567) ==32510== by 0x33AB06FDA1: vsnprintf (vsnprintf.c:120) ==32510== by 0x567B4D5: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x567B683: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x5670300: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x567A853: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x57AB67B: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x57AC208: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x5679E77: JVM_handle_linux_signal (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x33AB40EEAF: ??? (in /lib64/libpthread-2.14.so) ==32510== by 0x687868F: ??? ==32510== ==32510== ==32510== Process terminating with default action of signal 11 (SIGSEGV) ==32510== General Protection Fault ==32510== at 0x567B60F: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x5677B65: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x57ABC4F: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x57AC208: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x5679E77: JVM_handle_linux_signal (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x33AB40EEAF: ??? (in /lib64/libpthread-2.14.so) ==32510== by 0x687868F: ??? ==32510== by 0xEB707B07: ??? ==32510== by 0xB8510B0F: ??? ==32510== by 0xC22B8D1F: ??? ==32510== by 0xB84B9B0800000000: ??? ==32510== by 0x6600000008: ??? ==32510== ==32510== HEAP SUMMARY: ==32510== in use at exit: 8,387,890 bytes in 3,178 blocks ==32510== total heap usage: 71,965 allocs, 68,787 frees, 123,623,154 bytes allocated ==32510== ==32510== Thread 1: ==32510== 9 bytes in 1 blocks are possibly lost in loss record 15 of 1,397 ==32510== at 0x4A0649D: malloc (vg_replace_malloc.c:236) ==32510== by 0x537A4A0: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x537BB4E: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x574439B: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x5742AAF: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x5744A32: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x53DA347: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x54CA899: ??? (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so) ==32510== by 0x67F9B91: ??? ==32510== by 0x67E29B2: ??? ==32510== by 0x67E29B2: ??? ==32510== by 0x67E29B2: ???