Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6902121

intermittent JdbMethodExitTest timeout



    • Subcomponent:
    • CPU:
    • OS:


      During my baseline testing of the following JDK promotion:

          java version "1.7.0-ea"
          Java(TM) SE Runtime Environment (build 1.7.0-ea-b76)
          Java HotSpot(TM) Server VM (build 17.0-b05, mixed mode)

      the following JDI_REGRESSION test timed out:

      RULE com/sun/jdi/JdbMethodExitTest.sh Timeout any

      on my Solaris X86 test machine:

          % uname -a
          SunOS oliver-gs 5.10 Generic_137138-09 i86pc i386 i86pc
          % psrinfo -v
          Status of virtual processor 0 as of: 11/17/2009 10:19:53
            on-line since 10/03/2009 21:14:48.
            The i386 processor operates at 2800 MHz,
              and has an i387 compatible floating point processor.
          Status of virtual processor 1 as of: 11/17/2009 10:19:53
            on-line since 10/03/2009 21:15:03.
            The i386 processor operates at 2800 MHz,
              and has an i387 compatible floating point processor.

      The .jtr timestamps show the previous tests and following
      tests executed quickly:

      -rw-rw-r-- 1 dcubed green 1628 Nov 13 18:20 JdbArgTest.jtr
      -rw-rw-r-- 1 dcubed green 3347 Nov 13 18:20 JdbLockTest.jtr
      drwxrwxr-x 2 dcubed green 512 Nov 13 18:20 JdbMethodExitTest/
      -rw-rw-r-- 1 dcubed green 25436 Nov 13 18:21 JdbMethodExitTest.jtr
      -rw-rw-r-- 1 dcubed green 3335 Nov 13 18:21 JdbMissStep.jtr

      /var/adm/messages showed no messages during this time frame.

      Since these were product JDK and product VM bits, this test
      shouldn't have timed out.

      I've attached the complete .jtr file, but here are some
      observations about the failure:

      - the test was executing the following block in

         268 cmd step # step into traceExit()
         269 cmd trace method exit
         270 cmd cont
         271 jdbFailIfNotPresent "Method exited: return value = \"traceExit\""
         272 cmd untrace
         273 cmd step up
         276 cmd step
         277 cmd step # skip over setting return value in caller :-(
         278 cmd trace go method exit
         279 cmd cont
         280 jdbFailIfNotPresent 'Method exited: .*JdbMethodExitTest.traceExit1'
         281 cmd quit

         The test had just finished the "traceExit" test and was starting
         on the "traceExit1" test which is the last test section. So the
         test had just finished line 276 and was starting line 277.

      - the last few commands sent by the test script are:

        trace method exit
        step up

      - the test output shows the results of the above commands:

        main[1] main[1] >
        Method exited: return value = "traceExit", "thread=main", JdbMethodExitTest.traceExit(), line=104 bci=2
        104 return "traceExit";

        main[1] main[1] >
        Step completed: "thread=main", JdbMethodExitTest.main(), line=139 bci=43
        139 traceExit();

        Step completed: "thread=main", JdbMethodExitTest.main(), line=142 bci=44
        142 traceExit1();

        main[1] > Input stream closed.

      - the TestScaffold detected that the test was stuck; the jstack output
        shows something interesting:

      ----------------- t@2 -----------------
      0xfeec9455 ___lwp_cond_wait + 0x15
      0xfea3998e void os::PlatformEvent::park() + 0xb2
      0xfea20f39 int ParkCommon(ParkEvent*,long long) + 0x59
      0xfea2148d int Monitor::IWait(Thread*,long long) + 0xa5
      0xfea21d3a bool Monitor::wait(bool,long,bool) + 0x256
      0xfeb2f004 int JavaThread::java_suspend_self() + 0xe0
      0xfeb0fb78 int ObjectMonitor::raw_wait(long long,bool,Thread*) + 0x140
      0xfe95669e jvmtiError JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long long)
      + 0xde
      0xfe8f4531 jvmti_RawMonitorWait + 0x139
      0xfe14972d debugMonitorWait + 0x31
      0xfe13959d enqueueCommand + 0x14d
      0xfe13acdc eventHelper_reportEvents + 0xf0
      0xfe135505 reportEvents + 0x131
      0xfe135a35 event_callback + 0x345
      0xfe135dbb cbSingleStep + 0x11b
      0xfe9661ca void JvmtiExport::post_single_step(JavaThread*,methodOopDesc*,unsigned char*) + 0x67a
      0xfe9619fd void JvmtiExport::at_single_stepping_point(JavaThread*,methodOopDesc*,unsigned char*) + 0x195
      0xfe5f4d68 void InterpreterRuntime::at_safepoint(JavaThread*) + 0x250
      0xfb00b9ae * JdbMethodExitTest.main(java.lang.String[]) bci:44 line:142 (Interpreted frame)
      0xfb000348 <StubRoutines>
      0xfe51ea36 void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*) + 0x1c2
      0xfe51ece7 void os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*)
      + 0x17
      0xfe51ed1b void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*) + 0x2f
      0xfe5ab1cc void jni_invoke_static(JNIEnv_*,JavaValue*,_jobject*,JNICallType,_jmethodID*,JNI_ArgumentPusher*,Thread*) + 0xe8
      0xfe5b51bb jni_CallStaticVoidMethod + 0x97
      0xfef734af JavaMain + 0x88f
      0xfeec59b9 _thr_setup + 0x4e
      0xfeec5ca0 _lwp_start

      The thread that is posting a single step event has self suspended
      due to a external suspend request. This might be part of the usual
      single-step implementation and not an indication of a problem; I
      have some vague memories that single stepping uses suspend/resume
      combined with InterpreterRuntime::at_safepoint() in order to make
      sure that each bytecode is stepped.


          Issue Links



              Unassigned Unassigned
              dcubed Daniel Daugherty
              0 Vote for this issue
              3 Start watching this issue