You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Gregory Shimansky (JIRA)" <ji...@apache.org> on 2007/12/14 21:32:43 UTC
[jira] Commented: (HARMONY-5305) [drlvm][jit][EUT] regression in
jdtdebug in Linux x86_64
[ https://issues.apache.org/jira/browse/HARMONY-5305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551933 ]
Gregory Shimansky commented on HARMONY-5305:
--------------------------------------------
I think I've found a fix for the bug with NPE. The method org/eclipse/jdt/core/dom/DefaultCommentMapper.getExtendedEnd(Lorg/eclipse/jdt/core/dom/ASTNode;)I contains the following bytecodes:
74: lload_3
75: l2i
76: aaload
The index for array is long, it is converted to int and then aaload is executed. For it JET generates the following code:
74: lload_3
75: l2i
0x00002aaacbfc3720: sub $0x8,%rsp
0x00002aaacbfc3724: mov %r12,%rdi
0x00002aaacbfc3727: mov %rsi,0xfffffffffffffda8(%rbp)
0x00002aaacbfc372e: mov $0x2aaaada1892c,%r8
0x00002aaacbfc3738: rex64Z callq *%r8 <- execute rt_h_i64_2_i32, result is in RAX
0x00002aaacbfc373b: add $0x8,%rsp
76: aaload
0x00002aaacbfc373f: mov 0xfffffffffffffda8(%rbp),%r9
0x00002aaacbfc3746: mov $0x2aaaae2b8000,%r10
0x00002aaacbfc3750: cmp %r10,%r9
0x00002aaacbfc3753: jne,pt 0x2aaacbfc3790 <- Check for managed null
0x00002aaacbfc375a: mov %eax,0xfffffffffffffda0(%rbp)
0x00002aaacbfc3760: mov %r9,0xfffffffffffffda8(%rbp)
0x00002aaacbfc3767: movl $0x2,0xfffffffffffffdec(%rbp)
0x00002aaacbfc3771: movl $0x1,0xfffffffffffffde0(%rbp)
0x00002aaacbfc377b: sub $0x8,%rsp
0x00002aaacbfc377f: mov $0x2aaaacdc3200,%r11
0x00002aaacbfc3789: rex64Z callq *%r11
0x00002aaacbfc378c: add $0x8,%rsp
0x00002aaacbfc3790: cmp %eax,0x10(%r9)
0x00002aaacbfc3794: ja,pt 0x2aaacbfc37d1 <- Check for array bounds, note EAX is checked, not RAX
0x00002aaacbfc379b: mov %eax,0xfffffffffffffda0(%rbp)
0x00002aaacbfc37a1: mov %r9,0xfffffffffffffda8(%rbp)
0x00002aaacbfc37a8: movl $0x2,0xfffffffffffffdec(%rbp)
0x00002aaacbfc37b2: movl $0x1,0xfffffffffffffde0(%rbp)
0x00002aaacbfc37bc: sub $0x8,%rsp
0x00002aaacbfc37c0: mov $0x2aaaacdc3350,%r11
0x00002aaacbfc37ca: rex64Z callq *%r11
0x00002aaacbfc37cd: add $0x8,%rsp
0x00002aaacbfc37d1: mov 0x18(%r9,%rax,4),%ecx <- SIGSEGV here R9 = 0x2aaab490f328 RAX = 0x100000001
0x00002aaacbfc37d6: mov $0x2aaaae2b8000,%r11
0x00002aaacbfc37e0: add %r11,%rcx
0x00002aaacbfc37e3: orl $0x20,0xfffffffffffffde8(%rbp)
The R9 is base address for array. RAX is its index converted to int with rt_h_i64_2_i32. For index range JET checks EAX since array indexes are int. But for some reason RAX value is 0x100000001 which means that upper half of RAX is not zero.
Looking at the code in rt_h_i64_2_i32 I see the following:
0x00002aaaada1892c <_ZN7Jitrino3Jet14rt_h_i64_2_i32Ex+0>: push %rbp
0x00002aaaada1892d <_ZN7Jitrino3Jet14rt_h_i64_2_i32Ex+1>: mov %rsp,%rbp
0x00002aaaada18930 <_ZN7Jitrino3Jet14rt_h_i64_2_i32Ex+4>: mov %rdi,0xfffffffffffffff8(%rbp)
0x00002aaaada18934 <_ZN7Jitrino3Jet14rt_h_i64_2_i32Ex+8>: mov 0xfffffffffffffff8(%rbp),%rax
0x00002aaaada18938 <_ZN7Jitrino3Jet14rt_h_i64_2_i32Ex+12>: leaveq
0x00002aaaada18939 <_ZN7Jitrino3Jet14rt_h_i64_2_i32Ex+13>: retq
There is no sign of clearing the upper half of long value in this code. So if upper half of it contained garbage, then it remains there. A workaround for this bug is a patch like this:
Index: vm/jitrino/src/jet/arith_rt.cpp
===================================================================
--- vm/jitrino/src/jet/arith_rt.cpp (revision 604244)
+++ vm/jitrino/src/jet/arith_rt.cpp (working copy)
@@ -268,7 +268,7 @@
double __stdcall rt_h_i32_2_dbl(int i) { return (double)i; };
// i64 ->
-int __stdcall rt_h_i64_2_i32(int64 i) { return (int32)i; };
+int __stdcall rt_h_i64_2_i32(int64 i) { return (int32)(i & 0xffffffff); };
float __stdcall rt_h_i64_2_flt(int64 i) { return (float)i; };
double __stdcall rt_h_i64_2_dbl(int64 i) { return (double)i; };
// flt ->
I am not sure if the bug is in the helper or JET, I am inclined to think the latter since looking at the code, the long index couldn't get the value 0x100000001 in normal conditions.
But since my workaround helps with the problem I am going to check EUT now to see whether jdtdebug actually fails because of this problem.
> [drlvm][jit][EUT] regression in jdtdebug in Linux x86_64
> --------------------------------------------------------
>
> Key: HARMONY-5305
> URL: https://issues.apache.org/jira/browse/HARMONY-5305
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Linux x86_64
> Reporter: Vladimir Beliaev
> Attachments: Breakpoints.java, IBreakpoints.java
>
>
> The jdtdebug suite start hanging on Linux x86_64.
> The issue migt be the same to HARMONY-5303, still CC start repoting this crash earlier - the latest non-crashed revision is 595048 (15-Nov-2007)
> http://people.apache.org/~smishura/r595048/Linux_x86_64/eut33/results/html/org.eclipse.jdt.debug.tests_linux.gtk.x86_64.html
> See the run instruction in HARMONY-5303, still use jdtdebug instead of coreresources.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.