[ 
https://issues.apache.org/jira/browse/BATIK-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119538#comment-16119538
 ] 

Zsolt Kúti commented on BATIK-802:
----------------------------------

A patch based on above comments sent to dev list together with a test-like code 
that shows apparence/disapparence of NPE without/with the fix.

> Race condition in CleanerThread.java getReferenceQueue() method
> ---------------------------------------------------------------
>
>                 Key: BATIK-802
>                 URL: https://issues.apache.org/jira/browse/BATIK-802
>             Project: Batik
>          Issue Type: Bug
>          Components: Utilities
>    Affects Versions: 1.8
>         Environment: Operating System: All
> Platform: All
>            Reporter: Archie Cobbs
>            Assignee: Batik Developer's Mailing list
>
> In org.apache.batik.util.CleanerThread we see:
>     public static ReferenceQueue getReferenceQueue() {
>         if ( queue == null ) {
>             synchronized (CleanerThread.class) {
>                 queue = new ReferenceQueue();
>                 thread = new CleanerThread();
>             }
>         }
>         return queue;
>     }
> This method is not thread safe due to a race condition. The test for "if 
> (queue
> == null)" needs to be inside the synchronized block, not outside of it. As
> written, it's possible for the initialization code to be executed more than 
> once.
> Fix: make the entire method synchronized, or add an additional test for "if
> (queue == null)" within the synchronized block (but see
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html for why
> the variable needs to remain volatile).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-h...@xmlgraphics.apache.org

Reply via email to