Segfault in GC: pinned object in 'objects_to_trace'

[Ed]

I encountered a reproducible segfault when running a particular script, both with release builds and with lldebug.

PyPy assertion failed at rpython_memory_gc.c:22908:
in pypy_g_IncrementalMiniMarkGC_visit: pinned object in 'objects_to_trace'

The script and further details are provided in the attachment.

[mattip]

For future reference, as a clear and reproducable issue report, here is the README from the attachment

README

This is an attempt to reproduce a segfault in the GC of PyPy 5.3.1.

The crash has been observed using an lldebug build on x64 CentOS 6.4, and also when using the following binaries on x64 Debian 8.4: https://bitbucket.org/pypy/pypy/downloads/pypy2-v5.3.1-linux64.tar.bz2

The crash occurs with and without --jit off using the above binaries.

When encountered using a regular release build, a plain segfault occurs. When encountered using an lldebug build, the following is displayed:

 $ ./start.sh 
  wikidump/enwiki-20160801-pages-articles1.xml-p000000010p000030302.bz2
  ..............PyPy assertion failed at rpython_memory_gc.c:22908:
  in pypy_g_IncrementalMiniMarkGC_visit: pinned object in 'objects_to_trace'

I am not able to reproduce this using the debian-provided PyPy 2.4.0.

The version of the "requests" library does not seem to matter. Included is the latest as of writing (2016-08-03) and it was retrieved from https://github.com/kennethreitz/requests/tarball/master

ADDITIONAL PREPARATIONS:

Download a bz2-compressed xml dump of the english wikipedia, the smallest partial archive is usually enough: https://dumps.wikimedia.org/enwiki/20160801/enwiki-20160801-pages-articles1.xml-p000000010p000030302.bz2

if that link has become 404, select a timestamp on this link: https://dumps.wikimedia.org/enwiki/

and then choose one or more archives below the following headline: "Articles, templates, media/file descriptions, and primary meta-pages."

Place one or more of these .xml-pXXXpXXX.bz2 files in the wikidump folder. Adding multiple archives appear to increase the odds of hitting the segfault. Unfortunately there seems to be many variables deciding when (or if) it'll happen during a run.

[Armin Rigo]

Thanks for the very well-prepared bug report! Found the issue in 1d29fd069ef0 and fixed it in 93a5d95ec126. (Tracking the problem was done using the great tool 'undodb-gdb', which I can only recommend.)