650446 - Fennec crash/abort when viewing CSS Grid spec, in BasicShadowableThebesLayer::CreateBuffer or nsIFrame::BuildDisplayListForChild

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Daniel Holbert [:dholbert]]

STEPS TO REPRODUCE:
 1. Load http://www.w3.org/TR/css3-grid-layout/ in a Fennec trunk build
     (e.g. from http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mozilla-central-linux/ )
 2. Maximize fennec. OR: Zoom in as much as you can.

ACTUAL RESULTS: Crash! (Confirmed personally in Fennec on Android, Win7,  & Linux. 100% reproducible.)

On Linux, the crash report looks like:
 bp-d49d4a33-0fb4-455c-83e4-fbfe72110415
 bp-119b7437-0256-49c1-b090-3c52e2110415

{
Crash Reason	SIGABRT
Crash Address	0xab6
User Comments	
Processor Notes 	INFO: This record is a replacement for a previous record with the same uuid; WARNING: Json file missing Add-ons
EMCheckCompatibility	False

0 	linux-gate.so 	linux-gate.so@0x430 	
1 	libc-2.13.so 	libc-2.13.so@0x2e2cd 	
2 	libmozalloc.so 	mozalloc_abort 	mozalloc_abort.cpp:75
3 	libxul.so 	NS_DebugBreak_P 	xpcom/base/nsDebugImpl.cpp:388
4 	libxul.so 	mozilla::layers::BasicShadowableThebesLayer::CreateBuffer 	gfx/layers/basic/BasicLayers.cpp:1930
5 	libxul.so 	mozilla::layers::BasicThebesLayerBuffer::CreateBuffer 	gfx/layers/basic/BasicLayers.cpp:673
6 	libxul.so 	mozilla::layers::ThebesLayerBuffer::BeginPaint 	gfx/layers/ThebesLayerBuffer.cpp:368
7 	libxul.so 	mozilla::layers::BasicThebesLayer::PaintThebes 	gfx/layers/basic/BasicLayers.cpp:593
8 	libxul.so 	mozilla::layers::BasicLayerManager::PaintLayer 	gfx/layers/basic/BasicLayers.cpp:1499
9 	libxul.so 	mozilla::layers::BasicLayerManager::PaintLayer 	gfx/layers/basic/BasicLayers.cpp:1512
10 	libxul.so 	mozilla::layers::BasicLayerManager::EndTransactionInternal 	gfx/layers/basic/BasicLayers.cpp:1364
11 	libxul.so 	mozilla::layers::BasicLayerManager::EndTransaction 	gfx/layers/basic/BasicLayers.cpp:1321
12 	libxul.so 	mozilla::layers::BasicShadowLayerManager::EndTransaction 	gfx/layers/basic/BasicLayers.cpp:2786
13 	libxul.so 	nsDisplayList::PaintForFrame 	layout/base/nsDisplayList.cpp:597
14 	libxul.so 	nsDisplayList::PaintRoot 	layout/base/nsDisplayList.cpp:505
15 	libxul.so 	nsLayoutUtils::PaintFrame 	layout/base/nsLayoutUtils.cpp:1637
16 	libxul.so 	PresShell::Paint 	layout/base/nsPresShell.cpp:6035
17 	libxul.so 	nsViewManager::RenderViews 	view/src/nsViewManager.cpp:449
18 	libxul.so 	nsViewManager::Refresh 	view/src/nsViewManager.cpp:424
19 	libxul.so 	nsViewManager::DispatchEvent 	view/src/nsViewManager.cpp:930
20 	libxul.so 	HandleEvent 	view/src/nsView.cpp:161
21 	libxul.so 	mozilla::widget::PuppetWidget::DispatchEvent 	widget/src/xpwidgets/PuppetWidget.cpp:323
22 	libxul.so 	mozilla::widget::PuppetWidget::DispatchPaintEvent 	widget/src/xpwidgets/PuppetWidget.cpp:533
23 	libxul.so 	mozilla::widget::PuppetWidget::PaintTask::Run 	widget/src/xpwidgets/PuppetWidget.cpp:572
24 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:618
25 	libxul.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:250
26 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
27 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:219
28 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:202
29 	libxul.so 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:189
30 	libxul.so 	XRE_RunAppShell 	toolkit/xre/nsEmbedFunctions.cpp:673
31 	libxul.so 	mozilla::ipc::MessagePumpForChildProcess::Run 	ipc/glue/MessagePump.cpp:215
32 		@0xffdbab43 	
33 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:219
34 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:202
35 	libxul.so 	XRE_InitChildProcess 	toolkit/xre/nsEmbedFunctions.cpp:510
36 	plugin-container 	main 	MozillaRuntimeMain.cpp:80
37 	libc-2.13.so 	libc-2.13.so@0x16e36 	
38 	plugin-container 	plugin-container@0xea0 	
39 	plugin-container 	plugin-container@0xf53 	
40 	ld-2.13.so 	ld-2.13.so@0xed5f 	
41 	ld-2.13.so 	ld-2.13.so@0x1d917
}

