88386 - Crash going to netscape home pages [@ HTMLContentSink::ProcessSCRIPTTag]

Status: VERIFIED FIXED

(SeaMonkey :: General, defect)

Description

[Tracy Walker [:tracy]]

seen on linux commercial build 2001-06-29-06-trunk

-go to http://my.netscape.com or http://home.netscape.com/ja/index1.html or 
http://home.netscape.com/de/index1.html

or

click the throbber

all will cause the browser to crash

Comment 1

[Tracy Walker [:tracy]]

seeing this on mac commercial build 2001-06-29-08-trunk also

Comment 2

[doctor__j]

I saw that on Win32 build 2001062906 too.
Changing platform & OS to ALL.

Comment 3

[doctor__j]

Attachment: Testcase (the evil "document.location.replace" that causes crash)

Comment 4

[doctor__j]

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

Comment 5

[Travis Ogdon]

Confirming for those pages on linux, and adding http://textism.com. There are
probably others as well. These all worked for me (at least my.netscape.com and
textism.com) with yesterday's build.

Comment 6

[Tracy Walker [:tracy]]

this is affecting TRUNK only on all platforms....BRANCH is okay. *whew*

Comment 7

[Brian Nesse (gone)]

Here's a stack from the 8am mac build:

  00000000    PPC  3D440334  
  0D76FE30    PPC  3D42BB04  main+00130
  0D76FDD0    PPC  3D42ADB4  main1(int, char**, nsISupports*)+00C1C
  0D76FAA0    PPC  3D2AF214  nsAppShellService::Run()+00018
  0D76FA60    PPC  3CFA4990  nsAppShell::Run()+00048
  0D76FA10    PPC  3CFA53E0  nsMacMessagePump::DoMessagePump()+0003C
  0D76F9C0    PPC  3CFA5AE0  nsMacMessagePump::DispatchEvent(int,
EventRecord*)+00170
  0D76F970    PPC  3CFB9CB8  Repeater::DoRepeaters(const EventRecord&)+00030
  0D76F930    PPC  3CF91224 
nsMacNSPREventQueueHandler::RepeatAction(constEventRecord&)+0000C
  0D76F8F0    PPC  3CF91460  nsMacNSPREventQueueHandler::ProcessPLEventQueue()+00060
  0D76F880    PPC  3D303AC0  nsEventQueueImpl::ProcessPendingEvents()+00038
  0D76F810    PPC  3D358D44  PL_ProcessPendingEvents+00088
  0D76F7D0    PPC  3D358EC8  PL_HandleEvent+00020
  0D76F790    PPC  3D0F7080  nsARequestObserverEvent::HandlePLEvent(PLEvent*)+00020
  0D76F750    PPC  3D0F7CC8  nsOnStopRequestEvent::HandleEvent()+000B4
  0D76F6F0    PPC  3D1022B4  nsHttpChannel::OnStopRequest(nsIRequest*,
nsISupports*, unsigned int)+000B4
  0D76F6A0    PPC  3D0F1E7C  nsStreamListenerTee::OnStopRequest(nsIRequest*,
nsISupports*, unsigned int)+00084
  0D76F650    PPC  3CFDD5EC  nsDocumentOpenInfo::OnStopRequest(nsIRequest*,
nsISupports*, unsigned int)+00084
  0D76F5F0    PPC  3D0377CC  nsParser::OnStopRequest(nsIRequest*, nsISupports*,
unsigned int)+000E0
  0D76F500    PPC  3D03682C  nsParser::ResumeParse(int, int)+0011C
  0D76F4A0    PPC  3D036B44  nsParser::BuildModel()+00080
  0D76F450    PPC  3D011DA0  CNavDTD::BuildModel(nsIParser*, nsITokenizer*,
nsITokenObserver*, nsIContentSink*)+00204
  0D76F3A0    PPC  3D012E50  CNavDTD::HandleToken(CToken*, nsIParser*)+005C4
  0D76F290    PPC  3D014E8C  CNavDTD::HandleStartToken(CToken*)+00300
  0D76F220    PPC  3D0191CC  CNavDTD::AddHeadLeaf(nsIParserNode*)+00144
  0D76F120    PPC  3D019034  CNavDTD::AddLeaf(const nsIParserNode*)+00058
  0D76F0E0    PPC  3CA0163C  HTMLContentSink::AddLeaf(const nsIParserNode&)+00130

