Bug ID: JDK-6452446 JDI test fails because of debuggee VM crashes in compiled code

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 6

Priority: P3
Status: Closed
Resolution: Won't Fix
OS: solaris
CPU: x86

Submitted: 2006-07-25
Updated: 2012-10-01
Resolved: 2010-12-14

JDI tests
	nsk/jdi/MonitorWaitRequest/MonitorWaitRequest002
	nsk/jdi/MonitorWaitedRequest/MonitorWaitedRequest002
fail because of debuggee VM crashes in compiled code, hs_err file is attached. Bug reproduces intermittently(~ 1 of 10).

To reproduce:
	ssh vmsqe-p3-04.russia.sun.com
	cd /net/vmsqe.russia/export4/results/nightly/2006-07-25/vm/SOLARIS-I586/client/mixed/vm-vm_testbase_SPB_1.6.0-NIGHTLY_client_mixed_SOLARIS-I5862006-07-25-01-05-08/ResultDir/MonitorWaitedRequest002
	sh reproduce_bug.sh MonitorWaitedRequest002.tlog
(script 'reproduce_bug.sh' executes test till fail)

EVALUATION The code no longer works this way so I'm closing as will not fix. The bug still exists in older versions.

14-12-2010

EVALUATION I think I see what's happening and it looks like a problem with polling and deopt: The code in question looks like this before it's deoptimized: 0xcf1049a7: call Thread.yield() 0xcf1049ac: nop # 1 byte nop 0xcf1049ad: testl -765329152, %eax # poll When we die it looks like this: 0xcf1049a7: call Thread.yield() # native method 0xcf1049ac: call deopt blob 0xcf1049b1: call %edx # some random instruction resulting from # overwriting part of the poll. The problem is that our pc is 0xcf1049ad so we die because we're decoding garbage. So presumably we hit the poll at 49ad, stopped, deoptimized the nmethod and then resumed at 49ad on top of garbage. So this could be fixed in a number of ways. The poll is eliminatable because there's a call which dominates so we could just skip emitting it. Otherwise we need to insert space for the call in between using either multiple nops or a fat_nop.

01-08-2006