RE: [xsl] Bizarre problem with MSXML4 that doesn't happen in MSXM L3

Subject: RE: [xsl] Bizarre problem with MSXML4 that doesn't happen in MSXM L3
From: Rod Humphris - FLPTN <rod.humphris@xxxxxxxxxxxxxx>
Date: Fri, 11 Apr 2003 17:24:09 +0100
Just to ask the obvious:

Is this reproduceable on multiple machines?
Have you rulled out having a duff copy of msxml4 by removing and
reinstalling from a different source (eg a new download)?
Is it the unique instance of the xslt that causes the problem or does the
same code written again, perhaps in a different editor, cause the same
error?

I'm curious because we have a lot of code now that uses it and have seen no
problems.

Cheers 

Rod

-----Original Message-----
From: Josh Twist [mailto:jtwist@xxxxxxxxxxxxxxx]
Sent: 11 April 2003 16:16
To: XSL-List@xxxxxxxxxxxxxxxxxxxxxx
Subject: [xsl] Bizarre problem with MSXML4 that doesn't happen in MSXML3


Has anybody else ran into problems with MSXML4 crashing intermittently
when transforming certain XSL templates?

We've trawled the lists and we can't find anything that matches our
problem (including this post with a similar problem:
http://www.biglist.com/lists/xsl-list/archives/200208/msg00029.html; but
we aren't using the number() function at all).

It only happens with certain templates and will crash about 1 in every 7
runs (though it is entirely random).

We're using the Xselerator product and that bails out with the following
error "Access violation at address 69B219E9 in module 'msxml4.dll'. Read
of address 00000000"

We've also written a test VB app to repeatedly transform the XSLT and that
crashes leaving the following in the event log: "Faulting application
testxml4.exe, version 1.0.0.0, faulting module msxml4.dll, version
4.10.9404.0, fault address 0x0003fae7"

Neither have a problem if we transform using MSXML3 but we don't want to
go back to this as 4 runs rings around it speed-wise.

We're still not sure what is causing it, though we have noted that
commenting out the code below stops it crashing:

<xsl:variable name="objacl">
<!--
	COMMENT THIS OUT AND IT DOESN'T CRASH
	<xsl:choose>
		<xsl:when test="count(object/data/row) > 0">
			<xsl:value-of
select="/object/data/row[1]/field[@ref='f1']"/>
		</xsl:when>
		<xsl:when test="boolean(/object/securityacl)=true">
			<xsl:value-of select="/object/securityacl"/>
		</xsl:when>
		<xsl:otherwise>00000000</xsl:otherwise>
	</xsl:choose>
-->
</xsl:variable>

This is particularly strange as this code is used in other templates that
don't crash (and the resulting variable is used in other templates in just
the same way). Additionally, commenting out some different bits of code
can also stop the crash though again, there seems to be no pattern or
logic to what will and won't crash it.

This feels like we're chasing rainbows. The crash is intermittent and we
can't chase it down or isolate it. Any ideas?

Apologies if this problem has been covered before but we'd sure appreciate
a link to any related discussion!

Regards

Josh


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________


________________________________________________________________
Any opinions expressed in this email are those of the individual and not necessarily the Company. Unless expressly stated to the contrary, this email is not intended to give rise to a new, or affect an existing, contractual or other legal relationship.This email and any files transmitted with it, including replies and forwarded copies which may contain alterations) subsequently transmitted from the Company, are confidential and solely for the use of the intended recipient. The unauthorised use, disclosure or copying of this email, or any other information contained or attached,is prohibited and could, in certain circumstances, be a criminal offence.

If you have received this email in error please notify the sender as soon as possible.

This footnote also confirms that this email message has been swept for the presence of computer viruses.

www.focusdiy.co.uk
_________________________________________________________________

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread