JDK-4331369 : jdb: it needs to call 'step' twice to step from brkpoint in main
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmdi
  • Affected Version: 1.3.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2000-04-18
  • Updated: 2002-09-06
  • Resolved: 2002-09-06
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
1.3.0 sol-beta2Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
User needs to call 'step' twice to move from brkpoint
when stopped at the brkpoint in the main after 'run'.

To reproduce:

class Class {

    public static void main(String args[]) {
        System.out.println("Start");
        System.out.println("Print");
        System.out.println("End");
    }
}

jdb:

stop in Class.main
run
step

Result:
Initializing jdb...
> stop in Class.main
Deferring breakpoint Class.main.
It will be set after the class is loaded.
> run
run Class
Java HotSpot(TM) Client VM warning: Setting of property "java.compiler" is ignored
> 
VM Started: Set deferred breakpoint Class.main

Breakpoint hit: thread="main", Class.main(), line=4, bci=0
  4     System.out.println("Start");

main[1] step
main[1] 
Breakpoint hit: thread="main", Class.main(), line=4, bci=0      <<< This line
  4     System.out.println("Start");                            <<< reported twice

main[1] step
main[1] Start

Step completed: thread="main", Class.main(), line=5, bci=8
  5     System.out.println("Print");

main[1] step
main[1] Print

Step completed: thread="main", Class.main(), line=6, bci=16
  6     System.out.println("End");


Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: kest-sol-beta2 FIXED IN: kest-sol-beta2 INTEGRATED IN: kest-sol-beta2
29-07-2004

