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

vmTestbase/nsk/jdi/Event/request/request001 can still fail with "ERROR: new event is not ThreadStartEvent"

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 18
    • Fix Version/s: 18
    • Component/s: core-svc
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b16

      Description

      JDK-8262080 attempted to fix the issue of request001 failing due to unexpected THREAD_START events for threads unrelated to the test. However, the fix is not working, and fails consistently with loom, which creates a large number of carrier threads if the test is run in vthread wrapper mode.

      The problem is when JDIBase.getEventSetForThreadStartDeath() is called. It is suppose to exit when a THREAD_START or THREAD_END event arrives for the named thread, and skip all other THREAD_START and THREAD_END events, so it should work when there are extra THREAD_START events for carrier threads. However, there are two bugs, one in the test and one in getEventSetForThreadStartDeath().

      The bug in the test is that it adds a count filter of 1 to the ThreadStartRequest (and ThreadDeathRequest). This means that once the first spurious THREAD_START is received, all future THREAD_START event are filtered out. I'm not sure why the count filter was added in the first place (it was there before your fix). I think it can be removed, although to be extra safe probably the event request should also be disabled once the event is received.

      The other bug has its origins in the test, but is really in getEventSetForThreadStartDeath(). The test sets up the ThreadStartRequest and ThreadDeathRequest with a suspend policy of SUSPEND_ALL. This means once the first spurious THREAD_START is received, all threads are suspended and never resume. A call to vm.resume() is needed after each of these spurious events. Otherwise the test just times out waiting for the next event.

      After fixing these two issues I have the test passing, but I'm a little unsure if they are proper fixes. It looks like the only other test could end up with this same issue is nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001, although I haven't seen it fail. That's probably because it only uses getEventSetForThreadStartDeath() for the THREAD_END event, and we don't get any spurious THREAD_END events. So it is likely not going to be impacted by my changes.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              amenkov Alex Menkov
              Reporter:
              cjplummer Chris Plummer
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: