GNOME Bugzilla – Bug 343411
libxslt (1.1.16) crashes when processing certain files
Last modified: 2006-06-01 17:34:19 UTC
Steps to reproduce: 1. download http://www.cc.com.pl/temp/xslterror.zip and uncompress the contents, for example, to /tmp (notice that there is no subdirectory in the ZIP file) 2. run xsltproc /tmp/zly.xsl /tmp/zly.xml Stack trace: *** glibc detected *** realloc(): invalid next size: 0x08155a18 *** Program received signal SIGABRT, Aborted. 0xb7c4e7c7 in raise () from /lib/tls/libc.so.6 (gdb) whe
+ Trace 68544
Other information: Platform: Debian Unstable, libxml2 - 2.6.24, libxslt - 1.1.16 gcc 4.0.4
Fixed now in CVS, transform.c, revision 1.290. Better also check out xslt.c, revision 1.290. Thanks for the report! This was a hard nut, and kept us searching for hours. The problem is related to a difference in handling of non-output-escaped text-nodes in xsl:value-of and xsl:text; plus a scenario where xsl:value-of and xsl:text are used alternately - the test case is full of such constellations. For xsl:value-of ---------------- xsltValueOf(): --> xsltCopyTextString() --> xsltAddTextString(): This function uses the optimized string growing mechanism. Here ctxt->lasttext points to the content of the last text-node. ctxt->lasttsize indicates the size of the allocated memory (e.g. 2142 Bytes) - but not the actualy size of the string. This is all OK until now. For xsl:text ------------ --> xsltCopyText() Here the xsl:text content is copied and given to --> xmlAddChild() Here (via xmlStrncat()) the strings of the last text-node and the new text-node are merged (since adjacent). This reallocates the string of the last text-node, *but* keeps the same pointer for the reallocated result, since the size of the previously allocated memory in xsltAddTextString() was greater (2142 Bytes) than needed for the nre merged string - so realloc keeps the pointer for the string. We get a scenario, where ctxt->lasttsize is 2142, and ctxt->lasttext points still to the text-node's string, but the string was reallocated to a smaller size. Any further processing of this text-node's content via xsltAddTextString() will result in access violations, since the ctxt->lasttsize is out of sync with the real size of the allocated memory. The bug was fixed by processing non-output-escaped the same way as normal text nodes in xsltCopyText(). Easy fix, but not easy to find and understand what's going on.
Ohhh ! I see, so this bug was probably there nearly forever (well since dict optimization was added), but only triggered recently. Good catch, thanks Kasimier ! Daniel
By the way: the @select attribute on a xsl:call-template is not allowed; i.e., only the @name attribute is allowed. The processor currently just misses to report this error.