harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Shimansky (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-5305) [drlvm][jit][EUT] regression in jdtdebug in Linux x86_64
Date Fri, 14 Dec 2007 20:32:43 GMT

    [ 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.


Mime
View raw message