Closed Bug 45831 Opened 24 years ago Closed 23 years ago

Don't catch XPath syntax error in "category/hascategories='true'"

Categories

(Core :: XSLT, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.3

People

(Reporter: jbailey, Assigned: peterv)

References

Details

(Keywords: crash)

Attachments

(1 file)

Using a standalone compile of the TransforMiiX (did I spell that right?) from
July 16th CVS, this CSS+XSLT files runs until the computer runs out of RAM and
then core dumps.

This failure occurs in the file called "fail.xsl".  There is a simple change
that I've made to isolate the failure, compare it against working.xsl

I may have made a mistake in the XSLT, I've only been writing it for 2 days.
I'm filing this bug because I figure that core dumps are bad even when the human
is stupid.

The file will be attached shortly.
Incidentally, this is how I invoke it:

./transfrmx -i categories-vcp.xml -s fail.xsl -o output.html

I just change fail.xsl with working.xsl and I get an output.html
Hi Jeff,
I tested this, and confirm this bug. This is a bug in our xpath implememtation,
as the xsl is horked, and we should bail on it.

Jeff, if you change the xsl to
<xsl:template match="category[attribute::hascategories='true']">
it works allright.

Keith, Peter, is there any syntax checking in the xpath implementation?
From a short glimpse on the spec, we can have comparisons only in [], is that 
right?

Axel
Status: NEW → ASSIGNED
Thanks for the tip - I found the XSL problem by using xalan from the Apache
group.  I really appreciated the output that it gave, and it might be nice to
expose this information.  I can file this as a separate RFE if you'd like.
Here's the output sample:

========= Parsing file:/home/jbailey/xslt/fail.xsl ==========
XSL Error: pattern = 'category/hascategories='true''
Extra illegal tokens: '=', ''true'', style tree node:
org.apache.xalan.xslt.ElemTemplate@daa81937
XSL Error: Could not parse file:/home/jbailey/xslt/fail.xsl document!, Location
file:/home/jbailey/xslt/fail.xsl, line 19, offset 53
XSL Error: processStylesheet not succesfull!, Location
file:/home/jbailey/xslt/fail.xsl, line 19, offset 53
XSLT: pattern = 'category/hascategories='true''
Extra illegal tokens: '=', ''true''
Xalan: was not successful.
XSLProcessor: done
There is some syntax checking, but we could definately use some better error 
reporting. I'll look into this, and see if I can add some this weekend.
Using Jeff's test case I found a bug in ExprParser.cpp in createPathExpr. If the 
token is an operator, it pushes it back on the stack, and then returns...but the 
function it's returning too, will eventually call the method again, and we get 
into an endless loop. Basically we need to report the error, but at this point 
in the parser we don't have too many options. So, I am modifying PathExpr to 
take an error message, and upon evaluation, it will report this error to the 
ContextState. We really need to redesign error handling within in the processor, 
but hopefully this *hack* will temporarily resolve the issue. I'll check in the 
temp fix soon.
Status: ASSIGNED → NEW
spam: Adding crash keyword...
Keywords: crash
Is this still a problem? Can it be closed or at least moved to assigned.
Do we want to open a tracking bug on error handling/reporting?
Status: NEW → ASSIGNED
OK, we need to get the error observer from the ProcessingState to the 
ExprParser, too.
Reassigning to peterv, he has state-plans. Setting milestone 0.9, we should
have some error handling then.
Updating all kinds of fields. No dependency on tracker, IMHO, not really 
blocking.

Axel
Assignee: kvisco → peterv
Status: ASSIGNED → NEW
OS: Linux → All
Hardware: PC → All
Summary: Crash when matching against specific value of an attribute → Don't catch XPath syntax error in "category/hascategories='true'"
Target Milestone: --- → mozilla0.9
Post-poning error handling.
Target Milestone: mozilla0.9 → mozilla0.9.1
moving to TM of 0.9.2 per PDT triage (you can check it into 0.9.1 until Friday,
18/May/01 or into 0.9.2 after the tree opens)
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Priority: P3 → P2
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Fixed with the lexer/parser rewrite
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
I did that allright.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: