[ http://issues.apache.org/jira/browse/COLLECTIONS-85?page=all ]
Stephen Colebourne closed COLLECTIONS-85. ----------------------------------------- Fix Version/s: (was: 3.3) Resolution: Invalid > 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 > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]