DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38853>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38853 Summary: [collections] ReferenceMap clears bindings too early Product: Commons Version: 3.1 Platform: Other OS/Version: Windows XP Status: NEW Severity: major Priority: P2 Component: Collections AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] 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. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
