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).

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

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