Bill: Thanks for your response. I created bug 495995 as a dump of my first email, and attached the testcase.
Looking forward to what you figure out! -Jake William M. Brack wrote: > Clearly this is a xslt / exslt bug. Could you please open a bugzilla > entry for it (brief description plus your sample file are sufficient), > and I'll do my best to chase it from there? > > Bill > > Jake Goulding wrote: >> Hey all: >> >> I have found a double free of a nodeset in global variables. Here is a >> truncated stack of the problem. The values in parenthesis refer to >> variables in the attached testcase. >> >> xsltEvalGlobalVariables >> xsltEvalGlobalVariable (xml) >> xsltCopyOf >> xsltEvalGlobalVariable (tokenized) >> exsltStrTokenizeFunction >> >> The str:tokenize function creates and registers a local RVT [1]. The >> tokenized result is saved in that RVT. The global variable evaluation >> function then saves the computed value of xml in the global eval >> structure. However, when the xsl:copy-of function exits, it releases the >> RVT, as it does not match the previous local RVT [2]. >> >> This causes the nodeset generated by str:tokenize to be free'd, even >> though the global variable hash still has a value for it, and will >> continue to use it. >> >> This will be a problem at two points of execution: >> 1/ If the variable is used again. >> 2/ During destruction of the globals hash. >> >> Attached is a test case that exhibits this problem. Run it against >> itself, preferably in valgrind, to see the issues. >> >> An example run (truncated for clarity): >> >> $ sudo valgrind xsltproc testcase.xsl testcase.xsl >> >> Invalid read of size 4 >> at 0x544BC05: xmlXPathNodeSetMerge >> by 0x54524A0: xmlXPathObjectCopy >> by 0x4B3B5E1: xsltXPathVariableLookup >> by 0x5456787: (within /usr/lib64/libxml2.so.2.6.30) >> by 0x5455CBE: (within /usr/lib64/libxml2.so.2.6.30) >> by 0x5455C2B: (within /usr/lib64/libxml2.so.2.6.30) >> by 0x545735D: (within /usr/lib64/libxml2.so.2.6.30) >> by 0x545B466: (within /usr/lib64/libxml2.so.2.6.30) >> by 0x545B638: xmlXPathCompiledEval >> by 0x4B4AEDB: xsltCopyOf >> by 0x4B48267: (within /usr/lib64/libxslt.so.1.1.22) >> by 0x4B3B09B: (within /usr/lib64/libxslt.so.1.1.22) >> Address 0x5D35EF0 is 8 bytes inside a block of size 120 free'd >> at 0x4A1F87E: free >> by 0x54230A6: xmlFreeNodeList >> by 0x4B3A70C: xsltReleaseRVT >> by 0x4B47F76: (within /usr/lib64/libxslt.so.1.1.22) >> by 0x4B48287: (within /usr/lib64/libxslt.so.1.1.22) >> by 0x4B3B09B: (within /usr/lib64/libxslt.so.1.1.22) >> by 0x542751E: xmlHashScanFull >> by 0x542756B: xmlHashScan >> by 0x4B3A510: xsltEvalGlobalVariables >> by 0x4B4CED4: (within /usr/lib64/libxslt.so.1.1.22) >> by 0x40227C: (within /usr/bin/xsltproc) >> by 0x402BA4: (within /usr/bin/xsltproc) >> >> Versions used: >> >> $ xsltproc -V >> Using libxml 20630, libxslt 10122 and libexslt 813 >> xsltproc was compiled against libxml 20630, libxslt 10122 and libexslt >> 813 >> libxslt 10122 was compiled against libxml 20630 >> libexslt 813 was compiled against libxml 20630 >> >> Thanks in advance for your help in fixing this! >> >> -Jake Goulding >> >> [1] libexslt/strings.c:72-74 >> [2] libxslt/transform.c:2588 >> _______________________________________________ >> xslt mailing list, project page http://xmlsoft.org/XSLT/ >> [email protected] >> http://mail.gnome.org/mailman/listinfo/xslt >> > > > _______________________________________________ xslt mailing list, project page http://xmlsoft.org/XSLT/ [email protected] http://mail.gnome.org/mailman/listinfo/xslt
