JDK-4337667 : crash (sig 11) on second invocation of a breakpoint
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmdi
  • Affected Version: 1.3.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_7
  • CPU: generic,sparc
  • Submitted: 2000-05-12
  • Updated: 2002-08-30
  • Resolved: 2002-08-30
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.
Other Other
1.3.0Fixed 1.3.1 1.3.1Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Several bugs describe the behavior of stopping twice at a breakpoint:

	4278333 & 4331369 & 4326260 & 4294585 & 4303298 

This may just be another dup but I am submitting it because it has
the additional property of crashing the VM.

Test program:

---- cut here ---
public class BPTest {
  public static void main(String[] args) {
    for(int i=0; i < 100; i++){
      System.out.println("i = " + i);      
      BPTest Instance = new BPTest();  // add breakpoint here !!
    }
  }
}
---- cut here ---

The run (on Merlin/Solaris):

% jdb BPTest
Initializing jdb...
> stop at BPTest:5
Deferring breakpoint BPTest:5.
It will be set after the class is loaded.
> run
run BPTest
Java HotSpot(TM) Client VM warning: Setting of property "java.compiler" is ignored
> 
VM Started: Set deferred breakpoint BPTest:5
i = 0

Breakpoint hit: thread="main", BPTest.main(), line=5, bci=30
  5       ErrorTest Instance = new ErrorTest();  // add breakpoint here !!

main[1] resume
All threads resumed.
> 
Breakpoint hit: thread="main", BPTest.main(), line=5, bci=30
  5       ErrorTest Instance = new ErrorTest();  // add breakpoint here !!

main[1] resume
All threads resumed.
> #
# HotSpot Virtual Machine Error, Unexpected Signal 11
#
# Error ID: 4F533F534F4C415249530E43505007CA 01
#

The application has been disconnected
%

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: kest-sol-beta2 FIXED IN: kest-sol-beta2 INTEGRATED IN: 1.3.1 kest-sol-beta2 VERIFIED IN: 1.3.1_01a
14-06-2004

EVALUATION daniel.daugherty@Eng 2000-05-17 The breakpoint is hit on the first loop, but on the next loop the breakpoint is not hit. I temporarily modified the TraceBytecodes option support to only dump breakpoint bytecodes and only two are found. BreakpointInfo::set() is where a method's bytecode is modified to the breakpoint bytecode. BreakpointInfo::set_orig_bytecode_at() and BreakpointInfo::clear() are where a method's breakpoint bytecode is restored to the original bytecode. I set breakpoints at the start of each method. set() is called once by jdb before the target class file is run and it is called once for each breakpoint set by jdb. set_orig_bytecode_at() is called when the program is almost finished running. clear() is never called. methodOopDesc::orig_bytecode_at() returns a copy of the original bytecode before the breakpoint was set. I set a breakpoint at orig_bytecode_at() to see who was asking for the original bytecode. The first requestor was the interpreter code for the breakpoint bytecode which called via InterpreterRuntime::get_original_bytecode_at(). The breakpoint was then posted to jdb. I issued the "resume" command in jdb and hit orig_bytecode_at() again: methodOopDesc::orig_bytecode_at(int 0x0000001e) line 922 Bytecodes::non_breakpoint_code_at(unsigned char * 0x0c436fbe, methodOopDesc * 0x0c436f60) line 41 Bytecodes::code_at(unsigned char * 0x0c436fbe, methodOopDesc * 0x00000000) line 313 + 49 bytes InterpreterRuntime::code() line 31 + 16 bytes InterpreterRuntime::already_patched(Bytecodes::Code _new) line 32 + 8 bytes InterpreterRuntime::_new(JavaThread * 0x00763328, constantPoolOopDesc * 0x0c436d90, int 0x0000000a) line 97 + 19 bytes 009b05c0() The _new() interpreter function is looking to patch the _new bytecode to the _fast_new bytecode in certain situations. if (UseFastInterpreterAllocation && !already_patched(Bytecodes::_new) && !(UseSpecLock && SpecLock::is_speclock_class(klass())) && klass->is_initialized() && !klass->has_finalizer()) { // patch bytecode - doesn't matter if it happens more than once Bytecode_at(bcp())->set_code(Bytecodes::_fast_new); } In our case, we don't want to patch in _fast_new because that clobbers the _breakpoint bytecode. Adding a new is_breakpoint() method and only patching in _fast_new when we don't have a breakpoint allowed the _breakpoint bytecode to be found on each loop. However, the _breakpoint() interpreter logic prevented the breakpoint event from being delivered because the breakpoint was at the same method and bytecode. This logic is appropriate for slow breakpoints where each bytecode is interpreted and checked.
11-06-2004

SUGGESTED FIX daniel.daugherty@Eng 2000-05-18 See attached webrev.tar file for the changes.
18-05-2000