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

Setting target to M4 and accepting bug...

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

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

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.

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.

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.

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

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