crash in mozilla::layers::PImageContainerChild::FatalError

NEW
Unassigned

Status

Firefox OS
General
--
critical
5 years ago
3 years ago

People

(Reporter: Scoobidiver (away), Unassigned)

Tracking

(Depends on: 1 bug, {crash})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [b2g-crash], crash signature)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
It has been hit by one user in B2G 18.0/20130415: bp-8cc9bf3a-b8d4-452e-a3f5-089982130415.

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::PImageContainerChild::FatalError 	PImageContainerChild.cpp:539
3 	libxul.so 	mozilla::layers::PImageContainerChild::Read 	PImageContainerChild.cpp:1047
4 	libxul.so 	mozilla::layers::PImageContainerChild::Read 	PImageContainerChild.cpp:652
5 	libxul.so 	mozilla::layers::PImageContainerChild::Read 	PImageContainerChild.cpp:845
6 	libxul.so 	mozilla::layers::PImageContainerChild::OnMessageReceived 	PImageContainerChild.cpp:392
7 	libxul.so 	mozilla::layers::PCompositorChild::OnMessageReceived 	PCompositorChild.cpp:637
8 	libxul.so 	mozilla::ipc::AsyncChannel::OnDispatchMessage 	AsyncChannel.cpp:473
9 	libxul.so 	mozilla::ipc::RPCChannel::OnMaybeDequeueOne 	RPCChannel.cpp:402
10 	libxul.so 	RunnableMethod<IPC::ChannelProxy::Context, void , Tuple0>::Run 	tuple.h:383
11 	libxul.so 	mozilla::ipc::RPCChannel::DequeueTask::Run 	RPCChannel.h:425
12 	libxul.so 	MessageLoop::RunTask 	message_loop.cc:334
13 	libxul.so 	MessageLoop::DeferOrRunPendingTask 	message_loop.cc:342
14 	libxul.so 	MessageLoop::DoWork 	message_loop.cc:442
15 	libxul.so 	base::MessagePumpDefault::Run 	message_pump_default.cc:23
16 	libxul.so 	MessageLoop::RunInternal 	message_loop.cc:216
17 	libxul.so 	MessageLoop::Run 	message_loop.cc:209
18 	libxul.so 	base::Thread::ThreadMain 	thread.cc:156
19 	libxul.so 	ThreadFunc 	platform_thread_posix.cc:39
20 	libc.so 	__thread_entry 	pthread.c:217
21 	libc.so 	pthread_create 	pthread.c:357 

More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort+|+NS_DebugBreak_P+|+mozilla%3A%3Alayers%3A%3APImageContainerChild%3A%3AFatalError
Inari Crash
(In reply to Scoobidiver from comment #0)
> More reports at:
> https://crash-stats.mozilla.com/report/
> list?signature=mozalloc_abort+|+NS_DebugBreak_P+|+mozilla%3A%3Alayers%3A%3API
> mageContainerChild%3A%3AFatalError

In the report, Thread 13 is camera thread. The thread was running the shut down task mozilla::ReleaseHardwareTask::Run() and releasing the SurfaceDescriptorGralloc. 
- ImageBridgeChild::DeallocSurfaceDescriptorGralloc()
It seems that Parent side send the already deallocated GraphicBuffer by child side. This case was fixed in Bug 826829. There might be a case that Bug 826829 does handle.
(In reply to Sotaro Ikeda [:sotaro] from comment #3)
>There might be a case that Bug 826829 does handle.

Correction:
There might be a case that Bug 826829 does not handle.
Created attachment 747821 [details]
unagi weekly build 13.05.02 crash report

tara also has the same crash backtrace
Created attachment 747823 [details]
unagi weekly build 13.05.02 crash report 2
We can reproduce this issue, delete the video thumbnail by 'adb shell rm -r data/local/indexDB/*video*', then enter the video playback.
(In reply to Sotaro Ikeda [:sotaro] from comment #4)
> (In reply to Sotaro Ikeda [:sotaro] from comment #3)
> >There might be a case that Bug 826829 does handle.
> 
> Correction:
> There might be a case that Bug 826829 does not handle.

Sotaro, how to handle deallocated GraphicBuffer properly? Kill the thread which will crash?
(In reply to James Zhang from comment #8)
> Sotaro, how to handle deallocated GraphicBuffer properly?

GraphicBuffer is encapsulated by GrallocBufferActor. It is allocated in b2g process and delivered to content process. In camera preview's case, preview frames are deallocated by ImageBridgeChild::DeallocSurfaceDescriptorGralloc(). After the deletion, content process and b2g process should not use the GraphicBuffer(SurfaceDescriptor).

> Kill the thread which will crash?

I could not understand question. What are you asking about?
(In reply to Sotaro Ikeda [:sotaro] from comment #9)
> (In reply to James Zhang from comment #8)
> > Sotaro, how to handle deallocated GraphicBuffer properly?
> 
> GraphicBuffer is encapsulated by GrallocBufferActor. It is allocated in b2g
> process and delivered to content process. In camera preview's case, preview
> frames are deallocated by
> ImageBridgeChild::DeallocSurfaceDescriptorGralloc(). After the deletion,
> content process and b2g process should not use the
> GraphicBuffer(SurfaceDescriptor).
> 
> > Kill the thread which will crash?
> 
> I could not understand question. What are you asking about?

Sorry, my mistake, this comment should be attached in bug 868965.
In bug 868965, you can see the backtrace, when thread 0 is deallocing buffer, another thread which is reading buffer will crash. I mean how to prevent the reading buffer thread crash.
(Reporter)

Updated

4 years ago
Depends on: 868965, 886897

Comment 11

3 years ago
This issue could be reproduced in v1.4
When click video button continuously, camera app is crashed
You need to log in before you can comment on or make changes to this bug.