EVALUATION daniel.daugherty@Eng 2000-05-19 The first single step event is posted via the following stack trace: jvmdi::post_single_step_event(JavaThread * 0x00763258, methodOopDesc * 0x0c38cb48, unsigned char * 0x0c38cb88) line 3006 jvmdi::at_safepoint(JavaThread * 0x00763258, methodOopDesc * 0x0c38cb48, unsigned char * 0x0c38cb88) line 2855 + 17 bytes InterpreterRuntime::at_safepoint(JavaThread * 0x00763258) line 654 + 21 bytes 009a9798() JVM_G! unsigned char * StubRoutines::_code1 + 411 bytes JavaCalls::call_helper(JavaValue * 0x0006f67c, methodHandle * 0x0006f580, JavaCallArguments * 0x0006f5dc, Thread * 0x00763258) line 355 + 54 bytes os::os_exception_wrapper(void (JavaValue *, methodHandle *, JavaCallArguments *, Thread *)* 0x0800472d JavaCalls::call_helper(class JavaValue *,class methodHandle *,class JavaCallArguments *,class Thread *), JavaValue * 0x0006f67c, methodHandle * 0x0006f580, JavaCallArguments * 0x0006f5dc, Thread * 0x00763258) line 922 + 19 bytes JavaCalls::call(JavaValue * 0x0006f67c, methodHandle {...}, JavaCallArguments * 0x0006f5dc, Thread * 0x00763258) line 284 + 26 bytes JavaCalls::call_special(JavaValue * 0x0006f67c, KlassHandle {...}, symbolHandle {...}, symbolHandle {...}, JavaCallArguments * 0x0006f5dc, Thread * 0x00763258) line 215 + 21 bytes JavaCalls::call_special(JavaValue * 0x0006f67c, Handle {...}, KlassHandle {...}, symbolHandle {...}, symbolHandle {...}, Handle {...}, Handle {...}, Thread * 0x00763258) line 236 + 29 bytes SystemDictionary::validate_protection_domain(instanceKlassHandle {...}, Handle {...}, Handle {...}, Thread * 0x00763258) line 402 + 115 bytes SystemDictionary::resolve_instance_class_or_null(symbolHandle {...}, Handle {...}, Handle {...}, Thread * 0x00763258) line 528 + 21 bytes SystemDictionary::resolve_or_null(symbolHandle {...}, Handle {...}, Handle {...}, Thread * 0x00763258) line 344 + 21 bytes SystemDictionary::resolve_or_fail(symbolHandle {...}, Handle {...}, Handle {...}, long 0x00000001, Thread * 0x00763258) line 311 + 21 bytes constantPoolOopDesc::klass_at_impl(constantPoolHandle {...}, int 0x00000017, Thread * 0x00763258) line 48 + 31 bytes constantPoolOopDesc::klass_at(int 0x00000017, Thread * 0x00763258) line 160 + 17 bytes constantPoolOopDesc::klass_ref_at(int 0x00000100, Thread * 0x00763258) line 170 LinkResolver::resolve_klass(KlassHandle & {...}, constantPoolHandle {...}, int 0x00000100, Thread * 0x00763258) line 87 + 23 bytes LinkResolver::resolve_field(FieldAccessInfo & {...}, constantPoolHandle {...}, int 0x00000100, Bytecodes::Code _getstatic, long 0x00000000, long 0x00000001, Thread * 0x00763258) line 275 + 21 bytes LinkResolver::resolve_field(FieldAccessInfo & {...}, constantPoolHandle {...}, int 0x00000100, Bytecodes::Code _getstatic, long 0x00000000, Thread * 0x00763258) line 262 + 31 bytes InterpreterRuntime::resolve_get_put(JavaThread * 0x00763258, Bytecodes::Code _getstatic) line 395 + 29 bytes 009afced() JVM_G! unsigned char * StubRoutines::_code1 + 411 bytes JavaCalls::call_helper(JavaValue * 0x0006fcd4, methodHandle * 0x0006fbe4, JavaCallArguments * 0x0006fc28, Thread * 0x00763258) line 355 + 54 bytes os::os_exception_wrapper(void (JavaValue *, methodHandle *, JavaCallArguments *, Thread *)* 0x0800472d JavaCalls::call_helper(class JavaValue *,class methodHandle *,class JavaCallArguments *,class Thread *), JavaValue * 0x0006fcd4, methodHandle * 0x0006fbe4, JavaCallArguments * 0x0006fc28, Thread * 0x00763258) line 922 + 19 bytes JavaCalls::call(JavaValue * 0x0006fcd4, methodHandle {...}, JavaCallArguments * 0x0006fc28, Thread * 0x00763258) line 284 + 26 bytes jni_invoke(JNIEnv_ * 0x007632f0, JavaValue * 0x0006fcd4, _jobject * 0x00000000, JNICallType JNI_STATIC, _jmethodID * 0x0076f0a8, JNI_ArgumentPusher * 0x0006fcac, Thread * 0x00763258) line 590 + 21 bytes jni_CallStaticVoidMethod(JNIEnv_ * 0x007632f0, _jclass * 0x00764e58, _jmethodID * 0x0076f0a8) line 927 + 29 bytes JAVA_G! 004017d4() JAVA_G! 0040302f() KERNEL32! 77f1ba06() The second breakpoint event is posted via the following stack trace: jvmdi::post_single_step_event(JavaThread * 0x00763258, methodOopDesc * 0x0c3970f8, unsigned char * 0x0c397138) line 3006 jvmdi::at_safepoint(JavaThread * 0x00763258, methodOopDesc * 0x0c3970f8, unsigned char * 0x0c397138) line 2855 + 17 bytes InterpreterRuntime::at_safepoint(JavaThread * 0x00763258) line 654 + 21 bytes 009a9798() JVM_G! unsigned char * StubRoutines::_code1 + 411 bytes JavaCalls::call_helper(JavaValue * 0x0006fc58, methodHandle * 0x0006fb20, JavaCallArguments * 0x0006fb8c, Thread * 0x00763258) line 355 + 54 bytes os::os_exception_wrapper(void (JavaValue *, methodHandle *, JavaCallArguments *, Thread *)* 0x0800472d JavaCalls::call_helper(class JavaValue *,class methodHandle *,class JavaCallArguments *,class Thread *), JavaValue * 0x0006fc58, methodHandle * 0x0006fb20, JavaCallArguments * 0x0006fb8c, Thread * 0x00763258) line 922 + 19 bytes JavaCalls::call(JavaValue * 0x0006fc58, methodHandle {...}, JavaCallArguments * 0x0006fb8c, Thread * 0x00763258) line 284 + 26 bytes JavaCalls::call_virtual(JavaValue * 0x0006fc58, KlassHandle {...}, symbolHandle {...}, symbolHandle {...}, JavaCallArguments * 0x0006fb8c, Thread * 0x00763258) line 180 + 21 bytes JavaCalls::call_virtual(JavaValue * 0x0006fc58, Handle {...}, KlassHandle {...}, symbolHandle {...}, symbolHandle {...}, Thread * 0x00763258) line 186 + 29 bytes JavaThread::exit(long 0x00000000) line 875 + 70 bytes jni_DetachCurrentThread(JavaVM_ * 0x08286fd4 struct JavaVM_ main_vm) line 2100 JAVA_G! 00401813() JAVA_G! 0040302f() KERNEL32! 77f1ba06() During execution of the step, InterpreterRuntime::resolve_get_put() is called to resolve a reference made by the test's java code. During the link resolution process, some other java code is executed. Since the safepoint table is already in use, a single step event is sent for the "other" java code. From the jdb user's point of view, the same line of code at which the breakpoint executed is executed again via the subsequent "step". The next "step" command behaves as expected because the link resolution is done. daniel.daugherty@Eng 2000-05-22 The above problem is only the first layer of the onion. When single stepping is enabled after a breakpoint is hit, the change in safepoint tables causes the breakpoint instruction to be repeated. Sequence of events: JDB commands VM activities -------------- --------------------------------- jdb -listenany VM started set internal breakpoint stop in Class.main run set Class.main breakpoint interpret _breakpoint bytecode: breakpoint event posted thread sleeps waiting for jdb step notice_safepoints() called interpret _breakpoint bytecode finishes at_single_stepping_point() runs single step event posted interpret _breakpoint bytecode: breakpoint event posted thread sleeps waiting for jdb
29-07-2004

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