This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gregory.p.smith
Recipients gregory.p.smith, vstinner
Date 2017-04-27.03:12:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1493262733.0.0.556588714448.issue30165@psf.upfronthosting.co.za>
In-reply-to
Content
This report is based on manual code inspection in CPython head after we encountered a deadlock using pytracemalloc on Python 2.7.12 where it _appeared_ to be the scenario I've described.

I see now that I missed noticing the "#ifndef Py_HAVE_NATIVE_TLS" within thread.c which should imply a different PyThread_get_key_value() implementation that likely does not use our lock acquiring fallback find_key().  So my code analysis may not make sense...

To give a taste of the large process setup we saw it in:

* A CPython process that has extension modules which create their own threads as well as potentially Python having created its own threads.
* We've called faulthandler.enable() *and* faulthandler.register(SIGTERM).
* We send a SIGTERM to processes in this environment which are taking too long to complete; the goal was to get a stack trace of what the process was potentially stuck doing when our external timeout monitoring mechanism kicked in.

our stuck process had received the SIGTERM and analyzing it revealed a deadlock between two threads which appeared to involve this faulthandler path.

let me gather more info into one place.  from there i should be able to come up with a way to reproduce it (or even better, not)
History
Date User Action Args
2017-04-27 03:12:13gregory.p.smithsetrecipients: + gregory.p.smith, vstinner
2017-04-27 03:12:13gregory.p.smithsetmessageid: <1493262733.0.0.556588714448.issue30165@psf.upfronthosting.co.za>
2017-04-27 03:12:12gregory.p.smithlinkissue30165 messages
2017-04-27 03:12:12gregory.p.smithcreate