.xml page did not load

VERIFIED FIXED in M4

Status

()

P1
critical
VERIFIED FIXED
20 years ago
20 years ago

People

(Reporter: njames, Assigned: nisheeth_mozilla)

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

20 years ago
I tried to load a .xml page and this happed it crashed and here is the details.

APPRUNNER caused an invalid page fault in
module KERNEL32.DLL at 0177:bff87eaa.
Registers:
EAX=00000001 CS=0177 EIP=bff87eaa EFLGS=00010202
EBX=0076fe28 SS=017f ESP=04220074 EBP=0076f81c
ECX=0076f80c DS=017f ESI=0076f864 FS=4bef
EDX=00000001 ES=017f EDI=8166b0a0 GS=0000
Bytes at CS:EIP:
55 a1 d8 9c fc bf 8b ec 83 ec 6c 53 56 57 8b 30
Stack dump:
ffecbad7 042200a4 04220088 0000000e 00000007 c0000005 00000000 00000000 bff87eaa
00000002 00000001 0422017c 0001001f 00000000 00000000 00000000
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: M4
(Assignee)

Comment 1

20 years ago
Setting target to M4 and accepting bug...

Comment 2

20 years ago
OK, this is a pretty bad bug.  Here's what happens on NT.  The status bar shows
that about 32K of the new document has been loaded and then the system goes into
an infinite loop eating up all the available system memory.  When the browser is
forced to exit, all the memory is reclaimed.

I'll update this as I know more...
(Assignee)

Comment 3

20 years ago
I posted the earlier message from Troy's computer, so please don't bug troy
about this bug.
(Assignee)

Comment 4

20 years ago
For some reason, nsDecoderSupport::DoubleBuffer() in
mozilla/intl/uconv/ucvlatin/nsUCvLatinSupport.cpp keeps getting called during
unicode character conversion of the data coming from the netlib stream.  These
repeated calls keep increasing the size of mBuffer in nsDecoderSupport
exponentially until all memory is exhausted.

I've asked the owner of nsDecoderSupport, cata@netscape.com, to take a
look at this problem.  Adding cata and chofmann to the cc list.

Comment 5

20 years ago
Ok, I found a fix. There were 2 problems:

1) The XML parser was using the wrong converter: UTF8 (default) instead of the
specified Latin1. That's because the parser should really read & interpret this
line in the .xml file: <?xml version='1.0' encoding='ISO-8859-1'
standalone='no'?>

2) The crash happened because the UTF8 converter was encountering a wrong input
char and entered into an unexpected error state - the internal buffer was being
doubled in a loop! - buggy handling of illegal input.

I fixed the 2nd issue in a very minimalistic way, by limiting the size of the
internal buffer and returning err when that limit is reached. I checked into the
tip. Nisheeth will check it out, locally merge it to the M4 branch, test it and
check it into the M4 branch.
(Assignee)

Updated

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

Comment 6

20 years ago
I've checked in cata's fix to the M4 branch.

I want to explicitly state that this bug was not related to the expat checkin.
It happened even when expat was disabled.

cata's earlier post saying that the "XML parser was using the wrong converter",
might lead one to believe that the problem was with expat.  Please keep in mind
that he is referring to the nsParser object which coordinates the parsing of XML
*and* HTML documents; the nsParser object has been a part of the Gecko
architecture from day one.  Expat, the newly added code, is hidden behind the
nsIExpatTokenizer interface and is only responsible for converting the XML
stream into a sequence of tokens that get fed into the XML DTD.

Updated

20 years ago
QA Contact: 3849 → 4110

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 7

20 years ago
Using 5/10 Apprunner, no crashes. Verifying bug fixed.

Comment 8

20 years ago
Correcting the previous comments, bug was verified fixed with 5/20 Apprunner
You need to log in before you can comment on or make changes to this bug.