Author neologix
Recipients meador.inge, neologix, skrah, vstinner
Date 2011-09-11.15:07:04
SpamBayes Score 2.83414e-06
Marked as misclassified No
Message-id <1315753625.28.0.563122143844.issue12936@psf.upfronthosting.co.za>
In-reply-to
Content
> Could faulthandler cause problems like these:

Well, that would explain why it crashes in the TLS lookup code, and why the core dump looks borked.

1) Apparently, Etch on ARM uses linuxthread instead of NPTL: what does
$ getconf GNU_LIBPTHREAD_VERSION
return on your box?

2) If it's using linxthreads, the culprit is likely the call to PyGILState_GetThisThreadState() from faulthandler_fatal_error(), which does a TLS lookup (which screws up because it's running in a user-allocated stack allocated with sigaltstack).
However, this should only happen when a a fatal signal is handled by faulthandler, which should - AFAICT - only happen in test_faulthandler.

Rebuilding faulthandler with
#undef HAVE_SIGALTSTACK

at the top of the file, should do the trick.
History
Date User Action Args
2011-09-11 15:07:05neologixsetrecipients: + neologix, vstinner, skrah, meador.inge
2011-09-11 15:07:05neologixsetmessageid: <1315753625.28.0.563122143844.issue12936@psf.upfronthosting.co.za>
2011-09-11 15:07:04neologixlinkissue12936 messages
2011-09-11 15:07:04neologixcreate