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:
#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.