Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
From: bugzilla@apache.org
To: commons-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 38853]  New:  - [collections] ReferenceMap clears
 bindings too early
Message-ID: <bug-38853-7685@http.issues.apache.org/bugzilla/>
Date: Sat,  4 Mar 2006 07:58:45 +0100 (CET)

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: commons-dev@jakarta.apache.org
        ReportedBy: eric@bodden.de


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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org