User's Java program receives SIGILL unecpectedly.
The location of crash dump has a genuine instruction.
Few suggestions were posted to the customer. The output of implementing the fixes would have helped us investigate this further. Since the customer did not get back, this escalation and hence the bug id is being closed. Please create a new CR if such a problem re-surfaces. (Refer the suggested Fix section for the suggestions that were posted to the customer)

Below is the investigation report


This is a crash with 1.4.2_10 with following stack trace

Stack: [0x8d100000,0x8d180000), sp=0x8d17f700, free space=509k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
v ~StubRoutines::handler_for_implicit_exception
v ~RuntimeStub::_complete_monitor_locking_Java
J weblogic.socket.PosixSocketMuxer.processSockets()V
v ~OSRAdapter
j weblogic.socket.SocketReaderRequest.execute(Lweblogic/kernel/ExecuteThread;)V+13
j weblogic.kernel.ExecuteThread.execute(Lweblogic/kernel/ExecuteRequest;)V+23
j weblogic.kernel.ExecuteThread.run()V+66
v ~StubRoutines::call_stub
V [libjvm.so+0x15dbc4]
V [libjvm.so+0x24cab4]
V [libjvm.so+0x25fd10]
V [libjvm.so+0x271080]
V [libjvm.so+0x26a758]
V [libjvm.so+0x266c38]

From dbx:
---- called from signal handler with signal 4 (SIGILL) ------
 [10] 0xf9c36cc0(0xbea3cbb8, 0x8d17f8c0, 0xcd46b0, 0x36b, 0xacc55d10, 0xf2111958), at 0xf9c36cc0
 [11] 0xf9c342e8(0xbea3cbb8, 0x8d17f8c0, 0xf1847288, 0xbea3bd80, 0xfb7dc000, 0xa792e4b8), at 0xf9c342e8
 [12] 0xfa08dda8(0xf1818618, 0xa83e4730, 0xbea44698, 0x5, 0x0, 0xbea3cbb8), at 0xfa08dda8
 [13] 0xfa0a9178(0x8d17f9fc, 0xb6, 0xf3c69810, 0xf9c14180, 0x8, 0x8d17f8d0), at 0xfa0a9178
 [14] 0xf9c05804(0x8d17fa84, 0xf19d2da0, 0x0, 0xf9c15ef8, 0x4, 0x8d17f998), at 0xf9c05804
 [15] 0xf9c05a8c(0x8d17fb14, 0xb6, 0x0, 0xf9c16430, 0x8, 0x8d17fa20), at 0xf9c05a8c
 [16] 0xf9c05804(0x8d17fb9c, 0x0, 0x0, 0xf9c15eb0, 0x8, 0x8d17fab0), at 0xf9c05804
 [17] 0xf9c0010c(0x8d17fc28, 0x8d17fe90, 0xa, 0xf20fbc08, 0x4, 0x8d17fb40), at 0xf9c0010c
 [18] JavaCalls::call_helper(0x8d17fe88, 0x8d17fcf0, 0x8d17fda8, 0xcd46b0, 0xcd46b0, 0x8d17fd00), at 0xfed5dbbc
 [19] JavaCalls::call_virtual(0xff180000, 0xcf1e08, 0x8d17fd9c, 0x8d17fd98, 0x8d17fda8, 0xcd46b0), at 0xfee4caac
 [20] JavaCalls::call_virtual(0x8d17fe88, 0x8d17fe84, 0x8d17fe7c, 0x8d17fe74, 0x8d17fe6c, 0xcd46b0), at 0xfee5fd08
 [21] thread_entry(0xcd46b0, 0xcd46b0, 0xc39bd0, 0xcf1e08, 0x31583c, 0xfee6a728), at 0xfee71078
 [22] JavaThread::run(0xcd46b0, 0x13f, 0x40, 0x0, 0x40, 0x0), at 0xfee6a750
 [23] _start(0xcd46b0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfee66c30

Looking at the Stub frames(10, 11) and the compiled frame ProcessSockets in dbx:

frame 12:
(dbx) x 0xfa08dda0/10i
0xfa08dda0: add %sp, 96, %o1
0xfa08dda4: mov %l2, %o0
0xfa08dda8: call 0xf9c342c0 ! 0xf9c342c0 <--- at pc
0xfa08ddac: nop
0xfa08ddb0: ba,pt %icc,0xfa08d7c4 ! 0xfa08d7c4
0xfa08ddb4: nop
0xfa08ddb8: add %sp, 100, %o1
0xfa08ddbc: mov %i1, %o0
0xfa08ddc0: call 0xf9c342c0 ! 0xf9c342c0
0xfa08ddc4: nop

So frame 12 (compiled code of ProcessSockets) calls 0xf9c342c0 at 0xfa08dda8.

Now looking at what 0xf9c342c0 is:
(dbx) x 0xf9c342c0/15i
0xf9c342c0: save %sp, -96, %sp
0xf9c342c4: mov %i1, %o1
0xf9c342c8: mov %i0, %o0
0xf9c342cc: or %g2, 0, %l0
0xf9c342d0: clr [%l0 + 144]
0xf9c342d4: st %sp, [%l0 + 136]
0xf9c342d8: mov %l0, %o2
0xf9c342dc: call complete_monitor_locking_C ! 0xfedbd81c
0xf9c342e0: mov %g2, %l7
0xf9c342e4: mov %l7, %g2
0xf9c342e8: clr [%l0 + 136] <----- at pc
0xf9c342ec: clr [%l0 + 144]
0xf9c342f0: ld [%l0 + 4], %l0
0xf9c342f4: brnz,pn %l0, 0xf9c34308 ! 0xf9c34308
0xf9c342f8: nop

This is frame 11. Looks like ~RuntimeStub::_complete_monitor_locking_Java which is internally calling C implementation complete_monitor_locking_C. PC of this frame is 0xf9c342e8. I don't understand how at this instruction the control goes to the above frame 10 which is ~StubRoutines::handler_for_implicit_exception.

This instruction seems to be a valid instruction:
0xf9c342e8: clr [%l0 + 136]
which would be machine instruction
    st %g0 [%l0 + 136]

0xf9c342e8: 0xc0242088
which is:
11 00000 000100 10000 1 0000010001000

and this decodes correctly to st %g0 [%l0 + 136]

l0 at this point conatins JavaThread* 0x00cd46b0. and this instruction is trying to clear
(dbx) x 0x00cd46b0+136
0x00cd4738: 0x8d17f800
(dbx) x 0x8d17f800
0x8d17f800: 0x00cd46b0 <---JavaThread*

Now looking at frame 10:
Instructions around the pc of this frame:

(dbx) x 0xf9c36cb0/10i
0xf9c36cb0: unimp 0x0
0xf9c36cb4: unimp 0x0
0xf9c36cb8: unimp 0x0
0xf9c36cbc: unimp 0x0
0xf9c36cc0: save %sp, -96, %sp <---- at pc
0xf9c36cc4: mov %g1, %l1
0xf9c36cc8: mov %g3, %l3
0xf9c36ccc: mov %g4, %l4
0xf9c36cd0: mov %g5, %l5
0xf9c36cd4: mov %g2, %l7

So we are at the begining of ~StubRoutines::handler_for_implicit_exception. This does not seem to an illegal instruction