Closed Bug 569229 Opened 14 years ago Closed 8 years ago

"XML Parsing Error: unexpected parser state" on netError.xhtml

Categories

(Core :: XML, defect)

Product:
Core
Component:
XML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla53
Tracking Flags:
Tracking Status
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- fixed
firefox53 --- fixed

People

(Reporter: robarnold, Assigned: peterv)

References

(
URL
)

Details

(Whiteboard: [necko-backlog])

Attachments

(2 files)

XML parse error
663.59 KB, image/jpeg
Details
v1
3.27 KB, patch
erahm
: review+
jcristau
: approval-mozilla-aurora+
Details | Diff | Splinter Review 
I see this on trunk periodically but I can't reproduce it. The page I was trying to load was timing out I think (but I'm not sure).
I have been writing my own extension and have also come across this error.

It has occurred as follows:

Error: unexpected parser state
Source file: jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/netError.xhtml
Line: 323, Column: 68
Source code:
        <div id="ed_connectionFailure">&connectionFailure.longDesc;</div>
 ----------
Error: unexpected parser state
Source file: jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/netError.xhtml
Line: 324, Column: 54
Source code:
        <div id="ed_netTimeout">&netTimeout.longDesc;</div>
 ----------
Error: unexpected parser state
Source file: jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/netError.xhtml
Line: 327, Column: 50
Source code:
        <div id="ed_netReset">&netReset.longDesc;</div>
 ----------
Error: unexpected parser state
Source file: jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/netError.xhtml
Line: 329, Column: 58
Source code:
        <div id="ed_netInterrupt">&netInterrupt.longDesc;</div>


Looking thru netError.dtd I have noticed that the ONLY ENTITYies
that refer to other ENTITYies are the following!

<!ENTITY connectionFailure.longDesc "&sharedLongDesc;">
<!ENTITY netTimeout.longDesc "&sharedLongDesc;">
<!ENTITY netReset.longDesc "&sharedLongDesc;">
<!ENTITY netInterrupt.longDesc "&sharedLongDesc;">

I doubt that this is a coincidence and the bug may be fixed by not having one
ENTITY refer to another?
Also netError.xhtml notes that the Error page is loaded in background which
may cause above noted sistuation to cause problem??
I've got an error similar to this on Mac 10.6.4, FF 3.6.13:

XML Parsing Error: unexpected parser state
Location: jar:file:///Applications/Firefox.app/Contents/MacOS/chrome/toolkit.jar!/content/global/netError.xhtml
Line Number 329, Column 58:        <div id="ed_netInterrupt">&netInterrupt.longDesc;</div>
---------------------------------------------------------^

when trying to access localhost when the server isn't running
I've been seeing this a lot lately.
This just happened to me for the first time, on a page that failed DNS resolution. Firefox 16.0.1 (French locale) on Windows XP x64.

Erreur d'analyse XML : état du parseur inattendu
Emplacement : jar:file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/omni.ja!/chrome/toolkit/content/global/netError.xhtml
Numéro de ligne 309, Colonne 54 :        <div id="ed_netTimeout">&netTimeout.longDesc;</div>
-----------------------------------------------------^
Copying my info from duplicate bug #770609



