102900 - Trunk M095 crash when i visit community.walla.co.il [@ nsFontMetricsWin::RealizeFont]

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Barak]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4+) Gecko/20011003
BuildID:    2001100303



Reproducible: Always
Steps to Reproduce:
1.just enter the site


Actual Results:  mozilla crash

Comment 1

[Robert Rainwater]

wfm Win Me Build 2001100203

Although the layout is messed up.  The site is using flash.  Do you have the
plugin installed?

Comment 2

[Matthias Versen [:Matti]]

wfm with win2k build 20011003..
Reporter: Can you use a talkback enabled build and poste a talkback ID ?

Comment 3

[Ashley Bischoff (blog at handcoding.com)]

Reporter: To elaborate on Matti's comment, you can get a talkback-enabled build
here: http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip
(as always, be sure to delete your old Mozilla directory before installing the
new one)

Then, if you get a crash, please post the Talkback ID here.

Comment 4

[rcummins]

Win98, build 2001100103

Talkbacks:
TB36234426Z
TB36234384E

Seems to crash only when Javascript is enabled.

Comment 5

[rcummins]

Ditto Win98 2001100303

TB36234841Z
TB36234810M

Comment 6

[Barak]

yes i have flash plugin installed and the page layout seems to me ok.
i downloaded talkback build but i cant find what "Talkback ID" is.

Comment 7

[Barak]

oh ok its
TB36234712H

Comment 8

[Christian Reis]

WFM Linux 2001100308

Comment 9

[Asa Dotzler [:asa]]

