Éric Araujo mer...@netwok.org added the comment:
See #11393 for discussion about integration in 3.3.
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
___
Stephen J. Turnbull step...@xemacs.org added the comment:
Re: msg124528
Yes, XEmacs installs a signal handler on what are normally fatal errors. (I
don't know about GNU Emacs but they probably do too.)
The handler has two functions: to display a Lisp backtrace and to output a
message
Stefan Krah stefan-use...@bytereef.org added the comment:
[Alexander]
if sys.getenv('PYTHONSEGVHANDLER'):
import segvhandler
segvhandler.enable()
+1
If this doesn't find support, I'd name sys.setsegfaultenabled()
sys.setsegvhandlerenabled() or sys.enable_segvhandler().
--
STINNER Victor victor.stin...@haypocalc.com added the comment:
Note: To avoid the signal-safe requirement, another solution is to use
sigsetjmp()+siglongjmp().
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
STINNER Victor victor.stin...@haypocalc.com added the comment:
I tested the patch version 11 on Windows: all tests pass. But #include
unistd.h should be skipped on Windows (Python/fault.c): I will add #ifdef
MS_WINDOWS.
--
___
Python tracker
STINNER Victor victor.stin...@haypocalc.com added the comment:
I tested the patch version 11 on Windows: all tests pass.
Oh, and I forgot to say that the Windows fault handler does catch the fault too
(Windows opens a popup with a question like Should the error be reported to
Microsoft?).
STINNER Victor victor.stin...@haypocalc.com added the comment:
Tested on FreeBSD 8: all tests pass (all of the 4 signals are supported) and
FreeBSD dumps a core file.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
Stefan Krah stefan-use...@bytereef.org added the comment:
STINNER Victor rep...@bugs.python.org wrote:
Note: To avoid the signal-safe requirement, another solution is to use
sigsetjmp()+siglongjmp().
FWIW, there is a caveat in the OpenBSD man page concerning the use of
siglongjmp():
STINNER Victor victor.stin...@haypocalc.com added the comment:
Tested on Ubuntu 10.04: all tests pass and apport intercepts the fault. Apport
ignores the faults because I am testing a Python executable compiled from SVN
(py3k). Apport logs (/var/log/apport.log):
---
apport (pid 18148) Thu Dec
STINNER Victor victor.stin...@haypocalc.com added the comment:
Georg rejected this patch in Python 3.2:
I did say I like the feature, but that was a) before beta 2
was released, now the next release is a release candidate, and b) this
thread showed that it is not at all obvious how the feature
STINNER Victor victor.stin...@haypocalc.com added the comment:
Version 11 of my patch:
- Disable the fault handler (and displaying the backtrace on a fatal error) by
default
- The fault handle can be enabled by setting the PYTHONFAULTHANDLER
environment variable or using -X faulthandler
Changes by STINNER Victor victor.stin...@haypocalc.com:
Removed file: http://bugs.python.org/file20102/segfault_handler-9.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
___
Changes by STINNER Victor victor.stin...@haypocalc.com:
Removed file: http://bugs.python.org/file20113/segfault_handler-10.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
___
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
versions: +Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
___
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Stephen,
I wonder if you would have comments on this. As far as I know emacs installs
SEGV handlers similar to the ones proposed here. How well do they work? Does
it really help users to produce meaningful bug
Scott Dial sc...@scottdial.com added the comment:
On 12/22/2010 8:52 PM, STINNER Victor wrote:
Amaury asked for a sys.setsegfaultenabled() option: I think that the command
line option and the environment variable are enough.
I really think you should think of it as a choice the developer of
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Wed, Dec 22, 2010 at 9:27 PM, Scott Dial rep...@bugs.python.org wrote:
Scott Dial sc...@scottdial.com added the comment:
On 12/22/2010 8:52 PM, STINNER Victor wrote:
Amaury asked for a sys.setsegfaultenabled()
STINNER Victor victor.stin...@haypocalc.com added the comment:
Does the latest patch address the GIL/multithreading issues?
Yes.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
Le jeudi 23 décembre 2010 à 02:27 +, Scott Dial a écrit :
Scott Dial sc...@scottdial.com added the comment:
On 12/22/2010 8:52 PM, STINNER Victor wrote:
Amaury asked for a sys.setsegfaultenabled() option: I think that the
STINNER Victor victor.stin...@haypocalc.com added the comment:
Le jeudi 23 décembre 2010 à 02:27 +, Scott Dial a écrit :
Scott Dial sc...@scottdial.com added the comment:
On 12/22/2010 8:52 PM, STINNER Victor wrote:
Amaury asked for a sys.setsegfaultenabled() option: I think that the
STINNER Victor victor.stin...@haypocalc.com added the comment:
Le jeudi 23 décembre 2010 à 02:45 +, Alexander Belopolsky a écrit :
As I suggested on python-dev, I also think this belongs to a separate
module rather than core or sys.
Why do you want to move it outside Python core? It is
Scott Dial sc...@scottdial.com added the comment:
On 12/22/2010 10:35 PM, STINNER Victor wrote:
Why do you think so? Can you give me an use case of
sys.setsegfaultenabled()?
To feed back your own argument on python-dev:
How do you know that you application will crash? The idea is to give
STINNER Victor victor.stin...@haypocalc.com added the comment:
Le lundi 20 décembre 2010 07:55:08, vous avez écrit :
+#define NFAULT_SIGNALS (sizeof(fault_signals) / sizeof(fault_signals[0]))
+static fault_handler_t fault_handlers[4];
, should use NFAULT_SIGNALS instead of 4.
Ah yes,
STINNER Victor victor.stin...@haypocalc.com added the comment:
The fault handler is unable to retrieve the thread state if the GIL is
released. I will try to fix that.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
Scott Dial sc...@scottdial.com added the comment:
On 12/20/2010 8:30 AM, STINNER Victor wrote:
Write into a closed file descriptor just does nothing. Closed file
descriptors
are not a problem.
My issue not with a closed file descriptor, it is with an open file
descriptor that is not what
Antoine Pitrou pit...@free.fr added the comment:
The problem is to detect that stderr file descriptor changes (eg. closed,
duplicated, reopened, etc.). I don't think that it's possible to detect
such
changes (with a portable function).
When I said that, I hadn't fully investigated
STINNER Victor victor.stin...@haypocalc.com added the comment:
Why was sys.setsegfaultenabled() omitted?
Just because I forgot your message, sorry.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
STINNER Victor victor.stin...@haypocalc.com added the comment:
Version 10 of my patch:
- the fault handler restores the previous signal handler instead of calling
(DebugBreak() and) abort(): the previous signal handler will be called later to
keep the orignal behaviour
- _testcapi.sigill()
Scott Dial sc...@scottdial.com added the comment:
FYI, in v10,
+#define NFAULT_SIGNALS (sizeof(fault_signals) / sizeof(fault_signals[0]))
+static fault_handler_t fault_handlers[4];
, should use NFAULT_SIGNALS instead of 4.
However, this bit of code bothers me a lot:
+const int fd = 2; /*
STINNER Victor victor.stin...@haypocalc.com added the comment:
Version 9 of my patch:
- Create PYTHONNOHANDLER environment variable: don't install the signal
handler if the variable is set
- Rename Segfault by FaultHandler
- reverse_string() does nothing if len==0, even if it cannot occur
Changes by STINNER Victor victor.stin...@haypocalc.com:
Removed file: http://bugs.python.org/file19214/segfault_handler-5.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
___
Changes by STINNER Victor victor.stin...@haypocalc.com:
Removed file: http://bugs.python.org/file19227/segfault_handler-6.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
___
Changes by STINNER Victor victor.stin...@haypocalc.com:
Removed file: http://bugs.python.org/file19288/segfault_handler-7.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
___
Changes by STINNER Victor victor.stin...@haypocalc.com:
Removed file: http://bugs.python.org/file19289/segfault_handler-8.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
Oh, I'm tired...
Summary of the patch:
- ...abort the process (call the debugger on Windows)
(the debugger is only called if Python is compiled in debug mode)
- Add PYTHONNOHANDLER environment variable ...
Oops, the correct
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Why was sys.setsegfaultenabled() omitted?
It may be useful to disable the handler from a script
--
nosy: +amaury.forgeotdarc
___
Python tracker rep...@bugs.python.org
Changes by R. David Murray rdmur...@bitdance.com:
--
stage: - patch review
type: - feature request
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
___
Changes by R. David Murray rdmur...@bitdance.com:
--
versions: +Python 3.3 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
___
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
If it's an env variable, though, it should be clear that it's
CPython-specific, so I'm not sure how to call it.
Why do you think that only this variable is CPython-specific? CPython has an
option called PYTHONDONTWRITEBYTECODE,
Changes by David Fraser dav...@sjsoft.com:
--
nosy: +davidfraser
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
___
___
Python-bugs-list
Antoine Pitrou pit...@free.fr added the comment:
I don't think that a command line option and an environment variable
is pratical for an OS distributor.
Environment variables are probably the most practical for OS vendors,
since they can simply set them in /etc/profile.d (Mandriva does that
STINNER Victor victor.stin...@haypocalc.com added the comment:
Patch version 7:
- don't use snprintf() because it is not signal safe
- catch also SIGBUS and SIGILL if available
- Py_FatalError() uses fileno(stderr) instead of directly 2
- Factorize code in segfault.c and test_segfault.py
STINNER Victor victor.stin...@haypocalc.com added the comment:
Patch version 8:
- fix compiler warning on Windows
- skip test_sigfpe() on Windows: it looks like the signal handler is not
executed, the program exits directly
- fix tests for Windows end of line (\r\n vs \n)
--
Added
STINNER Victor victor.stin...@haypocalc.com added the comment:
One other concern: many OSes (e.g. Linux distributions) implement
some kind of system-wide crash-catching utility; ...
Even if it would be possible to call the original signal handler, I think that
it would be better to just
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
title: Segfault handler: display Python backtrace on segfault - Display Python
backtrace on SIGSEGV, SIGFPE and fatal error
___
Python tracker rep...@bugs.python.org
STINNER Victor victor.stin...@haypocalc.com added the comment:
I posted the patch on Rietveld for a review (as asked by Antoine):
http://codereview.appspot.com/2477041
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
Dave Malcolm dmalc...@redhat.com added the comment:
It looks like this doesn't yet have any test cases.
You probably should invoke a child python process that crashes and examine the
output (perhaps running some/all of the examples in Lib/test/crashers ?); you
may want to steal some of the
Dave Malcolm dmalc...@redhat.com added the comment:
One other concern: many OSes (e.g. Linux distributions) implement some kind of
system-wide crash-catching utility; for example in Fedora we have ABRT (
https://fedorahosted.org/abrt/wiki ).
I'm not sure yet exactly how these are implemented,
Antoine Pitrou pit...@free.fr added the comment:
By the way, don't you want to handle SIGILL and SIGBUS too?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8863
___
Josh Bressers j...@bress.net added the comment:
You would be wise to avoid using heap storage once you're in the crash handler.
From a security standpoint, if something has managed to damage the heap (which
is not uncommon in a crash), you should not attempt to allocate or free heap
memory.
Antoine Pitrou pit...@free.fr added the comment:
You would be wise to avoid using heap storage once you're in the crash
handler. From a security standpoint, if something has managed to
damage the heap (which is not uncommon in a crash), you should not
attempt to allocate or free heap memory.
Josh Bressers j...@bress.net added the comment:
I am then confused by this in the initial comment:
It calls indirectly PyUnicode_EncodeUTF8() and so call
PyBytes_FromStringAndSize() which allocates memory on the heap.
I've not studied the patch though, so this may have changed.
--
Antoine Pitrou pit...@free.fr added the comment:
I am then confused by this in the initial comment:
It calls indirectly PyUnicode_EncodeUTF8() and so call
PyBytes_FromStringAndSize() which allocates memory on the heap.
I've not studied the patch though, so this may have changed.
The
STINNER Victor victor.stin...@haypocalc.com added the comment:
Version 6:
- don't use fputc(), fputs(), fprintf() or fflush() on stderr: use write() on
file descriptor 2 (should be stderr)
- write tests: add sigsegv(), sigfpe() and fatal_error() functions to the
_testcapi module
I was too
STINNER Victor victor.stin...@haypocalc.com added the comment:
TODO (maybe): Call the original signal handler to make tools like apport or
ABRT able to catch segmentation faults.
By the way, don't you want to handle SIGILL and SIGBUS too?
Maybe. SIGILL is a very rare exception. To test it,
Dave Malcolm dmalc...@redhat.com added the comment:
About SIGBUS: I don't know this signal. Is it used on Linux? If not, on
which OS is it used?
Yes, IIRC typically you'll only see it on RISC CPUs that require instructions
to be word-aligned; you typically see it if the program counter jumps
56 matches
Mail list logo
