DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7622>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7622 DTM Exceptions when reusing a tranformer [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From [EMAIL PROTECTED] 2002-04-06 11:31 ------- 1) Transform#1 creates an XRTreeFrag. This has a reference to a DTM, that in turn is registered with a DTMManager. The DTM will need to be deleted from the DTMManager when the XRTreeFrag is deleted. The XRTreeFrag also contains a reference to the XPathContext. 2) Transform#1 completes. The XPathContext is reset... namely the a bunch of structures are reset or rebuilt, including DTMManagerDefault#m_dtms. BUT, the XRTreeFrags are still hanging around, waiting to unregister themselves. 3) Transform#2 starts humming along. It builds a XRTreeFrag and installs that RTF DTM into DTMManagerDefault#m_dtms[2]. 4) The finalizer thread wakes and decides to delete some of those old XRTreeFrags from Transform#1. 5) The XRTreeFrag#finalize() method references through the XPathContext, and deletes what it thinks is it's DTM from DTMManagerDefault#m_dtms[2] (via getDTMIdentity(dtm)). 6) Transform#2 tries to reference DTMManagerDefault#m_dtms[2], finds it is null, and chaos results. ...so, before calling xctxt.release, etc., check to make sure the DTM is actually entered in the current DTMManager. I'm not totally sure this is the best or final fix, but I've considered a number of possibilities and, so far, this wins out. Revision Changes Path 1.22 +30 -4 xml- xalan/java/src/org/apache/xpath/objects/XRTreeFrag.java Index: XRTreeFrag.java =================================================================== RCS file: /home/cvs/xml- xalan/java/src/org/apache/xpath/objects/XRTreeFrag.java,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- XRTreeFrag.java 29 Mar 2002 15:20:00 -0000 1.21 +++ XRTreeFrag.java 2 Apr 2002 19:29:55 -0000 1.22 @@ -187,7 +187,10 @@ { if(m_allowRelease) { - if(null != m_dtm) + // See #destruct() for a comment about this next check. + int ident = m_xctxt.getDTMIdentity(m_dtm); + DTM foundDTM = m_xctxt.getDTM(ident); + if(foundDTM == m_dtm) { m_xctxt.release(m_dtm, true); m_dtm = null; @@ -205,9 +208,32 @@ { if(null != m_dtm) { - m_xctxt.release(m_dtm, true); - m_dtm = null; - m_xctxt = null; + // For this next check, see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7622. + // What happens if you don't do this this check: + // 1) Transform#1 creates an XRTreeFrag. This has a reference to a DTM, that in turn + // is registered with a DTMManager. The DTM will need to be deleted from the + // DTMManager when the XRTreeFrag is deleted. The XRTreeFrag also contains a + // reference to the XPathContext. + // 2) Transform#1 completes. The XPathContext is reset... namely the a bunch + // of structures are reset or rebuilt, including DTMManagerDefault#m_dtms. + // BUT, the XRTreeFrags are still hanging around, waiting to unregister themselves. + // 3) Transform#2 starts humming along. It builds a XRTreeFrag and installs that + // RTF DTM into DTMManagerDefault#m_dtms[2]. + // 4) The finalizer thread wakes and decides to delete some of those old XRTreeFrags + // from Transform#1. + // 5) The XRTreeFrag#finalize() method references through the XPathContext, and + // deletes what it thinks is it's DTM from DTMManagerDefault#m_dtms [2] (via + // getDTMIdentity(dtm)). + // 6) Transform#2 tries to reference DTMManagerDefault#m_dtms[2], finds it is + // null, and chaos results. + int ident = m_xctxt.getDTMIdentity(m_dtm); + DTM foundDTM = m_xctxt.getDTM(ident); + if(foundDTM == m_dtm) + { + m_xctxt.release(m_dtm, true); + m_dtm = null; + m_xctxt = null; + } } m_obj = null; }