Stack Trace
nsFontMetricsWin::RealizeFont
[d:\builds\seamonkey\mozilla\gfx\src\windows\nsFontMetricsWin.cpp, line 3054]
nsFontMetricsWin::Init
[d:\builds\seamonkey\mozilla\gfx\src\windows\nsFontMetricsWin.cpp, line 444]
nsFontCache::GetMetricsFor
[d:\builds\seamonkey\mozilla\gfx\src\nsDeviceContext.cpp, line 570]
DeviceContextImpl::GetMetricsFor
[d:\builds\seamonkey\mozilla\gfx\src\nsDeviceContext.cpp, line 234]
ComputeLineHeight
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLReflowState.cpp, line 2157]
nsHTMLReflowState::CalcLineHeight
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLReflowState.cpp, line 2199]
nsBlockReflowState::nsBlockReflowState
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowState.cpp, line 174]
nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 711]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 738]
CanvasFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp, line 584]
nsBoxToBlockAdaptor::Reflow
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp, line 885]
nsBoxToBlockAdaptor::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp, line 541]
nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 1004]
nsScrollBoxFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsScrollBoxFrame.cpp, line 393]
nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 1004]
nsBoxFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 920]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 738]
ViewportFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp, line 575]
PresShell::InitialReflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 2674]
HTMLContentSink::StartLayout
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLContentSink.cpp,
line 3898]
HTMLContentSink::DidBuildModel
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLContentSink.cpp,
line 2741]
CNavDTD::DidBuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp,
line 669]
nsParser::DidBuildModel
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1424]
nsParser::Terminate [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp,
line 1494]
nsHTMLDocument::StopDocumentLoad
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLDocument.cpp, line 879]
DocumentViewerImpl::Stop
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp, line 1240]
nsDocShell::Stop [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line
2296]
nsDocShell::Destroy [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp,
line 2441]
nsWebShell::Destroy [d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp,
line 1412]
nsHTMLFrameInnerFrame::~nsHTMLFrameInnerFrame
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsFrameFrame.cpp, line 696]
nsHTMLFrameInnerFrame::`scalar deleting destructor'
nsFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrame.cpp,
line 473]
nsFrameList::DestroyFrames
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp, line 131]
nsContainerFrame::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 136]
nsFrameList::DestroyFrames
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp, line 131]
nsContainerFrame::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 136]
nsLineBox::DeleteLineList
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineBox.cpp, line 267]
nsBlockFrame::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 328]
nsLineBox::DeleteLineList
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineBox.cpp, line 267]
nsBlockFrame::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 328]
nsLineBox::DeleteLineList
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineBox.cpp, line 267]
nsBlockFrame::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 328]
nsFrameList::DestroyFrame
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp, line 217]
CanvasFrame::RemoveFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp, line 371]
FrameManager::RemoveFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 859]
nsCSSFrameConstructor::ReconstructDocElementHierarchy
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp,
line 7145]
StyleSetImpl::ReconstructDocElementHierarchy
[d:\builds\seamonkey\mozilla\content\base\src\nsStyleSet.cpp, line 1186]
PresShell::ReconstructFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5113]
PresShell::StyleSheetAdded
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5123]
nsDocument::InsertStyleSheetAt
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 1386]
CSSLoaderImpl::InsertSheetInDoc
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1113]
CSSLoaderImpl::SheetComplete
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 823]
CSSLoaderImpl::ParseSheet
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 878]
CSSLoaderImpl::LoadInlineStyle
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1302]
HTMLContentSink::ProcessSTYLETag
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLContentSink.cpp,
line 5207]
HTMLContentSink::AddLeaf
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLContentSink.cpp,
line 3460]
CNavDTD::AddLeaf [d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 3774]
CNavDTD::AddHeadLeaf [d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp,
line 3833]
CNavDTD::HandleStartToken
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 1719]
CNavDTD::HandleToken [d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp,
line 895]
CNavDTD::BuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp,
line 526]
nsParser::BuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp,
line 2027]
nsParser::ResumeParse [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp,
line 1891]
nsParser::Parse [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line
1755] 

Comment 10

[Marc Attinasi]

WFM on Win2K with 10-03 build.

This could be related to rbs' font changes - cc'ing him.

Comment 11

[rbs]

WFM too. 

Reporter - are you browsing with a particular language group (or some other
Fonts prefs that you modified after installation).

Comment 12

[Barak]

Yes im using Arial font on Serif and Sans serif, Aharoni on cursive and Fantasy
and Courier New on Monospace for Hebrew (Visual).

Comment 13

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

This is a topcrash on the trunk.

Comment 14

[rbs]

Taking the bug. Hope to investigate next week.

Those of us who are reporting WFM are doing so on Win2K. Could people with 
access to Win9x give another try to the testcase?

From the stack trace, the crash is happening on a null pointer deference in
nsFontMetricsWin::RealizeFont :

  nsFontWin* font = FindFont(dc1, 'a');
  mFontHandle = font->mFont;

This is very weird because |font| is not expected to be null. A null |font|
there means that there is no font at all to represent the simple letter 'a', 
which is weird because the program wouldn't even work in the first place.

barak, on Win2K, I still couldn't crash after setting my prefs as per your 
comments of "2001-10-05 10:48". Do you keep crashing when you revert to the 
default prefs (with the Western language group). [If I still can't reproduce,
I might provide a special build to you that will log what is happening 
in FindFont('a') for further analysis].

Comment 15

[Barak]

still crashs even with Western language group.

i dont really remember what was the original font prefs for Hebrew visual,
anyway with other fonts it still crash.
i also noticed the site changing the Character coding to Unicode but again if i
switch to western before it crash it will reload the page in western coding and
crashs anyway.

Comment 16

[rbs]

Some data:

The site is sniffing and sending different things depending on the browser.

Feeding the URL to the web-sniffer (http://webtools.mozilla.org/web-sniffer/):
http://webtools.mozilla.org/web-sniffer/view.cgi?url=http%3A%2F%2Fcommunity.walla.co.il%2F&verbose=on

On my system, it returns the following with Mozilla or IE:
Content-type: text/html; charset=windows-1255

And it returns the following with Nav4.x (note: iso-8859-8 is Visual Hebrew):
Content-type: text/html; charset=iso-8859-8

So, I configured myself as Nav4.x by setting the following pref in my 
profile's prefs.js:

user_pref("general.useragent.override", "Mozilla/4.77 [en] (Windows 98; U)");

Still no crash.

barak: what happens you save the page locally and view it from your disk.

Comment 17

[rbs]

s/what happens you/what happens when you/

Comment 18

[Barak]

The site doesnt crash netscape 6.1 so i used it to download the page.
i downloaded the page without any other files (images, css, another page insaid
iframe...)

if i open the page when im online everything is the same (still crashing), but
it doesnt show any hebrew chracters (if it doesnt crash before im able to see
part of the page)
when im off line it takes something like 10 sec to bring up the page but never
stop loading it, again without any hebrew characters, (might related to the fact
it doesnt have the css file).
i wasn't able to bring it down when its offline (even after switching several
characer coding).

Now this is really strange, i discovered that if i try using "User Defined"
coding on any page its hangs mozila for 5 sec and than not only crashing mozilla
its bringing down my whole system (i wasnt even able to send data with talkback
build) 
my user defined font prefs are
serif = Arial
sans serif = Arial
cursive = Arial
Fantasy = Arial
monospace = Courier New

Comment 19

[rbs]

Do well to open another bug about the weirdness of "User Defined".

Do you still crash if you comment out the block
<!-- <ilayer> ... </ilayer> --> (i.e., including the <iframe> that it contains?

Comment 20

[timeless]

fwiw, i sent in lots of stacks for this (w98). i triggered it by running out of
resources (notepad insisted i had no fonts and suggested i install some using
the control panel). among them was  Incident ID 36312913.

Comment 21

[rbs]

dbaron, are these stack trace made available somewhere (e.g., on mozilla.org) 
for me to look at?

timeless, since you are Win98 -- care to also save the URL and then disable the 
<iframe> part that loads the flash plugin as I indicated above. (I am highly
suspicious that it isn't just a confined font problem and I am trying to proceed 
by elimination.)

Comment 22

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

http://ftp.mozilla.org/pub/data/crash-data/

Comment 23

[rbs]

Another plausible cause could be a missing release so that leaks are swamping 
the GDI.

Comment 24

[Barak]

Doesnt crash with <iframe> part disabled.

also reported new 103673 bug for the "user-defined weirdness".

Comment 25

[rbs]

And the page renders correctly? No missing Hebrew characters?

Comment 26

[rbs]

Also, what happens when you create another page in which you only keep the 
<iframe>...</iframe> part?

Comment 27

[Barak]

The page doesnt renders correctly, i have to switch the coding to Hebrew
(Windows-1255) to see hebrew characters.

i wasnt able to bring it down with a page contains only the Iframe part (with
the head of the page)

I also noticed it doesnt crash the latest bulids every time i view the page (but
still crashes most of the times).

Comment 28

[rbs]

The symptoms of this bug are very similar to that of bug 102778.

I think an infinite recursion might be happening in the handling of <iframe>.
I noted this fact in the course of investigating bug 102778. I had put a break
point in nsWindow::Create(), c.f. attachment 52084 [details] which is a stack trace of 
where the crash is reported in bug 102778. My break point was hit ad infinitum 
until a crash occurred, and each time the break point was hit, some 
htmlframe-related function was on the visible stack -- unfortunately due to the 
infinite recursion, this is not apparent on the final stack trace attached to 
that bug. Since fonts are amongst the first resources requested when laying a 
document, they tend to be exhausted first and disaster strikes there first.

There was a recent fix in bug 101746 that helped the situation. That may explain 
the differences that barak is observing in the latest builds.

I have no idea why the Linux build is not showing the problem. I am not sure if
the particularities of nsWindow::Create() in each platform are of any effect.

Anyway, there seems to be a regression still lurking around from the original 
fix for bug 49874.

Re-assigning back to attinasi, cc:ing hyatt who fixed bug 49874 and bug 101746.

Comment 29

[rbs]

barak, I am curious of something else... what happens when you just change 
<iframe> to <div> (this is to know if the shockwave plugin is playing any role).

Comment 30

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

Judging from the disassembly and the registers, this is crashing on line 3054
because |font|, which is the return value of FindFont, is null.  The disassembly is:

60358946 8b4024           mov     eax,[eax+0x24]      <=== CRASH HERE
60358949 8b1de0f03560     mov     ebx,[6035f0e0]
6035894f 50               push    eax
60358950 89868c000000     mov     [esi+0x8c],eax
60358956 ff75ec           push    dword ptr [ebp-0x14]
60358959 ffd3             call    ebx
6035895b 8945e4           mov     [ebp-0x1c],eax
6035895e 8b4660           mov     eax,[esi+0x60]
60358961 8d55fc           lea     edx,[ebp-0x4]

and EAX is 0.

Comment 31

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

Is this related to bug 103777?

Comment 32

[rbs]

> |font|, which is the return value of FindFont, is null
Yep, that's what I noted earlier -- what is curious there is that in the worst
case scenario, there is the font substitute fallback which is supposed to be
never null -- in theory, that is.

> Is this related to bug 103777?
Let me have a look.

Comment 33

[timeless]

rbs: um i can try, but my crashes had nothing to do w/ the url here. I
litterally had exhausted all of my font resources somewhere else (requires
9x...) so i could run mozilla, load 4 windows (ctrl-1,..4) and be assured that
mozilla would crash.

currently my 98 box is in the midst of a js memory exhaustion algoritm, i'll try
this page sometime after that either crashes or i need to recover the computer.

Comment 34

[rbs]

Noted something in the course of this (rjesup, what you think?) :

nsFontCache :: GetMetricsFor

-         mFontMetrics.MoveElement(0, cnt);
+         mFontMetrics.MoveElement(cnt, 0);

Comment 35

[rbs]

barak, here is a special build that will log what is happening in the 
font-subystem using the timeline service (from bug 78793). Basically, the
code will, amongst other things, log what is happening with the fonts and the 
ellapsed time between each operation:

ftp://ftp.maths.uq.edu.au/pub/rbs/mozilla-win32-bug102900.exe

To test the build:

1. Install the self-extracting file, e.g. in C:\temp\mozilla-bug102900
2. cd c:\temp\mozilla-bug102900\bin
3. set NS_TIMELINE_LOG_FILE=c\temp\timeline.txt
4. mozilla

Then, visit the crash site and let see how it goes...

Comment 36

[rbs]

Attachment: sample timeline output on my system when I visit the crash site

Comment 37

[rbs]

The attached sample shows what I get when I open a blank window (no sidebar),
and enter http://community.walla.co.il/ in the urlbar, and then exit when the
'Document: done' appears. Searching the crash url on the sample enables to go 
straight where the load starts and to see what is happening from there. (Note
to developers: I added F_SYNC to the timeline logging service in my tree -- hope 
that will help not to miss logging bits if a crash occur.)

Comment 38

[Marc Attinasi]

Reassign - well, you are doing all the work here ;)

Comment 39

[Randell Jesup [:jesup] (needinfo me)]

Opened a bug (bug 104260) to cover the nsFontCache issue.

Comment 40

[greer]

Adding Trunk and M095 to the summary for talkback (160 incidents in M095, 141 in
Trunk under the  nsFontMetricsWin::RealizeFont signature).

Comment 41

[rbs]

No luck reproducing this so far on the urls provided with the talback data.
The connection with the <iframe> is still to be elucidated too.

Comment 42

[Jay Patel [:jay]]

Attachment: MozillaTrunk user comments and urls to help reproduce

Comment 43

[Jay Patel [:jay]]

Attachment: Mozilla 0.9.5 user comments and urls to help reproduce

Comment 44

[Jay Patel [:jay]]

This is the #1 crasher for Mozilla 0.9.5 thus far.  I have attached all the user
comments and urls submitted by users on both the MozillaTrunk and M095.  Adding
qawanted keyword to see if we can get a solid testcase or reproducible steps.

Comment 45

[rbs]

Attachment: null pointer check

Comment 46

[rbs]

I had hoped to get down to the problem but since I have no luck reproducing,
I am falling back (with some reluctance) to the good old null pointer check.
Note that the proposed check used to be there, but I removed it when fixing
printing bug 102243:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsFontMetricsWin.cpp&root=/cvsroot&subdir=mozilla/gfx/src/windows&command=DIFF_FRAMESET&rev1=3.118&rev2=3.119

It evades me why this check should be there because the basic problem is to find
a font that can represent the simple letter 'a' -- rendering cannot even work
without that font. (It is the ASCII font that is subsequently used to get the
CSS metrics as I commented about in my font changes.) My gut feeling so far is
that the crash is arising because objects/resources are been destroyed while
layout is still in progress, instead of halting all the layout chain first.
Admittedly however, FindFont('a') can also fail in low-memory situations, so...
seeking r/sr to re-instate the null check.

Comment 47

[Marc Attinasi]

Comment on attachment 53911 [details] [diff] [review]
null pointer check

sr=attinasi

Comment 48

[rbs]

rods, review?

Comment 49

[rods (gone)]

look godd r=rods

Comment 50

[rbs]

Fixed with the null check.