Improve diagnostic logging for SIGSEGV, SIGBUS, SIGILL, and SIGFPE

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Fixed
    • Priority: Major - P3
    • 7.2.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Service Arch
    • Fully Compatible
    • v7.0, v6.0
    • Service Arch 2023-01-23, Service Arch 2023-02-06, Service Arch 2023-05-15, Service Arch 2023-07-24, Service Arch 2023-08-07, Service Arch 2023-08-21, Service Arch 2023-09-04, Service Arch 2023-09-18
    • 5
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      Currently, when we receive SIGSEGV, SIGBUS, SIGILL, or SIGFPE, we only log the following information:

      • whether the the signal was an invalid access or invalid operation
      • what address triggered the signal (i.e. the si_addr field in siginfo_t we receive)
      • the signal number
      • the backtrace

      While this information is often enough, there are cases where we need more diagnostic information than what we log right now, information which is available in our signal handler, but discarded by it.

      Furthermore, because our signal handler ends up calling raise to terminate the process, the contents of siginfo_t that get written to the core dump don't correspond to the siginfo_t we receive in our signal handler.

      At the very minimum we should:

      • log the contents of si_code
      • emit an informative message that explains that the contents of $_siginfo in GDB don't represent the information that was received in the signal handler

      Further possible improvements are to log:

      • the entire contents of siginfo_t as a hex blob
      • architecture-specific information accessible via ucontext_t
        • on x86_64, for segfaults, we can emit the contents of uc_mcontext.gregs[REG_ERR] to help distinguish whether the fault was caused by:
          • a read or a write access
          • a kernel-mode or a user-mode access
          • an instruction fetch or not

            Assignee:
            Vojislav Stojkovic
            Reporter:
            Vojislav Stojkovic
            Votes:
            1 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: