Closed Bug 834372 Opened 7 years ago Closed 7 years ago

crash in mozilla::layers::BasicShadowableThebesLayer::CreateBuffer with abort message: "creating ThebesLayer 'back buffer' failed! width=2621440, height=2064384, type=3000"

Categories

(Core :: Graphics: Layers, defect, critical)

18 Branch
ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
blocking-b2g -
Tracking Status
b2g18 + ---

People

(Reporter: scoobidiver, Assigned: pchang)

References

Details

(Keywords: crash, Whiteboard: [b2g-crash][apps watch list][closeme 4/3/2013])

Crash Data

There are two crashes in B2G 18.0.

There might be STR in bug 650446 comment 0.

Signature 	mozalloc_abort | NS_DebugBreak_P | mozilla::layers::BasicShadowableThebesLayer::CreateBuffer More Reports Search
UUID	5e591994-305d-4174-8146-02e152130124
Date Processed	2013-01-24 10:08:24
Process Type	content
Uptime	45521
Install Age	12.7 hours since version was first installed.
Install Time	2013-01-23 21:31:53
Product	B2G
Version	18.0
Build ID	20130123070202
Release Channel	nightly
OS	Android
OS Version	0.0.0 Linux 3.0.8-perf #1 PREEMPT Tue Oct 16 07:34:52 PDT 2012 armv7l toro/full_unagi/unagi:4.0.4.0.4.0.4/OPENMASTER/103:user/test-keys
Build Architecture	arm
Build Architecture Info	
Crash Reason	SIGSEGV
Crash Address	0x0
App Notes 	
xpcom_runtime_abort([Child 834] ###!!! ABORT: creating ThebesLayer 'back buffer' failed! width=2621440, height=2064384, type=3000: file ../../../gecko/gfx/layers/basic/BasicThebesLayer.cpp, line 460)
Processor Notes 	sp-processor01.phx1.mozilla.com_12003:2008; this crash has been processed more than once; WARNING: JSON file missing Add-ons; exploitablity tool: ERROR: unable to analyze dump
EMCheckCompatibility	False
Adapter Vendor ID	
Adapter Device ID	
Device	toro unagi1
Android API Version	15(AOSP)
Android CPU ABI	armeabi-v7a

Frame 	Module 	Signature 	Source
0 	libxul.so 	mozalloc_abort 	mozalloc_abort.cpp:30
1 	libxul.so 	NS_DebugBreak_P 	nsDebugImpl.cpp:423
2 	libxul.so 	mozilla::layers::BasicShadowableThebesLayer::CreateBuffer 	BasicThebesLayer.cpp:460
3 	libxul.so 	mozilla::layers::BasicThebesLayerBuffer::CreateBuffer 	BasicBuffers.cpp:64
4 	libxul.so 	mozilla::layers::ThebesLayerBuffer::BeginPaint 	ThebesLayerBuffer.cpp:306
5 	libxul.so 	mozilla::layers::BasicThebesLayer::PaintThebes 	BasicThebesLayer.cpp:172
6 	libxul.so 	mozilla::layers::BasicShadowableThebesLayer::PaintThebes 	BasicThebesLayer.cpp:307
7 	libxul.so 	mozilla::layers::BasicLayerManager::PaintSelfOrChildren 	BasicLayerManager.cpp:826
8 	libxul.so 	mozilla::layers::BasicLayerManager::PaintLayer 	BasicLayerManager.cpp:939
9 	libxul.so 	mozilla::layers::BasicLayerManager::PaintSelfOrChildren 	BasicLayerManager.cpp:841
10 	libxul.so 	mozilla::layers::BasicLayerManager::PaintLayer 	BasicLayerManager.cpp:939
11 	libxul.so 	mozilla::layers::BasicLayerManager::PaintSelfOrChildren 	BasicLayerManager.cpp:841
12 	libxul.so 	mozilla::layers::BasicLayerManager::PaintLayer 	BasicLayerManager.cpp:939
13 	libxul.so 	mozilla::layers::BasicLayerManager::PaintSelfOrChildren 	BasicLayerManager.cpp:841
14 	libxul.so 	mozilla::layers::BasicLayerManager::PaintLayer 	BasicLayerManager.cpp:939
15 	libxul.so 	mozilla::layers::BasicLayerManager::EndTransactionInternal 	BasicLayerManager.cpp:586
16 	libxul.so 	mozilla::layers::BasicLayerManager::EndTransaction 	BasicLayerManager.cpp:509
17 	libxul.so 	mozilla::layers::BasicShadowLayerManager::EndTransaction 	BasicLayerManager.cpp:1149
18 	libxul.so 	nsDisplayList::PaintForFrame 	nsDisplayList.cpp:1144
19 	libxul.so 	nsDisplayList::PaintRoot 	nsDisplayList.cpp:1009
20 	libxul.so 	nsLayoutUtils::PaintFrame 	nsLayoutUtils.cpp:1955
21 	libxul.so 	PresShell::Paint 	nsPresShell.cpp:5349
22 	libxul.so 	nsViewManager::ProcessPendingUpdatesForView 	nsViewManager.cpp:431
23 	libxul.so 	nsViewManager::ProcessPendingUpdates 	nsViewManager.cpp:1221
24 	libxul.so 	nsRefreshDriver::Notify 	nsRefreshDriver.cpp:436
25 	libxul.so 	nsTimerImpl::Fire 	nsTimerImpl.cpp:476
26 	libxul.so 	nsTimerEvent::Run 	nsTimerImpl.cpp:556
27 	libxul.so 	nsThread::ProcessNextEvent 	nsThread.cpp:620
28 	libxul.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:237
29 	libxul.so 	mozilla::ipc::MessagePump::Run 	MessagePump.cpp:82
30 	libxul.so 	mozilla::ipc::MessagePumpForChildProcess::Run 	MessagePump.cpp:231
31 	libxul.so 	MessageLoop::RunInternal 	message_loop.cc:215
32 	libxul.so 	MessageLoop::Run 	message_loop.cc:208
33 	libxul.so 	nsBaseAppShell::Run 	nsBaseAppShell.cpp:163
34 	libxul.so 	XRE_RunAppShell 	nsEmbedFunctions.cpp:646
35 	libxul.so 	mozilla::ipc::MessagePumpForChildProcess::Run 	MessagePump.cpp:198
36 	libxul.so 	MessageLoop::RunInternal 	message_loop.cc:215
37 	libxul.so 	MessageLoop::Run 	message_loop.cc:208
38 	libxul.so 	XRE_InitChildProcess 	nsEmbedFunctions.cpp:485 

More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort+|+NS_DebugBreak_P+|+mozilla%3A%3Alayers%3A%3ABasicShadowableThebesLayer%3A%3ACreateBuffer
blocking-b2g: tef? → ---
tracking-b2g18: --- → ?
There's more than 2 crashers from the time of the report.  Not sure, this may be the current top crasher in b2g right now.
Keywords: topcrash
Scoobidiver, let's not add the topcrash keyword for B2G-specific stuff right now as we don't have any criteria for that yet and B2G issues are well-tracked enough that we don't need that keyword at this time. This will change in the future, probably some time after we shipped this to the public.
Keywords: topcrash
Depends on: 837097
It is the second most top crasher for the week looking at all of b2g for the week.
It is the second most top crasher that has a decent stack for the week looking at all of b2g for the week.
It happens with a single user.
Re-nom if this shows up with more than one user affected. It could be a developer testing something.
Odd.  I don't see a manifest.webapp under the test directory.  I'm not sure where that came from.  I tried installing the mapwire app and it installed fine.

Steps in bug 650446 comment 0 are not reproducing the issue.
There have been no crashes since 18.0/20130212.
Duplicate of this bug: 837097
Firm STR is given in the dupe of this bug. The app associated with that bug is blocked in the review queue without this bug fixed, which might warrant blocking on this for leo. It's too late for tef, however.
blocking-b2g: --- → leo?
Keywords: reproducible
Component: General → Graphics: Layers
Product: Boot2Gecko → Core
Version: unspecified → Trunk
No longer depends on: 837097
Version: Trunk → 18 Branch
It looks like just the one app that triggers this (and seemingly not 100% of the time) and now that bug 840290 is fixed, the affected app was reviewed and is now in the marketplace.  Without another active, 100% reproducible case there's no reason to block here, we'll have to gather more crash data and see if we can uncover a broader root issue before we can assign resources to this.
blocking-b2g: leo? → -
Keywords: qawanted
(In reply to Lukas Blakk [:lsblakk] from comment #12)
> It looks like just the one app that triggers this (and seemingly not 100% of
> the time) and now that bug 840290 is fixed, the affected app was reviewed
> and is now in the marketplace.  Without another active, 100% reproducible
> case there's no reason to block here, we'll have to gather more crash data
> and see if we can uncover a broader root issue before we can assign
> resources to this.

Completely wrong. The app does consistently 100% reproduce this and this app was not pushed publicly to marketplace. It's still blocked on this getting fixed. Back to nom.
blocking-b2g: - → leo?
Removing qawanted as there's clear STR in the dupe.
Keywords: qawanted
Also note - we can't rely on crash metrics too much on b2g for analysis due to low user volume.
Blocking+ for investigation, due to ability of web content to force a Gaia crash/restart.
blocking-b2g: leo? → leo+
HI Peter, please help with this one.
Assignee: nobody → pchang
Can't reproduce crash issue from bug 837097 in my unagi device.

But I found the height/width were very strange during back buffer creation.
(Creating ThebesLayer 'back buffer' failed! width=2621440, height=2064384, type=3000)

I tried to hack one app and created the same size of back buffer. I saw the same crash issue and gaia restarted.

The crash was caused by the following NS_RUNTIMEABORT code because unexpected backbuffer allocation failed.

Need app owner to check why they are trying to create the large buffer for display.
And we can check NS_RUNTIMEABORT is needed or not when buffer creation failed.

[Code]
  if (!BasicManager()->AllocBuffer(gfxIntSize(aSize.width, aSize.height),
                                   aType,
                                   &mBackBuffer)) {
    enum { buflen = 256 };
    char buf[buflen];
    PR_snprintf(buf, buflen,
                "creating ThebesLayer 'back buffer' failed! width=%d, height=%d, type=%x",
                aSize.width, aSize.height, int(aType));
    NS_RUNTIMEABORT(buf);
  }
need info on app owner to address the above comment
Flags: needinfo?(mael.lavault)
Correct information on comment 18.

Both b2g and app(content) processes will try to allocate buffer by invoking above AllocBuffer call.

If content process fails to allocate buffer then only the content process restarts.
But if b2f fails to allocate buffer then b2g process restarts.

Which case did you see?
You should look at the leaflet library, it seems that this is where the buffer is created.
Flags: needinfo?(mael.lavault)
Whiteboard: [b2g-crash] → [b2g-crash][apps watch list]
(In reply to pchang from comment #20)
> Correct information on comment 18.
> 
> Both b2g and app(content) processes will try to allocate buffer by invoking
> above AllocBuffer call.
> 
> If content process fails to allocate buffer then only the content process
> restarts.
> But if b2f fails to allocate buffer then b2g process restarts.
> 
> Which case did you see?

https://bugzilla.mozilla.org/show_bug.cgi?id=837097#c0 from the developer seems to imply that he was typically getting content crashes and occasionally a full b2g process crash.
I will look into leaflet library but I can't reproduce crash issue from bug 837097 in my unagi device. (Tried to search city on app main screen).

Is it easy to happen? Or need to use for a while.
Yeah it is really easy to happen. It works very rarely. Most of the time the app just crash and sometimes it makes gaia restart. Just try a few time it should happend ;)
Talked with Peter offline - both of us can't reproduce this crash at all. Renom to minus for tracking and blocking until we get better STR.
blocking-b2g: leo+ → leo?
Keywords: reproducible
Whiteboard: [b2g-crash][apps watch list] → [b2g-crash][apps watch list][closeme 4/3/2013]
Jason, I can work with Mael to get more information. Are you saying you need a new crash log with different debug information or ?? Thanks.
(In reply to Mark Coggins from comment #26)
> Jason, I can work with Mael to get more information. Are you saying you need
> a new crash log with different debug information or ?? Thanks.

The underlying problem is that both of us can't reproduce the crash with the packaged app (Cartes) provided. I believe the problem has to do with the app itself not entirely working that's preventing from getting to the point of when you hit the crash. When searching for a location in the app, I'm getting ajax errors that results in the location not being found.
Tracking+. Please request approval once a patch exists. Sounds like a narrower testcase would really help.

Blocking-. No patch, narrow affected group, no reproducibility.
blocking-b2g: leo? → leo+
I think you meant to minus?
blocking-b2g: leo+ → leo?
Flags: needinfo?(dietrich)
Ha, yes :)
Flags: needinfo?(dietrich)
correct to leo- per comment 30
blocking-b2g: leo? → -
I can't reproduce the crash anymore for some times now so I guess it has been fixed in a previous update.
case closed due to can't reproduce now
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.