You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by "Michael Glavassevich (JIRA)" <xe...@xml.apache.org> on 2007/12/08 07:06:43 UTC

[jira] Resolved: (XERCESJ-1284) Race condition in dom traversal

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

Michael Glavassevich resolved XERCESJ-1284.
-------------------------------------------

    Resolution: Duplicate

Duplicate of XERCESJ-911.

This is not a bug; it's a usage error. Xerces DOM implementation is not thread-safe [1] by design. Applications must synchronize their access to the DOM even if they're just reading it.  If you're looking for more info there have been plenty of discussions concerning this topic on the Xerces-J mailing lists over the years.

[1] http://xml.apache.org/xerces2-j/faq-dom.html#faq-1

> Race condition in dom traversal
> -------------------------------
>
>                 Key: XERCESJ-1284
>                 URL: https://issues.apache.org/jira/browse/XERCESJ-1284
>             Project: Xerces2-J
>          Issue Type: Bug
>          Components: DOM (Level 3 Core)
>    Affects Versions: 2.9.1
>         Environment: Windows XP running java 1.6 and 1.5.
>            Reporter: Bob Miller
>
> After a parse an xml document into a dom tree using a single thread I create multiple threads to traverse the tree and read data (no updates).  I have found a race condition involving nodeListGetLength in ParentNode and getNodeListCache in CoreDocumentImpl.  The problem lies in the fact that when you free your fNodeListCache you can still keep using it, with the expectation that when your cache object is reallocated that it is removed from you.  The race works as such.  Imagine two threads T1 and T2.  T1 has just started executing nodeListGetLength and has a non null fNodeListCache and T2 has just started executing CoreDocumentImpl and is about to give away the cache object that T1 uses.
> T1 passes if(fNodeListCache == null)
> T2 aqueires for itself fFreeNLCache and sets c.fOwner.fNodeListCache = null
> T1 checks fNodeListCache.fLength and fails on a null pointer error
> I am thinking that nodeListGetLength and getNodeListCache need to both synchronize on either the document or the node cache object.  Synchronizing will have no effect on single thread access and should clean up multithreaded access.  I am working on a test program that does not contain sensitive data and am also working on writing a patch.
> Does anyone have any suggestions or see anything I haven't?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org