314660 - XML Parsing Error: out of memory when parsing remote XUL CMS and crash [@ nsExpatDriver::ParseBuffer] [@ little2_updatePosition]

Status: RESOLVED INCOMPLETE

(Core :: XML, defect)

Description

[Daniel Sevcik]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

I'm getting random errors of this type:

XML Parsing Error: out of memory
Location: http://bugzilla:[e-mail]/admin/
Line Number XXX, Column X:

I'm seeing this errors for few months with different builds of Firefox but I was unable to provide you with URL - it was on local development machnine.

It happens randomly. Sometimes it helps to re-open the tab and try again, somtimes helps to click on "reload current page" numerous times and sometimes restarting the Firefox helps...

It happens at least once for every 20 reloads for me. But sometimes it happens ten times in row...


Reproducible: Sometimes

Steps to Reproduce:
It is enough to go to page 
http://bugzilla:[e-mail]/admin/

If page loades then it is not the case. You should see red message for example like this one:

XML Parsing Error: out of memory
Location: http://bugzilla:[e-mail]/admin/
Line Number 417, Column 1:

<?xml-stylesheet href="/packages/filemanager/secure/css/chrome.css" type="text/css"?>
^

Actual Results:  
XML Parsing Error: out of memory
Location: http://bugzilla:[e-mail]/admin/
Line Number 417, Column 1:

<?xml-stylesheet href="/packages/filemanager/secure/css/chrome.css" type="text/css"?>
^

Expected Results:  
XUL application 

I experienced it on Windows XP box, notebook with gentoo, workstation with gentoo - all with Firefox installed. (Few months ago I experienced it with Epiphany, Mozilla Suite on gentoo too, but I resign to test it in all browsers from then so I'm not sure if the problem persists.)

Comment 1

[Daniel Sevcik]

Attachment: Captured communication from port 80 when problem occured

Captured file containing communication from port 80 when problem occured:XML Parsing Error: out of memory Location: http://live.webdevelopers.cz/admin/ Line Number 461, Column 54

Comment 2

[Daniel Sevcik]

It looks like the problem is only for HTTP. So far I didn't noticed it under HTTPS.

Comment 3

[Peter van der Woude [:Peter6]]

*** Bug 315460 has been marked as a duplicate of this bug. ***

Comment 4

[Peter van der Woude [:Peter6]]

crashes

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051107
Firefox/1.5 ID:2005110712

TB11568621M
TB11568891K

Comment 5

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051107 Firefox/1.5 ID:2005110712
TB11569266X
TB11569249K

Comment 6

[Martijn Wargers (dead)]

From Talkback ID's:
little2_updatePosition  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/parser/expat/lib/xmltok_impl.c, line 1745]
MOZ_XML_GetCurrentColumnNumber  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/parser/expat/lib/xmlparse.c, line 1726]
nsExpatDriver::ParseBuffer  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/parser/htmlparser/src/nsExpatDriver.cpp, line 940]
nsExpatDriver::ConsumeToken  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/parser/htmlparser/src/nsExpatDriver.cpp, line 984]
nsParser::Tokenize  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/parser/htmlparser/src/nsParser.cpp, line 2826]

So maybe a Core->XML bug?

Comment 7

[Adam Guthrie]

I get this assertion before I crash:

###!!! ASSERTION: Unexpected negative value?: 'parserBytesConsumed == -1', file /moz/mozilla/parser/htmlparser/src/nsExpatDriver.cpp, line 877
Break: at file /moz/mozilla/parser/htmlparser/src/nsExpatDriver.cpp, line 877

Then the stacktrace: 

