35297 - this page crashes browser - mozilla & pr6

Status: VERIFIED WORKSFORME

(SeaMonkey :: General, defect, P3)

Description

[roger day]

Actually, start at

http://www.globalgraphics.com/

and try and view any of the companies in the GG group.

The pages were produced by adobe GoLive, and I think the problem is javascript 
libraries.

Comment 1

[Blake Ross]

Just out of curiousity, if you're using a PC as your platform, what is your OS? 
(you chose Other)

Also, does this really belong as "major?"  marking down to normal, I've seen 
quite a few page crash bugs and most have been marked normal.

Can anyone confirm that this is a javascript problem so we can attribute it to a 
more specific component?

Comment 2

[Blake Ross]

adding to cc list, sorry for spam

Comment 3

[Hugh Kennedy]

confirming, fixing URL listing, setting plat and os to "all".

this occurs in M14 on winNT (build ID: 2000030317), and solaris 2.6.

solaris stack trace follows:


###!!! ASSERTION: leaf w/o container: 'mStackPos > 0', file
nsHTMLContentSink.cpp, line 1994
###!!! Break: at file nsHTMLContentSink.cpp, line 1994
###!!! ASSERTION: leaf w/o container: 'mCurrentContext->mStackPos > 0', file
nsHTMLContentSink.cpp, line 4171
###!!! Break: at file nsHTMLContentSink.cpp, line 4171
^G###!!! ASSERTION: leaf w/o container: 'mStackPos > 0', file
nsHTMLContentSink.cpp, line 1994
###!!! Break: at file nsHTMLContentSink.cpp, line 1994
^G

Program received signal SIGBUS, Bus error.
0xed0b80f0 in SinkContext::CloseContainer (this=0x6e4058, aNode=@0x677698) at
nsHTMLContentSink.cpp:1355
(gdb) No breakpoints or watchpoints.
(gdb) bt
#0  0xed0b80f0 in SinkContext::CloseContainer (this=0x6e4058, aNode=@0x677698)
at nsHTMLContentSink.cpp:1355
#1  0xed0be7ac in HTMLContentSink::CloseContainer (this=0x7990a0,
aNode=@0x677698) at nsHTMLContentSink.cpp:2910
#2  0xecad9484 in CNavDTD::CloseContainer (this=0x6e3e88, aNode=0x677698,
aTarget=eHTMLTag_userdefined, aClosedByStartTag=0) at CNavDTD.cpp:2975
#3  0xecad973c in CNavDTD::CloseContainersTo (this=0x6e3e88, anIndex=1,
aTarget=eHTMLTag_userdefined, aClosedByStartTag=0) at CNavDTD.cpp:3011
#4  0xecad9a74 in CNavDTD::CloseContainersTo (this=0x6e3e88,
aTarget=eHTMLTag_userdefined, aClosedByStartTag=0) at CNavDTD.cpp:3166
#5  0xecad6258 in CNavDTD::HandleEndToken (this=0x6e3e88, aToken=0x6bfd78) at
CNavDTD.cpp:1626
#6  0xecad3cd4 in CNavDTD::HandleToken (this=0x6e3e88, aToken=0x6bfd78,
aParser=0x57d808) at CNavDTD.cpp:768
#7  0xecad32b4 in CNavDTD::BuildModel (this=0x6e3e88, aParser=0x57d808,
aTokenizer=0x6c10c8, anObserver=0x0, aSink=0x7990a0) at CNavDTD.cpp:504
#8  0xecaf109c in nsParser::BuildModel (this=0x57d808) at nsParser.cpp:1218
#9  0xecaf0dd8 in nsParser::ResumeParse (this=0x57d808, aDefaultDTD=0x0,
aIsFinalChunk=0) at nsParser.cpp:1133
#10 0xecaefe70 in nsParser::EnableParser (this=0x57d808, aState=1) at
nsParser.cpp:824
#11 0xed0c3728 in HTMLContentSink::ResumeParsing (this=0x7990a0) at
nsHTMLContentSink.cpp:4012
#12 0xed0c3ec0 in HTMLContentSink::OnStreamComplete (this=0x7990a0,
aLoader=0x66e860, aContext=0x0, aStatus=0, stringLen=31251, string=0x7ed5d0
"CSAg = window.navigator.userAgent; CSBVers =
parseInt(CSAg.charAt(CSAg.indexOf(\"/\")+1),10);\nfunction IsIE() { return
CSAg.indexOf(\"MSIE\") > 0;}\nfunction CSIEStyl(s) { return
document.all.tags(\"div\")[s"...) at nsHTMLContentSink.cpp:4108
#13 0xee264684 in nsStreamLoader::OnStopRequest (this=0x66e860,
channel=0x5550e8, ctxt=0x0, status=0, errorMsg=0x0) at nsStreamLoader.cpp:109
#14 0xebe4ba60 in InterceptStreamListener::OnStopRequest (this=0x7ad168,
channel=0x5550e8, ctxt=0x0, status=0, errorMsg=0x0) at nsCachedNetData.cpp:1116
#15 0xebf72c1c in nsHTTPChannel::ResponseCompleted (this=0x5550e8,
aTransport=0x78bc14, aListener=0x7ad168, aStatus=0, aMsg=0x0) at
nsHTTPChannel.cpp:1339
#16 0xebf78f68 in nsHTTPResponseListener::OnStopRequest (this=0x799250,
channel=0x78bc14, i_pContext=0x5550e8, i_Status=0, i_pMsg=0x0) at
nsHTTPResponseListener.cpp:257
#17 0xee23fd14 in nsOnStopRequestEvent::HandleEvent (this=0x6777d8) at
nsAsyncStreamListener.cpp:282
#18 0xee23ef50 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x436078) at
nsAsyncStreamListener.cpp:97
#19 0xef5658c0 in PL_HandleEvent (self=0x436078) at plevent.c:526
#20 0xef565740 in PL_ProcessPendingEvents (self=0x11ba28) at plevent.c:487
#21 0xef567e28 in nsEventQueueImpl::ProcessPendingEvents (this=0x119ae0) at
nsEventQueue.cpp:298
#22 0xedfccd34 in event_processor_callback (data=0x119ae0, source=6,
condition=GDK_INPUT_READ) at nsAppShell.cpp:141
#23 0xedfcc7e8 in our_gdk_io_invoke (source=0x183a68, condition=G_IO_IN,
data=0x1759a0) at nsAppShell.cpp:54
#24 0xedcf5a00 in g_io_unix_dispatch (source_data=0x185878,
current_time=0xefffe6d8, user_data=0x1759a0) at giounix.c:135
#25 0xedcf76d4 in g_main_dispatch (current_time=0xefffe6d8) at gmain.c:656
#26 0xedcf7f60 in g_main_iterate (block=-305017700, dispatch=1) at gmain.c:874
#27 0xedcf8174 in g_main_run (loop=0x2bc9b0) at gmain.c:932
#28 0xede495c4 in gtk_main () at gtkmain.c:476
#29 0xedfcd5c4 in nsAppShell::Run (this=0x140dc0) at nsAppShell.cpp:304
#30 0xee346db0 in nsAppShellService::Run (this=0x11b928) at
nsAppShellService.cpp:399
#31 0x1cfbc in main1 (argc=1, argv=0xefffebdc, splashScreen=0x0) at
nsAppRunner.cpp:651
#32 0x1d800 in main (argc=1, argv=0xefffebdc) at nsAppRunner.cpp:770
(gdb)

stepping into nsHTMLContentSink.cpp, mStackPos is -1 in SinkContext::CloseContainer

through the following snippet (around line 1355):

  nsHTMLTag nodeType = mStack[mStackPos].mType;
  nsIHTMLContent* content = mStack[mStackPos].mContent;
  content->Compact();

this is returning garbage, and mozilla isn't liking it.

Comment 4

[Sean Richardson]

FWIW, I tried several of the links to group company websites with the 
2000-04-09-08-M15 nightly binary on WinNT 4.0, and got no crash. This problem
may have been fixed in the last month, and in any case it needs to be 
reproduced in a current build. M15 should be out soon.

Actually, crashes confirmed in a current build should have a severity of 
"critical" (see http://bugzilla.mozilla.org/bug_status.html#severity)
and get the "crash" keyword.

Comment 5

[Blake Ross]

sorry bout that, I was unaware that crashes should receive that severity.  In 
that case, lots of crashes should be changed.

changing severity to critical in light of this new info (though it sounds like 
this problem may have been fixed, I don't have Moz on this computer so I can't 
try to reproduce/verify)

Comment 6

[Jeffrey Baker]

Can't reproduce this crash using the given URL on 2000040909 i686-pc-linux-gnu.

Comment 7

[Blake Ross]

also could not reproduce on 2000041008 on either win98 or win2000, marking 
WORKSFORME for now

Comment 8

[Peter "jag" Annema]

These pages don't crash me either on Win95 OSR2.1 moz-build 2000040908 and Linux
moz-build 2000040909. Since NS6PR1 crashes are Netscape's domain (talkback), can
someone either give details on recent mozilla builds which still crash, or mark
this one fixed?

Comment 9

[Blake Ross]

I've already marked it WORKSFORME, not gonna mark it fixed unless I know that 
someone specifically submitted a fix for it.

Feel free to VERIFY.

Comment 10

[Asa Dotzler [:asa]]

verified with 060108 build