United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6498878 client compiler crashes on windows when dealing with breakpoint instructions
JDK-6498878 : client compiler crashes on windows when dealing with breakpoint instructions

Details
Type:
Bug
Submit Date:
2006-11-29
Status:
Closed
Updated Date:
2011-04-20
Project Name:
JDK
Resolved Date:
2011-04-20
Component:
hotspot
OS:
windows
Sub-Component:
compiler
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.0
Fixed Versions:
hs12 (b02)

Related Reports
Backport:
Backport:
Relates:
Relates:

Sub Tasks

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
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
                                     
2006-12-01



Hardware and Software, Engineered to Work Together