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
Posted Date : 2006-11-29 23:30:31.0

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.
Posted Date : 2007-07-16 16:07:25.0

N/A

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
Posted Date : 2006-12-01 01:45:39.0

Is it possible that this fix broke some breakpoint functionality?

https://bugs.eclipse.org/bugs/show_bug.cgi?id=279137, "Breakpoints fail to hit under JDK 1.6.0_14"

The "coincidence" is that some breakpoints are missed (at least on Windows XP) even if you use jdb, but it -seems- to work if you use the Server JVM.