108240 - Crash at www.iht.com

Status: RESOLVED DUPLICATE of bug 105619

(Core :: Layout, defect, P1)

Description

[Minko Markov]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.5+) Gecko/20011101
BuildID:    2001110112

Javascript enabled, Java disabled.
Load the page. Nothing happens for
several seconds, then Mozilla crashes.
This is a problem with 2001110112.
M 0.9.5 worked OK (almost, except for
back/forward navigation) with iht.com

Reproducible: Always
Steps to Reproduce:
1. Load the page

The site uses heavily Javascript.
I assume this is a Javascript
problem with yesterday's build.

Comment 1

[Phil Schwartau]

Attachment: Console output + stack traces

Comment 2

[Phil Schwartau]

Confirming with WinNT trunk binary 20011030xx. OS : Linux ---> All.

The stack includes calls to 

               FrameManager::ComputeStyleChangeFor ()
               nsCSSFrameConstructor::AttributeChanged()
                               etc.
                               etc.

I will reassign this to Layout for further analysis; it doesn't
look like JS Engine to me.


The calls near the top of the stack seem strange:

#6  0x4025e3a4 in nsAString::Equals (this=0x882a348, rhs=@0x8802038) at 
../../dist/include/string/nsAString.h:671

#7  0x41c84eac in operator!= (lhs=@0x882a348, rhs=@0x8802038) at 
../../../dist/include/string/nsAString.h:678


I've never seen this before. cc'ing jst, jband in case this has
anything to do with the recent work on null strings, etc.

My WinNT Mozilla binary from 2001-10-19 loads the site fine,
but one from 2001-10-26 crashes just like the current builds do.

So perhaps a checkin between these two dates is responsible - 

Comment 3

[[e-mail] (gone - use [e-mail] instead)]

Attachment: TB37564132

Comment 4

[John Bandhauer]

The stack I see here is a little different. I see uninitialized (or garbage) 
data. So it may be somewhat random as to where it will get tripped up and stop 
in the debugger. I'll attach the stack I see.

Anyway, this does not look like anything to do with string changes. The 
font->mFont in ComputeLineHeight looks like garbage. There is no initialized 
string object in it and its other members look suspect. This font comes from a 
call to  aStyleContext->GetStyleData(eStyleStruct_Font). I don't know why it is 
not fully initialized. FWIW, I saw this same thing once recently in a 
Purify build while trying to debug bug 108226. Hope this helps.

Comment 5

[John Bandhauer]

Attachment: here's the stack I see on W2K

Comment 6

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 7

[Markus Hübner]

Changing summary.

Comment 8

[Marc Attinasi]

bug 105619? I'm seeing a lot of these lately... worrying.

Comment 9

[Markus Hübner]

Since 108994 was filed a dupe of 105619 doing the same here too.


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

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I can't reproduce this crash using a current Linux build.  Is there something I
need to do to get the page to crash?

Comment 11

[John Bandhauer]

This crashes for me on W2K as the page is loading. I just reproduced it with a 
depend debug build from sources pulled this afternoon.