According to "man sigaction"
"All functions not in the above lists are considered to be unsafe with respect to signals. That is to say, the behaviour of such functions when called from a signal handler is undefined. In general though, signal handlers should do
little more than set a flag; most other actions are not safe."
So most of our existing error handling code is out of compliance here.
Additional consequence of moving it out of process is that other parts of VM would benefit, like our current WX memory protection mechanism, that requires non-null thread.
For WX memory protection we could be using statically created pthread TLS mechanism to keep track of the state.
"All functions not in the above lists are considered to be unsafe with respect to signals. That is to say, the behaviour of such functions when called from a signal handler is undefined. In general though, signal handlers should do
little more than set a flag; most other actions are not safe."
So most of our existing error handling code is out of compliance here.
Additional consequence of moving it out of process is that other parts of VM would benefit, like our current WX memory protection mechanism, that requires non-null thread.
For WX memory protection we could be using statically created pthread TLS mechanism to keep track of the state.
- relates to
-
JDK-8327860 Java processes get killed, leaving no hs_err/stack trace on macOS 14.4
- Closed
-
JDK-8301403 Eliminate memory allocations in JVMFlag::printFlags during signal handling
- Resolved