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

Memory leaks of C-heap allocated ResourceObjs

    XMLWordPrintable

    Details

    • Type: Backport
    • Status: Resolved
    • Priority: P2
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.4.2_14
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
      gc
    • Introduced In Build:
      1.4.1
    • Introduced In Version:
    • Resolved In Build:
      b01

      Description

      Certain GrowableArrays are being allocated with the "C_heap" flag set
      to true but without the ResourceObj::C_HEAP flag being passed to
      operator new for the GrowableArray object itself. This is a problem
      because it is very easy to accidentally allocate the GrowableArray
      underneath a ResourceMark which is later cleared, which will cause the
      storage for the GrowableArray object itself (including nesting, arena,
      and data pointer flags) to be overwritten later. This can cause
      crashes in product mode and/or assertion failures in debug mode. In
      the absence of assertions that the allocation class of the
      GrowableArray matches that of its contained data array, these
      allocation sites should be fixed to pass ResourceObj::C_HEAP as
      argument to operator new. It is possible that these sites are benign
      because the allocation is being done at a point where the ResourceMark
      nesting is known, but if we add assertion checking later then these
      allocation sites will fail.

      When making this change the responsible engineer should be careful not
      to introduce new memory leaks. In particular, the following cleanup
      sequence for these arrays should be obeyed:

        array->clear_and_deallocate();
        delete array; // call destructors, but ResourceObj destructor
                      // doesn't free memory which was allocated in
                      // the C-heap with malloc
        FreeHeap(Array); // ... so use this to free the memory

      See Label::free() in assembler.hpp for an example.

      The relevant allocation sites for this group's code are attached.

      ------------------------------------------------------------------

      Adding specifics to the description for gc:

      hotspot/garbage_collector:
      src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp:540: _preserved_oop_stack = new (ResourceObj::C_HEAP) GrowableArray<oop>(40, true);
      src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp:539: _preserved_mark_stack = new (ResourceObj::C_HEAP) GrowableArray<markOop>(40, true);
      src/share/vm/gc_implementation/shared/markSweep.cpp:118: _preserved_mark_stack = new (ResourceObj::C_HEAP) GrowableArray<markOop>(40, true);
      src/share/vm/gc_implementation/shared/markSweep.cpp:119: _preserved_oop_stack = new (ResourceObj::C_HEAP) GrowableArray<oop>(40, true);
         - stacks are deleted but FreeHeap is not called on them
      src/share/vm/memory/defNewGeneration.cpp:595: _objs_with_preserved_marks = new (ResourceObj::C_HEAP)
      src/share/vm/memory/defNewGeneration.cpp:597: _preserved_marks_of_objs = new (ResourceObj::C_HEAP)
         - stacks are deleted but FreeHeap is not called on them; also, no
           clear_and_deallocate is called (** SERIOUS **)
         - genMarkSweep.cpp: _preserved_mark_stack and _preserved_oop_stack:
           call FreeHeap after operator delete

      Above Information was written by kenneth.russell [2005-08-05 00:31]

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              poonam Poonam Bajaj Parhar
              Reporter:
              coleenp Coleen Phillimore
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: