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

crash_handler code makes safepoint polling threads look like they crashed

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Won't Fix
    • Affects Version/s: 13, 14
    • Fix Version/s: tbd
    • Component/s: hotspot
    • Labels:
      None

      Description

      In debugging a crash, where one thread hit an assert, we were waylaid trying to figure out why two other threads also looked like they failed because in this core file two other threads called report_and_die from crash_handler from a Java frame:

         0x7f2af82d7794: mov 0x108(%r15),%r10
         0x7f2af82d779b: movabs $0x4637f38c0,%r8
      => 0x7f2af82d77a5: test %eax,(%r10)
      r15 is the thread
      r15 0x7f2a706ff800 139820251740160
      r10 is the thing we can't read
      r10 0x7f2b0d231008 139822880722952
      (gdb) x 0x7f2b0d231008
      0x7f2b0d231008: Cannot access memory at address 0x7f2b0d231008
      (gdb) print *(Thread*)0x7f2a706ff800
      $2 = {<ThreadShadow> = {<CHeapObj<(MemoryType)2>> = {<No data fields>},
          _vptr.ThreadShadow = 0x7f2b0c4eacf8 <vtable for JavaThread+16>, _pending_exception = 0x0, _exception_file = 0x0,
      ...
        _threads_do_token = 66652, _rcu_counter = 0, _polling_page = 0x7f2b0d231008,

      This is the polling page address.

      I don't know why the signal handler is not JVM_handle_linux_signal for this thread anymore, which would have done the right thing for the safepoint polling address (and other signals that that code handles). It shouldn't be crash_handler anyway.


        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              coleenp Coleen Phillimore
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: