United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4915922 : vmark failed with tiger b16/17 on solaris sparc 64 bits

Details
Type:
Bug
Submit Date:
2003-09-02
Status:
Resolved
Updated Date:
2004-06-25
Project Name:
JDK
Resolved Date:
2003-10-07
Component:
hotspot
OS:
solaris_9,generic
Sub-Component:
compiler
CPU:
sparc,generic
Priority:
P1
Resolution:
Fixed
Affected Versions:
1.4.2_04,5.0
Fixed Versions:
1.4.2_06 (06)

Related Reports
Backport:

Sub Tasks

Description
On jtg-e250-4.sfbay, ( SunOS jtg-e250-4 5.8 Generic_108528-23 sun4u sparc SUNW,Ultra-250)  with tiger b16/17, vmark failed within 2 hours when running
with -d64.

The failure is reproducible.

Error message:
Unexpected Signal: 11 at pc=0xffffffff3900b8e0, pid=1514, tid=0
An error has just occurred.
To debug, use 'dbx - 1514'; then switch to thread t@0

To reproduce the failure:
1. telnet to jtg-e250-4 as root
2. export JAVA_HOME=<your java home>
3. execute the script
/net/jtgb4u4c/export/sail8/bigapps/tests/runvmark.ksh -d64
4. log files are under /bt/volanomark*

###@###.### 2003-09-02

The failure is reproducible with tiger b18.
The failure is NOT reproducilble when running with -server

###@###.### 2003-09-03

                                    

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.4.2_06
generic
tiger

FIXED IN:
1.4.2_06
tiger

INTEGRATED IN:
1.4.2_06
tiger
tiger-b22

VERIFIED IN:
tiger-beta


                                     
2004-07-08
EVALUATION


The bug is in the following code produced by
 InterpreterGenerator::generate_fixed_frame():

0xffffffff38c0b914:     add     %o2, 0x8, %o2
0xffffffff38c0b918:     cmp     %o2, %o1
0xffffffff38c0b91c:     bleu,a,pt %icc,0xffffffff38c0b914
0xffffffff38c0b920:     stx     %g0, [%o2]    <<<< SEGV here
0xffffffff38c0b924:     mov     0x1, %g3

This code zeroes out the local variables when creating an interpreter frame.
However the branch instruction is incorrect on 64-bit SPARC.  It should
test the %xcc condition codes instead of the %icc condition codes.  This
bug will cause problems in the very rare situation when the region being
zeroed crosses a 4 Gb boundary.

The fix is to change this instruction to use the %xcc condition codes on
64-bit sparc.  I will check for other cases of this type of error in
the other generated code.

###@###.### 2003-09-18

My analasis above of when this bug will cause a problem is not quite
correct.  A problem occurs when the region being zeroed is at the end of,
or crosses a 4 Gb boundary.  If the LSW of the address of end of the
memory region is 0xfffffff8, the loop does not properly terminate and
zeroes memory far beyond the the intended region (this is the cause of
the SEGV.)  If the region crosses a 4 Gb boundary, the loop will not
execute at all. 

###@###.### 2003-09-22
                                     
2003-09-22



Hardware and Software, Engineered to Work Together