418381 - crash [@ HashString(nsAString_internal const&)]

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P2)

Description

[Samuel Sidler (old account; do not CC)]

Firefox 3 beta 3 has a new topcrash. This still occurs on the trunk, though it appears to be more popular in beta 3. It looks like it happens on Windows and Mac only.

See also: bp-2af10d28-dedb-11dc-aa76-001a4bd46e84

Crashing Thread
Frame 	Signature 	Source
0 	HashString(nsAString_internal const&) 	nsTHashtable.cpp:48
1 	nsTHashtable<gfxFontCache::HashEntry>::s_HashKey(PLDHashTable*, void const*) 	nsTHashtable.h:359
2 	PL_DHashTableOperate 	pldhash.c:588
3 	gfxFontCache::Lookup(nsAString_internal const&, gfxFontStyle const*) 	mozilla/gfx/thebes/src/gfxFont.cpp:115
4 	GetOrMakeFont 	mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:466
5 	gfxWindowsFontGroup::GetFontAt(int) 	mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:523
6 	nsThebesFontMetrics::GetMetrics() 	mozilla/gfx/src/thebes/nsThebesFontMetrics.cpp:106
7 	nsThebesFontMetrics::GetMaxHeight(int&) 	mozilla/gfx/src/thebes/nsThebesFontMetrics.cpp:194
8 	nsTextBoxFrame::GetTextSize(nsPresContext*, nsIRenderingContext&, nsString const&, nsSize&, int&) 	mozilla/layout/xul/base/src/nsTextBoxFrame.cpp:925
9 	nsTextBoxFrame::CalcTextSize(nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsTextBoxFrame.cpp:942
10 	nsTextBoxFrame::GetBoxAscent(nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsTextBoxFrame.cpp:990
11 	nsSprocketLayout::GetAscent(nsIFrame*, nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsSprocketLayout.cpp:1525
12 	nsBoxFrame::GetBoxAscent(nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsBoxFrame.cpp:843
13 	nsSprocketLayout::GetAscent(nsIFrame*, nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsSprocketLayout.cpp:1525
14 	nsBoxFrame::GetBoxAscent(nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsBoxFrame.cpp:843
15 	nsSprocketLayout::GetAscent(nsIFrame*, nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsSprocketLayout.cpp:1525
16 	nsBoxFrame::GetBoxAscent(nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsBoxFrame.cpp:843
17 	nsSprocketLayout::GetAscent(nsIFrame*, nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsSprocketLayout.cpp:1525
18 	nsBoxFrame::GetBoxAscent(nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsBoxFrame.cpp:843
19 	nsSprocketLayout::GetAscent(nsIFrame*, nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsSprocketLayout.cpp:1525
20 	nsBoxFrame::GetBoxAscent(nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsBoxFrame.cpp:843
21 	nsSprocketLayout::GetAscent(nsIFrame*, nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsSprocketLayout.cpp:1525
22 	nsBoxFrame::GetBoxAscent(nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsBoxFrame.cpp:843
23 	nsSprocketLayout::Layout(nsIFrame*, nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsSprocketLayout.cpp:244
24 	nsBoxFrame::DoLayout(nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsBoxFrame.cpp:945
25 	nsIFrame::Layout(nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsBox.cpp:561
26 	nsStackLayout::Layout(nsIFrame*, nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsStackLayout.cpp:292
27 	nsBoxFrame::DoLayout(nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsBoxFrame.cpp:945
28 	nsIFrame::Layout(nsBoxLayoutState&) 	mozilla/layout/xul/base/src/nsBox.cpp:561
29 	nsBoxFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) 	mozilla/layout/xul/base/src/nsBoxFrame.cpp:756
30 	nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*) 	mozilla/layout/generic/nsContainerFrame.cpp:755
31 	ViewportFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) 	mozilla/layout/generic/nsViewportFrame.cpp:286
32 	PresShell::DoReflow(nsIFrame*) 	mozilla/layout/base/nsPresShell.cpp:6197
33 	PresShell::ProcessReflowCommands(int) 	mozilla/layout/base/nsPresShell.cpp:6302
34 	PresShell::DoFlushPendingNotifications(mozFlushType, int) 	mozilla/layout/base/nsPresShell.cpp:4510
35 	PresShell::ReflowEvent::Run() 	mozilla/layout/base/nsPresShell.cpp:6064
36 	nsThread::ProcessNextEvent(int, int*) 	mozilla/xpcom/threads/nsThread.cpp:510
37 	NS_ProcessNextEvent_P(nsIThread*, int) 	nsThreadUtils.cpp:227
38 	nsBaseAppShell::Run() 	mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:154
39 	nsAppStartup::Run() 	mozilla/toolkit/components/startup/src/nsAppStartup.cpp:181
40 	PR_GetEnv 	
41 	NS_internal_main(int, char**) 	mozilla/browser/app/nsBrowserApp.cpp:158
42 	wmain 	mozilla/toolkit/xre/nsWindowsWMain.cpp:55
43 	__tmainCRTStartup 	crtexe.c:594
44 	BaseProcessStart

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Sam, these bugs (this one along with 418382 and 418384) are mostly worthless without some way to reproduce -- all the stacks are generic enough that there isn't really any way to have any idea what's going on.  Not sure what we can do about them.

Comment 2

[Samuel Sidler (old account; do not CC)]

We've fixed crashes before without ways to reproduce. Topcrashes, even. There's nothing useful in them that could help us determine what might be causing this in code?

I can go through every report to look for comments that will lead to a testcase of some kind, but my guess is that these crashes *are* fairly generic and that there isn't a solid, known way to reproduce them.

(Welcome to topcrashes, eh?...)

Comment 3

[Ben Turner (not reading bugmail, use the needinfo flag!)]

This crash is occurring across multiple builds, not really concentrated anywhere.

Firefox 3.0b3pre: (http://tinyurl.com/39arsq)
  140

Firefox 3.0b3: (http://tinyurl.com/3c3xsp)
  1533

Firefox 3.0b4pre: (http://tinyurl.com/2oab6z)
  45

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

(In reply to comment #3)
Sorry, those are counts of crashes per version.

Comment 5

[chris hofmann]

this bug, along with https://bugzilla.mozilla.org/show_bug.cgi?id=418378
might be good test cases to see if mini-dumps can help in more detailed crash analysis of top crashes where the stack traces and comments just aren't helping to diagnose what is going on.   

we are trying to make sure that we have a system in place for the breakpad/sirocco system for doing this kind of more detailed analysis. See
https://bugzilla.mozilla.org/show_bug.cgi?id=411431#c5

would grabbing one of the mini-dumps help in looking at this bug?

Comment 6

[chris hofmann]

still ranking around #11 or #12 on beta 4. all the comments received on beta 4 so far seem to indicate its a start-up crash.  Seconds since start-up is broken in the reporting system, but should be fixed soon and that will help to confirm if all these are start up crashes.  Here is all we have to go on right now.

It´s dont work at all. I´m using Vista 32 bit. Dont know why

It is not working when i start it ,it crashes

It didn't work on start up.

I cannot even run Firefox. Beta 3 worked fine, but each build before that crashed, too.

first launch after upgrading from 2.0

Every time the thing starts, it crashes. Every one of the betas has done this. 

I can't use software that doesn't run.

Da jeg åbner et genvej på skrivebordet sker dette.

Its interesting that we only have one Mac report so far.  Wonder if there is anything unique in the module list or other parts of the blackbox that might help to isolate.
http://crash-stats.mozilla.com/report/index/ae701f94-f004-11dc-8543-001a4bd46e84

Comment 7

[timeless]

yes, a minidump would be useful (how valid is the data being hashed, what does the font that thebes have look like, and what url is the browser visiting).

the mac stack is strange, i can't recall ever having seen so many proxy objects at the bottom of a stack trace. it also scares me as there's a threadshutdown floating around in it (what if a proxy came from the thread being shutdown?).

Comment 8

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

These look like they're null-pointer dereferences.  In particular, the address is 0x4, so we're probably loading from a member of a struct that's null.  In particular, nsThebesFontMetrics::GetMetrics does this:

    return mFontGroup->GetFontAt(0)->GetMetrics();

which calls into code here:

gfxWindowsFont *
gfxWindowsFontGroup::GetFontAt(PRInt32 i)
{
    if (!mFonts[i]) {
        nsRefPtr<gfxWindowsFont> font = GetOrMakeFont(mFontEntries[i], &mStyle);
        mFonts[i] = font;
    }

    return static_cast<gfxWindowsFont*>(mFonts[i].get());
}

I think what's happening here is that mFontEntries[i] is null -- although you could probably confirm using a minidump (I think you can probably ask Ted for one).

Comment 9

[Ben Turner (not reading bugmail, use the needinfo flag!)]

That mac stack is seriously messed up... there are 13 proxy objects that get run, all of which are for shutting down an nsThread. The only folks I see offhand who use proxy objects to shut down their threads are:

1. nsStreamTransportService's thread pool
2. The JSShell extension (is that built?)
3. The SQL extension (pretty sure that isn't built)

My bet is on 1 unless I missed something... but hopefully that isn't related to this crash?

Comment 10

[timeless]

Attachment: use zeros for null case

I've tested w/ a breakpoint that forces the get to always fail, this seems durable (tested w/ profile manager/wizard and the xul filepicker [on windows])

Comment 11

[Karl Tomlinson (:karlt)]

That looks sensible, but it looks like there is still an issue with FindFontEntry returning NULL:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/gfx/thebes/src/gfxWindowsFonts.cpp&rev=1.175&mark=481-483,503-504#474
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/gfx/thebes/src/gfxWindowsPlatform.cpp&rev=1.39&mark=602-605#595

Comment 12

[Stuart Parmenter]

FindFontEntry can return null, but GetFontAt(0) should never be null

Comment 13

[timeless]

AppendElement in most implementations I've met can fail for oom and your code isn't checking the rv.

Comment 14

[Stuart Parmenter]

I feel pretty good about this not being an OOM bug

Comment 15

[Karl Tomlinson (:karlt)]

I'm wondering whether there is any reason why logFont.lfFaceName for DEFAULT_GUI_FONT should be the name corresponding to the system locale.

Looking at http://blogs.msdn.com/michkap/archive/2006/04/28/585735.aspx, I would guess not.

If this font has a different name corresponding to the system locale, then mFonts would only have the name matching the locale, and mFontAliases would only have logFont.lfFaceName if that name had been explicitly requested somewhere to invoke gfxWindowsPlatform::FontResolveProc.

I guess it's unlikely that DEFAULT_GUI_FONT would be a vertical font?

Comment 16

[Karl Tomlinson (:karlt)]

This crash is no longer showing up.
It morphed into bug 434401, which should hopefully be fixed now.