JDK-4968267 : sparc 64bit VM, SEGV in interpreter, br should be brx
  • Type: Bug
  • Status: Closed
  • Resolution: Fixed
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P3
  • Affected Version: 1.4.2_01,1.4.2_04
  • OS: solaris_8
  • CPU: sparc
  • Submit Date: 2003-12-13
  • Updated Date: 2012-10-08
  • Resolved Date: 2004-02-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
Other
1.4.2_06 06Fixed
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
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

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

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