Charles-François Natali added the comment: > SIGBUS as well as SIGFPE or SIGSEGV is a synchronous signal. It is delivered > to the thread that caused the trouble and the stack contents is well defined.
Except that signal handlers are per-process, not per thread. So if another thread (which could be running without the GIL, e.g. doing some lengthy computation) triggers a SIGBUS while the handler is setup, it's going to try to longjmp to the jmp_buf set by the other thread. And this will get really nasty. > >> https://www.securecoding.cert.org/confluence/display/seccode/SIG35-C.+Do+not+return+from+SIGSEGV,+SIGILL,+or+SIGFPE+signal+handlers > > Does not apply here: longjmp is not a return. I still don't understand how you plan to handle the SIGBUS/SIGSEGV. Where will you longjmp to? If the idea is to dump a traceback and exit, then there's faulthandler for that. As for the stack content, variables with automatic storage class (i.e. local variables) modified should be declared volatile (which may or may not be an issue here). >> https://www.securecoding.cert.org/confluence/display/seccode/SIG32-C.+Do+not+call+longjmp%28%29+from+inside+a+signal+handler > > The grounds are weak. They refer to SIG30-C, which is based on ISO C standard. > > POSIX explicitly declares the fact that longjmp is allowed to exit signal > handlers as an extension to ISO C standard. It is allowed, but as said earlier, 99% of use cases are just wrong. > Besides, POSIX explicitly states that only async-signal-safe functions can be > called from the handlers, which "are invoked asynchronously with process > execution". That's not out case as mentioned above, we are not in > asynchronous context as it could be with, say, SIGINT. Well, nothing prevents "kill -SEGV <PID>". Besides, setjmp() is expensive, and here we would be setting up a jmp_buf even for a single byte memory access. But I think we've talked enough :-) Honestly, if you manage to find a way to handle this, I'll be happy to commit it, so don't hesitate if you think you've found an approach that will work. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16212> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
