[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Éric Araujo added the comment: See #11393 for discussion about integration in 3.3. -- nosy: +eric.araujo ___ Python tracker ___ ___ Py

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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 should look like. The fact

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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 23 13:29:25 2010: called for

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Stefan Krah added the comment: STINNER Victor 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(): http://www.openbsd.org/cgi-bin/man.cgi?query=sigsetjmp

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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 ___ _

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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?"). -- ___

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor added the comment: I tested the patch version 11 on Windows: all tests pass. But #include should be skipped on Windows (Python/fault.c): I will add #ifdef MS_WINDOWS. -- ___ Python tracker ___

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor added the comment: Note: To avoid the signal-safe requirement, another solution is to use sigsetjmp()+siglongjmp(). -- ___ Python tracker ___

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Stefan Krah 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(). -- nosy: +skrah __

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Stephen J. Turnbull 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 explaining how to report

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Scott Dial 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 > informations to t

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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 very dependent of Python inte

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor added the comment: Le jeudi 23 décembre 2010 à 02:27 +, Scott Dial a écrit : > Scott Dial 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

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor added the comment: Le jeudi 23 décembre 2010 à 02:27 +, Scott Dial a écrit : > Scott Dial 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

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor added the comment: > Does the latest patch address the GIL/multithreading issues? Yes. -- ___ Python tracker ___ ___ P

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Alexander Belopolsky added the comment: On Wed, Dec 22, 2010 at 9:27 PM, Scott Dial wrote: > > Scott Dial 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 va

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Scott Dial 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 an application mak

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Alexander Belopolsky 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 reports? -- nosy: +belopolsky,

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Changes by STINNER Victor : -- versions: +Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Changes by STINNER Victor : Removed file: http://bugs.python.org/file20113/segfault_handler-10.patch ___ Python tracker ___ ___ Python-bugs-lis

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Changes by STINNER Victor : Removed file: http://bugs.python.org/file20102/segfault_handler-9.patch ___ Python tracker ___ ___ Python-bugs-list

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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" command line option (instead of

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Antoine Pitrou 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 the i

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Scott Dial 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 you think it is.

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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 ___

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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, NFAULT_SIGNALS is a better

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Scott Dial 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; /* should be filen

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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() and _testcapi.sigbus() send SI

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor added the comment: > Why was sys.setsegfaultenabled() omitted? Just because I forgot your message, sorry. -- ___ Python tracker ___ __

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Amaury Forgeot d'Arc added the comment: Why was sys.setsegfaultenabled() omitted? It may be useful to disable the handler from a script -- nosy: +amaury.forgeotdarc ___ Python tracker __

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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 name is PYTHONNOFAULTHANDLER

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Changes by STINNER Victor : Removed file: http://bugs.python.org/file19289/segfault_handler-8.patch ___ Python tracker ___ ___ Python-bugs-list

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Changes by STINNER Victor : Removed file: http://bugs.python.org/file19288/segfault_handler-7.patch ___ Python tracker ___ ___ Python-bugs-list

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Changes by STINNER Victor : Removed file: http://bugs.python.org/file19227/segfault_handler-6.patch ___ Python tracker ___ ___ Python-bugs-list

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Changes by STINNER Victor : Removed file: http://bugs.python.org/file19214/segfault_handler-5.patch ___ Python tracker ___ ___ Python-bugs-list

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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 when it's called by dump_d

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Changes by R. David Murray : -- versions: +Python 3.3 -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Changes by R. David Murray : -- stage: -> patch review type: -> feature request ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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, but PyPy doesn't create .pyc

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Changes by David Fraser : -- nosy: +davidfraser ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Antoine Pitrou 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 with PYTHONDON

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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 disable this feature if a (bett

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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 file: http://bugs.python.org/f

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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 -- Added file: http://b

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Dave Malcolm 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 to a broken addr

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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, should I send a SIGILL signa

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor 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 lazy to reimplement functions

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Antoine Pitrou 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 patch ce

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Josh Bressers 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. -- _

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Antoine Pitrou 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. As far as

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Josh Bressers 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. On modern glibc

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Antoine Pitrou added the comment: By the way, don't you want to handle SIGILL and SIGBUS too? -- ___ Python tracker ___ ___ Python-bug

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Dave Malcolm 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, but we'd want to av

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Dave Malcolm 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 wrapper code from Li

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

STINNER Victor added the comment: I posted the patch on Rietveld for a review (as asked by Antoine): http://codereview.appspot.com/2477041 -- ___ Python tracker ___

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Changes by STINNER Victor : -- title: Segfault handler: display Python backtrace on segfault -> Display Python backtrace on SIGSEGV, SIGFPE and fatal error ___ Python tracker ___