862230 - crash in mozilla::layers::PImageContainerChild::FatalError

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Scoobidiver (away)]

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

Comment 1

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

Inari Crash

Comment 2

[Sotaro Ikeda [:sotaro]]

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

Comment 3

[Sotaro Ikeda [:sotaro]]

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.

Comment 4

[Sotaro Ikeda [:sotaro]]

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

Comment 5

[James Zhang (Spreadtrum)]

Attachment: unagi weekly build 13.05.02 crash report

tara also has the same crash backtrace

Comment 6

[James Zhang (Spreadtrum)]

Attachment: unagi weekly build 13.05.02 crash report 2

Comment 7

[James Zhang (Spreadtrum)]

We can reproduce this issue, delete the video thumbnail by 'adb shell rm -r data/local/indexDB/*video*', then enter the video playback.

Comment 8

[James Zhang (Spreadtrum)]

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

Comment 9

[Sotaro Ikeda [:sotaro]]

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

Comment 10

[James Zhang (Spreadtrum)]

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

Comment 11

[jongsoo.oh]

This issue could be reproduced in v1.4
When click video button continuously, camera app is crashed

Comment 12

[BMO Automation]

Firefox OS is not being worked on