#6  0xb4715c7e in little2_updatePosition (enc=0xb472c1e0, ptr=0x8ca4000 <Address 0x8ca4000 out of bounds>, end=0x8c7254e " ", pos=0x88afa6c) at xmltok_impl.c:1745
#7  0xb46ff115 in MOZ_XML_GetCurrentColumnNumber (parser=0x88af8d8) at /moz/mozilla/parser/expat/lib/xmlparse.c:1725
#8  0xb46d58f2 in nsExpatDriver::HandleError (this=0x8876ac8) at /moz/mozilla/parser/htmlparser/src/nsExpatDriver.cpp:805
#9  0xb46d6098 in nsExpatDriver::ParseBuffer (this=0x8876ac8, aBuffer=0x8c62180 "<", aLength=9102, aIsFinal=0) at /moz/mozilla/parser/htmlparser/src/nsExpatDriver.cpp:938
#10 0xb46d61e4 in nsExpatDriver::ConsumeToken (this=0x8876ac8, aScanner=@0x890faa0, aFlushTokens=@0xbfbc0994) at /moz/mozilla/parser/htmlparser/src/nsExpatDriver.cpp:981
#11 0xb46e9db4 in nsParser::Tokenize (this=0x8770280, aIsFinalChunk=1) at /moz/mozilla/parser/htmlparser/src/nsParser.cpp:2714
#12 0xb46ed134 in nsParser::ResumeParse (this=0x8770280, allowIteration=1, aIsFinalChunk=1, aCanInterrupt=1) at /moz/mozilla/parser/htmlparser/src/nsParser.cpp:1871
#13 0xb46edbb5 in nsParser::ContinueInterruptedParsing (this=0x8770280) at /moz/mozilla/parser/htmlparser/src/nsParser.cpp:1350
#14 0xb46e8b2f in nsParser::ContinueParsing (this=0x8770280) at /moz/mozilla/parser/htmlparser/src/nsParser.cpp:1328
#15 0xb51c6210 in CSSLoaderImpl::SheetComplete (this=0x88b23c0, aLoadData=0x8c78b38, aStatus=0) at /moz/mozilla/layout/style/nsCSSLoader.cpp:1502
#16 0xb51c7781 in CSSLoaderImpl::ParseSheet (this=0x88b23c0, aStream=0x88d46b8, aLoadData=0x8c78b38, aCompleted=@0xbfbc0c90) at /moz/mozilla/layout/style/nsCSSLoader.cpp:1431
#17 0xb51c7f3c in SheetLoadData::OnStreamComplete (this=0x8c78b38, aLoader=0x8c712b8, aContext=0x0, aStatus=0, aDataStream=0x88d46b8) at /moz/mozilla/layout/style/nsCSSLoader.cpp:826
#18 0xb712d8fe in nsUnicharStreamLoader::OnStopRequest (this=0x8c712b8, request=0x8c78bf0, ctxt=0x0, aStatus=0) at /moz/mozilla/netwerk/base/src/nsUnicharStreamLoader.cpp:172
#19 0xb712b49c in nsStreamListenerTee::OnStopRequest (this=0x8c2a6d8, request=0x8c78bf0, context=0x0, status=0) at /moz/mozilla/netwerk/base/src/nsStreamListenerTee.cpp:65
#20 0xb71bd847 in nsHttpChannel::OnStopRequest (this=0x8c78bc0, request=0x8c79888, ctxt=0x0, status=0) at /moz/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp:4095
#21 0xb70fccd3 in nsInputStreamPump::OnStateStop (this=0x8c79888) at /moz/mozilla/netwerk/base/src/nsInputStreamPump.cpp:506
#22 0xb70fcdf6 in nsInputStreamPump::OnInputStreamReady (this=0x8c79888, stream=0x8c7978c) at /moz/mozilla/netwerk/base/src/nsInputStreamPump.cpp:343
#23 0xb7e40a9d in nsInputStreamReadyEvent::EventHandler (plevent=0x8c79cdc) at /moz/mozilla/xpcom/io/nsStreamUtils.cpp:119
#24 0xb7e63382 in PL_HandleEvent (self=0x8c79cdc) at /moz/mozilla/xpcom/threads/plevent.c:688
#25 0xb7e6320e in PL_ProcessPendingEvents (self=0x80c84d8) at /moz/mozilla/xpcom/threads/plevent.c:623
#26 0xb7e66291 in nsEventQueueImpl::ProcessPendingEvents (this=0x80dead8) at /moz/mozilla/xpcom/threads/nsEventQueue.cpp:417
#27 0xb6710514 in event_processor_callback (source=0x846f7e8, condition=G_IO_IN, data=0x80dead8) at /moz/mozilla/widget/src/gtk2/nsAppShell.cpp:67
#28 0xb77c431c in g_vasprintf () from /usr/lib/libglib-2.0.so.0
#29 0xb779d4ee in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#30 0xb77a04f6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#31 0xb77a07e3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#32 0xb7ba1e65 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#33 0xb6710f0a in nsAppShell::Run (this=0x815d1c8) at /moz/mozilla/widget/src/gtk2/nsAppShell.cpp:139
#34 0xb660277f in nsAppStartup::Run (this=0x815d180) at /moz/mozilla/toolkit/components/startup/src/nsAppStartup.cpp:161
#35 0x080521e1 in XRE_main (argc=1, argv=0xbfbc14d4, aAppData=0x806bc80) at /moz/mozilla/toolkit/xre/nsAppRunner.cpp:2289
#36 0x0804b436 in main (argc=1, argv=0xbfbc14d4) at /moz/mozilla/browser/app/nsBrowserApp.cpp:61

Comment 8

[Ria Klaassen (not reading all bugmail)]

