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 61608 - xsltproc --repeat crashes for certain documents
xsltproc --repeat crashes for certain documents
Status: VERIFIED INCOMPLETE
Product: libxslt
Classification: Platform
Component: general
unspecified
Other All
: Normal major
: ---
Assigned To: Daniel Veillard
Daniel Veillard
Depends on:
Blocks:
 
 
Reported: 2001-10-02 19:01 UTC by mcarrato
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description mcarrato 2001-10-02 19:01:59 UTC
This applies to release version 1.0.4. I have built it in Microsoft Visual 
Studio, but I think the bug applies to all versions.

When running xsltproc with --repeat, the app crashes.

I have examined the code, and it appears that the second application of a 
stylesheet is failing because it has cached pointers into the original 
source document. Of course, the original source document is destroyed so 
those cache pointers are pointing to garbage.

It seems as if the call to xsltCleanupTemplates(style) should clean up 
this cache information, but it is not. The actual crash occurs in 
pattern.c, line 571. Here is the context (>>> identifies the offending 
line):

		if ((select != NULL) &&
		    (select->op == XSLT_OP_ELEM) &&
		    (select->value != NULL) &&
		    (node->type == XML_ELEMENT_NODE) &&
		    (node->parent != NULL)) {

		    if ((select->previous != NULL) &&
>>>>>>>>>		(select->previous->parent == node->parent)) {
			/*
			 * just walk back to adjust the index
			 */
			int indx = 0;
			xmlNodePtr sibling = node;

The select->previous pointer is bad (non-NULL, invalid). In the first call 
to xsltApplyStylesheet(...), select->previous is NULL, whereas in the 
second call (at the same point of traversal) it is NOT null, so it appears 
that the value is not being cleaned up from the previous call.

I believe the way to fix this is to add cleanup code to 
xsltCleanupTemplates(), specifically to clean up all of the cached values 
in all of the xsltCompMatchPtr members in the stylesheet structure.
Comment 1 Daniel Veillard 2001-10-05 09:22:21 UTC
I can't reproduce this here, I tried with half a dozen
stylesheets which seems to use the cache, can you provide
a testcase which exhibit the problem ?

thanks,

Daniel
Comment 2 mcarrato 2001-10-05 17:00:48 UTC
I am attempting to create a simple test document pair that reproduces 
this bug, but I am having difficulty. The XSL/XML that produces this 
crash is fairly complicated, and when I try to trim it down to a 
reasonable sample the crash seems to go away. Unfortunately, I can't 
provide the entire sample because it contains proprietary info. I 
will continue to try to produce an appropriate sample.

Mike
Comment 3 Daniel Veillard 2001-11-26 14:04:23 UTC
Well no more info, let's close the bug unless one can provide
an example,

Daniel