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

memset() is called after operator new

    XMLWordPrintable

    Details

      Description

      Note: this bug can be reproduced in JDK 17u only.
      JDK 17u repo: https://github.com/openjdk/jdk17u
      gcc version 10.3.0 (GCC)

      For some reason, it's no longer reproducible in JDK mainline. For a simpler reproducer in the JDK mainline, see the second comment below.

      The following patch causes a crash in the delete operation:

      --- a/src/hotspot/share/classfile/systemDictionaryShared.cpp
      +++ b/src/hotspot/share/classfile/systemDictionaryShared.cpp
      @@ -1257,6 +1257,8 @@ DumpTimeSharedClassInfo* SystemDictionaryShared::find_or_allocate_info_for_locke
         assert_lock_strong(DumpTimeTable_lock);
         if (_dumptime_table == NULL) {
           _dumptime_table = new (ResourceObj::C_HEAP, mtClass)DumpTimeSharedClassTable();
      + delete _dumptime_table;
      + _dumptime_table = new (ResourceObj::C_HEAP, mtClass)DumpTimeSharedClassTable();
         }
         return _dumptime_table->find_or_allocate_info_for(k, _dump_in_progress);
       }

      Gcc generates the following code:

         0x00007ffff6681adc <+14>: mov $0x2,%esi
         0x00007ffff6681ae1 <+19>: mov $0x1f0a8,%edi
         0x00007ffff6681ae6 <+24>: callq 0x7ffff5a2e7dc <ResourceObj::operator new(unsigned long, ResourceObj::allocation_type, MEMFLAGS)>
         0x00007ffff6681aeb <+29>: mov %rax,%rbx
         0x00007ffff6681aee <+32>: test %rbx,%rbx
         0x00007ffff6681af1 <+35>: je 0x7ffff6681b10 <foofoo()+66>
         0x00007ffff6681af3 <+37>: mov %rbx,%rax
         0x00007ffff6681af6 <+40>: mov $0x1f0a8,%edx
         0x00007ffff6681afb <+45>: mov $0x0,%esi
         0x00007ffff6681b00 <+50>: mov %rax,%rdi
      >>>0x00007ffff6681b03 <+53>: callq 0x7ffff5827470 <memset@plt> <<<<<<<<<<<<<<<<< HERE
         0x00007ffff6681b08 <+58>: mov %rbx,%rdi
         0x00007ffff6681b0b <+61>: callq 0x7ffff6687db8 <DumpTimeSharedClassTable::DumpTimeSharedClassTable()>

      ResourceObj::_allocation_t is initialized inside the new operator, and it gets trashed by the subsequent call to memset().

      As a result, we get an assertion failure inside the destructor:

      $ java -Xshare:dump
      [....]
      # Internal Error (/jdk2/mnd/open/src/hotspot/share/memory/allocation.cpp:190), pid=10343, tid=10344
      # assert(~(_allocation_t[0] | allocation_mask) == (uintptr_t)this) failed: lost resource object

      V [libjvm.so+0x4ebb89] ResourceObj::get_allocation_type() const+0x31
      V [libjvm.so+0x4ec0e8] ResourceObj::allocated_on_C_heap() const+0x18
      V [libjvm.so+0x4eb9f0] ResourceObj::operator delete(void*)+0x18
      V [libjvm.so+0x113eb17] SystemDictionaryShared::find_or_allocate_info_for_locked(InstanceKlass*)+0x8b


      However, adding a dummy constructor for DumpTimeSharedClassTable makes the problem goes away. The memset is no longer generated by gcc.

      ==================
      --- a/src/hotspot/share/classfile/systemDictionaryShared.cpp
      +++ b/src/hotspot/share/classfile/systemDictionaryShared.cpp
      @@ -219,6 +219,7 @@ class DumpTimeSharedClassTable: public ResourceHashtable<
         int _builtin_count;
         int _unregistered_count;
       public:
      + DumpTimeSharedClassTable(int dummy) {}
         DumpTimeSharedClassInfo* find_or_allocate_info_for(InstanceKlass* k, bool dump_in_progress) {
           bool created = false;
           DumpTimeSharedClassInfo* p;
      @@ -1256,7 +1257,9 @@ DumpTimeSharedClassInfo* SystemDictionaryShared::find_or_allocate_info_for(Insta
       DumpTimeSharedClassInfo* SystemDictionaryShared::find_or_allocate_info_for_locked(InstanceKlass* k) {
         assert_lock_strong(DumpTimeTable_lock);
         if (_dumptime_table == NULL) {
      - _dumptime_table = new (ResourceObj::C_HEAP, mtClass)DumpTimeSharedClassTable();
      + _dumptime_table = new (ResourceObj::C_HEAP, mtClass)DumpTimeSharedClassTable(0);
      + delete _dumptime_table;
      + _dumptime_table = new (ResourceObj::C_HEAP, mtClass)DumpTimeSharedClassTable(0);
         }
         return _dumptime_table->find_or_allocate_info_for(k, _dump_in_progress);
       }

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              iklam Ioi Lam
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated: