-
Type:
Improvement
-
Resolution: Fixed
-
Priority:
Major - P3
-
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
- 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: