After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 151201 - <xsl:key> breaks unrelated document()
<xsl:key> breaks unrelated document()
Status: VERIFIED FIXED
Product: libxslt
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
: 158766 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-08-27 11:16 UTC by Phil Endecott
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Three files demonstrating the problem. (428 bytes, application/x-gtar)
2004-08-27 11:18 UTC, Phil Endecott 		Details

Description Phil Endecott 2004-08-27 11:16:43 UTC 
I will attach a tar file containing 3 files, an XSLT file, an XML input file,
and another XML file that is accessed via document().  The stylesheet does
nothing very complicated.  The expected output is the following:

$ xsltproc s.xslt c.xml
<?xml version="1.0"?>
<p>XXXXXXXXXXX</p><p>XXXXXXXXXXX</p>

However, when an unrelated <xsl:key> declaration is present, something goes
wrong and the first (but only the first) access to the document() fails, and
this output is generated:

$ xsltproc s.xslt c.xml
<?xml version="1.0"?>
<p></p><p>XXXXXXXXXXX</p>

Commenting-out or removing the key gives the expected behaviour.

This is libxslt from CVS.

$ xsltproc --version
Using libxml 20611, libxslt 10108-CVS934 and libexslt 806-CVS934
xsltproc was compiled against libxml 20611, libxslt 10108 and libexslt 806
libxslt 10108 was compiled against libxml 20611
libexslt 806 was compiled against libxml 20611

I wonder if this is a regression introduced by the fixes to my
previously-reported issues with keys and documents.  Is anyone able to try this
with an older version?
Comment 1 Phil Endecott 2004-08-27 11:18:55 UTC 
Created attachment 31011 [details]
Three files demonstrating the problem.
Comment 2 John Fleck 2004-08-27 13:29:37 UTC 
I get the same result with older version:

[jfleck@localhost 151201]$ xsltproc s.xslt c.xml
<?xml version="1.0"?>
<p></p><p>XXXXXXXXXXX</p>
[jfleck@localhost 151201]$ xsltproc --version
Using libxml 20610, libxslt 10107 and libexslt 805
xsltproc was compiled against libxml 20610, libxslt 10107 and libexslt 805
libxslt 10107 was compiled against libxml 20610
Comment 3 William M. Brack 2004-08-28 04:06:25 UTC 
I believe this problem was caused by the routine xsltInitCtxtKey modifying a transformation context 
variable (ctxt->node).  I added in some code to save and restore that variable, and it seems to solve the 
problem demonstrated by your test program (which I have also put into the libxslt regression tests).  
The modifications are in CVS (libxslt/keys.c).  Please check whether this solves your original problem, 
and re-open the bug if there is further trouble.

Thanks for the clear report and test case!

Bill
Comment 4 Phil Endecott 2004-08-28 11:26:40 UTC 
Yes, that seems to have fixed it.

Thanks for the very prompt response.

--Phil.
Comment 5 Daniel Veillard 2004-09-30 12:08:38 UTC 
  The release of libxslt-1.1.11 should fix this,
                                                                                
   thanks,
                                                                                
Daniel
Comment 6 William M. Brack 2004-11-24 03:02:12 UTC 
*** Bug 158766 has been marked as a duplicate of this bug. ***