Closed Bug 1151930 Opened 5 years ago Closed 5 years ago

Firefox Nightly and Aurora crash with deferred rendering WebGL demos (OOM)

Categories

(Core :: Canvas: WebGL, defect)

39 Branch
All
Windows 7
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla40
Tracking Status
firefox38 --- unaffected
firefox39 + verified
firefox40 + verified

People

(Reporter: postfilter, Assigned: jgilbert)

Details

(Keywords: regression)

Crash Data

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150407030207

Steps to reproduce:

Visit some of the XG deferred rendering demos with latest Firefox Nightly or Firefox Developer Edition, for example:

http://alteredqualia.com/xg/examples/deferred_skin.html
http://alteredqualia.com/xg/examples/animation_physics_terrain.html

Tested on:

Firefox Nightly 40.0a1 (2015-04-07)
Firefox Developer Edition (Aurora) 39.0a2 (2015-04-07)


Actual results:

Firefox crashed, closed itself and opened Mozilla Crash Reporter.


Expected results:

No crashes should happen.

These crashes seem to differ from some other WebGL crashes reported elsewhere:

https://bugzilla.mozilla.org/show_bug.cgi?id=1125466
https://bugzilla.mozilla.org/show_bug.cgi?id=1147447
https://bugzilla.mozilla.org/show_bug.cgi?id=1124427

Differences from other crash reports:

- both ANGLE and OpenGL WebGL rendering backends crash
- both notebooks with Optimus (Nvidia GTX 970M) and without Optimus (Nvidia Quadro 2000M) crash
- crashes happen on Windows 7 64-bit and Windows 8 64-bit
- crashes happen both with and without E10S flag enabled
- non-deferred XG demos do work, e.g.:

http://alteredqualia.com/xg/examples/forward_materials_skin_jonas.html
Crashes in Nightly 40.0a1 for me also, ok in FF 37.0.1

Windows 10 64bit (build 10049) iMac NVIDIA GeForce GTX 660M
I confirm this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I made a dumb in a previous patch. Oops.
Assignee: nobody → jgilbert
Status: NEW → ASSIGNED
Attachment #8589289 - Flags: review?(dglastonbury)
Hardware: x86 → All
Summary: Firefox Nightly and Aurora crash with deferred rendering WebGL demos → Firefox Nightly and Aurora crash with deferred rendering WebGL demos (OOM)
Version: 35 Branch → 39 Branch
With e10s enabled, it killed my computer, I needed to hard reboot.
Crash Signature: [@ OOM | large | mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity(unsigned int, unsigned int) | nsTArray_Impl<mozilla::WebGLFramebu…
Keywords: regression
Comment on attachment 8589289 [details] [diff] [review]
0001-Check-against-updated-length-while-appending.patch

Review of attachment 8589289 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/canvas/WebGLFramebuffer.cpp
@@ -829,5 @@
>      if (colorAttachmentId < ColorAttachmentCount())
>          return;
>  
> -    size_t colorAttachmentCount = ColorAttachmentCount();
> -    while (colorAttachmentCount < WebGLContext::kMaxColorAttachments) {

WAT? I hope I didn't write that.

@@ +834,1 @@
>          mMoreColorAttachments.AppendElement(AttachPoint(this, nextAttachPoint));

Why don't we just allocate this array at context creation time?
Attachment #8589289 - Flags: review?(dglastonbury) → review+
(In reply to Dan Glastonbury :djg :kamidphish from comment #6)
> Comment on attachment 8589289 [details] [diff] [review]
> 0001-Check-against-updated-length-while-appending.patch
> 
> Review of attachment 8589289 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/canvas/WebGLFramebuffer.cpp
> @@ -829,5 @@
> >      if (colorAttachmentId < ColorAttachmentCount())
> >          return;
> >  
> > -    size_t colorAttachmentCount = ColorAttachmentCount();
> > -    while (colorAttachmentCount < WebGLContext::kMaxColorAttachments) {
> 
> WAT? I hope I didn't write that.
> 
> @@ +834,1 @@
> >          mMoreColorAttachments.AppendElement(AttachPoint(this, nextAttachPoint));
> 
> Why don't we just allocate this array at context creation time?
We can do it after GL initialization, but not before. It should probably be a UniquePtr<Foo[]> though.
https://hg.mozilla.org/mozilla-central/rev/7658ee66cba9
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Tracking for 39+ since this is a recent regression.
QA Whiteboard: [good first verify]
Jeff, from the bug summary it looks like this also affects 39. Is this something that you may want to uplift to aurora?
Flags: needinfo?(jgilbert)
(In reply to Liz Henry (:lizzard) from comment #11)
> Jeff, from the bug summary it looks like this also affects 39. Is this
> something that you may want to uplift to aurora?

Yes.
Flags: needinfo?(jgilbert)
Comment on attachment 8589289 [details] [diff] [review]
0001-Check-against-updated-length-while-appending.patch

Approval Request Comment
[Feature/regressing bug #]: 1017865
[User impact if declined]: OOM crashes
[Describe test coverage new/current, TreeHerder]: on nightly
[Risks and why]: none
[String/UUID change made/needed]: none
Attachment #8589289 - Flags: approval-mozilla-aurora?
Comment on attachment 8589289 [details] [diff] [review]
0001-Check-against-updated-length-while-appending.patch

Approving for uplift to aurora as this may help with OOM crashes.
Attachment #8589289 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Hi,

Reproduced the bug in version Firefox Developer Edition (Aurora) 39.0a2 (2015-04-07).
Bug is resolved in version Firefox Developer Edition (Aurora) 39.0a2 (2015-05-03).

-Thanks
Suleman Rawla
Hi,

Bug is resolved in version FireFox Nightly 40.0a1 (2015-05-03).

-Thanks
Suleman Rawla
Thank you for your work to verify this Suleman! Setting status flags accordingly.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.