Message11209

Author stefan.richthofer
Recipients darjus, jamesmudd, stefan.richthofer
Date 2017-03-08.23:25:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1489015523.21.0.946042152091.issue2565@psf.upfronthosting.co.za>
In-reply-to
Content
I looked a bit deeper into this and other recent deadlock issues.
I will focus on test_logging from now on, because that one is easiest to reproduce (occurs most likely).

Anyway. All involve guava data structures (for caching) and ReentrantLock. Under some rare conditions it looks like a guava data structure does not immediately release the lock when the thread finishes the call. In this issue it happens in PyType.fromClass right before the sync-block. Under no circumstances a thread attempting to enter the sync-block should be owning a lock on LazyClassToTypeHolder.classToType - all calls on it should be done and unlocked. But in our deadlock scenario this must be the case.

- Do we somehow misuse guava?
- Or is it a bug in guava?
- Or what do I overlook?

I am going to build my own guava-fork for debug purpose, so I can access the internal locks. However will do this for test_logging for better reproducibility; there the issue is with locking on org.python.modules.sre.SRE_STATE$CACHE.cache. Quite the same cause - MainThread leaves a method of cache without properly being unlocked.
History
Date User Action Args
2017-03-08 23:25:23stefan.richthofersetmessageid: <1489015523.21.0.946042152091.issue2565@psf.upfronthosting.co.za>
2017-03-08 23:25:23stefan.richthofersetrecipients: + stefan.richthofer, darjus, jamesmudd
2017-03-08 23:25:23stefan.richthoferlinkissue2565 messages
2017-03-08 23:25:22stefan.richthofercreate