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.