Regression between 1.9a1_2005083010 and 1.9a1_2005083019 if it matters.

Comment 9

[Steve England [:stevee]]

Bonsia range from comment 8

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-30+09&maxdate=2005-08-30+20&cvsroot=%2Fcvsroot

Comment 10

[Ria Klaassen (not reading all bugmail)]

Weird but I can't reproduce any crash in branch although it's very easy in trunk.

Comment 11

[Peter van der Woude [:Peter6]]

this bug sux if you try to find the regression(s).
for one, you MUST create a new profile for every test you do !
(if not, you get completely diffrent results)

I spend the last 2 hours figuring it out, but will need far more hours to get a better result (which i really don't have atm).

Sofar i found (for branch):
until 20050830 1443 pdt the page loads fine
after that it loads forever
on 20050901 0702pdt it works fine (just 1 day)
after that the page loads forever again
in the 20051006 1447pdt (i picked a random date/time) build openin with middleclick is ok, opening with click (open in same tab) crashes
in the 20051014 0408pdt (i picked a random date/time) build I crash with both click and middleclick

observation from behaviour since 20050901, the page loads to ~90% and after that it's either full load, endless load or crash, but it all seems to start after that 90% load. 

Comment 12

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051108 Firefox/1.5 ID:2005110803
some more crahes whith vanilla profile (new for every test)

using leftclick on URL (2 tests - crashed 100%):
TB11612707X
TB11612556Y

using middleclick on URL (4 tests - crahed 25%):
TB11612654G

after that I got 403 for that page, so no further testing possible

Comment 13

[Daniel Sevcik]

I'm sorry. I work every day on the live.webdvelopers.cz... Please, use this address instead (it is the clon of the live.webdevelopers.cz):

http://dead.webdevelopers.cz/admin/?loader&direct

(parameters loader&direct skips the simple intro XUL page that I created because of this bug to be notified about any load failures...)

Comment 14

[Peter van der Woude [:Peter6]]

(In reply to comment #13)
> I'm sorry. I work every day on the live.webdvelopers.cz... Please, use this
> address instead (it is the clon of the live.webdevelopers.cz):
> 
> http://dead.webdevelopers.cz/admin/?loader&direct
> 
> (parameters loader&direct skips the simple intro XUL page that I created
> because of this bug to be notified about any load failures...)
> 
another 403 for me ,or have i been banned ?
I must have opened the page 100's of times trying to find the regressionwindow with different builds

Comment 15

[Boris Zbarsky [:bzbarsky]]

Peterv, any idea what's up here?  I don't crash on Linux, but I seem to go into an infinite loop where restarting the parser after loading a stylesheet tries to parse the same exact XML PI again, loading the stylesheet again, etc etc...  Pretty soon I'm up to 3000-some stylesheets in the document.

My build which doesn't block the parser for stylesheets just loads the page with no problems...

Comment 16

[Peter Van der Beken [:peterv]]

Need a testcase, preferably attached to bugzilla. The URL is 404 now.

Comment 17

[Peter Van der Beken [:peterv]]

I can't reproduce this on OS X, in a debug build I do crash but somewhere in layout code:

#0	0x0138a7a0 in NS_LogCOMPtrAddRef_P at nsTraceRefcntImpl.cpp:1164
#1	0x0d142350 in nsGetterAddRefs<nsIScrollbarMediator>::~nsGetterAddRefs at nsCOMPtr.h:1370
#2	0x0ca68e0c in nsNativeScrollbarFrame::Hookup at nsNativeScrollbarFrame.cpp:310
#3	0x0ca6928c in nsNativeScrollbarFrame::GetPrefSize at nsNativeScrollbarFrame.cpp:279
#4	0x0ca5e920 in nsSprocketLayout::GetPrefSize at nsSprocketLayout.cpp:1345
#5	0x0ca5a6c4 in nsBoxFrame::GetPrefSize at nsBoxFrame.cpp:906
#6	0x0c8adb60 in nsXULScrollFrame::AddRemoveScrollbar at nsGfxScrollFrame.cpp:2010
#7	0x0c8addb4 in nsXULScrollFrame::AddVerticalScrollbar at nsGfxScrollFrame.cpp:1957
#8	0x0c8b0378 in nsXULScrollFrame::Layout at nsGfxScrollFrame.cpp:2279
#9	0x0c8b083c in nsXULScrollFrame::DoLayout at nsGfxScrollFrame.cpp:1282
#10	0x0ca55a94 in nsIFrame::Layout at nsBox.cpp:798
#11	0x0ca6076c in nsSprocketLayout::Layout at nsSprocketLayout.cpp:543
#12	0x0ca59f40 in nsBoxFrame::DoLayout at nsBoxFrame.cpp:1063
#13	0x0ca55a94 in nsIFrame::Layout at nsBox.cpp:798
#14	0x0ca6076c in nsSprocketLayout::Layout at nsSprocketLayout.cpp:543
#15	0x0ca59f40 in nsBoxFrame::DoLayout at nsBoxFrame.cpp:1063
#16	0x0ca55a94 in nsIFrame::Layout at nsBox.cpp:798
#17	0x0ca6076c in nsSprocketLayout::Layout at nsSprocketLayout.cpp:543
#18	0x0ca59f40 in nsBoxFrame::DoLayout at nsBoxFrame.cpp:1063
#19	0x0ca55a94 in nsIFrame::Layout at nsBox.cpp:798
#20	0x0ca6076c in nsSprocketLayout::Layout at nsSprocketLayout.cpp:543
#21	0x0ca59f40 in nsBoxFrame::DoLayout at nsBoxFrame.cpp:1063
#22	0x0ca55a94 in nsIFrame::Layout at nsBox.cpp:798
#23	0x0ca6076c in nsSprocketLayout::Layout at nsSprocketLayout.cpp:543
#24	0x0ca59f40 in nsBoxFrame::DoLayout at nsBoxFrame.cpp:1063
#25	0x0ca55a94 in nsIFrame::Layout at nsBox.cpp:798
#26	0x0ca61ad8 in nsStackLayout::Layout at nsStackLayout.cpp:318
#27	0x0ca59f40 in nsBoxFrame::DoLayout at nsBoxFrame.cpp:1063
#28	0x0ca55a94 in nsIFrame::Layout at nsBox.cpp:798
#29	0x0ca5968c in nsBoxFrame::Reflow at nsBoxFrame.cpp:809
#30	0x0ca51e94 in nsRootBoxFrame::Reflow at nsRootBoxFrame.cpp:216
#31	0x0c87bf1c in nsContainerFrame::ReflowChild at nsContainerFrame.cpp:741
#32	0x0c929ff0 in ViewportFrame::Reflow at nsViewportFrame.cpp:242
#33	0x0c82c710 in IncrementalReflow::Dispatch at nsPresShell.cpp:853
#34	0x0c8430b0 in PresShell::ProcessReflowCommands at nsPresShell.cpp:6533
#35	0x0d130c10 in ReflowEvent::HandleEvent at nsPresShell.cpp:6359
#36	0x0c843490 in HandlePLEvent at nsPresShell.cpp:6377
#37	0x0136f1d4 in PL_HandleEvent at plevent.c:688
#38	0x0136efb8 in PL_ProcessPendingEvents at plevent.c:623
#39	0x0136f7f0 in _md_EventReceiverProc at plevent.c:1559
#40	0x9075da68 in __CFRunLoopDoSources0
#41	0x9075cf98 in __CFRunLoopRun
#42	0x9075ca18 in CFRunLoopRunSpecific
#43	0x9318f1e0 in RunCurrentEventLoopInMode
#44	0x9327403c in GetNextEventMatchingMask
#45	0x93273df0 in WNEInternal
#46	0x93273d50 in WaitNextEvent
#47	0x0990b0d8 in nsMacMessagePump::GetEvent at nsMacMessagePump.cpp:384
#48	0x0990ca38 in nsMacMessagePump::DoMessagePump at nsMacMessagePump.cpp:281
#49	0x098f6090 in nsAppShell::Run at nsAppShell.cpp:106
#50	0x0a4c9e14 in nsAppStartup::Run at nsAppStartup.cpp:161
#51	0x0020fbf0 in XRE_main at nsAppRunner.cpp:2364
#52	0x00002d18 in main at nsBrowserApp.cpp:61

Comment 18

[Sébatien HEITZMANN]

I Think I have exactly the same bug on 

http://ucaplast.gestnews.com/xul/

Comment 19

[Sébatien HEITZMANN]

(In reply to comment #18)
> I Think I have exactly the same bug on 
> 
> http://ucaplast.gestnews.com/xul/
> 

It happend 100% of time on a newly installed FF2.0 on Windows XP.
I have sometime the bug on my Ubuntu with FF 1.5

Comment 20

[chris hofmann]

anyone seen this lately?  I get mostly 404s or login pages on the test links.

Comment 21

[Jesse Ruderman]

This bug seems to cover several issues.  We would need separate bug reports on what causes us to run out of memory (comment 15, stylesheet recursion?) and the specific places where being out of memory causes us to crash (e.g. comment 17).  And it sounds like we have no way to reproduce, which would make it hard to collect enough information for any of those bugs.

Comment 22

[Jesse Ruderman]

Maybe the running-out-of-memory was bug 226425.