945821 - crash in mozalloc_abort(char const*) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | mozilla::layers::MemoryTextureClient::Allocate(unsigned int)

Status: RESOLVED DUPLICATE of bug 943392

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[Kevin Brosnan [Ex-Mozilla]]

This bug was filed from the Socorro interface and is 
report bp-42de1433-4a40-414a-b56f-e299a2131202.
=============================================================

Not much to go on at this time. One comment is saying this happens on HTML video content such as YouTube. Does not seem to be device or Android version specific. First crash was seen on 2013-10-05.

Comment 1

[bhavana bajaj [:bajaj]]

Tracking and NI, :milan & :blassey for some help with investigation on this OOM crasher. Based on crash-stats this is #2 on Fx27.0a2.

Comment 2

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

Looks like a this is only about a month old, and related to video.  Nicolas, can you take a look?

Comment 3

[Nicolas Silva [:nical]]

The crash is an OOM that is happening while allocating a buffer for to hold a video frame, which is not surprising, because we typically use a lot of memory when playing a video (we are keeping 10 decoded images in the VideoQueue + 1 that is on the compositor side, per video).
I verified we are not leaking TextureClients nor their buffer data (at least not in the video code paths that we seem to be using here).

However, interestingly, if you go to a web page with an video element like this one people.mozilla.org/~nsilva/video.html 
and do the following steps repetitively:
1) tap the address bar
2) tap the arrow on the top right to reload the page
3) repeat the steps above a few times

We don't garbage collect the VideoQueue for a looong while. so every time you reload the page we add ~11 video frames in memory. They are not actually leaked because if you lock the phone's screen and come back to firefox it usually triggers the GC/CC and the VideoQueue + textures are freed.

It doesn't have to be refreshing the same page, you can go from a page to another and have the same behavior.
It is very easily get to more than 100 frames in memory.

So it could be that we need to be more aggressive in letting go of the HTMLMediaElement or whatever is keeping the VideoQueue alive.

Anyway I think this doesn't belong to gfx. Maybe someone that knows media and/or dom can help here.

Comment 4

[Nicolas Silva [:nical]]

Note that I recently landed a patch that makes MemoryTextureClient use a fallible allocator, so this crash will not reproduce with the same symtoms (instead we will most likely miss video frames and OOM somewhere else).
But I believe that keeping that many VideoQueues alive is a problem!

Comment 5

[Nicolas Silva [:nical]]

Hey Paul, assigning to you so that this patch doesn't get forgotten. Feel free to reassign to someone who knows about this stuff :)

Comment 6

[Paul Adenot (:padenot)]

Anthony, do you have someone that can look into this?

Comment 7

[Robert Kaiser]

(In reply to Nicolas Silva [:nical] from comment #3)
> The crash is an OOM that is happening while allocating a buffer for to hold
> a video frame, which is not surprising, because we typically use a lot of
> memory when playing a video (we are keeping 10 decoded images in the
> VideoQueue + 1 that is on the compositor side, per video).

But... do we really need to crash the process just because a video is too large? Feels to me like it should just "gracefully" fail and not play the video.

Comment 8

[Robert Kaiser]

Actually, thinking about it, does comment #4 actually answer my question in comment #7?

That said, the not-really-leak is surely something useful to work on here. ;-)

Comment 9

[bhavana bajaj [:bajaj]]

NI on Edwin, to see if he has a chance to investigate this bug and what the next steps are, to get this top-crasher resolved before shipping Firefox 27.

Comment 10

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

This is no longer a crash after [1].

I'm planning on writing a patch to clear video queues when a page is hidden; keeping this bug open as a reminder.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=943392#c12

Comment 11

[bhavana bajaj [:bajaj]]

(In reply to Edwin Flores [:eflores] [:edwin] from comment #10)
> This is no longer a crash after [1].
> 
> I'm planning on writing a patch to clear video queues when a page is hidden;
> keeping this bug open as a reminder.
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=943392#c12

Thanks, this bug was mainly tracked for it being a top-crasher and release management typically uses tracking flags to keep track of release blockers. Given this was already fixed I am marking the status flag accordingly so this is off our worry list for Fx27.

Can you please use a white board tag or some other mechanism so this does not fall of your radar.