Message143869
> 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. |
|
Date |
User |
Action |
Args |
2011-09-11 15:07:05 | neologix | set | recipients:
+ neologix, vstinner, skrah, meador.inge |
2011-09-11 15:07:05 | neologix | set | messageid: <1315753625.28.0.563122143844.issue12936@psf.upfronthosting.co.za> |
2011-09-11 15:07:04 | neologix | link | issue12936 messages |
2011-09-11 15:07:04 | neologix | create | |
|