325456 - A large XML causes mozilla to trap

Status: RESOLVED WORKSFORME

(Core :: XML, defect)

Description

[Vit Timchishin]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.10) Gecko/20050720 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.10) Gecko/20050720 Firefox/1.0.6

When loading large XML file (over 4 megs) I am getting either SYS3175 or SYS0147 (still have ram available at that time)

Reproducible: Always

Steps to Reproduce:
1. Create large and complex XML file
2. Load it
3.

Actual Results:  
Either 
02-01-2006  17:24:30  SYS3175  PID 009a  TID 0001  Slot 009e
Z:\BIN\FIREFOX\BIN\FIREFOX.EXE
c0000005
1d54b852
P1=00000001  P2=00000000  P3=XXXXXXXX  P4=XXXXXXXX  
EAX=0011f114  EBX=00000000  ECX=0011efd4  EDX=00000000
ESI=00000000  EDI=00000000  
DS=0053  DSACC=f0f3  DSLIM=ffffffff  
ES=0053  ESACC=f0f3  ESLIM=ffffffff  
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:1d54b852  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0011efb0  SSACC=f0f3  SSLIM=ffffffff
EBP=0011f00c  FLG=00012246

GKLAYOUT.DLL 0001:0010b852

or SYS0147. In case of SYS0147 it does not written to POPUPLOG.OS2, but shows popup. Closing popup does not help - you get new one. The only option is to reboot.

Expected Results:  
XML loaded and displayed

Comment 1

[Peter Weilbacher]

Vit, can you please try with Firefox 1.5.0.1?

Also, reproducing (and possibly fixing) would be much easier if you could point to such a large XML file. If there isn't any on the web, could you perhaps create and upload (zipped) it somewhere? Or email me?

Comment 2

[Vit Timchishin]

Sure, here you are :
------------------------------------------------------------

03-20-2006  11:47:04  SYS3175  PID 0063  TID 0001  Slot 0075
Z:\BIN\FIREFOX\FIREFOX.EXE
c0000005
002a3c9f
P1=00000001  P2=00000020  P3=XXXXXXXX  P4=XXXXXXXX
EAX=00000000  EBX=00a1bd8c  ECX=00000000  EDX=00a1bd8c
ESI=00a1f624  EDI=00000001
DS=0053  DSACC=f0f3  DSLIM=ffffffff
ES=0053  ESACC=f0f3  ESLIM=ffffffff
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:002a3c9f  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:00a1ba1c  SSACC=f0f3  SSLIM=ffffffff
EBP=00a1ba1c  FLG=00012206

FIREFOX.EXE 0001:00293c9f
-----------------------------------------------------------
I will send you file directly - it is generated on real data, yet
I did remove all the numbers, it still does have names.

Comment 3

[Peter Weilbacher]

Vit, thanks, I received the file and it crashes here, too. I tried with a SeaMonkey from the trunk. The file takes fairly long to load and the crash occurs when almost all my RAM is used up.

In the debugger I saw one crash to occur at http://lxr.mozilla.org/seamonkey/source/layout/generic/nsIFrame.h#623
in the line that says
   nsIFrame* GetParent() const { return mParent; }
Subsequent attempts always crashed the debugger, too, so I didn't get very far in analyzing it.

Does your POPUPLOG.OS2 show if the crash always occurs at the same address?

Comment 4

[Peter Weilbacher]

It also takes a long time (a minute and more) to display on a similarly fast machine under Linux, but there it only uses lots of RAM and in the end _does_ display, so this is most likely an OS/2 only problem.

Comment 5

[Vit Timchishin]

Yes, it gives (at least for two times I've tried to load the document) same address.
It loads for 5 seconds, using ~ 200 MB of RAM (still more available), then traps.
I have VIRTUALADDRESSLIMIT=2048 (this is limit of VIRTUAL memory per application in OS/2) - 2 GB. Is it possible it uses much more virtual memory?
I will try now with VIRTUALADDRESSLIMIT=3072 to see if something change.

Comment 6

[Vit Timchishin]

Yes, it still crashed at the same point with VAL=3072. And I was incorrect, it takes not 10 secs, but nearly a minute.
Here is my current version (From Help->About):
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.0.1) Gecko/20060202 Firefox/1.5.0.1

Comment 7

[Peter Weilbacher]

OK, the crash location I posted in comment 3 can only happen in a debug build (it was caused by the NS_ASSERTION "In-flow frame has wrong parent" on line 1443 of nsCSSFrameConstructor.cpp).

Once I removed the extra call from the debug build, I get a similar crash in GetNextSibling() (also in nsIFrame.h). That function gets called a few hundred thousand times, so it's really difficult to catch it with the debugger.

Comment 8

[Vit Timchishin]

Another bug has information on similar crashes. Adding to dependencies

Comment 9

[Vit Timchishin]

Copy from bug  https://bugzilla.mozilla.org/show_bug.cgi?id=197956:

------- Comment #32 From Jeremy M. Dolan 2006-05-05 22:20 PDT [reply] -------

Seems like the most relevent bug to mention this. Just (unknowingly) tried to
load a large (14 meg) xml file. Firefox completely locked and had to be killed.

The file was an iTunes music library file, and is available:
http://ehpg.net/~gmr/Library.xml

Comment 10

[Peter Weilbacher]

I just tried to load your XML test file again, this time with my "high memory" enabled SeaMonkey 1.1b3 build from http://weilbacher.org/Mozilla/builds.html. It does not crash any longer. And while it takes several minutes to display it, uses 100% CPU during this time, and in the end consumes 372 MB of shared RAM, it is quite usable once the page has finished loading. My setup contains VIRTUALADDRESSLIMIT=1536 to make use of "high" memory.

Comment 11

[Vit Timchishin]

I did move to another OS, so can't test this on newer builds. Changing to WORKSFORME :)