JDK-6498878 : client compiler crashes on windows when dealing with breakpoint instructions
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2006-11-29
  • Updated: 2015-03-11
  • Resolved: 2011-04-20
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 6 Other
6u14Fixed hs12Fixed
Related Reports
Relates :  
JDK-4984394 - assertion error CallGenerator::for_inline occured in vtest run
Relates :  
JDK-4926272 - methodOopDesc::method_from_bcp is unsafe
Description
The test SDK regression test:
   com/sun/jdi/SuspendThreadTest.java 
crashes when run on 5.0.x on some windows machines(multi core?), but not others. 
The test basically just
- sets a bkpt in a trivial debuggee method that is called in a loop
- when the bkpt it hit, the debugger disables it, resumes the debuggee
  and then re-enables the bkpt.
This is repeated 200 times. 

On a dual core xeon machine(Windows 2003 Server), the
test always fails before 200 iterations are completed. 
On a single processor athlon,(Win XP) the test never crashes, nor has 
it been seen to fail on a two processor solx86 machine.

The failure only occurs with the client compiler. 
The failure occurs with 5.0_11 and earlier updates (at least those I tried)
back to and including 5.0 FCS.

See the attached hs_err file which came from 5.0_11.
See also:
   4926272: methodOopDesc::method_from_bcp is unsafe
com.sun.jdi.SuspendThreadTest

See, e.g., the tlog file at 

http://gtee.sfbay/gtee/results/JDK7/NIGHTLY/VM/latest/JDK6U3/vm/64BITLINUX-AMD64/server/mixed/vm-64BITLINUX-AMD64_server_mixed_JDI_REGRESSION2007-07-15-14-32-29/com/sun/jdi/SuspendThreadTest.jtr

which mentions this bug id.
Comments
RULE com/sun/jdi/SuspendThreadTest.java Crash none RULE com/sun/jdi/SuspendThreadTest.java Exception com.sun.jdi.VMDisconnectedException: Connection closed
11-03-2015
EVALUATION The problem is the _is_compilable part of the test that guards the replacing of breakpoints in ciMethod::load_code. // Revert any breakpoint bytecodes in ci's copy if (_is_compilable && me->number_of_breakpoints() > 0) { BreakpointInfo* bp = instanceKlass::cast(me->method_holder())->breakpoints(); for (; bp != NULL; bp = bp->next()) { if (bp->match(me)) { code_at_put(bp->bci(), bp->orig_bytecode()); } } } Whether a method is compilable can change at pretty much any time as breakpoints are added and removed but for the root of a compile compilable is only checked before the method is enqueued for compilation. So a compilable method gets enqueued, another thread inserts a breakpoint, the compiler dequeues it and tries to compile and when it copies the bytecodes out it leaves the breakpoints in there. The fix is simply to remove the _is_compilable test. Easy enough to fix and I'm not sure why we never hit this before. It still affects mustang and dolphin, and should effect C2 except that it compiles much less often so it's less exposed. - Tom
01-12-2006