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

ThreadService::remove_thread_dump() must be called before memory free in jdk5

    XMLWordPrintable

    Details

    • Subcomponent:
      svc
    • Introduced In Version:
    • Resolved In Build:
      b08
    • CPU:
      x86
    • OS:
      windows_2008
    • Verification:
      Not verified

      Backports

        Description

        A JavaSE CU faces with an access violation during GC and java process terminated abnormally.
        A CU found some problem in JVM source code.

        The report and request is attached.

        =====
        Configuration:
         OS : Windows Server 2008(x64)
         JDk : 5u18(32bits)

        Our application calls java.lang.Thread.dumpThreads().
        When the crash occurred, 4 threads are calling dumpThreads().

        ----
          "http-9005-Processor9" prio=??? tid=0x2d3af830 nid=0x2820 runnable
            at java.lang.Thread.dumpThreads(Native Method)
            at java.lang.Thread.getStackTrace(Thread.java:1383)
                 ....
        ----

        We investigated the crash, Hotspot seemed to cause this during the following portion.

        ----
        hotspot/src/share/vm/services/threadServices.cpp

        [JDK 5.0]
          ThreadDumpResult::~ThreadDumpResult() {
            // free all the ThreadStackTrace objects created during
            // the VM_ThreadDump operation
            for (int i = 0; i < _num_threads; i++) {
              delete _traces[i]; << A >>
            }
            FREE_C_HEAP_ARRAY(ThreadStackTrace*, _traces); << B >>
            ThreadService::remove_thread_dump(this); << C >>
          }
        ----

        The above destructor frees memory at <A> and <B>,
        and delete "this" object from _threaddump_list at <C>


        When GC occurs at the same time, Java Thread may terminate
        at the following <D> just after ThreadService::remove_thread_dump()
        starts.

        ----

          void ThreadService::remove_thread_dump(ThreadDumpResult* dump) {
            MutexLocker ml(Management_lock); << D: JavaThread stops during GC >>
          
            ThreadDumpResult* prev = NULL;
            bool found = false;
            for (ThreadDumpResult* d = _threaddump_list; d != NULL; prev = d, d = d->next()) {
              if (d == dump) {
                if (prev == NULL) {
                  _threaddump_list = dump->next();
                } else {
                  prev->set_next(dump->next());
                }
                found = true;
                break;
              }
            }
            assert(found, "The threaddump result to be removed must exist.");
          }

        ----

        Assume this scenario,
         -some memory area are released at <A> and <B>,
         -OS dispatches other process(thread) until <C>,
         -the newly assigned process use the released area
          and GC starts at the same time
        In this case, Java Thread stops at <D>.

        Because "this" object still remains in _threaddump_list,
        the informaiton in memory pointed by ThreadDumpResult object is
        invalid, that is changed by other process(thread).

        We looked into dump file in our customers site,
        we found that the object is under incorrect status.

        We think ThreadService::remove_thread_dump() must be called
        before memory area is released in destructor of ThreadDumpResult.


        NOTE:
        In jdk6, ThreadService::remove_thread_dump() is called
        before memory release.

        ---
        ....

          ThreadDumpResult::~ThreadDumpResult() {
            ThreadService::remove_thread_dump(this);
          
            // free all the ThreadSnapshot objects created during
            // the VM_ThreadDump operation
            ThreadSnapshot* ts = _snapshots;
            while (ts != NULL) {
              ThreadSnapshot* p = ts;
              ts = ts->next();
              delete p;
            }
          }

        ....
        ---

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                minqi Yumin Qi
                Reporter:
                tbaba Tadayuki Baba (Inactive)
                Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: