United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4968267 sparc 64bit VM, SEGV in interpreter, br should be brx
JDK-4968267 : sparc 64bit VM, SEGV in interpreter, br should be brx

Details
Type:
Bug
Submit Date:
2003-12-13
Status:
Closed
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
2004-02-02
Component:
hotspot
OS:
solaris_8
Sub-Component:
runtime
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.2_01,1.4.2_04
Fixed Versions:
1.4.2_06 (06)

Related Reports
Backport:

Sub Tasks

Description

Name: cl74495			Date: 12/13/2003


We are seeing SEGV's in the generated intepreter in a 64 bit Sparc VM
when the stack frame of an interpreted method contains
the memory location with address 0xfffffffefffffff8 .
We are seeing this when running with -Xmx in the range of 490M
to 600M.  We have application native code that is mmap'ing
quite a bit of memory, so the exact -Xmx and number of threads
needed to reproduce this in a simple test program are hard to specify .

The findpc() function says the PC where the SEGV happened is in
   method entry point (kind = zerolocals)

In the sources for J2SE 1.4.2.03 ,
in file cpu/sparc/vm/interpreter_sparc.cpp,
in function InterpreterGenerator::generate_asm_interpreter_entry
there is the following code .
   1506   __ bind( clear_loop );
   1507   __ inc( O2, wordSize );
   1508
   1509   __ cmp( O2, O1 );
   1510   __ br( Assembler::lessEqualUnsigned, true, Assembler::pt, clear_loop );
   1511   __ delayed()->st_ptr( init_value, O2, 0 );

The instruction generated by line 1511 is producing a SEGV
and the registers at the point of the SEGV are
 o1 = 0xfffffffefffffff8 , o2 = 0xffffffff00002000

  To fix this, the "br" at line 1510 should be "brx" .


I did a search for all "__ br(" occurances in sparc code and
after excluding branches with any of
  ::equal ::zero ::always ::notZero ::notEqual
I find one additional place where I believe "br should be "brx".
We have not seen SEGV at this location yet , which is
in file cpu/sparc/vm/templateTable_sparc.cpp,
in function TemplateTable::fast_linearswitch
   1569   // table search
   1570   __ bind(loop);
   1571   __ cmp(O4, Otos_i);
   1572   __ br(Assembler::equal, true, Assembler::pn, found);
   1573   __ delayed()->ld(O3, BytesPerInt, O4); // offset -> O4
   1574   __ inc(O3, 2 * BytesPerInt);
   1575
   1576   __ bind(loop_entry);
   1577   __ cmp(O2, O3);
   1578   __ br(Assembler::greaterUnsigned, true, Assembler::pt, loop);
   1579   __ delayed()->ld(O3, 0, O4);

The "br" at line 1578 should be "brx" , I believe , since the cmp
at line 1577 is comparing two pointers .
(Incident Review ID: 230298) 
======================================================================

                                    

Comments
EVALUATION



Name: cp112406			Date: 12/15/2003


   The first "br" was fixed for bugid 4915922 .
   The second looks wrong and is FIP.



======================================================================

Thank you for finding this and reporting it!!  I have fixed the second instance
where br() should be brx() and inspected the code yet again to see if there are any more that are wrong.  I didn't find any.  Thank you for telling us about the
fast_linearswitch case.


###@###.### 2003-12-17
                                     
2003-12-17
WORK AROUND



Name: cl74495			Date: 12/13/2003


try changing your -Xmx setting, and/or configuring the
application code to start fewer threads.
======================================================================
                                     
2004-07-08
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.4.2_06
generic
tiger-beta2

FIXED IN:
1.4.2_06
tiger-beta2

INTEGRATED IN:
1.4.2_06
tiger-beta2


                                     
2004-07-08



Hardware and Software, Engineered to Work Together