4874 - .xml page did not load

Status: VERIFIED FIXED

(Core :: XML, defect, P1)

Description

[njames]

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

Comment 1

[Nisheeth Ranjan]

Setting target to M4 and accepting bug...

Comment 2

[troy]

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...

Comment 3

[Nisheeth Ranjan]

I posted the earlier message from Troy's computer, so please don't bug troy
about this bug.

Comment 4

[Nisheeth Ranjan]

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, [e-mail], to take a
look at this problem.  Adding cata and chofmann to the cc list.

Comment 5

[cata]

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.

Comment 6

[Nisheeth Ranjan]

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.

Comment 7

[Christine Hoffman]

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

Comment 8

[Christine Hoffman]

Correcting the previous comments, bug was verified fixed with 5/20 Apprunner