Python and segfaulting extension modules

[zypher]

BPO	975387
Nosy	@loewis

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2004-06-20.21:10:26.000>
created_at = <Date 2004-06-18.14:32:54.000>
labels = ['interpreter-core']
title = 'Python and segfaulting extension modules'
updated_at = <Date 2004-06-20.21:10:26.000>
user = 'https://bugs.python.org/zypher'

bugs.python.org fields:

activity = <Date 2004-06-20.21:10:26.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2004-06-18.14:32:54.000>
creator = 'zypher'
dependencies = []
files = []
hgrepos = []
issue_num = 975387
keywords = []
message_count = 2.0
messages = ['21214', '21215']
nosy_count = 2.0
nosy_names = ['loewis', 'zypher']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue975387'
versions = ['Python 2.3']

[zypher]

Normally when a segfault occurs in a python thread
(mainly in extension modules), two things can happen:

• Python segfaults
• Python uses 99% CPU while Garbage Collecting the
  same INVALID object over and over again

The second result is reported as a bug somewhere else.

In a python program with lots of threads and lots of
loaded extension modules it is almost impossible to find
the cause of a segfault.

Wouldn't it be possible to have some traceback printed
when a SIGSEGV occurs? Would be really very handy.

There even exists an extension module that does just
that, but unfortunately only intercepts problems from
the main thread. (http://systems.cs.uchicago.edu/wad/)

I think something similar should be standard behaviour of
python.

Even nicer would be if python just raises an exception
encapsulating the c stacktrace or even converting a c
trace to a python traceback

Example WAD output:

WAD can either be imported as a Python extension
module or linked to an extension module. To illustrate,
consider the earlier example:

% python foo.py
Segmentation Fault (core dumped)
%

To identify the problem, a programmer can run Python 
interactively and import WAD as follows: 
  % python
  Python 2.0 (#1, Oct 27 2000, 14:34:45) 
  [GCC 2.95.2 19991024 (release)] on sunos5
  Type "copyright", "credits" or "license" for more   
information.
  >>> import libwadpy
  WAD Enabled
  >>> execfile("foo.py")
  Traceback (most recent call last):
    File "", line 1, in ?
    File "foo.py", line 16, in ?
      foo()
    File "foo.py", line 13, in foo
      bar()
    File "foo.py", line 10, in bar
      spam()
    File "foo.py", line 7, in spam
      doh.doh(a,b,c)
  SegFault: [ C stack trace ]
  
  #2   0x00027774 in call_builtin   
(func=0x1c74f0,arg=0x1a1ccc,kw=0x0)
  #1   0xff022f7c in _wrap_doh
(0x0,0x1a1ccc,0x160ef4,0x9c,0x56b44,0x1aa3d8)
  #0   0xfe7e0568 in doh(a=0x3,b=0x4,c=0x0) in 'foo.c', 
line 28

/u0/beazley/Projects/WAD/Python/foo.c, line 28

    int doh(int a, int b, int *c) {
 =>   *c = a + b;
      return *c;
    }

>>

[loewis]

Logged In: YES
user_id=21627

This is not a bug report: there is no specific bug being
reported.

Instead, it is a feature request, but I'd like to reject it,
as it is unimplementable, in a generic, platform-independent
way. The fact that WAD only works for the main thread should
be reported as a bug report to the WAD maintainers.

If you think something should be done about this, please
contribute patches. I personally prefer to use a
fully-featured debugger to analyse problems in extension
modules.