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

Reporter

Description

•

11 years ago

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

Jason Smith [:jsmith]

Updated

•

11 years ago

blocking-b2g: tef? → ---

tracking-b2g18: --- → ?

Naoki Hirata :nhirata (please use needinfo instead of cc)

Comment 1

•

11 years ago

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.

Scoobidiver (away)

Reporter

Updated

•

11 years ago

Keywords: topcrash

Robert Kaiser

Comment 2

•

11 years ago

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

Scoobidiver (away)

Reporter

Updated

•

11 years ago

Depends on: 837097

Naoki Hirata :nhirata (please use needinfo instead of cc)

Comment 3

•

11 years ago

It is the second most top crasher for the week looking at all of b2g for the week.

Naoki Hirata :nhirata (please use needinfo instead of cc)

Comment 4

•

11 years ago

It is the second most top crasher that has a decent stack for the week looking at all of b2g for the week.

Scoobidiver (away)

Reporter

Comment 5

•

11 years ago

It happens with a single user.

Lukas Blakk [:lsblakk] use ?needinfo

Comment 6

•

11 years ago

Re-nom if this shows up with more than one user affected. It could be a developer testing something.

tracking-b2g18: ? → -

Naoki Hirata :nhirata (please use needinfo instead of cc)

Comment 7

•

11 years ago

http://www.mapwire.net/manifest.webap
app://test/manifest.webapp

Naoki Hirata :nhirata (please use needinfo instead of cc)

Comment 8

•

11 years ago

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.

Scoobidiver (away)

Reporter

Comment 9

•

11 years ago

There have been no crashes since 18.0/20130212.

Jason Smith [:jsmith]

Comment 11

•

11 years ago

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?

tracking-b2g18: - → ?

Keywords: reproducible

Jason Smith [:jsmith]

Updated

•

11 years ago

Component: General → Graphics: Layers

Product: Boot2Gecko → Core

Version: unspecified → Trunk

Scoobidiver (away)

Reporter

Updated

•

11 years ago

No longer depends on: 837097

Version: Trunk → 18 Branch

Lukas Blakk [:lsblakk] use ?needinfo

Comment 12

•

11 years ago

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? → -

tracking-b2g18: ? → -

Keywords: qawanted

Jason Smith [:jsmith]

Comment 13

•

11 years ago

(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?

tracking-b2g18: - → ?

Jason Smith [:jsmith]

Comment 14

•

11 years ago

Removing qawanted as there's clear STR in the dupe.

Keywords: qawanted

Jason Smith [:jsmith]

Comment 15

•

11 years ago

Also note - we can't rely on crash metrics too much on b2g for analysis due to low user volume.

Dietrich Ayala (:dietrich)

Comment 16

•

11 years ago

Blocking+ for investigation, due to ability of web content to force a Gaia crash/restart.

blocking-b2g: leo? → leo+

tracking-b2g18: ? → +

Wayne Chang [:wchang]

Comment 17

•

11 years ago

HI Peter, please help with this one.

Assignee: nobody → pchang

Peter Chang[:pchang]

Assignee

Comment 18

•

11 years ago

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);
  }

Jason Smith [:jsmith]

Comment 19

•

11 years ago

need info on app owner to address the above comment

Flags: needinfo?(mael.lavault)

Peter Chang[:pchang]

Assignee

Comment 20

•

11 years ago

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?

Maël Lavault

Comment 21

•

11 years ago

You should look at the leaflet library, it seems that this is where the buffer is created.

Flags: needinfo?(mael.lavault)

Mark Coggins

Updated

•

11 years ago

Whiteboard: [b2g-crash] → [b2g-crash][apps watch list]

Jason Smith [:jsmith]

Comment 22

•

11 years ago

(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.

Peter Chang[:pchang]

Assignee

Comment 23

•

11 years ago

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.

Maël Lavault

Comment 24

•

11 years ago

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 ;)

Jason Smith [:jsmith]

Comment 25

•

11 years ago

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?

tracking-b2g18: + → ?

Keywords: reproducible

Whiteboard: [b2g-crash][apps watch list] → [b2g-crash][apps watch list][closeme 4/3/2013]

Mark Coggins

Comment 26

•

11 years ago

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.

Jason Smith [:jsmith]

Comment 27

•

11 years ago

(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.

Dietrich Ayala (:dietrich)

Comment 28

•

11 years ago

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+

tracking-b2g18: ? → +

Jason Smith [:jsmith]

Comment 29

•

11 years ago

I think you meant to minus?

blocking-b2g: leo+ → leo?

Flags: needinfo?(dietrich)

Dietrich Ayala (:dietrich)

Comment 30

•

11 years ago

Ha, yes :)

Flags: needinfo?(dietrich)

Joe Cheng [:jcheng] (please needinfo)

Comment 31

•

11 years ago

correct to leo- per comment 30

blocking-b2g: leo? → -

Maël Lavault

Comment 32

•

11 years ago

I can't reproduce the crash anymore for some times now so I guess it has been fixed in a previous update.

Peter Chang[:pchang]

Assignee

Comment 33

•

11 years ago

case closed due to can't reproduce now

Status: NEW → RESOLVED

Closed: 11 years ago

Resolution: --- → WORKSFORME