Segfault inside of gc/weakref

[alex]

BPO	13529
Nosy	@alex

^{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 2011-12-04.22:48:05.039>
created_at = <Date 2011-12-04.20:08:18.992>
labels = ['interpreter-core', 'invalid']
title = 'Segfault inside of gc/weakref'
updated_at = <Date 2011-12-04.22:48:05.037>
user = 'https://github.com/alex'

bugs.python.org fields:

activity = <Date 2011-12-04.22:48:05.037>
actor = 'alex'
assignee = 'none'
closed = True
closed_date = <Date 2011-12-04.22:48:05.039>
closer = 'alex'
components = ['Interpreter Core']
creation = <Date 2011-12-04.20:08:18.992>
creator = 'alex'
dependencies = []
files = []
hgrepos = []
issue_num = 13529
keywords = []
message_count = 3.0
messages = ['148855', '148856', '148857']
nosy_count = 1.0
nosy_names = ['alex']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue13529'
versions = ['Python 2.6', 'Python 2.7']

[alex]

I don't have a particularly minimal test case for this, however I am able to reproduce it consistently (so far reproduced on multiple machines, 32-bit and 64-bit on 2.6 and 2.7), using these steps:

First get a checkout of the PyPy repository:

hg clone ssh://hg@bitbucket.org/pypy/pypy

Next, get to the correct revision:

hg up -C 82e1fc9c253c

Finally, attempt to run the tests:

./pytest.py pypy/module/micronumpy/ -x

At this point you should have a segfault that appears to be because of a bad address for a weakref (but I could be horrifically wrong).

[alex]

Antoine asked for a gdb bt, here's the last couple of useful frames:

#0 _PyWeakref_ClearRef (self=0x4000000000000000) at Objects/weakrefobject.c:97
#1 0x00000000004d4c66 in handle_weakrefs (old=0x78a2b0, unreachable=0x7fffffff87b0) at Modules/gcmodule.c:595
#2 collect (generation=0) at Modules/gcmodule.c:924
#3 0x00000000004d5640 in collect_generations () at Modules/gcmodule.c:996
#4 _PyObject_GC_Malloc (basicsize=<optimized out>) at Modules/gcmodule.c:1457
#5 0x0000000000466ba9 in PyType_GenericAlloc (type=0x31d05e0, nitems=0) at Objects/typeobject.c:753
#6 0x000000000046ad83 in type_call (type=0x31d05e0, args=(257, None, [], 8, 51), kwds=0x0) at Objects/typeobject.c:721
#7 0x000000000041ebc7 in PyObject_Call (func=<type at remote 0x31d05e0>, arg=<optimized out>, kw=<optimized out>) at Objects/abstract.c:2529
#8 0x000000000049b152 in do_call (nk=<optimized out>, na=<optimized out>, pp_stack=0x7fffffff89b0, func=<type at remote 0x31d05e0>)
at Python/ceval.c:4239
#9 call_function (oparg=<optimized out>, pp_stack=0x7fffffff89b0) at Python/ceval.c:4044
#10 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2666

[alex]

Turns out this was a subtle bug in some raw memory manipulation code, which amaury spotted.