Closed
Bug 569510
Opened 14 years ago
Closed 14 years ago
Firefox 4.0b Crash [@ _cairo_array_num_elements ]
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: chofmann, Assigned: jfkthame)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
1.90 KB,
patch
|
jtd
:
review+
|
Details | Diff | Splinter Review |
there is a crash on the trunk that looks like below. same signature exists on 3.6.3, but is much lower volume by about 13:1, and it might be another stack and bug checking --- _cairo_array_num_elements 20100531-crashdata.csv found in: 3.7a5pre 3.6.3 release total-crashes _cairo_array_num_elements crashes pct. all 372037 14 3.76307e-05 3.7a5pre 1716 13 0.00757576 3.6.3 259555 1 3.85275e-06 the 3.7a5pre stack looks like http://crash-stats.mozilla.com/report/index/bb358d73-3ba3-4cdb-8e51-b1b082100601 Frame Module Signature [Expand] Source 0 xul.dll _cairo_array_num_elements gfx/cairo/cairo/src/cairo-cache.c:48 1 xul.dll gfxFont::Draw gfx/thebes/src/gfxFont.cpp:898 2 xul.dll gfxTextRun::Draw gfx/thebes/src/gfxFont.cpp:2876 3 xul.dll nsTextFrame::DrawText layout/generic/nsTextFrameThebes.cpp:4854 4 xul.dll nsTextFrame::PaintText layout/generic/nsTextFrameThebes.cpp:4841 5 xul.dll mozilla::FrameLayerBuilder::DrawThebesLayer layout/base/FrameLayerBuilder.cpp:532 6 xul.dll mozilla::layers::BasicThebesLayer::Paint gfx/layers/basic/BasicLayers.cpp:266 7 xul.dll mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayers.cpp:675 8 xul.dll mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayers.cpp:678 9 xul.dll mozilla::layers::BasicLayerManager::EndTransaction gfx/layers/basic/BasicLayers.cpp:569 10 xul.dll nsDisplayList::PaintForFrame layout/base/nsDisplayList.cpp:464 11 xul.dll nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:1262 12 xul.dll PresShell::Paint layout/base/nsPresShell.cpp:5759 13 xul.dll nsViewManager::Refresh view/src/nsViewManager.cpp:426 14 xul.dll nsViewManager::DispatchEvent view/src/nsViewManager.cpp:877 15 xul.dll HandleEvent view/src/nsView.cpp:160 16 xul.dll nsWindow::DispatchEvent widget/src/windows/nsWindow.cpp:3220 17 xul.dll nsWindow::DispatchWindowEvent widget/src/windows/nsWindow.cpp:3248 18 xul.dll nsWindow::OnPaint widget/src/windows/nsWindowGfx.cpp:535 19 xul.dll nsWindow::ProcessMessage widget/src/windows/nsWindow.cpp:4239 20 xul.dll nsWindow::WindowProc widget/src/windows/nsWindow.cpp:3955 21 user32.dll InternalCallWinProc 22 user32.dll UserCallWinProcCheckWow 23 user32.dll DispatchClientMessage 24 user32.dll __fnDWORD 25 ntdll.dll KiUserCallbackDispatcher 26 xul.dll xul.dll@0x5942f 27 user32.dll DispatchMessageW 28 xul.dll nsBaseAppShell::OnProcessNextEvent widget/src/xpwidgets/nsBaseAppShell.cpp:294 29 xul.dll nsTArray_base::ShiftData obj-firefox/xpcom/build/nsTArray.cpp:164 30 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:118 31 xul.dll MessageLoop::RunInternal ipc/chromium/src/base/message_loop.cc:216 32 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:199 33 xul.dll xul.dll@0x309613 more reports at http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&query=_cairo_array_num_elements&date=06%2F01%2F2010%2018%3A05%3A03&range_value=1&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&signature=_cairo_array_num_elements
Reporter | ||
Comment 1•14 years ago
|
||
probably the wrong component, but didn't see a better match.
blocking2.0: --- → ?
Keywords: crash
Reporter | ||
Comment 2•14 years ago
|
||
yeah, here are the two stacks. the 3.6.3 crash appears to run though font metrics code, and the trunk crash is running through nsTextFrame::DrawText and nsTextFrame::PaintText 13 _cairo_array_num_elements gfxFont::Draw(gfxTextRun *,unsigned int,unsigned int,gfxContext *,int,gfxPoint *,gfxFont::Spacing *) gfxTextRun::Draw(gfxContext *,gfxPoint,unsigned int,unsigned int,gfxRect const *,gfxTextRun::PropertyProvider *,double *) nsTextFrame::DrawText(gfxContext *,gfxPoint const &,unsigned int,unsigned int,gfxRect const *,PropertyProvider *,double &,int) nsTextFrame::PaintText(nsIRenderingContext *,nsPoint,nsRect const &) mozilla::FrameLayerBuilder::DrawThebesLayer(mozilla::layers::ThebesLayer *,gfxContext *,nsIntRegion const &,void *) mozilla::layers::BasicThebesLayer::Paint(gfxContext *,void (*)(mozilla::layers::ThebesLayer *,gfxContext *,nsIntRegion const &,void *),void *) 1 _cairo_array_num_elements gfxFont::Draw(gfxTextRun *,unsigned int,unsigned int,gfxContext *,int,gfxPoint *,gfxFont::Spacing *) gfxTextRun::Draw(gfxContext *,gfxPoint,unsigned int,unsigned int,gfxRect const *,gfxTextRun::PropertyProvider *,double *) nsThebesFontMetrics::DrawString(unsigned short const *,unsigned int,int,int,int,int const *,nsThebesRenderingContext *) nsThebesRenderingContext::DrawString(unsigned short const *,unsigned int,int,int,int,int const *) nsThebesRenderingContext::DrawString(nsString const &,int,int,int,int const *) nsTextBoxFrame::DrawText(nsIRenderingContext &,nsRect const &,unsigned int const *)
Reporter | ||
Comment 3•14 years ago
|
||
looks like the trunk form of the crash might have started showing up on may 17th, in builds from the 15th, with some spikes in the crashes around may 25 and yesterday. date crashes at cairo_array_num_elements count release-builds 20100510 2 3.6.3-20100401080539 20100511 2 3.0.1-92010031422 3.6.3-20100401080539 20100512 1 3.6.3-20100401080539 20100513 1 3.6.3-20100401080539 20100514 5 3.6.3-20100401080539 20100515 20100516 2 3.6.3-20100401080539 20100517 2 3.7a5pre-20100515040001 3.5.9-20100315083431 20100518 7 3.5.9-20100315083431 3.6.3-20100401080539 20100519 5 3.5.9-20100315083431 3.6.320100401080539 20100520 5 3.7a5pre-20100519040042 3.6.320100401080539 20100521 2 3.7a5pre-20100519040042 3.6.320100401080539 20100522 11 3.7a5pre-20100522040023 20100523 11 3.7a5pre-20100522040023 3.7a5pre20100523040016 3.7a4webm-20100518233040 20100524 20100525 17 3.7a5pre-20100523042844 3.6.3-20100401080539 20100526 2 3.7a5pre-20100522040023 3.7a4webm-20100518233040 20100527 7 3.7a5pre-20100527040336 3.5.5-20091102152451 20100528 5 3.7a5pre-20100528040337 3.7a5pre-20100527040336 20100529 2 3.7a5pre-20100528040337 3.6.3-20100401080539 20100530 2 3.7a4webm-20100518233040 20100531 14 3.7a5pre-20100531040317 3.7a5pre-20100530040319 3.6.3-20100401080539 jst, if there is time to a fix for this into the next alpha/developer release we should try.
Reporter | ||
Updated•14 years ago
|
Component: GFX: Color Management → Layout: Text
QA Contact: color-management → layout.fonts-and-text
Updated•14 years ago
|
Component: Layout: Text → Graphics
QA Contact: layout.fonts-and-text → thebes
so, this is a null pointer deref, but i can't figure out how to get a null pointer here (the stack trace is *probably* tail call optimized to oblivion)
Severity: normal → critical
Updated•14 years ago
|
blocking2.0: ? → -
Reporter | ||
Comment 5•14 years ago
|
||
now running about 50-80 crashes per day with the increase in the beta test population, and ranked around #19 in non-plugin related crashes on 4.0 betas.
blocking2.0: - → ?
Reporter | ||
Updated•14 years ago
|
Keywords: regression
Summary: Firefox 3.7a5pre Crash [@ _cairo_array_num_elements ] → Firefox 4.0b Crash [@ _cairo_array_num_elements ]
Updated•14 years ago
|
Assignee: nobody → jfkthame
blocking2.0: ? → final+
Assignee | ||
Comment 6•14 years ago
|
||
Now that bug 553963 has landed, we should see whether this keeps happening in 4.0b3; it seems possible that the issues fixed there might have been leading to other null-deref crashes as well.
Assignee | ||
Comment 7•14 years ago
|
||
(In reply to comment #6) > we should see whether this keeps happening in > 4.0b3 Errr..... beta4, I mean.
Assignee | ||
Comment 8•14 years ago
|
||
So we're still seeing this crash signature in 4.0b4, though I don't know of any specific STR. It looks like the crashes are occurring when gfxGDIFont::SetupCairoFont() calls cairo_scaled_font_status with a null mScaledFont. This patch should prevent that crash by adding the appropriate null-checks, in case initialization of the cairo font failed for some reason.
Attachment #469024 -
Flags: review?(jdaggett)
Updated•14 years ago
|
Attachment #469024 -
Flags: review?(jdaggett) → review+
Assignee | ||
Comment 9•14 years ago
|
||
Pushed http://hg.mozilla.org/mozilla-central/rev/94ac381a7893. Leaving this bug open for now, waiting to see how crash-stats respond...
Reporter | ||
Comment 10•14 years ago
|
||
yesterday we saw these numbers with about 310k users on beta4, and 250k on beta3 checking --- _cairo_array_num_elements 20100826-crashdata.csv found in: 4.0b4 4.0b2 3.6.8 release total-crashes _cairo_array_num_elements crashes pct. all 291046 73 0.000250819 4.0b4 17931 65 0.00362501 4.0b2 1733 6 0.0034622 3.6.8 185994 2 1.0753e-05 check again on beta5
Assignee | ||
Comment 11•14 years ago
|
||
Is this still happening? I couldn't seem to find any current reports on crash-stats, but the response to queries was being painfully slow and I may not have searched properly....
OS: Windows XP → All
Reporter | ||
Comment 12•14 years ago
|
||
peaked out on sept 7 with 126 crashes. now down to 8-12 crashes per day, but they are all b4 or older. 20101002 8 4 4.0b22010072019, 3 4.0b42010081813, 1 3.6.82010072215, 20101003 12 8 4.0b42010081813, 3 4.0b22010072019, 1 3.6.32010040108,
Reporter | ||
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Crash Signature: [@ _cairo_array_num_elements ]
You need to log in
before you can comment on or make changes to this bug.
Description
•