Closed Bug 945821 Opened 6 years ago Closed 6 years ago

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

Categories

(Firefox for Android :: Toolbar, defect)

All
Android
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 943392
Tracking Status
firefox26 --- unaffected
firefox27 + fixed
firefox28 + fixed
fennec 27+ ---

People

(Reporter: kbrosnan, Assigned: eflores)

Details

(Keywords: crash, topcrash-android-armv7, Whiteboard: [native-crash] [Fixed by Bug 943392])

Crash Data

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.
Tracking and NI, :milan & :blassey for some help with investigation on this OOM crasher. Based on crash-stats this is #2 on Fx27.0a2.
Flags: needinfo?(milan)
Flags: needinfo?(blassey.bugs)
Looks like a this is only about a month old, and related to video.  Nicolas, can you take a look?
Flags: needinfo?(milan) → needinfo?(nical.bugzilla)
Assignee: nobody → nical.bugzilla
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.
Assignee: nical.bugzilla → nobody
Flags: needinfo?(nical.bugzilla)
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!
Hey Paul, assigning to you so that this patch doesn't get forgotten. Feel free to reassign to someone who knows about this stuff :)
Assignee: nobody → paul
Flags: needinfo?(blassey.bugs)
Anthony, do you have someone that can look into this?
Flags: needinfo?(ajones)
(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.
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. ;-)
Assignee: paul → edwin
Flags: needinfo?(ajones)
tracking-fennec: ? → 27+
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.
Flags: needinfo?(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
Severity: critical → normal
Flags: needinfo?(edwin)
(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.
Whiteboard: [native-crash] → [native-crash] [Fixed by Bug 943392]
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 943392
You need to log in before you can comment on or make changes to this bug.