JDK-7150046 : SIGILL on sparcv9 fastdebug
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs24
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris
  • CPU: sparc
  • Submitted: 2012-03-01
  • Updated: 2013-06-26
  • Resolved: 2012-03-10
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 Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u40Fixed 8Fixed hs24Fixed
Related Reports
Duplicate :  
Description
Tom writes:
On Feb 29, 2012, at 4:45 PM, David Holmes wrote:
> On 1/03/2012 10:37 AM, Tom Rodriguez wrote:
>> On Feb 29, 2012, at 4:19 PM, David Holmes wrote:
>>
>>> Does this look familiar to anyone?
>> A SIGILL in the interpreter is fairly odd.  Did you get an hs_err from it?  jprt
>> isn't very good at grabbing them anymore but if you look at the log for the run
>> you can often grab it off the machine as long as a new job hasn't started on it.
>>
> Managed to find the hserr log - attached. Crash reproduced on a resubmit too. 

I think you're in lock_method in templateInterpreter_sparc.cpp.

;; ffffffff7281bd08 d0 5c a0 18             ldx  [ %l2 + 0x18 ], %o0
;; ffffffff7281bd0c d0 5a 20 20             ldx  [ %o0 + 0x20 ], %o0
;; ffffffff7281bd10 d0 5a 20 78             ldx  [ %o0 + 0x78 ], %o0
;; ffffffff7281bd14 80 90 00 08             tst  %o0
;; ---------------
;; ffffffff7281bd18 83 d0 20 10             te  0x10
;; ffffffff7281bd1c 9c 23 a0 10             sub  %sp, 0x10, %sp
;; ffffffff7281bd20 a0 24 20 10             sub  %l0, 0x10, %l0
;; ffffffff7281bd24 a8 25 20 10             sub  %l4, 0x10, %l4
;; ffffffff7281bd28 d0 75 20 08             stx  %o0, [ %l4 + 8 ]
;; ffffffff7281bd2c c8 5a 20 00             ldx  [ %o0 ], %g4
;; ffffffff7281bd30 82 09 20 07             and  %g4, 7, %g1
;; ffffffff7281bd34 80 a0 60 05             cmp  %g1, 5

o0 is 0x0000000700000000.  This is the MacroAssembler that generates the trap:

#ifdef ASSERT
    __ tst(O0);
    __ breakpoint_trap(Assembler::zero);
#endif // ASSERT   

by default breakpoint_trap uses icc which isn't suitable for pointers.  It should be using ptr_cc which is of course xcc in 64 bit.  breakpoint_trap probably shouldn't have a default argument at all.

----

This crash is occuring during JPRT submissions:

JPRT: [east] job notification - FAILED with job 2012-03-01-011409.daholme.hotspot-emb

Failure reason: Targets failed.  Target solaris_sparcv9-fastdebug-c2-jvm98 FAILED. 

Problem may be exacerbated when running on Solaris zones/ldoms.

Comments
EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8a48c2906f91
22-03-2012

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8a48c2906f91
05-03-2012

EVALUATION See description
01-03-2012