JDK-6496524 : Setting breakpoint in jdb crashes Hotspot JVM
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0u9,7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_10
  • CPU: generic,x86
  • Submitted: 2006-11-22
  • Updated: 2010-07-29
  • Resolved: 2007-06-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 JDK 7 Other
6u4Fixed 7Fixed hs10Fixed
Related Reports
Duplicate :  
Here are the steps to reproduce the issue. Please see the attached testcase:

1. Run the program:
java -agentlib:jdwp=transport=dt_socket,server=y,address=8000,suspend=n

2. Attach a debugger in parallel:
jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=8000

3. Wait some seconds in the debugger

4. Set a breakpoint in line 21 (the one starting '  int index = ...')
stop at BreakpointBugTest$Runner:21

5. Now the VM chrashes.



SUGGESTED FIX See PRT webrev: http://prt-web.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2007/20070608153504.rasbold.c2_baseline/workspace/webrevs/webrev-2007.06.08/index.html

SUGGESTED FIX It seems that continuation_for() should compute "code" like this: Bytecodes::Code code = Bytecodes::java_code(Bytecodes::code_at(bcp)); instead of this: Bytecodes::Code code = Bytecodes::java_code(Bytecodes::cast(*bcp)); More investigation needed.

EVALUATION Jdb is setting a breakpoint at an invokestatic bytecode. The VM safepoints, then deopts at this same bytecode. AbstractInterpreter::continuation_for() is confused. It chooses the wrong tos type: vtos based on _breakpoint, instead of itos based on _invokestatic. The continuation state is wrong, so deopt_entry() returns the wrong entry point and hijinks ensue.