This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients Vladimir.Ushakov, christian.heimes, jcea, neologix, pitrou, vstinner
Date 2012-10-14.15:04:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM3jmCMa=w2HrGXyQvCQ+BLbs2tieoqwanJynnSyVimqGQ@mail.gmail.com>
In-reply-to <1350205488.51.0.396212784135.issue16212@psf.upfronthosting.co.za>
Content
> 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.
History
Date User Action Args
2012-10-14 15:04:26neologixsetrecipients: + neologix, jcea, pitrou, vstinner, christian.heimes, Vladimir.Ushakov
2012-10-14 15:04:25neologixlinkissue16212 messages
2012-10-14 15:04:25neologixcreate