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
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:
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
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
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:
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
Changes by Christian Heimes:
--
components: +Documentation
keywords: +easy
priority: - normal
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1215
__
___
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
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]
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
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
__
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';
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
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
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).
__
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
16 matches
Mail list logo
