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
  test/com/sun/jdi/JdbMethodExitTest.sh:

   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
   274
   275
   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
  cont
  untrace
  step up
  step

- 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();

  main[1]
  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.