Re: XML::LibXSLT registered functions: a preliminary fix

Hi Robin, Liz, All,

I'm sorry for joining this discussion so late, I'm being too busy
these days. I'd also like to thank Elizabeth for pointing this problem
out.

Robin Berjon <robin.berjon@xxxxxxxxx> writes:

> I must have been sleeping or something. The twain can meet, at least
> somehow:
>
>    http://search.cpan.org/~rberjon/XML-XPathExt-0.01_01/XPathExt.pm
>
> That's a very very very alpha thing, it's there as a show of how it
> could be done. If XML::LibXSLT extensions stop blowing up on me, I'll
> be happy to finish and test it properly, and release a nicer version.

I agree with Robin that the two modules are/should be able to share
extension functions in the sense that a single perl sub can be
registered as an extension function with any of them (although the
registering API may slightly differ for those two modules). It means,
that there should be no significant difference in how extension
functions are written for XPathContext and LibXSLT. The only real
difference I know about is that ulike XPathContext, LibXSLT doesn't
pass empty nodesets, so for example with LibXSLT, urn:foo(//para, 10)
would call the Perl implementation subroutine with just @_=(10) if
there was no node matching //para. It is obviously a bug and I'll
patch it as soon as I'll find the spare 15 minutes to do it properly.

Also, it should be noted, that Liz's workaround is only needed for
LibXSLT, not for XPathContext and I strongly discourage from using it
for XPathContext because there is already something similar but less
expensive implemented down on the XS level.

I do appreciate Elizabeth's code (there are certaninly some nice
points to learn from it and it will probably serve well enough as a
temporary solution), but I still feel we should find a more direct
solution. The first step to do so is to find the real cause of the
problem, which isn't still obvious to me.

Strangely enough, I'm able to reproduce the problem even when the
extension function is completely empty: urn:foo { } In that case Liz's
workaround doesn't even apply!

In this case, the nodeset passed to the extension function originates
from the inline XML code in XSLT.  It is most probably represented as
XPATH_XSLT_TREE XPath object by libxslt (I'll have to check in a
debugger). Each node is then cloned by LibXSLT before it is passed to
Perl. If Perl returns some nodes, they are clonned as well. Liz, you
described the problem as:

>> I've traced this problem to DESTROY being called on the node that
>> is passed as a parameter to the function.  Since the node is part
>> of the stylesheet, the DESTROY starts deleting parts of the
>> stylesheet when it shouldn't.

I don't understand two things here: why the destruction happens after
the transformation and not at the end of the extension function call
and why the nodes (which have been cloned by LibXSLT) are still part of
the stylesheet.

One more note: The problem with the approach used in Liz's code is,
that bypassing DESTROY will probably fix any segmentations faults
because they usualy happen when free is called, which is most often in
DESTROY. So it is a non-fix. The problem remains, it is just being
masked (and code using this workaround will probably leak quite
heavily :-().

So anyone willing to help me with further investigation of this issue
and finding a correct patch on LibXSLT is very welcome.

-- Petr
_______________________________________________
Perl-XML mailing list
Perl-XML@xxxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs