123475 - Trunk crash [@ little2_updatePosition] [@ XML_GetCurrentColumnNumber][@ nsExpatDriver::GetLine]

Status: VERIFIED FIXED

(Core :: XML, defect, P1)

Description

[rbs]

When visiting XML pages with <script src="." />, I often get a crash with the 
following stack trace. The crash goes away after restarting, suggesting that it 
might be due to a race condition or something, depending on whether the script 
file is there/cached or not. I got the following stack trace when visiting: 
http://www.mozilla.org/projects/mathml/demo/mtable.xhtml

little2_updatePosition(const encoding * 0x01b09558 little2_encoding, const char 
* 0x034ab000, const char * 0x01220232, position * 0x046e8cac) line 1735 + 3 
bytes
XML_GetCurrentColumnNumber(void * 0x046e8ae0) line 1043 + 46 bytes
nsExpatDriver::HandleError(const char * 0x034bf2c8, unsigned int 2200, int 0) 
line 598 + 15 bytes
nsExpatDriver::ParseBuffer(const char * 0x034bf2c8, unsigned int 2200, int 0) 
line 634
nsExpatDriver::ConsumeToken(nsExpatDriver * const 0x046eaf04, nsScanner & {...}, 
int & 0) line 737 + 30 bytes
nsParser::Tokenize(int 1) line 2589 + 26 bytes
nsParser::ResumeParse(int 1, int 1, int 1) line 1846 + 12 bytes
nsParser::ContinueParsing() line 1495 + 19 bytes
nsXMLContentSink::ScriptEvaluated(nsXMLContentSink * const 0x046db820, unsigned 
int 0, nsIDOMHTMLScriptElement * 0x048eb4a8, int 0, int 1) line 1087
nsScriptLoader::FireScriptEvaluated(unsigned int 0, nsScriptLoadRequest * 
0x048ed4d0) line 538
nsScriptLoader::ProcessRequest(nsScriptLoadRequest * 0x048ed4d0) line 497
nsScriptLoader::OnStreamComplete(nsScriptLoader * const 0x046db754, 
nsIStreamLoader * 0x048ed3a0, nsISupports * 0x048ed4d0, unsigned int 0, unsigned 
int 4294967295, const char * 0x034f5982) line 787
nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x048ed3a4, nsIRequest * 
0x048eb660, nsISupports * 0x048ed4d0, unsigned int 0) line 163
nsStreamListenerTee::OnStopRequest(nsStreamListenerTee * const 0x048f7710, 
nsIRequest * 0x048eb660, nsISupports * 0x048ed4d0, unsigned int 0) line 25
nsHttpChannel::OnStopRequest(nsHttpChannel * const 0x048eb664, nsIRequest * 
0x048ea624, nsISupports * 0x00000000, unsigned int 0) line 2454
nsOnStopRequestEvent::HandleEvent() line 213
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x048f5a14) line 116
PL_HandleEvent(PLEvent * 0x048f5a14) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00497860) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x004f07d2, unsigned int 49503, unsigned int 0, 
long 4814944) line 1071 + 9 bytes
USER32! 77e148dc()
USER32! 77e14aa7()
USER32! 77e266fd()
nsAppShellService::Run(nsAppShellService * const 0x004b5ac0) line 308
main1(int 1, char * * 0x00444ab0, nsISupports * 0x00000000) line 1285 + 32 bytes
main(int 1, char * * 0x00444ab0) line 1625 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e992a6()

Comment 1

[rbs]

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

Comment 2

[greer]

This one has made the Trunk topcrash reports, marking as topcrash. Using build 
2002020610 on Win2000, I got this crash loading 
http://www.mozilla.org/projects/mathml/demo/texvsmml.xml. Same conditions at rbs 
described, loads fine second time around.  
Could this one be targeted for M099?

Comment 3

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I am a bit unclear what src="." is supposed to load. I would guess index.html
but that doesn't make sense and does not seem to be what you are reporting...

Comment 4

[rbs]

I wasn't meaning src="." literally. Rather, it was an abbreviation referring to 
the fact that the script loads a file (a big file actually - it has the MathML 
entities in it. These are used to support the MathML WYSIWYG source viewer).

Comment 5

[basic]

build 2002021303 win32 trunk
Interestingly it seems like this crash clears my clipboard.

here's some of the talkback numbers that was generated (though I doubt it would
be of much help)
TB2879634E
TB2879596G

Comment 6

[basic]

make that clear my clipboard sometimes. It cleared my clipboard the first 3
times it crashed but now it doesn't clear it anymore. Note that I'm still unable
to view
http://www.mozilla.org/projects/mathml/demo/texvsmml.xml as it always crashes
for me.

isn't this a parser bug?

Comment 7

[basic]

I tried downloading http://www.mozilla.org/projects/mathml/demo/texvsmml.xml
and added a <base
href="http://www.mozilla.org/projects/mathml/demo/texvsmml.xml"/> to the <head>
section and it loaded after 2 tries (froze on the first try)

Note that it still crashes when I visit
http://www.mozilla.org/projects/mathml/demo/texvsmml.xml

Comment 8

[basic]

now I'm getting a little different behavior. seems like I can get the locally
modified file to display the first time, however if I try reloading or just
loading it a second time (by just pressing Enter in the url bar) it freezes.

Comment 9

[harishd]

Working on this.

--> 0.9.9

Comment 10

[harishd]

Attachment: patch v1.0

Expat parser's XML_ParseBuffer wasn't aware of the BLOCKING and hence failed to
update the buffer position ( bufferPtr ). The fix would update the bufferPtr
such that, when the expat parser gets unblocked, we'd resume from the point we
stopped. (

Comment 11

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Comment on attachment 69537 [details] [diff] [review]
patch v1.0 

r=heikki

Comment 12

[Heikki Toivonen (remove -bugzilla when emailing directly)]

This is bizarre; without the patch I can crash pretty reliably by doing a
shift+reload. With the patch I get XML parser error in the beginning of a math
tag when doing shift+reload. Normal loads everything works fine. Or well, every
now and then doing normal load will give me:

###!!! ASSERTION: nsStandardURL not thread-safe: 'owningThread == NS_CurrentThre
ad()', file c:\builds\mozilla\xpcom\glue\nsDebug.cpp, line 528
###!!! Break: at file c:\builds\mozilla\xpcom\glue\nsDebug.cpp, line 528
###!!! ASSERTION: nsGenericElement not thread-safe: 'owningThread == NS_CurrentT
hread()', file c:\builds\mozilla\xpcom\glue\nsDebug.cpp, line 528
###!!! Break: at file c:\builds\mozilla\xpcom\glue\nsDebug.cpp, line 528
###!!! ASSERTION: nsGenericElement not thread-safe: 'owningThread == NS_CurrentT
hread()', file c:\builds\mozilla\xpcom\glue\nsDebug.cpp, line 528
###!!! Break: at file c:\builds\mozilla\xpcom\glue\nsDebug.cpp, line 528

Comment 13

[harishd]

I get parser error with or without my patch ( α undefined...or something
like that ).

Comment 14

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Fix "expected tag" error message to be localizable

While testing I noticed we had regressed with the expected tag message
regarding l10n.

Comment 15

[harishd]

It's impossible to reproduce the crash either from the local disk or from a
local server. rbs, could you attach a reduced testcase?

Comment 16

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: ngrep log

This is the output of ngrep (network grep) done loading the URL twice: first
normal reload, then shift+reload.

On shift+reload I got:

XML Parsing Error: not well-formed
Location: http://www.mozilla.org/projects/mathml/demo/texvsmml.xml
Line Number 147, Column 1:<math mode="displa?
^

Specially you'll be interested in this part:

  ipts>.</mrow>.</math>.</td></tr>..<tr>.<td>3</td>.<td><img src="../scr
  eenshots/ex21.gif" /></td>.<td>.<math mode="displa
##
T 207.200.81.215:80 -> 10.169.98.236:2907 [A]
  y" xmlns="&mathml;">.<mrow>.	<mfrac>.    <mrow>.	 <mi>x</mi>.
    <mo>+</mo>.      <msup>.	    <mi>y</mi>.        <mn>2</mn>.

The ? in the error message is exactly on the boundary of the two chunks coming
from the web.

Comment 17

[rbs]

> rbs, could you attach a reduced testcase?

I don't have a small example that brings the crash. There are numerous images in
the Torture test page, and it contains a large JS file; it seems these are the
right ingredients to bring the crash. If your network is too fast so that you
have troubles reproducing the problem, you might want to clear and disable the
cache altogther.

Comment 18

[harishd]

Attachment: patch v1.1

rbs: could you please try this patch and let me know if it still poses any
problem?
Thanx

Comment 19

[rbs]

Before trying the patch, I was trying to reproduce the crash again, but I am not 
able to get the crash at the moment (in fact, in normal browsing this crash has 
remained occasional). I cleared the cache, and even disabled it, but to no 
avail. So if I apply the patch, it won't tell much. Heikki, any luck that you 
get the crash as before and try out the patch?

Comment 20

[harishd]

Comment on attachment 69607 [details] [diff] [review]
Fix "expected tag" error message to be localizable

r=harishd 
for the localization patch.

Comment 21

[rbs]

harishd informed me via e-mail that heikki is on vacation and metioned that:

>     If I remember right Heikki was able to reproduce the problem with
> the following steps:
> 1) load the document
> 2) reload the document
> 3) shift+reload the document.
> 
> Result:
> - without the patch you should see a crash

Yes, I could reproduce the crash with the steps above.

> - with patch v1.0 you should see XML error

Didn't try.

> - with patch v 1.1 you should see neither a crash nor a XML error .

Tried this patch and it does fix the crash.

Comment 22

[rbs]

Comment on attachment 70127 [details] [diff] [review]
patch v1.1

r=rbs

Comment 23

[Johnny Stenback (:jst)]

Comment on attachment 70127 [details] [diff] [review]
patch v1.1

sr=jst

Comment 24

[greer]

There is anther signature in the Trunk topcrash reports that looks like it is 
caused by this bug. Adding [@ nsExpatDriver::GetLine] in the summary so that 
Talkback can verify when the fix goes in. If that doesn't fix the crashes at 
this signature I will open a separate bug.

Comment 25

[harishd]

Fix for the crash is in. I've opened up another bug ( 126452 ) to cover the
localization issue.

Comment 26

[rbs]

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

Comment 27

[Chris Petersen]

Changing QA contact