The BasicLayers.cpp:1930 line at stacklevel 4 is this NS_RUNTIMEABORT:
> 1927     if (!BasicManager()->AllocBuffer(gfxIntSize(aSize.width, aSize.height),
> 1928                                      aType,
> 1929                                      &mBackBuffer)) {
> 1930       NS_RUNTIMEABORT("creating ThebesLayer 'back buffer' failed!");
> 1931     }

I believe the crash is at that line on all platforms (though the signatures & stack levels inside that call end up being different between platforms, depending on the implementation of NS_RUNTIMEABORT)

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to comment #0)
>  2. Maximize fennec.

('maximize' only applies to fennec-on-the-Desktop, of course - not on Android.  AFAICT, for this bug's purposes, it's just a quick and easy way of doing a lot of zooming all at once.)

Comment 2

[Daniel Holbert [:dholbert]]

crash report on Win7: bp-0f28c04e-58e1-44e7-b3e3-a501f2110415

Comment 3

[Daniel Holbert [:dholbert]]

Crash report on Android: bp-7c208087-b959-45c3-896f-d53902110416 -- it's inside of nsIFrame::BuildDisplayListForChild, though. (different from on Linux / Windows)
{
Crash Reason	SIGSEGV
Crash Address	0xdeadbaad
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	libc.so 	libc.so@0x15ca4 	
1 	libc.so 	libc.so@0x1c80e 	
2 	libc.so 	libc.so@0x426b7 	
3 	libc.so 	libc.so@0x426b7 	
4 	libc.so 	libc.so@0x426b7 	
5 	libmozalloc.so 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:75
6 	libxul.so 	nsIFrame::BuildDisplayListForChild 	layout/generic/nsFrame.cpp:1709
}

The line of BuildDisplayListForChild pointed to in stackframe 6 is:
> 1709        rv = aBuilder->DisplayCaret(aChild, dirty, aLists.Content());
http://hg.mozilla.org/mozilla-central/annotate/2a343ee6acd3/layout/generic/nsFrame.cpp#l1709

Comment 4

[Scoobidiver (away)]

libc.so@0x15dd8 crash signature has a similar stack trace.

Comment 5

[Scoobidiver (away)]

The libc.so@0x15e7c crash signature has a similar stack trace.

Comment 6

[Daniel Holbert [:dholbert]]

BTW - I'm afraid that the crash "signatures" here are generic and apply to multiple types of crashes, unfortunately.  It looks like we're aborting in all stack traces posted so far, so many other bugs that trigger aborts will end up with the same signature.

(This isn't so much a response to Comment 4/5 as a response to a comment in IRC from someone who thought they'd hit the same crash with completely different STR, because the crash signature matched.)

Comment 7

[Josh Matthews [:jdm]]

Can't reproduce on OSX in a local debug build. Daniel, do you still see this?

Comment 8

[Scoobidiver (away)]

As libc.so, libc-2.13.so and linux-gate.so have been added to the Socorro skiplist, I change the crash signature.

Comment 9

[u279076]

I am closing this as incomplete since I can find no recent reports of this crash. Please reopen if you are able to reproduce the crash.

Comment 10

[Daniel Holbert [:dholbert]]

Sorry, I must not've seen jdm's question directed to me in comment 7.

In any case, I can't reproduce anymore (testing Firefox Nightly on Android), so I'll upgrade the resolution to WORKSFORME.