
Add new tests: - traceme_crash_trap - traceme_crash_segv - traceme_crash_ill (temporarily disabled) - traceme_crash_fpe - traceme_crash_bus - unrelated_tracer_sees_crash_trap - unrelated_tracer_sees_crash_segv - unrelated_tracer_sees_crash_ill (temporarily disabled) - unrelated_tracer_sees_crash_fpe - unrelated_tracer_sees_crash_bus These tests verify two subtle kernel paths that differ internally: - for a tracer that is a parent of a traced program (and not vforked) real parent == tracer - for a tracer that is an unrelated process of a traced program real parent != tracer Regressions in the signal code can cause to break one of the scenarios, and keep working the other one. It might be propagated to a scenario like: - attaching to a process with a debugger (over pid) - starting a process inside a debugger We can assert on the ATF level that both will be functional. While there, cover all the crash signals as testing is done practically for free. While the Machine Independent signal routing code for crash signals is mostly the same in the kernel, we can verify whether Machine Dependent parts works as expected emitting the proper signal number and signal code (si_code). There have been already caught an unexpected behavior on Alpha, that instead of SIGBUS we receive SIGSEGV. Another benefit is that it's easier to catch races, as they pop up more frequently. (This already helped to catch bugs more quickly) These tests will help assert correctness of future kernel changes in the signal routines. All tests pass. Sponsored by <The NetBSD Foundation>
…
…
…
…
…
…
…
Description
No description provided
Languages
C
85.3%
Roff
7.2%
Assembly
3.1%
Shell
1.7%
Makefile
1.2%
Other
0.9%