homepage

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.