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

Corrupt oop in ClassLoaderData

XMLWordPrintable

    • b07
    • x86
    • linux

        Very occasionally (but frequently enough to cause problems), we see a crash in the Serial collector when it's visiting oops in the `ClassLoaderData`. In these cases, the application is invoked with `-Xshare:on`. The stack trace looks like:

        ```
        V [libjvm.so+0x6cba4c] DefNewGeneration::copy_to_survivor_space(oopDesc*)+0xac
        V [libjvm.so+0x58869c] FastScanClosure::do_oop(oopDesc**)+0x8c
        V [libjvm.so+0x60bb6a] ClassLoaderData::oops_do(OopClosure*, bool, bool)+0x7a
        V [libjvm.so+0x6c9c8a] CLDScanClosure::do_cld(ClassLoaderData*)+0x3a
        V [libjvm.so+0x60e3c9] ClassLoaderDataGraph::roots_cld_do(CLDClosure*, CLDClosure*)+0x39
        V [libjvm.so+0x822beb] GenCollectedHeap::young_process_roots(StrongRootsScope*, OopsInGenClosure*, OopsInGenClosure*, CLDClosure*, OopStorage::ParState<false, false>*)+0x26b
        V [libjvm.so+0x6cc8ed] DefNewGeneration::collect(bool, bool, unsigned long, bool)+0x4bd
        V [libjvm.so+0x823c8d] GenCollectedHeap::collect_generation(Generation*, bool, unsigned long, bool, bool, bool, bool)+0x26d
        V [libjvm.so+0x824548] GenCollectedHeap::do_collection(bool, bool, unsigned long, bool, GenCollectedHeap::GenerationType)+0x2e8
        V [libjvm.so+0x8252b8] GenCollectedHeap::satisfy_failed_allocation(unsigned long, bool)+0x1e8
        V [libjvm.so+0xf37f0f] VM_GenCollectForAllocation::doit()+0x8f
        V [libjvm.so+0xf39547] VM_Operation::evaluate()+0xe7
        V [libjvm.so+0xf3fa06] VMThread::evaluate_operation(VM_Operation*) [clone .constprop.67]+0xb6
        V [libjvm.so+0xf3ff38] VMThread::loop()+0x428
        V [libjvm.so+0xf403d3] VMThread::run()+0x73
        ```

        It's crashing on `oop->size()`. The oop here is passed in RDI, RAX holds the `klass` pointer (which is null here):
        ```
        RAX=0x0 is NULL
        ...
        RDI=0x0000000800099120 is pointing into metadata
        ```
        The metadata here is mapped to the shared archive:
        ```
        800000000-800003000 rwxp 00001000 fe:00 543305 /var/lang/lib/server/runtime.jsa
        800003000-80064b000 rw-p 00004000 fe:00 543305 /var/lang/lib/server/runtime.jsa
        80064b000-80107f000 r--p 0064c000 fe:00 543305 /var/lang/lib/server/runtime.jsa
        80107f000-801080000 rw-p 01080000 fe:00 543305 /var/lang/lib/server/runtime.jsa
        801080000-801a90000 r--p 01081000 fe:00 543305 /var/lang/lib/server/runtime.jsa
        ```

        Crash log file is attached. The environment here makes it difficult to collect core files or make changes to the command line parameters. I suspect it's an issue with CDS.

          1. cds-trace.log
            1.12 MB
          2. disasm.s
            7 kB
          3. disasm-by-gcc-7.3.0-1.s
            9 kB
          4. hs_err_11.0.8+10.log
            55 kB
          5. hs_err_11.0.9.1+12.log
            56 kB
          6. hs_err_2.log
            53 kB
          7. hs_err_3.log
            55 kB
          8. hs_err_4.log
            55 kB
          9. hs_err_mark_and_push.log
            221 kB
          10. hs_err_possibly_not_related.log
            60 kB

              coleenp Coleen Phillimore
              wkemper William Kemper
              Votes:
              0 Vote for this issue
              Watchers:
              12 Start watching this issue

                Created:
                Updated:
                Resolved: