[ 
https://issues.apache.org/jira/browse/BATIK-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zsolt Kúti updated BATIK-802:
-----------------------------
    Attachment: BATIK_802__fixed__test_added.patch

First run the "test" file without the fix. NPE-s will appear.
Then run it with the fix, where no NPEs should be present in the output.

I copy here what was sent to the mailing list:
"A little explanation to the test. While it looks like being a unit test it is 
not that. CleanerThread catches everything in its run method therefore NPEs 
presence or absence can only be observed by way of printStacktrace code 
originally put there. Implementing something in CT just for the case of a test 
is perhaps not worth the effort."

> 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
>         Attachments: BATIK_802__fixed__test_added.patch
>
>
> 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