(In reply to Virtual_ManPL [:Virtual] from comment #0)
> I see that sometimes I get error page like this shown on 'error1.png' and
> 'error2.png'
> Console shows "XML Parsing Error: unexpected parser state -
> netInterrupt.longDesc in netError.xhtml". Full log can be seen in 'error in
> console.png'
> 
> It occurs when ABP is enabled. Can't reproduce it without ABP. Maybe because
> it happens rarely. So culprit for now is ABP.
> 
> Steps to reproduce:
> 1. Go to http://forums.miranda-im.org/showthread.php?2162-History
> 2. Start quickly open open all links on the right of the green text with
> CTRL + left mouse button
> 3. If it won't happen, restart browser and do 1&2 steps again
> 
> I mean this links:
> "    latest build zip: http://themiron.mirandaim.ru/historypp
>     mirror: http://slav.pp.ru/historypp
>     changelog: http://themiron.mirandaim.ru/changelog
>     debug build: http://themiron.mirandaim.ru/historypp-db
>     latest alpha zip: http://themiron.mirandaim.ru/alpha
>     changelog: https://opensvn.csie.org/traccgi/historypp/log/
>     debug build: http://themiron.mirandaim.ru/alpha-db
>     latest stable release on the Addons site:
> http://addons.miranda-im.org/details...ewfile&id=2995
> 
>     website: http://themiron.mirandaim.ru/
>     mirror: http://slav.pp.ru/
>     Wiki: https://opensvn.csie.org/traccgi/his.../trac.cgi/wiki
>     FAQ: https://opensvn.csie.org/traccgi/his...AskedQuestions"
> 
> 
> Using Nightly 16.0a1pre(20120630) and AdBlock Plus 2.1.2a5322
> 
> bug #408267
> bug #506443
> bug #569229
> bug #608051
> bug #615050
> bug #626553
> bug #633696
> bug #700206 looks related in some ways
I can reproduce the XML Parsing Error. 
And I filed Bug 812853 with STR. Bug 812853 is caused(regressed) by Bug 405407.
I think that Bug 405407 expose and trigger this bug .
Blocks: 812853
Just saw this (or something related) for the first time.  64-bit Slackware-14-current running FF 19.0.  The webpage seemed to time out while loading.  "omni.ja" is a file in the FF package; not sure where netError.xhtml lives.

XML Parsing Error: unexpected parser state
Location: jar:file:///usr/lib64/firefox-19.0/omni.ja!/chrome/toolkit/content/global/netError.xhtml
Line Number 311, Column 58:        <div id="ed_netInterrupt">&netInterrupt.longDesc;</div>
---------------------------------------------------------^
I'm getting this error in TB 17.0.5 now.  This is the full text:
XML Parsing Error: unexpected parser state Location: jar:file:///C:/Program%20Files/TBREL/omni.ja!/chrome/toolkit/content/global/netError.xhtm
Line Number 308, Column 50: <div id="ed_netReset">&netReset.longDesc;</div> -------------------------------------------------^

I don't know how to verify this, but it seems the error is thrown when I switch to a new folder and no e-mail is selected.  The message pane header, though, displays the header of the last e-mail I viewed, which is not in the folder to which I switched.
Ooops...  Sorry I entered my text too soon.  My error isn't exactly the same, but it is a parsing error.
I'm getting this error after few attempts open a website which times out.
It doesn't happened all the time however.

With a userscript for Greasemonkey/Scriptish http://userscripts.org/scripts/show/4125 it can be reproduced faster. Sometimes it takes a few hours before the error showed...
I was attempting to acess securityoveride.org when I was getting repeated timeouts and then this error.(cant access the site at all)

http://postimg.org/image/v9r5oct0j/
Got this error when trying to access my test server at home, on https://quamis.no-ip.org address.

The server is behind a router, and the DNS is served by no-ip. I belive it maybe somehow related to this configuration.


XML Parsing Error: unexpected parser state 
Location: jar:file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/omni.ja!/chrome/toolkit/content/global/netError.xhtml 

Line Number 311, Column 58: <div id="ed_netInterrupt">&netInterrupt.longDesc;</div> -----------------------------------------------------------------------------^
Component: General → Networking
Product: Firefox → Core
It's not only an Adblock Plus problem - the error seems to happen when the connection abort happens between preloading error information and overwriting it with the data of the DTD.
(In reply to dennis.heine from comment #14)
> It's not only an Adblock Plus problem - the error seems to happen when the
> connection abort happens between preloading error information and
> overwriting it with the data of the DTD.

i've got a spam pluigin installed in firefox, and blocked the corresponding page to 127.0.0.1 - this is where the error appears sometimes on my side.
I can confirm that it has something to do with localhost. I see the error sometimes when my ADSL modem/router desyncs and starts intercepting HTTP traffic to show its error page.
I dont have adblock installed.
The error doesn't seem to reappear now, after some time passed by.  The system got restarted in the meantime, if it matters.

Installed extensions: 
- Firebug
- FirePath
- LastPass
- Print Edit
- Restartless Restart
- Xmarks
The error is not related to any extensions, it can occur on fresh, empty profile. It happens several times to me when computer went to sleep mode while Firefox was attempting connect to a website, on next wake it showed this error.
Since it's not easily reproducible and takes a while before it actually occur, it suggests that it has something to do with memory cleaning or something in this nature.
@John Volikas 
i didnt say it has something to do with localhost, my setup with localhost just means that the server is not accessible.
I got this error for the first time today. The error occurred while visiting brawlcustommusic.com when the server was down.

XML Parsing Error: unexpected parser state
Location: jar:file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/omni.ja!/chrome/toolkit/content/global/netError.xhtml
Line Number 304, Column 68:
     <div id="ed_connectionFailure">&connectionFailure.longDesc;</div> -------------------------------------------------------------------^

(I'm new here so I'm not sure how to monospace text, but the arrow was pointing at the semicolon before the div closed)
(In reply to ellescuba from comment #20)
> I got this error for the first time today. The error occurred while visiting
> brawlcustommusic.com when the server was down.
> 
> XML Parsing Error: unexpected parser state
> Location:
> jar:file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/omni.ja!/chrome/
> toolkit/content/global/netError.xhtml
> Line Number 304, Column 68:
>      <div id="ed_connectionFailure">&connectionFailure.longDesc;</div>
> -------------------------------------------------------------------^
> 
> (I'm new here so I'm not sure how to monospace text, but the arrow was
> pointing at the semicolon before the div closed)

EDIT: Reading above I wanted to add these are the extensions I have installed
DownThemAll
Garmin Communicator
Greasemonkey
HTML5 Notifications
IE Tab 2
Procon Latte
RealDownloader
Test Pilot
WOT
YouTube High Definition
Freecorder (disabled)
HP Smart Web Printing (disabled, incompatible with Firefox 27)
I encountered this when I attempted to log into a GUI on a router via facing IP.

This chipset is affected by Heartbleed, just wondering if it altered to affect the rom on the router?
I have separate browser instance with ~40 pages which refreshes on periodic basis and I can see this issue at least once in a day in a few tabs at once. In another instance I have one page which updates on periodic basis with the same issue.
Same bug, on Windows 7 x64 with Firefox 29.0.1, FR-fr

Erreur d'analyse XML : état du parseur inattendu Emplacement : jar:file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/omni.ja!/chrome/toolkit/content/global/netError.xhtml Numéro de ligne 311, Colonne 58 : <div id="ed_netInterrupt">&netInterrupt.longDesc;</div> ---------------------------------------------------------^

Bug occurs on a page that has a very long loading time (a custom maintenance PHP script that only answers when finished).
Just had the same error at http://www.beeldentekst.com/wp-admin/ . Had an error 500 there before, but now I saw 

XML Parsing Error: unexpected parser state Location: jar:file:///Applications/firefox-6/Firefox.app/Contents/MacOS/omni.ja!/chrome/toolkit/content/global/netError.xhtml Line Number 311, Column 58:
<sourcetext> <div id="ed_netInterrupt">&netInterrupt.longDesc;</div> ---------------------------------------------------------^</sourcetext>
</parsererror>

I am on Firefox 29.0.1 for Mac OSX Mavericks 10.9.2 and Firefox runs Firebug with Yslow and Pagespeed extensions.
Also just encounterred error on a site that appears to be temporary down / under heavy load I think.
OS: Windows 7 → All
Hardware: x86 → All
Flags: firefox-backlog?
I've seen it today when accessing an intranet site which requires VPN connection, which I forgot to establish:

Błąd przetwarzania XML: nieoczekiwany stan parsera Obszar: jar:file:///C:/Program%20Files/Mozilla%20Firefox/browser/omni.ja!/chrome/browser/content/browser/aboutneterror/netError.xhtml Numer wiersza: 304, kolumna 68: <div id="ed_connectionFailure">&connectionFailure.longDesc;</div> -------------------------------------------------------------------^
This looks like not a Firefox front-end bug, so not suitable for our backlog.
Flags: firefox-backlog? → firefox-backlog-
Jason, do you have some suggestions for somebody who could look at this?  It seems like a very old error with a ton of dupes, and offhand it seems like it shouldn't be too complex to fix.  There's some STR in comment 7, which may or may not still apply.
Flags: needinfo?(jduell.mcbugs)
I don't know anything about the XML parser for these error codes. It looks like the line in question is coming from 

  http://mxr.mozilla.org/mozilla-central/source/docshell/resources/content/netError.xhtml#311

I don't see anything obviously syntactically wrong with it.

bz, do you know where the XML parsing code here is, and who might know how to fix this?
Flags: needinfo?(jduell.mcbugs) → needinfo?(bzbarsky)
> do you know where the XML parsing code here is,

Sure.  parser/expat

The actual string is created by nsExpatDriver::HandleError; looks like we're getting an error 23 here.

As for who would know how to fix it, maybe Peter?  That's assuming this is an expat issue and not an issue in the data someone feeds to expat....
Flags: needinfo?(bzbarsky) → needinfo?(peterv)
Here is yet another variation - different netError.xhtml file location and line number. On the Firefox 34.0 release (and many more before it) on WinXP 32bit, German locale.

It happens quite frequently on a shaky WiFi connection (although with connectivity/DNS issues mostly before the WiFi router, not due to a weak WiFi signal). Although less frequently than the regular well formed "Server/Page not found" pages.

Please note that the arrow points to the '<' in the '</div>'. I aligned the white spaces accordingly, so that it appears as in the browser. The last two lines are shown using a fixed-width font in the browser.

XML-Verarbeitungsfehler: unerwarteter Parser-Status Adresse:
jar:file:///C:/Programme/Mozilla%20Firefox/browser/omni.ja!/chrome/browser/content/browser/aboutneterror/netError.xhtml
Zeile Nr. 340, Spalte 50:

        <div id="ed_netReset">&netReset.longDesc;</div> -------------------------------------------------^
(In reply to Joe Smith from comment #49)
> Here is yet another variation - different netError.xhtml file location and
> line number. On the Firefox 34.0 release (and many more before it) on WinXP
> 32bit, German locale.
> 
> It happens quite frequently on a shaky WiFi connection (although with
> connectivity/DNS issues mostly before the WiFi router, not due to a weak
> WiFi signal). Although less frequently than the regular well formed
> "Server/Page not found" pages.
> 
> Please note that the arrow points to the '<' in the '</div>'. I aligned the
> white spaces accordingly, so that it appears as in the browser. The last two
> lines are shown using a fixed-width font in the browser.
> 
> XML-Verarbeitungsfehler: unerwarteter Parser-Status Adresse:
> jar:file:///C:/Programme/Mozilla%20Firefox/browser/omni.ja!/chrome/browser/
> content/browser/aboutneterror/netError.xhtml
> Zeile Nr. 340, Spalte 50:
> 
>         <div id="ed_netReset">&netReset.longDesc;</div>
> -------------------------------------------------^

And here is one more (WiFi is having a bad day - it could be the signal strength this time):

XML-Verarbeitungsfehler: unerwarteter Parser-Status
Adresse: jar:file:///C:/Programme/Mozilla%20Firefox/browser/omni.ja!/chrome/browser/content/browser/aboutneterror/netError.xhtml
Zeile Nr. 336, Spalte 68:

        <div id="ed_connectionFailure">&connectionFailure.longDesc;</div> -------------------------------------------------------------------^
I've seem this as well. I can post STR if I could find one.
Can someone please own and fix this bug?
Reason for this comment:
Error in different line+column (402+68). 

Story:
Occurred while trying to access an URL from a server in a VPN without beeing connected to the VPN. 

System Info:
OS: Microsoft Windows 8 Enterprise
Version: 6.2.9200 Build 9200
FF: 37.0.2

Error Msg:
XML-Verarbeitungsfehler: unerwarteter Parser-Status
Adresse: jar:file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/browser/omni.ja!/chrome/browser/content/browser/aboutNetError.xhtml
Zeile Nr. 402, Spalte 68:        

        <div id="ed_connectionFailure">&connectionFailure.longDesc;</div>
-------------------------------------------------------------------^
unfortunately the str in comment 58 is wfm.
Hi all, got the above-mentioned error for the first time today:

XML Parsing Error: unexpected parser state Location: jar:file:///usr/lib/firefox/browser/omni.ja!/chrome/browser/content/browser/aboutNetError.xhtml Line Number 393, Column 50:
        <div id="ed_netReset">&netReset.longDesc;</div>
-------------------------------------------------^

All I was doing was watching a webcam (my own, generated by Motion http://www.lavrsen.dk/foswiki/bin/view/Motion/WebHome ).  I'd created a tab and was just letting the webcam run continuously in that tab (embedded in an iframe in a plain-jane html page) while I did other work.  When I came back an hour later, it had crashed like this.

Firefox 40.0.3 on Ubuntu 12.04, x86_64.
Connected to the net via ethernet cable.
Note: The usb webcam is on a computer in the next room.
We may need to investigate all of XML_ERROR_UNEXPECTED_STATE.
https://dxr.mozilla.org/mozilla-central/search?q=XML_ERROR_UNEXPECTED_STATE

see also comment 47.
Flags: needinfo?(shishirbindu88)
I just got this connecting to a site on Firefox 42. The connection timed out. Later attempts to connect gave "The connection has timed out"

XML Parsing Error: unexpected parser state Location: jar:file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/browser/omni.ja!/chrome/browser/content/browser/aboutNetError.xhtml Line Number 395, Column 68:
        <div id="ed_connectionFailure">&connectionFailure.longDesc;</div>
-------------------------------------------------------------------^
Whiteboard: [necko-backlog]
(In reply to dotnetCarpenter from comment #70)
> If someone who already has downloaded firefox trunk could try and and parse
> the error xhtml document(s) with the DTD, I think the answer will be obvious.

Just loading the error page won't reproduce this. We'll need to either have steps to reproduce (or catch this in rr). Without that it'll be pretty hard to figure out.
Firefox 45.0.1 at WinXPSP3 32-bit.

XML Parsing Error: unexpected parser state Location: jar:file:///C:/Program%20Files/Firefox/browser/omni.ja!/chrome/browser/content/browser/aboutNetError.xhtml Line Number 448, Column 54:
        <div id="ed_netTimeout">&netTimeout.longDesc;</div>
-----------------------------------------------------^

This happened when I try to reach an unreachable web site. It seems like Firefox tries to show an error message about the connection attempt timeout. I think you can easely reproduce this by trying to connect a fully firewolled host, i.e. a host that doesn't respond to any TCP packet, even to TCP ACK (the first packet of the TCP connection handshake).
>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160429030215
STR:
1. Open c:\Windows\System32\drivers\etc\hosts, add line "127.0.0.1 ad.doubleclick.net" w/o quotes
2. Open the following page in a new window
> data::,<script>onclick=function(){for(i=0;i++<100;)open("https://ad.doubleclick.net/")}</script>
3. Click on the page content to open 100 new tabs
4. Wait until each tab is loaded (they finish loading one by one, at speed 1 page / 2 seconds)

AR:  From 2 to 9 tabs show "XML Parsing Error: unexpected parser state ...". Usually 4 of 100 tabs.
ER:  All tabs should show a normal error page.

Note:
If you have super fast PC, use 1000 pages instead of 100. By the way, I've never seen anybody else doing stress-tests on this site. I guess that's according to the plan, if nobody cares about quality.
URL: data::,<script>onclick=function(){for...
Has STR: --- → yes
yf, did you confirm the STR? I ask becuase I note you changed the STR to use a dotted decimal IP (which will change the DNS code that is executed).

so far its wfm.

I presume both of you have no server at that address? (again, I did at first.. so just trying to be clear.)
Flags: needinfo?(yfdyh000)
Yes, I can use it to reproduce this problem in Nightly 49.0a1 (2016-05-03) e10s on/off. comment 74 is not work for me, it just open blank tabs without error page.

p.s. 50 tabs is enough for me always, it triggers about 3~5 times the error.
Flags: needinfo?(yfdyh000)
thank you - especially arni2033

so this is wfm with normal optimized builds.. even with 1000 tabs.

but if I load it up with debugging - debug, no-opt builds with RR enabled then it reproduces fairly easily. With RR no less.

so that's great. Thanks.

(rr) bt
#0  CreateErrorText (aDescription=0x7ffc5bfd28e0 u"unexpected parser state", aSourceURL=0x7f129aae0014 u"file:///home/mcmanus/src/mozilla2/wd/gecko-dev/browser/base/content/aboutNetError.xhtml", aLineNumber=517, 
    aColNumber=54, aErrorString=...) at /home/mcmanus/src/mozilla2/wd/gecko-dev/parser/htmlparser/nsExpatDriver.cpp:825
#1  0x00007f12c567277a in nsExpatDriver::HandleError (this=0x7f129ae28f30) at /home/mcmanus/src/mozilla2/wd/gecko-dev/parser/htmlparser/nsExpatDriver.cpp:938
#2  0x00007f12c5673f76 in nsExpatDriver::ConsumeToken (this=0x7f129ae28f30, aScanner=..., aFlushTokens=@0x7ffc5bfd2da3: false) at /home/mcmanus/src/mozilla2/wd/gecko-dev/parser/htmlparser/nsExpatDriver.cpp:1178
#3  0x00007f12c567a33b in nsParser::Tokenize (this=0x7f129b1733a0, aIsFinalChunk=true) at /home/mcmanus/src/mozilla2/wd/gecko-dev/parser/htmlparser/nsParser.cpp:1944
#4  0x00007f12c5678e59 in nsParser::ResumeParse (this=0x7f129b1733a0, allowIteration=true, aIsFinalChunk=true, aCanInterrupt=true) at /home/mcmanus/src/mozilla2/wd/gecko-dev/parser/htmlparser/nsParser.cpp:1463
#5  0x00007f12c5678c3e in nsParser::ContinueInterruptedParsing (this=0x7f129b1733a0) at /home/mcmanus/src/mozilla2/wd/gecko-dev/parser/htmlparser/nsParser.cpp:1056
#6  0x00007f12c5679361 in nsParser::HandleParserContinueEvent (this=0x7f129b1733a0, ev=0x7f129b9bf520) at /home/mcmanus/src/mozilla2/wd/gecko-dev/parser/htmlparser/nsParser.cpp:1128
#7  0x00007f12c568220f in nsParserContinueEvent::Run (this=0x7f129b9bf520) at /home/mcmanus/src/mozilla2/wd/gecko-dev/parser/htmlparser/nsParser.cpp:122
#8  0x00007f12c422b4e1 in nsThread::ProcessNextEvent (this=0x7f12d73b9700, aMayWait=false, aResult=0x7ffc5bfd313e) at /home/mcmanus/src/mozilla2/wd/gecko-dev/xpcom/threads/nsThread.cpp:989
#9  0x00007f12c42a432c in NS_ProcessNextEvent (aThread=0x7f12d73b9700, aMayWait=false) at /home/mcmanus/src/mozilla2/wd/gecko-dev/xpcom/glue/nsThreadUtils.cpp:290
#10 0x00007f12c4af75b1 in mozilla::ipc::MessagePump::Run (this=0x7f12c12b2980, aDelegate=0x7f12d73a7d50) at /home/mcmanus/src/mozilla2/wd/gecko-dev/ipc/glue/MessagePump.cpp:98
#11 0x00007f12c4a57725 in MessageLoop::RunInternal (this=0x7f12d73a7d50) at /home/mcmanus/src/mozilla2/wd/gecko-dev/ipc/chromium/src/base/message_loop.cc:233
#12 0x00007f12c4a576a5 in MessageLoop::RunHandler (this=0x7f12d73a7d50) at /home/mcmanus/src/mozilla2/wd/gecko-dev/ipc/chromium/src/base/message_loop.cc:226
#13 0x00007f12c4a5767d in MessageLoop::Run (this=0x7f12d73a7d50) at /home/mcmanus/src/mozilla2/wd/gecko-dev/ipc/chromium/src/base/message_loop.cc:206
#14 0x00007f12c7fc9f13 in nsBaseAppShell::Run (this=0x7f12b6617080) at /home/mcmanus/src/mozilla2/wd/gecko-dev/widget/nsBaseAppShell.cpp:156
#15 0x00007f12c90cf582 in nsAppStartup::Run (this=0x7f12b660f0b0) at /home/mcmanus/src/mozilla2/wd/gecko-dev/toolkit/components/startup/nsAppStartup.cpp:284
#16 0x00007f12c917bcd6 in XREMain::XRE_mainRun (this=0x7ffc5bfd3a30) at ../../../gecko-dev/toolkit/xre/nsAppRunner.cpp:4347
#17 0x00007f12c917c781 in XREMain::XRE_main (this=0x7ffc5bfd3a30, argc=5, argv=0x7ffc5bfd4ff8, aAppData=0x7ffc5bfd3ca8) at ../../../gecko-dev/toolkit/xre/nsAppRunner.cpp:4451
#18 0x00007f12c917cfb4 in XRE_main (argc=5, argv=0x7ffc5bfd4ff8, aAppData=0x7ffc5bfd3ca8, aFlags=0) at ../../../gecko-dev/toolkit/xre/nsAppRunner.cpp:4559
#19 0x0000000000405bd9 in do_main (argc=5, argv=0x7ffc5bfd4ff8, envp=0x7ffc5bfd5028, xreDirectory=0x7f12d7355b40) at ../../../gecko-dev/browser/app/nsBrowserApp.cpp:220
#20 0x0000000000405320 in main (argc=5, argv=0x7ffc5bfd4ff8, envp=0x7ffc5bfd5028) at ../../../gecko-dev/browser/app/nsBrowserApp.cpp:360
Sweet, I'll take a look.
Assignee: nobody → peterv
Flags: needinfo?(peterv)
I will figure out how to transfer a rr environment - I've never done that before.. this is from a local build.. do you need my obj tree? a cset? just the rr data directory?

In the meantime, this stack seems to lead to trouble.. it is 

4879	      processor = internalEntityProcessor;

but by the the time internalEntityProcessor is called openEntity is NULL which generates the error (4904 of xmlparse.c).. it is not null when the processor is assigned however the entity list is cleared before the stack returns to the point where processor() is called. This may be because processInternalEntity is on the stack re-entrantly and the popped stack version is the one that clears openEntity without changing processor.

#0  processInternalEntity (parser=0x7f4f40197400, entity=0x7f4f401fcd00, betweenDecl=0 '\000') at ../../../../gecko-dev/parser/expat/lib/xmlparse.c:4879
#1  0x00007f4f70b3fd7f in doContent (parser=0x7f4f40197400, startTagLevel=0, enc=0x7f4f74c49958 <little2_encoding_ns>, s=0x7f4f40536444 "&", end=0x7f4f40538de6 '\344' <repeats 199 times>, <incomplete sequence \344>..., 
    nextPtr=0x7f4f40197430, haveMore=1 '\001') at ../../../../gecko-dev/parser/expat/lib/xmlparse.c:2331
#2  0x00007f4f70b3d4e1 in contentProcessor (parser=0x7f4f40197400, start=0x7f4f405351e6 "\n", end=0x7f4f40538de6 '\344' <repeats 199 times>, <incomplete sequence \344>..., endPtr=0x7f4f40197430)
    at ../../../../gecko-dev/parser/expat/lib/xmlparse.c:2072
#3  0x00007f4f70b389a5 in MOZ_XML_ResumeParser (parser=0x7f4f40197400) at ../../../../gecko-dev/parser/expat/lib/xmlparse.c:1798
#4  0x00007f4f6cbee37b in nsExpatDriver::ParseBuffer (this=0x7f4f401070e0, aBuffer=0x0, aLength=0, aIsFinal=true, aConsumed=0x7ffcb492d39c) at /home/mcmanus/src/mozilla2/wd/gecko-dev/parser/htmlparser/nsExpatDriver.cpp:1003
#5  0x00007f4f6cbeeac5 in nsExpatDriver::ConsumeToken (this=0x7f4f401070e0, aScanner=..., aFlushTokens=@0x7ffcb492d633: false) at /home/mcmanus/src/mozilla2/wd/gecko-dev/parser/htmlparser/nsExpatDriver.cpp:1104
#6  0x00007f4f6cbf533b in nsParser::Tokenize (this=0x7f4f3f80a450, aIsFinalChunk=true) at /home/mcmanus/src/mozilla2/wd/gecko-dev/parser/htmlparser/nsParser.cpp:1944
#7  0x00007f4f6cbf3e59 in nsParser::ResumeParse (this=0x7f4f3f80a450, allowIteration=true, aIsFinalChunk=true, aCanInterrupt=true) at /home/mcmanus/src/mozilla2/wd/gecko-dev/parser/htmlparser/nsParser.cpp:1463
#8  0x00007f4f6cbf3c3e in nsParser::ContinueInterruptedParsing (this=0x7f4f3f80a450) at /home/mcmanus/src/mozilla2/wd/gecko-dev/parser/htmlparser/nsParser.cpp:1056
#9  0x00007f4f6cbf4361 in nsParser::HandleParserContinueEvent (this=0x7f4f3f80a450, ev=0x7f4f408288c0) at /home/mcmanus/src/mozilla2/wd/gecko-dev/parser/htmlparser/nsParser.cpp:1128
(In reply to Patrick McManus [:mcmanus] from comment #79)
> I will figure out how to transfer a rr environment - I've never done that
> before.. this is from a local build.. do you need my obj tree? a cset? just
> the rr data directory?
I think you can't really transfer rr replays from one machine to another. Peter will either need to reproduce locally or get access to your machine.
for reasons unknown this repros better for me (again debug and rr) using a file:/// html rather than the data url (and yes, the blocking alert increases the repro rate.. dunno why):

<script>
  onload=function(){
  alert('foo');
  for(i=0;i++<5;)
     open("http://127.0.0.1:82");
   }
</script>
hi
Component: Networking → XML
AFAICT the problem is that we suspend the parser right after we insert an element as a result of parsing an entity (in my case sharedLongDesc). The entity has been parsed completely, but nothing resets the processor. When we resume the parser we call into internalEntityProcessor again, but the entity is not open anymore because it's been parsed completely. It's a bit tricky to know where to reset the processor, because doContent can be called from a couple of processors :-/.
Attached patch v1 — — Splinter Review 
This is triggered by nested entities. Expat keeps a linked list of open entities (openInternalEntities) which goes from the most inner open entity to the most outer open entity. In this case we're parsing an entity and it ends in another (inner) entity. While parsing that inner entity we block the parser, either because we're loading something like script, or because we interrupt. The inner entity hasn't been completely parsed, so it's not marked closed and the handler is set to internalEntityProcessor, the outer entity is considered to have been parsed completely, so it is marked closed and openInternalEntities is set to null. When we unblock the parser we end up in internalEntityProcessor with a null openInternalEntities, which is a bogus state and we report an error.

The patch makes the code that closes the outer entity detect that the inner entity is still open (by checking if openInternalEntities points to the outer entity). In that case it just takes the outer entity out of the openInternalEntities linked list instead of setting openInternalEntities to openEntity->next (which is null in this case).
Attachment #8791932 - Flags: review?(erahm)
Comment on attachment 8791932 [details] [diff] [review]
v1

Review of attachment 8791932 [details] [diff] [review]:
-----------------------------------------------------------------

Wow, nice find. r=me with small fixes.

::: parser/expat/lib/xmlparse.c
@@ +4911,5 @@
>        openInternalEntities = openEntity->next;
> +#else
> +      if (openInternalEntities == openEntity) {
> +        openInternalEntities = openEntity->next;
> +      } else {

nit: prevailing style seems to be:

> if (foo) {
> }
> else {
> }

::: parser/htmlparser/tests/reftest/reftest.list
@@ +1,4 @@
>  == bug535530-1.html bug535530-1-ref.html
>  == view-source:bug535530-2.html bug535530-2-ref.html
>  == bug566280-1.html bug566280-1-ref.html
> +== bug535530-1.html bug535530-1-ref.html

Seems like this change needs to be reverted.
Attachment #8791932 - Flags: review?(erahm) → review+
Peter, would you have time to fix these nits? I highly suspect this error is causing Bug 1272942 and we'd love to finally close that one.

Thanks!
Flags: needinfo?(peterv)
https://hg.mozilla.org/integration/mozilla-inbound/rev/ee8e6503d47c5f5cf5515b41f9594ec5d9eb63ae
Bug 569229 - Close outer entities when they're parsed even if we're blocking the parser. r=erahm.
https://hg.mozilla.org/mozilla-central/rev/ee8e6503d47c
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox53: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Flags: needinfo?(peterv)
excellent.
Peter, can you think of uplifting that small patch to Aurora? We have a bunch of Tor Browser users that hit or have hit that bug and it would therefore be happy to have this fixed in the ESR 52 series (which we are switching to next). If you think this is upliftable and worth doing so, could you file a respective request? Thanks!
Flags: needinfo?(peterv)
Too late for 50 & 51 but it would be indeed go to take in 52 as it is the next esr.
status-firefox50: affected → wontfix
status-firefox51: affected → wontfix
Comment on attachment 8791932 [details] [diff] [review]
v1

Approval Request Comment
[Feature/Bug causing the regression]: old bug in the Expat parser (might be a regression from bug 274777)
[User impact if declined]: Network error pages sometimes don't display (showing an XML error page instead)
[Is this code covered by automated tests?]: patch adds an automated test
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: no
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: fairly low-risk
[Why is the change risky/not risky?]: the new code should only be triggered for XML pages with nested entities, which are rare
[String changes made/needed]: none
Flags: needinfo?(peterv)
Attachment #8791932 - Flags: approval-mozilla-aurora?
Comment on attachment 8791932 [details] [diff] [review]
v1

fix intermittent failure to display neterror pages, aurora52+
Attachment #8791932 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: