43174 - Blow the stack going to www.internet.com -- nasty crash

Status: VERIFIED DUPLICATE of bug 42138

(Core :: Layout, defect, P3)

Description

[Kathleen :Brade]

With a debug Macintosh build from this morning, I crash when I go to http://
www.internet.com.  I discovered this bug when I was running chofmann's browser 
buster (top 100 sites)

Comment 1

[Kathleen :Brade]

adding some keywords; not sure if this is cross-platform or not

Comment 2

[Doron Rosenberg (IBM)]

hmmm, it works in win32 2000062008, but loads wierdly

Comment 3

[Asa Dotzler [:asa]]

this crashes me on Mac os9 but not winNT

Comment 4

[Cyril Bortolato]

Works on Linux 2000-06-19-08, loads slowly.

Comment 5

[Andreas Franke (gone)]

www.internet.com loads fine on PC/Linux with build 2000062220.
However, I see lots of JavaScript errors in the shell output:
 
http://www.internet.com/home-d.html line 48: curDoc.layers has no properties

Comment 6

[Zach Lipton [:zach]]

Attachment: Mac OS Macsbug stdlog on the crasj

Comment 7

[Zach Lipton [:zach]]

I got this to work about once every other time by downloading the source in 4.7
and removing the large block of white space from the page. However, this only
works about half the time so I don?t think it will help, but you never know.

Comment 8

[Asa Dotzler [:asa]]

updating component and setting defualt owner. macsbug sc output from 071108 
mozilla build:

Calling chain using A6/R1 links
  Back chain  ISA  Caller
  00000000    PPC  1F2B7D64  
  0D6B5800    PPC  1F2A28A8  main+00130
  0D6B57A0    PPC  1F2A1DA4  main1(int, char**, nsISupports*)+00944
  0D6B54E0    PPC  1F03609C  nsAppShellService::Run()+00018
  0D6B54A0    PPC  1EB528B4  nsAppShell::Run()+00038
  0D6B5450    PPC  1EB52FB0  nsMacMessagePump::DoMessagePump()+0003C
  0D6B5400    PPC  1EB535B8  nsMacMessagePump::DispatchEvent(int, EventRecord*)+
00174
  0D6B53B0    PPC  1EB68D2C  Repeater::DoRepeaters(const EventRecord&)+00030
  0D6B5370    PPC  1EB30E88  nsMacNSPREventQueueHandler::RepeatAction(const 
EventRecord&)+000
0C
  0D6B5330    PPC  1EB30FA0  nsMacNSPREventQueueHandler::ProcessPLEventQueue()+
000B0
  0D6B52C0    PPC  1EE04DE8  nsEventQueueImpl::ProcessPendingEvents()+00038
  0D6B5250    PPC  1EE61DE0  PL_ProcessPendingEvents+0004C
  0D6B5210    PPC  1EE61EC8  PL_HandleEvent+00020
  0D6B51D0    PPC  1EA15F30  nsStreamListenerEvent::HandlePLEvent(PLEvent*)+00024
  0D6B5180    PPC  1EA1710C  nsOnDataAvailableEvent::HandleEvent()+00068
  0D6B5130    PPC  1EA90CF4  nsHTTPServerListener::OnDataAvailable(nsIChannel*, 
nsISupports*,
 nsIInputStream*, unsigned int, unsigned int)+00C68
  0D6B4D70    PPC  1EA46EAC  InterceptStreamListener::OnDataAvailable(nsIChannel*
, nsISupport
s*, nsIInputStream*, unsigned int, unsigned int)+00060
  0D6B4D20    PPC  1EA92788  nsHTTPFinalListener::OnDataAvailable(nsIChannel*, 
nsISupports*, 
nsIInputStream*, unsigned int, unsigned int)+00094
  0D6B4CC0    PPC  1F115998  nsDocumentOpenInfo::OnDataAvailable(nsIChannel*, 
nsISupports*, n
sIInputStream*, unsigned int, unsigned int)+00068
  0D6B4C60    PPC  1EAFA8E8  ImageConsumer::OnDataAvailable(nsIChannel*, 
nsISupports*, nsIInp
utStream*, unsigned int, unsigned int)+002A4
  0D6B4BC0    PPC  1F28FF54  NetReaderImpl::Write(const unsigned char*, long)+
00018
  0D6B4B80    PPC  1F293B34  IL_StreamWrite(il_container_struct*, const unsigned 
char*, long)
+00074
  0D6B4B30    PPC  1FC9689C  GIFDecoder::ImgDWrite(const unsigned char*, long)+
00018
  0D6B4AF0    PPC  1FC982F8  il_gif_write(il_container_struct*, const unsigned 
char*, long)+0
0B70
  0D6B4A80    PPC  1F2923BC  ImgDCallbk::ImgDCBImageSize()+0001C
  0D6B4A40    PPC  1F293584  il_size(il_container_struct*)+003B0
  0D6B49D0    PPC  1EAF45E0  ImageRendererImpl::NewPixmap(void*, int, int, 
_NI_Pixmap*, _NI_P
ixmap*)+000DC
  0D6B4960    PPC  1EAFE0FC  nsImageMac::Init(int, int, int, nsMaskRequirements)+
000DC
  0D6B4900    PPC  1EAFEBB8  nsImageMac::AllocateGWorld(short, ColorTable**, 
const Rect&, CGr
afPort**)+00030
  0D6B48B0    PPC  FFD1946C  PurgeSpace+00028
  0D6B4870    PPC  20008874  __PurgeSpace+00018

Comment 9

[Kathleen :Brade]

I ran chofmann's browser buster page (again) on today's mac (debug) build.
I managed to load **78** pages before I crashed at this website.

Nominate this for nsbeta2 since this is a top100 page.

Comment 10

[Simon Fraser [no longer active]]

Ah, we're getting heap corruption here. That's bad.

Comment 11

[Simon Fraser [no longer active]]

What's happening here is that we're blowing the stack. This site seems to use 
close to 1Mb of stack to lay out. I'll attach one example of a big, frame 
construction stack.

Sorry to doom you, Chris.

Comment 12

[Simon Fraser [no longer active]]

Attachment: Example of a large stack loading this page

Comment 13

[Kathleen :Brade]

actually the stack needs to be about 555K or so (for this url to not crash)

PDT--can we make the stack larger for nsbeta2 (on the branch)?

Comment 14

[Kathleen :Brade]

add pp keyword; cc buster (since table code may be the culprit), pierre, and 
kmcclusk

Comment 15

[leger]

sounds like increasing stack size may change the behaviour of the app in 
unmeasurable ways exposing unknown bugs. risky for beta. is there any other 
way to fix this? less risky way to fix this? 

Comment 16

[Simon Fraser [no longer active]]

Increasing the stack size has low risk; it is very unlikely to cause any new 
bugs.

Comment 17

[Chris Waterson]

This is unclosed-tag city. I'll attach the original page for posterity's sake, 
but it looks like there are about 100 unclosed <input type="hidden"> fields that 
are probably blowing the content model to hell in a bucket. harishd, this is 
probably your department...

Comment 18

[Chris Waterson]

Attachment: original text of http://www.internet.com/

Comment 19

[Chris Waterson]

harishd: what appears to be blowing its mind is -not- the <input type=hidden>, 
but instead the sekret tags in the head, which cuase the content model to get 
deeply nested. I tried removing all of those tags (everything between 
<csactions>...</csaction>), and life got much better.

Why do we let those tags affect the body?

Comment 20

[Hixie (not reading bugmail)]

ChrisW: <input> has no end tag anyway; that's why the unclosed <input>s are not
causing a problem. It is rather fun to see us trying interpret the unknown tags
and then failing dismally when we discover they don't have end tags though...

There is (or was) a bug on this issue already.

Comment 21

[harishd]

Increasing the stack is * a * solution ( though I'm unsure of the side effects ) 
but not * the * solution.  I'll be tackling a similar bug ( unclosed FONT ) for 
beta3 and therefore will look into this bug for beta3 ( since we don't have a 
lot of time for beta2 ).  

Comment 22

[Jay Patel [:jay]]

Putting on [nsbeta2+] radar for beta2 fix. The + is for a hack fix to increase 
the stack.

Comment 23

[harishd]

Chris, will have to work with you..since I don't have a Mac. system!!!

HEEEEELLLLLLPPPP.

Comment 24

[Chris Waterson]

PDT: please assign your "+" to bug 46722 instead. That way, we won't lose this 
one in the shuffle.

Comment 25

[Chris Waterson]

moving to nsbeta3

Comment 26

[Zach Lipton [:zach]]

Making a testcase for this one.

Comment 27

[Zach Lipton [:zach]]

Scrap the makingtest idea. I just don't have the time.

Comment 28

[Nisheeth Ranjan]

*** This bug has been marked as a duplicate of 42138 ***

Comment 29

[Scott Brodmerkle]

Verified  dupe.