Error in Expat Tokenizer does not stop parsing process

VERIFIED FIXED in M7

Status

()

P1
normal
VERIFIED FIXED
20 years ago
20 years ago

People

(Reporter: sdm, Assigned: harishd)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: 7/9 I need to develop a testcase for this. Will do monday.)

(Reporter)

Description

20 years ago
If I change the header of http://pimpmaster.org/simeon/xultool to:

<window xmlns:html="http://www.w3.org/TR/REC-html40"
  	xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
	style="margin: 0px;/*overflow: scroll*/"
<!--		onload="Startup();"-->
>

I get this in the terminal window:

Using Expat for parsing XML...
XML Error in file
'file:////usr/local/mozilla/dist/bin/res/samples/xultool-create.xul', Line
Number: 17, Col Number: 0, Description: not well-formed
Source Line: <!--               onload="Startup();"-->
Segmentation fault (core dumped)

Updated

20 years ago
Status: NEW → ASSIGNED
Target Milestone: M6

Comment 1

20 years ago
Setting TFV to M6 and accepting bug...

Updated

20 years ago
Assignee: nisheeth → harishd
Status: ASSIGNED → NEW
Summary: <!-- comments within a XUL tag cause crash. → Error in Expat Tokenizer does not stop parsing process
Target Milestone: M6 → M7

Comment 2

20 years ago
The XML spec says that comments within a tag are not allowed (see
http://www.w3.org/TR/1998/REC-xml-19980210#sec-comments).  So, the error
reported by expat is not a bug.

The real problem is that we crash in some cases when expat reports an error.
The reason for that behavior is that the expat tokenizer has no way to tell the
parser (nsParser) to stop processing buffers after an error is reported by the
expat parser.  So, right now, there is a hack in the expat tokenizer which
ignores all buffers passed in after an error is seen by the tokenizer.  We
need to remove the hack and do the right thing: stop the parse process when an
error occurs.  Harish has this task on his plate.  Re-assigning the bug to him.
This is probably not going to make the M6 milestone, so setting the milestone to
M7.

Updated

20 years ago
QA Contact: 4110 → 3847
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

20 years ago
Priority: P3 → P1
(Assignee)

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
(Assignee)

Comment 3

20 years ago
Checked in code, yesterday, that would allow parser to respond to errors from
XML,PICS, etc.. and "stop parsing" if necessary.

Marking the bug fixed.

Updated

20 years ago
Whiteboard: 6/18 awaiting developer response

Comment 4

20 years ago
Harish, when I try to go to the listed URL in the example
http://pimpmaster.org/simeon/xultool
I get bumped over to mozillazine.  Is there a local test I can look at and run
to verify this bug?  Thanks!
(Assignee)

Comment 5

20 years ago
Nisheeth, can you please verify this bug? Thanx

Comment 6

20 years ago
Jan, this bug can be verified by modifying any of our XUL files such that there
is a comment *within* a tag.  The XML parser should emit an error to the console
but the app should not crash.  Without Harish's fix, the app was crashing.

Updated

20 years ago
Whiteboard: 6/18 awaiting developer response → 7/9 I need to develop a testcase for this. Will do monday.

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 7

20 years ago
Verified fixt on Linux
Build ID: 1999071308

(Also checked and verified on NT)
You need to log in before you can comment on or make changes to this bug.