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

AsyncGetCallTrace crashes on ResourceMark

    XMLWordPrintable

Details

    • svc
    • b27

    Backports

      Description

        While running a fastdebug build I hit this:

        # To suppress the following error report, specify this argument
        # after -XX: or in .hotspotrc: SuppressErrorAt=/resourceArea.hpp:117
        #
        # A fatal error has been detected by the Java Runtime Environment:
        #
        # Internal Error (/Users/graal2/slave/e/main/jdk_tlda/open/src/hotspot/share/memory/resourceArea.hpp:117), pid=85699, tid=6403
        # assert(size_in_bytes() > state._size_in_bytes) failed: size: 984, saved size: 984

        V [libjvm.dylib+0x11730ed] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x6dd
        V [libjvm.dylib+0x117370b] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x3b
        V [libjvm.dylib+0x6177ef] report_vm_error(char const*, int, char const*, char const*, ...)+0x13f
        V [libjvm.dylib+0x5582] ResourceArea::rollback_to(ResourceArea::SavedState const&)+0x82
        V [libjvm.dylib+0x2d0c05] ResourceMark::~ResourceMark()+0x35
        V [libjvm.dylib+0xdd40d2] Method::bci_from(unsigned char*) const+0xe2
        V [libjvm.dylib+0xdd4162] Method::validate_bci_from_bcp(unsigned char*) const+0x52
        V [libjvm.dylib+0x6f980e] forte_fill_call_trace_given_top(JavaThread*, ASGCT_CallTrace*, int, frame)+0x42e
        V [libjvm.dylib+0x6f93b9] AsyncGetCallTrace+0x249
        C [libasyncProfiler.so+0x116c7] Profiler::getJavaTraceAsync(void*, ASGCT_CallFrame*, int)+0xc7
        C [libasyncProfiler.so+0x12379] Profiler::recordSample(void*, unsigned long long, int, _jmethodID*, ThreadState)+0x379
        C [libasyncProfiler.so+0x1923e] WallClock::signalHandler(int, __siginfo*, void*)+0x9e
        C [libsystem_platform.dylib+0x3d7d] _sigtramp+0x1d

        I think you can end up with a following chunk without changing the size of the current chunk if your allocation is bigger than the remaining space in the current chunk. So I think it should be >=. This seems to have been introduced by JDK-8251850.

        Attachments

          Issue Links

            Activity

              People

                coleenp Coleen Phillimore
                never Tom Rodriguez
                Votes:
                0 Vote for this issue
                Watchers:
                10 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: