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

JDK-8258284 introduced dangling TLH race

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • P3
    • 17
    • 17
    • hotspot
    • b03
    • 17
    • b17
    • generic
    • generic

    Description

      I ported some 20 year old tests using JDK-8262881 in order to help
      test [~rehn]'s fix for JDK-8257831. These tests in combination with
      one piece of the fix from JDK-8257831 revealed a bug in my fix for
      JDK-8258284 from back in Dec 2020.

      The race revealed by the ported tests from JDK-8262881 happens
      only with nested ThreadsListHandles. When TLH2 is destroyed, the
      thread updates its threads_hazard_ptr from the TLH2-list to the
      TLH1-list; I made this change back in 2020.12 using JDK-8258284.
      The threads_hazard_ptr can be observed by a thread calling
      ThreadsSMRSupport::free_list() as a stable ThreadsList at the same
      time as the TLH1 destructor is decrementing the nested_handle_cnt
      that permits the ThreadsList to be freed. So the thread calling
      ThreadsSMRSupport::free_list() thinks it has a stable hazard ptr
      (TLH1-list), but that hazard ptr can be freed and causes lots of
      confusion.

      Attachments

        Issue Links

          Activity

            People

              dcubed Daniel Daugherty
              dcubed Daniel Daugherty
              Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: