Closed
Bug 696013
Opened 15 years ago
Closed 15 years ago
Nightly crashes @ mozilla::layers::BasicShadowCanvasLayer::DestroyFrontBuffer
Categories
(Core :: Graphics, defect)
Tracking
()
VERIFIED
FIXED
mozilla10
| Tracking | Status | |
|---|---|---|
| firefox10 | --- | fixed |
People
(Reporter: xti, Assigned: romaxa)
References
()
Details
(Keywords: crash, reproducible, Whiteboard: [mobile-crash], [inbound])
Crash Data
Attachments
(1 file, 3 obsolete files)
Build ID: Mozilla/5.0 (Android;Linux armv7l;rv:10.0a1)Gecko/20111019
Firefox/10.0a1 Fennec/10.0a1
Devices: Samsung Galaxy S, HTC Desire Z
OS: Android 2.2, Android 2.3.3
Steps to reproduce:
1. Open Fennec App
2. Browse to http://randomibis.com/coolclock/
3. Let the page opened for a couple of minutes
Expected result:
After step 3, nothing should happen.
Actual result:
After step 3, Fennec will crash.
Notes:
- this issue is reproducible always only if JavaScript is enabled.
- if sync is connected before step 2, it will be disconnected when the app will reopen back after the crash.
- here are some crash reports:
https://crash-stats.mozilla.com/report/index/bp-dcf9a9c0-6566-4b03-876a-c0f2c2111020
https://crash-stats.mozilla.com/report/index/bp-f5f86f15-efae-4790-8857-add622111020
https://crash-stats.mozilla.com/report/index/bp-f5f324d6-7b32-4ff6-9b46-116372111020
https://crash-stats.mozilla.com/report/index/bp-43c057b8-6dda-4dab-860e-1e1892111020
Crashing Thread
Frame Module Signature [Expand] Source
0 libxul.so mozilla::layers::BasicShadowCanvasLayer::DestroyFrontBuffer gfx/layers/basic/BasicLayers.cpp:3025
1 libxul.so mozilla::layers::BasicShadowCanvasLayer::~BasicShadowCanvasLayer gfx/layers/basic/BasicLayers.cpp:3011
2 libxul.so mozilla::layers::BasicShadowCanvasLayer::~BasicShadowCanvasLayer mozalloc.h:253
3 libxul.so mozilla::layers::Layer::Release Layers.h:544
4 libxul.so mozilla::layers::ContainerRemoveChild<mozilla::layers::BasicShadowContainerLayer> gfx/layers/basic/BasicLayers.cpp:403
5 libxul.so mozilla::layers::BasicShadowContainerLayer::~BasicShadowContainerLayer gfx/layers/basic/BasicLayers.cpp:2852
6 libxul.so mozilla::layers::BasicShadowContainerLayer::~BasicShadowContainerLayer mozalloc.h:253
7 libxul.so mozilla::layers::Layer::Release Layers.h:544
8 libxul.so mozilla::layers::ContainerRemoveChild<mozilla::layers::BasicContainerLayer> gfx/layers/basic/BasicLayers.cpp:403
9 libxul.so mozilla::layers::BasicContainerLayer::~BasicContainerLayer gfx/layers/basic/BasicLayers.cpp:290
10 libxul.so mozilla::layers::BasicShadowableContainerLayer::~BasicShadowableContainerLayer gfx/layers/basic/BasicLayers.cpp:2111
11 libxul.so mozilla::layers::BasicShadowableContainerLayer::~BasicShadowableContainerLayer mozalloc.h:253
12 libxul.so mozilla::layers::Layer::Release Layers.h:544
13 libxul.so mozilla::layers::ContainerRemoveChild<mozilla::layers::BasicContainerLayer> gfx/layers/basic/BasicLayers.cpp:403
14 libxul.so mozilla::layers::BasicShadowableContainerLayer::RemoveChild gfx/layers/basic/BasicLayers.cpp:2153
15 libxul.so mozilla::FrameLayerBuilder::BuildContainerLayerFor layout/base/FrameLayerBuilder.cpp:1630
16 libxul.so nsDisplayList::PaintForFrame layout/base/nsDisplayList.cpp:598
17 libxul.so nsDisplayList::PaintRoot layout/base/nsDisplayList.cpp:539
18 libxul.so nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:1701
19 libxul.so PresShell::Paint layout/base/nsPresShell.cpp:5390
20 libxul.so nsViewManager::RenderViews view/src/nsViewManager.cpp:417
21 libxul.so nsViewManager::Refresh view/src/nsViewManager.h:238
22 libxul.so nsViewManager::DispatchEvent nsCOMPtr.h:515
23 libxul.so HandleEvent nsCOMPtr.h:515
24 libxul.so nsWindow::DispatchEvent widget/src/android/nsWindow.cpp:632
25 libxul.so nsWindow::DrawTo widget/src/android/nsWindow.cpp:933
26 libxul.so nsWindow::DrawTo widget/src/android/nsWindow.cpp:970
27 libxul.so nsWindow::OnDraw widget/src/android/nsWindow.cpp:1077
28 libxul.so nsWindow::OnGlobalAndroidEvent widget/src/android/nsWindow.cpp:837
29 libxul.so nsAppShell::ProcessNextNativeEvent widget/src/android/nsAppShell.cpp:408
30 libxul.so nsBaseAppShell::DoProcessNextNativeEvent widget/src/xpwidgets/nsBaseAppShell.cpp:172
31 libxul.so nsBaseAppShell::OnProcessNextEvent widget/src/xpwidgets/nsBaseAppShell.cpp:312
32 libxul.so mozilla::dom::ContentParent::OnProcessNextEvent dom/ipc/ContentParent.cpp:1144
33 libxul.so nsThread::ProcessNextEvent nsTArray.h:170
34 libxul.so NS_ProcessNextEvent_P obj-firefox/xpcom/build/nsThreadUtils.cpp:245
35 libxul.so nsXMLHttpRequest::Send content/base/src/nsXMLHttpRequest.cpp:2559
36 libxul.so nsIXMLHttpRequest_Send obj-firefox/js/src/xpconnect/src/dom_quickstubs.cpp:28459
37 libxul.so js::Interpret js/src/jscntxtinlines.h:298
38 libxul.so js::RunScript js/src/jsinterp.cpp:585
39 libxul.so js::InvokeKernel js/src/vm/Stack.h:984
40 libxul.so js_fun_apply js/src/vm/Stack.h:289
41 libxul.so js::Interpret js/src/jscntxtinlines.h:298
42 libxul.so js::RunScript js/src/jsinterp.cpp:585
43 libxul.so js::Invoke js/src/vm/Stack.h:984
44 libxul.so JS_CallFunctionValue js/src/jscntxt.h:1242
45 libxul.so nsXPCWrappedJSClass::CallMethod js/src/xpconnect/src/xpcwrappedjsclass.cpp:1662
46 libxul.so nsXPCWrappedJS::CallMethod js/src/xpconnect/src/xpcwrappedjs.cpp:586
47 libxul.so PrepareAndDispatch xpcom/reflect/xptcall/src/md/unix/xptcstubs_arm.cpp:133
48 libxul.so libxul.so@0x96330c
49 libxul.so NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/unix/xptcinvoke_arm.cpp:195
50 libxul.so XPCConvert::JSData2Native js/src/xpconnect/src/xpcconvert.cpp:634
51 libxul.so XPCWrappedNative::CallMethod js/src/xpconnect/src/xpcwrappednative.cpp:3148
52 libxul.so XPC_WN_CallMethod js/src/xpconnect/src/xpcwrappednativejsops.cpp:1629
53 libxul.so js::Interpret js/src/jscntxtinlines.h:298
54 libxul.so js::RunScript js/src/jsinterp.cpp:585
55 libxul.so js::Invoke js/src/vm/Stack.h:984
56 libxul.so JS_CallFunctionValue js/src/jscntxt.h:1242
57 libxul.so nsJSContext::CallEventHandler dom/base/nsJSEnvironment.cpp:1947
58 libxul.so nsGlobalWindow::RunTimeout nsCOMPtr.h:896
59 libxul.so nsGlobalWindow::TimerCallback nsAutoPtr.h:907
60 libxul.so nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:425
61 libxul.so nsTimerEvent::Run nsAutoPtr.h:907
62 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:631
63 libxul.so NS_ProcessNextEvent_P obj-firefox/xpcom/build/nsThreadUtils.cpp:245
64 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:111
65 libxul.so MessageLoop::RunInternal ipc/chromium/src/base/message_loop.cc:209
66 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:487
67 libxul.so nsBaseAppShell::Run widget/src/xpwidgets/nsBaseAppShell.cpp:191
68 libxul.so nsAppStartup::Run toolkit/components/startup/nsAppStartup.cpp:229
69 libxul.so XRE_main toolkit/xre/nsAppRunner.cpp:3583
70 libxul.so Java_org_mozilla_gecko_GeckoAppShell_nativeRun toolkit/xre/nsAndroidStartup.cpp:132
71 libmozutils.so Java_org_mozilla_gecko_GeckoAppShell_nativeRun other-licenses/android/APKOpen.cpp:232
72 libdvm.so dvmPlatformInvoke
73 libdvm.so dvmCallJNIMethod_general
74 libdvm.so dvmResolveNativeMethod
75 libdvm.so dvmAsmSisterStart
76 libdvm.so dvmMterpStd
77 libdvm.so dvmInterpret
78 libdvm.so dvmCallMethodV
79 libdvm.so dvmCallMethod
80 libdvm.so dvmDetachCurrentThread
81 libc.so __thread_entry
82 libc.so pthread_create
Severity: normal → critical
Crash Signature: [@ mozilla::layers::BasicShadowCanvasLayer::DestroyFrontBuffer ]
Component: General → Graphics
Keywords: crash
Product: Fennec → Core
QA Contact: general → thebes
Whiteboard: [mobile-crash]
Updated•15 years ago
|
status-firefox10:
--- → affected
Keywords: reproducible
Updated•15 years ago
|
tracking-fennec: --- → ?
Keywords: regressionwindow-wanted
Starting from the 27th: does not crash for the 9/27th build.
crash-stats indicates that there was a crash for 10/05th build.
28th is when the switch over from Fennec 9 and Fennec 10 occured.
9/28th does not crash; 10/05th build does crash. Still need to find regression range between them.
| Assignee | ||
Comment 3•15 years ago
|
||
Could be bug 689045, but need to double check
| Assignee | ||
Comment 4•15 years ago
|
||
hmm, tested it on maemo with latest inbound, and don't see any crash, also tested by moving fennec to background (release layers tree) and still cannot reproduce
| Assignee | ||
Comment 5•15 years ago
|
||
Ok, got it reproducible..
We are leaking SurfaceDescriptors
| Assignee | ||
Comment 6•15 years ago
|
||
Ok, found where is the problem...
seems after each canvas update we do destroy layers tree...
#0 mozilla::layers::BasicShadowCanvasLayer::Disconnect (this=0x3af17510)
at gfx/layers/basic/BasicLayers.cpp:3033
#1 0x3c2a4c24 in mozilla::layers::ShadowLayerParent::ActorDestroy (this=0x40652180,
why=mozilla::ipc::IProtocolManager<mozilla::ipc::RPCChannel::RPCListener>::Deletion)
at gfx/layers/ipc/ShadowLayerParent.cpp:93
#2 0x3c17161c in mozilla::layers::PLayerParent::DestroySubtree (this=0x40652180,
why=mozilla::ipc::IProtocolManager<mozilla::ipc::RPCChannel::RPCListener>::Deletion)
at obj-build/ipc/ipdl/PLayerParent.cpp:315
And that is calling Disconnect before destructor.
Each paint has next func calls order:
BasicShadowableCanvasLayer::BasicShadowableCanvasLayer(mozilla::layers::BasicShadowLayerManager*)::2580
BasicShadowableCanvasLayer::Paint(gfxContext*)::2666 Alloc Surf:[300,300]
BasicShadowCanvasLayer::BasicShadowCanvasLayer(mozilla::layers::BasicShadowLayerManager*)::3023
BasicShadowCanvasLayer::Swap(const mozilla::layers::CanvasSurface&, bool, mozilla::layers::CanvasSurface*)::3081 sz[300,300]->[0,0]
BasicShadowCanvasLayer::DestroyFrontBuffer()::3050 front:0
BasicShadowLayerManager::ForwardTransaction()::3357
BasicShadowableCanvasLayer::SetBackBuffer(const mozilla::layers::SurfaceDescriptor&)::2603 SetBack:[300,300]
BasicShadowableCanvasLayer::~BasicShadowableCanvasLayer()::2585
BasicShadowableCanvasLayer::DestroyBackBuffer()::2621 No Destroy Back:[300,300], type:0
BasicShadowCanvasLayer::Disconnect()::3035
BasicShadowCanvasLayer::DestroyFrontBuffer()::3046
BasicShadowCanvasLayer::~BasicShadowCanvasLayer()::3028
BasicShadowCanvasLayer::DestroyFrontBuffer()::3050 front:0
Before it was not reproducible because we were destroying front buffer from
BasicShadowableCanvasLayer::~BasicShadowableCanvasLayer
IIRC cjones was saying that Disconnect happen only in extra cases... when everything is dying... but it seems not
| Assignee | ||
Comment 7•15 years ago
|
||
| Assignee | ||
Comment 8•15 years ago
|
||
another question is why we destroy CanvasLayer after each paint (clock tik) here?
I don't know. Is it only this testcase?
On the compositor side (Shadow*Layer), Disconnect() is normal. On the content side (Shadowable*Layer), Disconnect() is not normal. Should be documented in BasicLayers.cpp.
| Assignee | ||
Comment 11•15 years ago
|
||
I tried some other clock example and same happening there
http://www.neilwallis.com/projects/html5/clock/index.php
| Assignee | ||
Comment 12•15 years ago
|
||
Ok, then I guess we should also destroy Front buffers for all Shadow disconnects.
Attachment #568517 -
Attachment is obsolete: true
Attachment #568517 -
Flags: review?(jones.chris.g)
Attachment #568550 -
Flags: review?(jones.chris.g)
| Reporter | ||
Comment 13•15 years ago
|
||
This issue doesn't occur on:
Build ID : Mozilla /5.0 (Android;Linux armv7l;rv:10.0a1) Gecko/20110929 Firefox/10.0a1 Fennec/10.0a1
http://hg.mozilla.org/mozilla-central/rev/cb4b93331e4f
but it occurs on:
Build ID : Mozilla /5.0 (Android;Linux armv7l;rv:10.0a1) Gecko/20110930 Firefox/10.0a1 Fennec/10.0a1
http://hg.mozilla.org/mozilla-central/rev/b5b082d183d0
Possible range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cb4b93331e4f&tochange=b5b082d183d0
| Reporter | ||
Updated•15 years ago
|
Keywords: regressionwindow-wanted
Comment on attachment 568550 [details] [diff] [review]
Fix proposal, for canvas and other shadow layers buffer leak
> virtual ~BasicShadowThebesLayer()
> {
> // If Disconnect() wasn't called on us, then we assume that the
> // remote side shut down and IPC is disconnected, so we let IPDL
> // clean up our front surface Shmem.
>+ DestroyFrontBuffer();
As the comment says, Disconnect() is the normal path. If we get to
the dtor with a valid buffer, then it's because the content process
crashed and it's somewhat dangerous to try to free the buffer here.
IPDL will do it automatically as part of the cleanup path. As the
comment says. Remove the DestroyFrontBuffer() call here.
>@@ -2900,32 +2901,34 @@ class BasicShadowImageLayer : public Sha
> public:
> BasicShadowImageLayer(BasicShadowLayerManager* aLayerManager) :
> ShadowImageLayer(aLayerManager, static_cast<BasicImplData*>(this))
> {
> MOZ_COUNT_CTOR(BasicShadowImageLayer);
> }
> virtual ~BasicShadowImageLayer()
> {
>+ DestroyFrontBuffer();
Remote this too.
> virtual void DestroyFrontBuffer()
> {
> if (mAllocator && IsSurfaceDescriptorValid(mFrontBuffer)) {
> mAllocator->DestroySharedSurface(&mFrontBuffer);
>+ mFrontBuffer = SurfaceDescriptor();
This is unnecessary; DestroySharedSurface() "nulls" this descriptor.
> virtual void DestroyFrontBuffer()
> {
> if (IsSurfaceDescriptorValid(mFrontSurface)) {
> mAllocator->DestroySharedSurface(&mFrontSurface);
>+ mFrontSurface = SurfaceDescriptor();
Same here.
Attachment #568550 -
Flags: review?(jones.chris.g)
| Assignee | ||
Comment 15•15 years ago
|
||
Attachment #568550 -
Attachment is obsolete: true
Attachment #569589 -
Flags: review?(jones.chris.g)
Comment on attachment 569589 [details] [diff] [review]
Fix for canvas and other shadow layers buffer leak
> virtual void DestroyFrontBuffer()
> {
> if (mAllocator && IsSurfaceDescriptorValid(mFrontBuffer)) {
> mAllocator->DestroySharedSurface(&mFrontBuffer);
>+ mFrontBuffer = SurfaceDescriptor();
This isn't necessary.
r=me with nitfix.
Attachment #569589 -
Flags: review?(jones.chris.g) → review+
| Assignee | ||
Updated•15 years ago
|
Keywords: checkin-needed
Comment 18•15 years ago
|
||
Keywords: checkin-needed
Whiteboard: [mobile-crash] → [mobile-crash], [inbound]
Comment 19•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
| Reporter | ||
Comment 20•15 years ago
|
||
Verified fixed on:
Mozilla/5.0 (Android;Linux armv7l;rv:10.0a1)Gecko/20111031
Firefox/10.0a1 Fennec/10.0a1
Devices: LG Optimus 2X
OS: Android 2.2
Status: RESOLVED → VERIFIED
Updated•12 years ago
|
tracking-fennec: ? → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•