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)
Core
XSLT
Tracking
()
VERIFIED
FIXED
mozilla0.9.3
People
(Reporter: jbailey, Assigned: peterv)
References
Details
(Keywords: crash)
Attachments
(1 file)
6.86 KB,
application/octet-stream
|
Details |
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.
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 2•24 years ago
|
||
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
Comment 3•24 years ago
|
||
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
Reporter | ||
Comment 4•24 years ago
|
||
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
Comment 5•24 years ago
|
||
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.
Comment 6•24 years ago
|
||
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
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?
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 9•24 years ago
|
||
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
Assignee | ||
Comment 10•23 years ago
|
||
Post-poning error handling.
Target Milestone: mozilla0.9 → mozilla0.9.1
Depends on: 75102
Comment 11•23 years ago
|
||
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
Updated•23 years ago
|
Priority: P3 → P2
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Fixed with the lexer/parser rewrite
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•