Comment 8

[Brian Nesse (gone)]

Adding jst 'cause he just checked in HTMLContentSink.

Comment 9

[Nisheeth Ranjan]

Adding Kevin because this could be related to the parser interruption code that 
he enabled yesterday.

Comment 10

[harishd]

My guess:

Could it be due to rpotts checkin to bug 87370?

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/uriloader/base&command=DIFF_FRAMESET&file=nsURILoader.cpp&rev1=1.79&rev2=1.80&root=/cvsroot

Reassigning to myself for now. Ccing rpotts & Kevin.

Comment 11

[Kevin McCluskey (gone)]

Brian: Could you try adding the pref to disable the interrupting of the parsing
and see if it still crashes?

user_pref("content.interrupt.parsing", false);

I tried each of the URL's:
http://my.netscape.com or http://home.netscape.com/ja/index1.html or 
http://home.netscape.com/de/index1.html

on WINNT and it does not crash. I tried both debug and release builds.

I also updated my tree so I have the change to nsURILoader.cpp that harishd
listed and I tried each of URL's and it does not crash for me on WINNT.

Comment 12

[Brian Nesse (gone)]

Kevin, yes it still crashes on the Mac if I add:
user_pref("content.interrupt.parsing", false);

Comment 13

[harishd]

So, it's not kevin then.

Comment 14

[harishd]

Brian: Could you back out jst's change to see if the problem goes away?


cvs update -j1.45 -j1.44 mozilla/content/xml/document/src/nsXMLContentSink.h
cvs update -j1.159 -j1.158 mozilla/content/xml/document/src/nsXMLContentSink.cpp
cvs update -j3.466 -j3.465 mozilla/content/html/document/src/nsHTMLContentSink.cpp

Comment 15

[Brian Nesse (gone)]

My build just finished. I'm looking at it now...

Comment 16

[Brian Nesse (gone)]

Ok, here's the deal... it's crashing on line 4958

->  if (mNeedToBlockParser || !mParser->IsParserEnabled()) {
    return NS_ERROR_HTMLPARSER_BLOCK;
  }

  return NS_OK;

because mParser is NULL. This is part of jst's patch, so backing it out should 
fix the problem. Easier would be to check for mParser being NULL, the problem is 
I don't know if it should return NS_ERROR_HTMLPARSER_BLOCK or NS_OK if mParser is 
NULL.

Comment 17

[Brian Nesse (gone)]

Backing out the patch does fix the crash.

Comment 18

[harishd]

Brian: Thanx for finding the crash. My build just finished..so will come up with
a fix soon.

Comment 19

[Brian Nesse (gone)]

Attachment: Patch to eliminate crash.

Comment 20

[Brian Nesse (gone)]

Based on the other logic using mParser, I believe this is the proper fix. And it 
does get me to my.netscape.com.

Comment 21

[harishd]

Brian: you're right. I've the same fix here and will be checking in now. Thanx
for your efforts.

Comment 22

[harishd]

Fix is in.

Comment 23

[Matthias Versen [:Matti]]

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

Comment 24

[Henrik Gemal]

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

Comment 25

[greer]

Adding topcrash keyword and stack signature for talkback tracking.

Comment 26

[Travis Ogdon]

I'm still seeing crashes in the 2001070208 linux build on http://textism.com.
These crashes started at the same time as the my.netscape.com and others. The
2001070208 linux build works with my.netscape.com now. 

Is this a different bug that was introduced at the same time, or is there still
a problem here?

Comment 27

[Tracy Walker [:tracy]]

with linux commercial build 2001-07-02-08-trunk

I am not having any trouble loading the netscape pages or textism.com

marking verified