Closed
Bug 418381
Opened 17 years ago
Closed 17 years ago
crash [@ HashString(nsAString_internal const&)]
Categories
(Core :: Graphics, defect, P2)
Core
Graphics
Tracking
()
RESOLVED
WORKSFORME
mozilla1.9
People
(Reporter: samuel.sidler+old, Unassigned)
References
()
Details
(Keywords: crash, topcrash)
Crash Data
Attachments
(1 file)
846 bytes,
patch
|
pavlov
:
review-
|
Details | Diff | Splinter Review |
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
Flags: blocking1.9?
Reporter | ||
Updated•17 years ago
|
Priority: -- → P1
Target Milestone: --- → mozilla1.9beta4
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.
Reporter | ||
Comment 2•17 years ago
|
||
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?...)
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
(In reply to comment #3)
Sorry, those are counts of crashes per version.
Comment 5•17 years ago
|
||
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?
Updated•17 years ago
|
Priority: P1 → P2
Target Milestone: mozilla1.9beta4 → mozilla1.9
Updated•17 years ago
|
Flags: tracking1.9? → blocking1.9?
Updated•17 years ago
|
Flags: blocking1.9? → blocking1.9-
Comment 6•17 years ago
|
||
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
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?).
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).
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•17 years ago
|
||
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])
Attachment #309090 -
Flags: review?(pavlov)
Comment 11•17 years ago
|
||
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•17 years ago
|
||
FindFontEntry can return null, but GetFontAt(0) should never be null
Updated•17 years ago
|
Attachment #309090 -
Flags: review?(pavlov) → review-
Comment 13•17 years ago
|
||
AppendElement in most implementations I've met can fail for oom and your code isn't checking the rv.
Comment 14•17 years ago
|
||
I feel pretty good about this not being an OOM bug
Comment 15•17 years ago
|
||
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•17 years ago
|
||
This crash is no longer showing up.
It morphed into bug 434401, which should hopefully be fixed now.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•14 years ago
|
Crash Signature: [@ HashString(nsAString_internal const&)]
You need to log in
before you can comment on or make changes to this bug.
Description
•