[jira] Updated: (COLLECTIONS-85) ReferenceMap clears bindings too early

["Stephen Colebourne (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/jira/browse/COLLECTIONS-85?page=all ]

Stephen Colebourne updated COLLECTIONS-85:
------------------------------------------

          Summary: ReferenceMap clears bindings too early  (was: [collections] ReferenceMap clears bindings too early)
      Bugzilla Id:   (was: 38853)
      Component/s: Map
    Fix Version/s: 3.3

Awaiting feedback - I will close as unreproducible otherwise

> ReferenceMap clears bindings too early
> --------------------------------------
>
>                 Key: COLLECTIONS-85
>                 URL: http://issues.apache.org/jira/browse/COLLECTIONS-85
>             Project: Commons Collections
>          Issue Type: Bug
>          Components: Map
>    Affects Versions: 3.1
>         Environment: Operating System: Windows XP
> Platform: Other
>            Reporter: Eric Bodden
>             Fix For: 3.3
>
>         Attachments: LORTest - Commons Map.zip
>
>
> Hello. This week I had to debug some small example program we are currently 
> working on and it really took me a long time to find the actual problem because 
> apprently there seems to be a bug in the implementation of ReferenceMap, which 
> was really very unexpected for me. To me this seems very critical because I 
> reckon that the ReferenceMap is in wide use. Hence I am describing my findings 
> in detail.
> The code is AspectJ code, but I also provide the bytecode. The puspose of the 
> code is to detect the so-called "lock order reversal pattern", a temporal event 
> pattern which gives indication of potentially unsafe locking. It tries to 
> detect patterns where a thread t1 tries to acquire locks in the order l1 l2 and 
> another thread t2 tries to do so in the order r2 r1.
> When you compile the attached code with the AspectBench compiler (www.
> aspectbench.org) and then execute "java LORTest", depending on the map 
> implementation you choose, one of the following traces is produced:
> - "log": your commons impl. (Reference identity map with weak key and values)
> - "log_jre": the JRE impl. (hash map with weak keys, no identity map, but does 
> not matter since the keys are threads, which do not implement equals(...))
> (Both logs are also in the tarball.)
> In log_jre you see that the LOR is detected (at the bottom). That works as 
> follows: Whenever a lock is taken, the relationship (thread,lock) is put into a 
> first (weak) map (see logging points "Xa"). Also, for all such relations which 
> are contained already, we put a reference to a pair (thread,(lock1,lock2)) into 
> a second map (logging points "Xb"). This represents the information "thread" 
> took first "lock1" then "lock2".
> As "log" shows, the weak map by commons is looses all the sudden some bindings. 
> (Compare to log_jre.) This seems really buggy, since subsequent logging output 
> shows that the threads and locked resources still exist! 
> For me this is fully deterministically reproducable. I am using Windows XP with 
> this JRE:
> java version "1.5.0_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)
> You can compile the code (using the AspectBench compiler) with "compile.bat" or 
> you can just run it with "run.bat", if you like.

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

        

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org