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

[Shigeru Chiba (JIRA)]

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


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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira