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

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?

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.

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?

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.

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.

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

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.

Another bug has information on similar crashes. Adding to dependencies

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

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.

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