[jboss-jira] [JBoss JIRA] Resolved: (JASSIST-86) Make concurrent calls to getRefClasses() safe.

Make concurrent calls to getRefClasses() safe. ---------------------------------------------- Key: JASSIST-86 URL: https://jira.jboss.org/jira/browse/JASSIST-86 Project: Javassist Issue Type: Bug Affects Versions: 3.10.0.GA Reporter: Shigeru Chiba Assignee: Shigeru Chiba Fix For: 3.11.0.GA Attachments: fix-javassist-concurrency There is a race condition when getRefClasses is called twice concurrently on the same class - one of the chains in HashMap for collision resolution can become cyclic, i.e. an infinitely long list, causing iteration on the list to enter an infinite loop. On a CtClass ct, the call path leading to the problem is: ct.getRefClasses() -> ct.renameClass() (it's a fake renameClass(), which does not rename anything) -> ct.constPool.renameClass() One can thus have concurrent calls to ct.constPool.renameClass(); a constPool then recreates the internal HashMap, i.e. reinserts again all elements into cp.classes (not a temporary map), so we have concurrent accesses to this map. In particular, since there can be a collision (as happened for me), the collision chain could become cyclic. This was found through remote debugging on a concurrent program using Javassist (attaching after a series of run-client invocations ended in a crash). It was a real-world program, not a client written on purpose to show this. This patch solves the problem well, and was tested in a configuration which caused a lot of crashes and stopped causing any. Lots of better fixes to this could be thought, but they're more invasive.