949169 - [Monkey Test] IPC Crash on jb_gonk

Status: RESOLVED INCOMPLETE

(Core :: IPC, defect)

Description

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: crash.extra file

We are seeing IPC crash on FFOS 1.3 during monkey testing. I attached ".extra" file for it.

Comment 1

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: stack trace when crash happened

stack trace

Comment 2

[Sotaro Ikeda [:sotaro]]

Changed the component depends on attachment 8346155 [details].

Comment 3

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

gaia/gecko revisions where we saw it:

"gaia" last commit SHA1="1abda08e450cb66a61a31bdcfd3352e2df9d9ace"
"gecko" last commit SHA1="e5638ae70aad34961a65e6a51b15ffe2f3553b0d"

Comment 4

[Preeti Raghunath(:Preeti)]

Sotaro,

Can you please take a look here or reassign appropriately?

Comment 5

[Greg Grisco]

Test Steps:
1. Copied different format video to the phone.
2. Opened video application.
3. Played a video.
4. OS rebooted.

Comment 6

[Sotaro Ikeda [:sotaro]]

Greg, how often the crash happen? Which video are you using for test? H.264? WebM?

Comment 7

[Sotaro Ikeda [:sotaro]]

Grag, do you know the video format when the crash happens.

Comment 8

[Greg Grisco]

We've only seen this happen only once so far.  Not sure what video format it is, except that it's not webm because software decoder is not being used.

Comment 9

[Greg Grisco]

We've only seen this happen only once so far.  Not sure what video format it is, except that it's not webm because software decoder is not being used.

Comment 10

[Sotaro Ikeda [:sotaro]]

From attachment 8346155 [details], crash happened at shmem allocation. But hw codec uses only uses gralloc. So, from Comment 9, crash seems not directly related to video buffer.  

----------------------------------------------
 2  libxul.so!mozilla::ipc::Shmem::OpenExisting(mozilla::ipc::Shmem::IHadBetterBeIPDLCodeCallingThis_OtherwiseIAmADoodyhead, IPC::Message const&, int*, bool) [Shmem.cpp : 564 + 0x15]
 3  libxul.so!mozilla::layers::PCompositorParent::OnMessageReceived(IPC::Message const&) [PCompositorParent.cpp : 375 + 0x9

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

What's a good way to reproduce this?  Or do we just have the stack+code inspection to go on?  Nicolas, anything obvious from the stack?

Comment 12

[Nicolas Silva [:nical]]

(In reply to Milan Sreckovic [:milan] from comment #11)
> Nicolas, anything obvious from the stack?

I don't remember ever running into this assertion. As Sotaro points out, this is a shmem thing so it's very unlikely that it was caused by hardware-accelerated video decoding/compositing (H264 videos) which use gralloc.
Throwing wild uneducated guesses:
* could we have run out of memory and failed to allocate a shmem because of that?
* could we be asking for a huge shmem size (because of some unitialized variable, int overflow or whatnot)?

googling the error shows that this assertion has been hit in the past:
https://bugzilla.mozilla.org/show_bug.cgi?id=599059
https://bugzilla.mozilla.org/show_bug.cgi?id=548437

Comment 13

[Andrew Overholt [:overholt]]

Ben Turner and I just took a look at this.  It looks like it might just be an OOM situation.

If it's only happened once in monkey testing, does it need to remain a certification blocker?

Comment 14

[Michael Vines [:m1] [:evilmachines]]

Looking at our database we haven't seen the crash reproduce this year yet, so lets not spend more time here until it does