[issue1215] Python hang when catching a segfault
Martin Pool m...@sourcefrog.net added the comment: The documentation for this can now point to the faulthandler module (in Python 3). -- nosy: +poolie ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1215 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1215] Python hang when catching a segfault
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: The consensus is that this is not a crash (and not even a bug). I am not sure what is the proper type for doc enhancement, but is certainly should not show up in a search for crashers. -- components: -Interpreter Core nosy: +belopolsky type: crash - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1215 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1215] Python hang when catching a segfault
Mark Lawrence breamore...@yahoo.co.uk added the comment: There are several suggestions inline as how how the docs should be changed. -- assignee: - d...@python nosy: +BreamoreBoy, d...@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1215 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1215] Python hang when catching a segfault
Terry J. Reedy tjre...@udel.edu added the comment: From the comments, it seems like this should be changed to a doc issue. Given that I do not know a 'synchronous' from an 'asynchronous' signal, I would want an expanded list if I were using this module. Strengthening 'little sense' to 'do not do it' makes sense, at least for 2.7 and 3.2. -- nosy: +tjreedy versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1215 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1215] Python hang when catching a segfault
Georg Brandl [EMAIL PROTECTED] added the comment: The docs already say Because the C signal handler always returns, it makes little sense to catch synchronous errors like :const:`SIGFPE` or :const:`SIGSEGV`. Should this still be reworded or promoted to a warning? -- nosy: +georg.brandl ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1215 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1215] Python hang when catching a segfault
Adam Olsen [EMAIL PROTECTED] added the comment: I'm in favour of just the doc change now. It's less work and we don't really need to disable that usage. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1215 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1215] Python hang when catching a segfault
Changes by Christian Heimes: -- components: +Documentation keywords: +easy priority: - normal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1215 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1215] Python hang when catching a segfault
Guido van Rossum added the comment: I'm not sure what the point of that would be. Somebody might want to send these asynchronously (using kill) which we might legitimately want to catch. Also you don't know which other synchronous signals a platform might define. I think at best a doc update on the relative uselessness of handlers for synchronous signals (with examples) is all we need. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1215 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1215] Python hang when catching a segfault
Ralf Schmitt added the comment: Those who want to legitimately catch SIGSEGV will end up with an uninterruptible python process using 100 % CPU on a real segmentation fault. But, then I can live with the current behaviour. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1215 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1215] Python hang when catching a segfault
Adam Olsen added the comment: In essence, it's a weakness of the POSIX API that it doesn't distinguish synchronous from asynchronous signals. The consequences of either approach seem minor though. I cannot imagine a sane use case for catching SIGSEGV, but documentation changes should be sufficient anyway. Suggested wording, if you take the documentation-only approach: Because of the precarious nature of how synchronously-generated signals must be handled, it is impossible to handle them correctly from python. You should never install handlers for synchronously-generated signals, such as SIGSEGV and SIGFPE. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1215 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1215] Python hang when catching a segfault
Ralf Schmitt added the comment: Should I work on a patch, which makes signal.signal raise an Exception for SIGSEGV, SIGBUS, SIGFPE,...? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1215 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1215] Python hang when catching a segfault
Ralf Schmitt added the comment: If you replace your call segfault.segfault() with os.kill(os.getpid(), signal.SIGSEGV) everything works as expected. The problem is that the signal is just caught in the c handler (and a flag is set) and then the program continues with the offending *c = 'a'; statement, which again ends with a SIGSEGV and the handler being called. The documentation explicitly states Because the C signal handler always returns, it makes little sense to catch synchronous errors like SIGFPE or SIGSEGV. I think raising that InvalidArgument exception is most probably the right thing to do (or at least printing a warning). Those that really want to handle SIGSEGV should do it from C anyway. -- nosy: +schmir __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1215 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1215] Python hang when catching a segfault
Adam Olsen added the comment: The warning in the documentation should be strengthened. Python simply does not and cannot support synchronously-generated signals. It is possible to send a normally synchronous signal asynchronously, such as the os.kill() Ralf mentioned, so it's theoretically possible to use custom handlers for them. However, I can't think of any real use cases, and having such a handler would be asking for trouble if a real synchronously-generated signal was produced. I guess that's an argument for not allowing custom handlers. ;) Suggested documentation: Because of the precarious nature of how synchronously-generated signals must be handled, the signal module does not allow installing handlers for them. This includes SIGSEGV, SIGFPE, SIGBUS, SIGILL, SIGABRT... I haven't been able to find a canonical list if synchronously-generated signals. Furthermore, I've seen conflicting claims about SIGABRT. -- nosy: +Rhamphoryncus __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1215 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1215] Python hang when catching a segfault
Guido van Rossum added the comment: Why is this a Python bug? -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1215 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1215] Python hang when catching a segfault
Miki Tebeka added the comment: Because it hangs Python :) I know, while 1: pass also hangs Python, however it'll nice if this behaviour was documented or (IMO better) that Python will raise an InvalidArgument exception on SIGSEGV (like it does for SIGKILL). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1215 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1215] Python hang when catching a segfault
New submission from Miki Tebeka:
The following code hangs Python:
#!/usr/bin/env python
import segfault
import signal
from os import _exit
from sys import stdout
def handler(signal, stackframe):
print OUCH
stdout.flush()
_exit(1)
if __name__ == __main__:
from sys import argv
signal.signal(signal.SIGSEGV, handler)
segfault.segfault()
segfault is the following C module:
#include Python.h
static PyObject *
segfault(PyObject *self, PyObject *args)
{
char *c;
c = 0;
*c = 'a';
return Py_BuildValue();
}
static PyMethodDef Methods[] = {
{ segfault, segfault, METH_VARARGS, will segfault},
{NULL, NULL, 0, NULL}/* Sentinel */
};
PyMODINIT_FUNC
initsegfault(void)
{
Py_InitModule(segfault, Methods);
}
--
components: Interpreter Core
messages: 56169
nosy: tebeka
severity: normal
status: open
title: Python hang when catching a segfault
type: crash
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1215
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
