sboag 01/01/08 23:15:11
Modified: java/src/org/apache/xalan/stree Parent.java
Log:
Set child.m_prev *before* m_next. From note to Joe K. about this:
I tried hard to reproduce this. I installed IBM's 1.3 JDK, and ran many
tests, but could not cause the problem.
These problems all seem to occur when xsl:number is involved. This might
make be suspect something with getPreviousSibling(). I notice in
Parent#appendChild:
if (null == m_first)
{
m_first = child;
}
else
{
m_last.m_next = child;
child.m_prev = m_last;
}
m_last = child;
m_last is only used in appendChild, which must always be synchronized at the
caller level, and is never entered by the transform thread anyway. But child
getPreviousSibling() can absolutely fail. So I think this should be changed to:
child.m_prev = m_last;
m_last.m_next = child;
This should be safe because getPreviousSibling() can't be called until the
node is navigated to via m_last.m_next.
However, I'm not sure why this would cause the particular problem you are
having with dropped text. I would think getPreviousSibling problem would
manifest itself as a bad numbering value, not a dropped text node. In fact, in
numbering64 it just uses <xsl:value-of select="."/> which is optimized as of
this weekend to just use the current node, and then the text value operation
uses getFirstChild to get to the text child of that element. So it seems like
it is really getFirstChild which is failing.
Well, I'll try reversing those on the theory that it might help. Sorry to be
making you do these runs... believe me, I wish I could reproduce the problem
myself.
I know that we're pretty close to the point of just doing absolute
synchronization in getFirstChild, getNextSibling, and getPreviousSibling. But,
not only am I afraid to do that because of performance issues (though I haven't
measured what the difference would be), I'm worried that I could somehow
introduce a deadlock or hang at this stage of the game.
It's also possible that there's something else going on in xsl:number above
the level of Stree which could be screwing things up.
(And the original note from Joe):
The failure frequency seems reduced... but there still seems to be a lurking
horror or two, and the pattern of failure seems unchanged.
Seventh pass, numbering64, line 9
5: hhh
5:
Eighth pass, numbering27, line 17
3+1-1: Level C
3+1-1:
Ninth pass
numb42, line 3
(1.): Level A
(1.):
numb66, line 35
C. Second Subsection in third Section in second Chapter
C.
Revision Changes Path
1.19 +1 -1 xml-xalan/java/src/org/apache/xalan/stree/Parent.java
Index: Parent.java
===================================================================
RCS file: /home/cvs/xml-xalan/java/src/org/apache/xalan/stree/Parent.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- Parent.java 2001/01/07 03:59:23 1.18
+++ Parent.java 2001/01/09 07:15:11 1.19
@@ -348,8 +348,8 @@
}
else
{
- m_last.m_next = child;
child.m_prev = m_last;
+ m_last.m_next = child;
}
m_last = child;
