Open Bug 938411 Opened 11 years ago Updated 2 years ago

Lose WebGLContexts from nsGlobalWindow::FreeInnerObjects

Categories

(Core :: Graphics: CanvasWebGL, enhancement, P3)

Product:
Core
Component:
Graphics: CanvasWebGL
Type:
enhancement

Tracking

()

Tracking Flags:
Tracking Status
firefox25 --- wontfix
firefox26 --- fixed
firefox27 --- fixed
b2g-v1.2 --- fixed

People

(Reporter: mccr8, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [MemShrink:P2][leave open])

Attachments

(3 files, 2 obsolete files)

Patch
6.38 KB, patch
Details | Diff | Splinter Review
check for lost context in PresentScreenBuffer
716 bytes, patch
jgilbert
: review+
lsblakk
: approval-mozilla-aurora+
lsblakk
: approval-mozilla-beta+
Details | Diff | Splinter Review
context-fix
11.17 KB, patch
jgilbert
: review+
Details | Diff | Splinter Review 
khuey had this idea.  It should make us get rid of WebGL memory faster, which would be useful for the WebGL devtools tests that are using a lot of memory.
'Lose' is the right terminology, "losing" a WebGL context means dropping all its associated graphics resources and putting it in a well-specced "lost" state. This is the way that it's possible to immediately free most of the memory used by WebGL objects, without waiting for GC to happen, and regardless of whether they are still referenced. To lose a WebGL context, call WebGLContext::LoseContext().

PS. I just wanted to add some context so noone is lost.

PPS. OK, that was lame.
Summary: Drop WebGLContexts from nsGlobalWindow::FreeInnerObjects → Lose WebGLContexts from nsGlobalWindow::FreeInnerObjects
Comment on attachment 832041 [details] [diff] [review]
Patch

Unfortunately this patch seems to cause bizarre memory corruption.
Attachment #832041 - Flags: review?(bjacob)
Benoit, can you figure out what I'm doing wrong here?
Flags: needinfo?(bjacob)
Comment on attachment 832041 [details] [diff] [review]
Patch

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

I don't know why this would cause any memory corruption, but I have a couple of suggestions.

::: content/canvas/src/WebGLContext.cpp
@@ +742,5 @@
> +{
> +    MOZ_ASSERT(aWindow->IsInnerWindow());
> +
> +    WebGLMemoryReporterWrapper::ContextsArrayType &contexts
> +      = WebGLMemoryReporterWrapper::Contexts();

Could you make this a constant reference? There is no reason why you should need to modify this array here. Lost contexts should remain in the array.

@@ +759,5 @@
> +            // (typically the compositor) is still holding on to the context.
> +            // Killing zombies is a no-brainer.
> +            const_cast<WebGLContext*>(contexts[i])->LoseContext();
> +            continue;
> +        }

Since this is copied from existing code (above in the same file), with nontrivial logic, consider putting this in a shared helper function.
Flags: needinfo?(bjacob)
Well I don't have the time to debug the memory corruption here, so if we want this somebody on the gfx team needs to pick it up.
Assignee: khuey → nobody
Blocks: MochiMem
Kyle: on what platform, while running what workload, using what tools, have you found memory corruption? I.e. is this something I can reproduce in Valgrind on linux running some testcase?
Flags: needinfo?(khuey)
See https://tbpl.mozilla.org/?tree=Try&rev=5a4b57b67ffa.  Most of the crashes are null ptr derefs in glContext::MakeCurrent, but there's some bizarre CSS assertion that looks like memory corruption.  I suppose its possible that fixing the null ptr issue will fix that.

I didn't try it on Linux.
Flags: needinfo?(khuey)
Oh, OK, that makes sense. I'll take a closer look then.
Indeed, it looks like PresentScreenBuffer needs to check that its GLContext* pointer is not null.

This is happening because this is called back by the compositor, so from there we have no other way of knowing that the context has just been lost, than checking the GLContext* pointer for nullness.

23:56:33  WARNING -  PROCESS-CRASH | chrome://mochitests/content/browser/browser/devtools/shadereditor/test/browser_se_programs-blackbox.js | application crashed [@ mozilla::gl::GLContext::MakeCurrent(bool)]
23:56:33     INFO -  Crash dump filename: c:\users\cltbld\appdata\local\temp\tmpz58wzt\minidumps\2488f3c3-8ea4-4181-95d5-7eb1722cecd5.dmp
23:56:33     INFO -  Operating system: Windows NT
23:56:33     INFO -                    6.1.7601 Service Pack 1
23:56:33     INFO -  CPU: x86
23:56:33     INFO -       GenuineIntel family 6 model 30 stepping 5
23:56:33     INFO -       8 CPUs
23:56:33     INFO -  Crash reason:  EXCEPTION_ACCESS_VIOLATION_READ
23:56:33     INFO -  Crash address: 0x0
23:56:33     INFO -  Thread 0 (crashed)
23:56:33     INFO -   0  xul.dll!mozilla::gl::GLContext::MakeCurrent(bool) [GLContext.h:5a4b57b67ffa : 2402 + 0x0]
23:56:33     INFO -      eip = 0x665bd3ac   esp = 0x0023e594   ebp = 0x0023e5a0   ebx = 0x00000000
23:56:33     INFO -      esi = 0x00000000   edi = 0x00000001   eax = 0x00000000   ecx = 0x00461a68
23:56:33     INFO -      edx = 0x00000000   efl = 0x00010246
23:56:33     INFO -      Found by: given as instruction pointer in context
23:56:33     INFO -   1  xul.dll!mozilla::WebGLContext::PresentScreenBuffer() [WebGLContext.cpp:5a4b57b67ffa : 1213 + 0x10]
23:56:33     INFO -      eip = 0x665d1ece   esp = 0x0023e5a8   ebp = 0x0023e5bc
23:56:33     INFO -      Found by: call frame info
23:56:33     INFO -   2  xul.dll!mozilla::WebGLContextUserData::PreTransactionCallback(void *) [WebGLContext.cpp:5a4b57b67ffa : 889 + 0x6]
23:56:33     INFO -      eip = 0x665d2a0f   esp = 0x0023e5b8   ebp = 0x0023e5bc
23:56:33     INFO -      Found by: call frame info
23:56:33     INFO -   3  xul.dll!mozilla::layers::CanvasLayer::FirePreTransactionCallback() [Layers.h:5a4b57b67ffa : 1782 + 0x7]
23:56:33     INFO -      eip = 0x673f8c0c   esp = 0x0023e5c4   ebp = 0x0023e5ec
23:56:33     INFO -      Found by: call frame info
23:56:33     INFO -   4  xul.dll!mozilla::layers::CanvasLayerD3D10::RenderLayer() [CanvasLayerD3D10.cpp:5a4b57b67ffa : 227 + 0xa]
23:56:33     INFO -      eip = 0x67406aa3   esp = 0x0023e5cc   ebp = 0x0023e5ec
23:56:33     INFO -      Found by: call frame info
23:56:33     INFO -   5  xul.dll!mozilla::layers::ContainerLayerD3D10::RenderLayer() [ContainerLayerD3D10.cpp:5a4b57b67ffa : 190 + 0x7]
23:56:33     INFO -      eip = 0x67407a63   esp = 0x0023e5f4   ebp = 0x0023e77c
23:56:33     INFO -      Found by: call frame info
23:56:33     INFO -   6  xul.dll!mozilla::layers::ContainerLayerD3D10::RenderLayer() [ContainerLayerD3D10.cpp:5a4b57b67ffa : 190 + 0x7]
23:56:33     INFO -      eip = 0x67407a63   esp = 0x0023e784   ebp = 0x0023e90c
23:56:33     INFO -      Found by: call frame info
23:56:33     INFO -   7  xul.dll!mozilla::layers::LayerManagerD3D10::Render(mozilla::layers::LayerManager::EndTransactionFlags) [LayerManagerD3D10.cpp:5a4b57b67ffa : 717 + 0xf]
23:56:33     INFO -      eip = 0x6740b3fd   esp = 0x0023e914   ebp = 0x0023e954
23:56:33     INFO -      Found by: call frame info
23:56:33     INFO -   8  xul.dll!mozilla::layers::LayerManagerD3D10::EndTransaction(void (*)(mozilla::layers::ThebesLayer *,gfxContext *,nsIntRegion const &,mozilla::layers::DrawRegionClip,nsIntRegion const &,void *),void *,mozilla::layers::LayerManager::EndTransactionFlags) [LayerManagerD3D10.cpp:5a4b57b67ffa : 392 + 0x9]
23:56:33     INFO -      eip = 0x6740b4f3   esp = 0x0023e95c   ebp = 0x0023e9a8
23:56:33     INFO -      Found by: call frame info
23:56:33     INFO -   9  xul.dll!mozilla::layers::LayerManagerD3D10::EndEmptyTransaction(mozilla::layers::LayerManager::EndTransactionFlags) [LayerManagerD3D10.cpp:5a4b57b67ffa : 362 + 0x9]
23:56:33     INFO -      eip = 0x67409ce9   esp = 0x0023e9b0   ebp = 0x0023e9bc
23:56:33     INFO -      Found by: call frame info
23:56:33     INFO -  10  xul.dll!PresShell::Paint(nsView *,nsRegion const &,unsigned int) [nsPresShell.cpp:5a4b57b67ffa : 5658 + 0x8]
23:56:33     INFO -      eip = 0x6634cc4a   esp = 0x0023e9c4   ebp = 0x0023eaf8
23:56:33     INFO -      Found by: call frame info
23:56:33     INFO -  11  xul.dll!nsViewManager::Refresh(nsView *,nsIntRegion const &) [nsViewManager.cpp:5a4b57b67ffa : 349 + 0x11]
23:56:33     INFO -      eip = 0x667a2b82   esp = 0x0023eb00   ebp = 0x0023eb48
23:56:33     INFO -      Found by: call frame info
23:56:33     INFO -  12  xul.dll!nsViewManager::PaintWindow(nsIWidget *,nsIntRegion) [nsViewManager.cpp:5a4b57b67ffa : 685 + 0xb]
23:56:33     INFO -      eip = 0x667a2c37   esp = 0x0023eb50   ebp = 0x0023eb5c
23:56:33     INFO -      Found by: call frame info
23:56:33     INFO -  13  xul.dll!nsView::PaintWindow(nsIWidget *,nsIntRegion) [nsView.cpp:5a4b57b67ffa : 1046 + 0x1f]
23:56:33     INFO -      eip = 0x667a0b2c   esp = 0x0023eb64   ebp = 0x0023eba4
23:56:33     INFO -      Found by: call frame info
23:56:33     INFO -  14  xul.dll!nsWindow::OnPaint(HDC__ *,unsigned int) [nsWindowGfx.cpp:5a4b57b67ffa : 535 + 0x1c]
23:56:33     INFO -      eip = 0x66d90005   esp = 0x0023ebac   ebp = 0x0023ed38
23:56:33     INFO -      Found by: call frame info
23:56:33     INFO -  15  xul.dll!nsWindow::ProcessMessage(unsigned int,unsigned int &,long &,long *) [nsWindow.cpp:5a4b57b67ffa : 4809 + 0xa]
23:56:33     INFO -      eip = 0x66d8de0d   esp = 0x0023ed40   ebp = 0x0023ee90
23:56:33     INFO -      Found by: call frame info
Kyle, can you confirm that this fixes the crash?
Attachment #8333808 - Flags: review?(jgilbert)
Flags: needinfo?(khuey)
You can push to try as easily as I can.
Flags: needinfo?(khuey)
Attachment #8333808 - Flags: review?(jgilbert) → review+
Now we're not crashing anymore, but we're leaking:

21:23:55     INFO -  TEST-INFO | leakcheck | leaked 1 MemoryMultiReporter (24 bytes)
21:23:55     INFO -  TEST-INFO | leakcheck | leaked 1 nsStringBuffer (8 bytes)
21:23:55     INFO -  TEST-INFO | leakcheck | leaked 1 nsTArray_base (4 bytes)
Looking over the code, my guess would be that WebGLMemoryReporterWrapper::sUniqueInstance isn't getting destroyed.  Adding MOZ_COUNT_CTOR/DTOR to that class would confirm it, and also be a good idea. ;)
Whiteboard: [MemShrink] → [MemShrink][leave open]
I think what is happening is that if you call LoseWebGLContextsForWindow after any GL contexts will be created, then sUniqueInstance gets created by WebGLMemoryReporterWrapper::UniqueInstance(), but we'll never call RemoveWebGLContext() again, because there are no contexts, and that's the only thing that clears sUniqueInstance.  There either needs to be some way to check if there are any contexts without creating a unique instance (perhaps by modifying GetContextCount() to return 0 if sUniqueInstance is null) or there needs to be some kind of shutdown cleanup of sUniqueInstance.
Wow, thanks Andrew for figuring this. This sounds like a leak that we already had, then, because for instance about:memory will call e.g. GetTextureMemoryUsed() which calls Contexts() which calls UniqueInstance() in the same way. So we already have that leak everytime people do memory measurements in about:memory and aren't using WebGL!
Does this need uplifting? :-)
Uplifting 531204b8d760 would be a good idea, as it fixes a real crash.
That method has been around since bug 716859, so cautiously setting all channels as affected - bjacob could you write the approval request text? :-)
status-firefox25: --- → wontfix
status-firefox26: --- → affected
status-firefox27: --- → affected
The previous patch fixes the memory leak; but Contexts() now asserts if it's called and UniqueInstance doesn't exist (it doesn't silently create it anymore).
Attachment #8337888 - Flags: review?(continuation)
Attachment #8337888 - Flags: review?(continuation) → review+
Comment on attachment 8333808 [details] [diff] [review]
check for lost context in PresentScreenBuffer

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Maybe 716859
User impact if declined: JS-triggerable crashes. Seem like just nullptr derefs so a priori no security issue.
Testing completed (on m-c, etc.): m-c for a few days now
Risk to taking this patch (and alternatives if risky): low risk, 2-line patch that makes sense.
String or IDL/UUID changes made by this patch: none
Attachment #8333808 - Flags: approval-mozilla-beta?
Attachment #8333808 - Flags: approval-mozilla-aurora?
Comment on attachment 8333808 [details] [diff] [review]
check for lost context in PresentScreenBuffer

given the news at today's crashkill meeting that we're seeing a very high level of OOM-caused crashes it seems like a no-brainer to take this low-risk fix.
Attachment #8333808 - Flags: approval-mozilla-beta?
Attachment #8333808 - Flags: approval-mozilla-beta+
Attachment #8333808 - Flags: approval-mozilla-aurora?
Attachment #8333808 - Flags: approval-mozilla-aurora+
I don't think that patch will help OOMs.
https://hg.mozilla.org/releases/mozilla-aurora/rev/6c018c4f2eae
https://hg.mozilla.org/releases/mozilla-beta/rev/0c6966e6cd33

If we end up wanting to uplift any of the remaining patches to Fx26/Fx27, please set the respective status flag back to affected.
status-firefox26: affected → fixed
status-firefox27: affected → fixed
Comment on attachment 8337887 [details] [diff] [review]
Fix memory leak when querying WebGL memory reporters when there are no WebGL contexts

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

::: content/canvas/src/WebGLMemoryReporterWrapper.h
@@ +34,5 @@
>      static WebGLMemoryReporterWrapper* UniqueInstance();
>  
> +    static ContextsArrayType & Contexts() {
> +        MOZ_ASSERT(sUniqueInstance);
> +        return UniqueInstance()->mContexts;

Why don't we just give back an empty array?
Having this behavior added a bunch of boilerplate code below, where we have to early-out if there's no sUniqueInstance, even though it doesn't appear to save much processing.
Flags: needinfo?(bjacob)
(In reply to Jeff Gilbert [:jgilbert] from comment #31)
> Comment on attachment 8337887 [details] [diff] [review]
> Fix memory leak when querying WebGL memory reporters when there are no WebGL
> contexts
> 
> Review of attachment 8337887 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: content/canvas/src/WebGLMemoryReporterWrapper.h
> @@ +34,5 @@
> >      static WebGLMemoryReporterWrapper* UniqueInstance();
> >  
> > +    static ContextsArrayType & Contexts() {
> > +        MOZ_ASSERT(sUniqueInstance);
> > +        return UniqueInstance()->mContexts;
> 
> Why don't we just give back an empty array?

Because this Contexts() function is called by AddWebGLContext(), so in the case of the first WebGL context it would return a dummy empty array, AddWebGLContext would add itself to it, instead of creating a unique instance and returning its contexts array. Of course we could be smart and do the right thing instead, but seeing that possibility, I was scared that we had been too smart here with implicit lifetime management and it was time to get back to plain old code. What do you think?
Flags: needinfo?(bjacob)
Note that the present code (with my patch) has the merit of rigidity: if someone forgot to early exit in the case of no uniqueinstance, they would get a nice assertion failure when calling Contexts().

Let me know if you can see a way of letting Contexts() return a ****read-only**** empty array when sUniqueInstance is null.
Whiteboard: [MemShrink][leave open] → [MemShrink:P2][leave open]
Flags: needinfo?(jgilbert)
Oops, wasn't supposed to put it off this long.
Why can't/shouldn't Contexts() auto-create sUniqueInstance?
Flags: needinfo?(jgilbert) → needinfo?(bjacob)
(In reply to Jeff Gilbert [:jgilbert] from comment #35)
> Oops, wasn't supposed to put it off this long.
> Why can't/shouldn't Contexts() auto-create sUniqueInstance?

It actually does auto-create sUniqueInstance: it calls UniqueInstance(), which does that.
Flags: needinfo?(bjacob)
(In reply to Benoit Jacob [:bjacob] from comment #36)
> (In reply to Jeff Gilbert [:jgilbert] from comment #35)
> > Oops, wasn't supposed to put it off this long.
> > Why can't/shouldn't Contexts() auto-create sUniqueInstance?
> 
> It actually does auto-create sUniqueInstance: it calls UniqueInstance(),
> which does that.

Then why do we assert that sUniqueInstance has been created, when we're going to immediately create it on the next line?
Flags: needinfo?(bjacob)
Ah, right, I was only looking at current code, now I've looked again at my patch here. It's been a while and this isn't very fresh in my mind anymore, but look at the above comments, there was a bad mem leak around here that prevented Kyle's patch from landing, and it had to do with our auto lifetime management here, with Contexts() and UniqueInstance(), being too clever for our own good. See above around comment 20.
Flags: needinfo?(bjacob)
Comment on attachment 8337887 [details] [diff] [review]
Fix memory leak when querying WebGL memory reporters when there are no WebGL contexts

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

This is r- until we either have much less boilerplate (better auto-creation) or a comment explaining why we can't do this nicer.

::: content/canvas/src/WebGLMemoryReporterWrapper.h
@@ +34,5 @@
>      static WebGLMemoryReporterWrapper* UniqueInstance();
>  
> +    static ContextsArrayType & Contexts() {
> +        MOZ_ASSERT(sUniqueInstance);
> +        return UniqueInstance()->mContexts;

Wait, why don't we just auto-create the UniqueInstance here?
Attachment #8337887 - Flags: review?(jgilbert) → review-
Sorry, I have totally lost track of this bug. Happy to help with any specific question.
(In reply to Benoit Jacob [:bjacob] from comment #40)
> Sorry, I have totally lost track of this bug. Happy to help with any
> specific question.

My specific question was above, and this is more or less your bug.
If you think it's complete, just mark it fixed.

However, there's one patch left here which claims to fix a memory leak, but I disagree with the approach. I can try to propose a mechanical counter-patch, but I have very little clue what's going on here.
I think we really should push to get this bug fixed. Here's my understanding of what is going on.

Currently, we rely on the GC to collect WebGL contexts. This is completely broken since the GC has no idea how much memory is actually tied to these contexts (could be GPU memory or whatever). To the GC, a WebGL context looks like a regular old JS object that has little effect on memory pressure. We really need to collect these contexts as eagerly as possible since they're much more likely to cause OOMs than normal objects.

My understanding is that Kyle's patch ensures that we drop contexts as soon as the page they're tied to is navigated away from (and leaves the bfcache I think). Kyle's patch triggered some problems on tryserver, so then Benoit posted some patches to fix various minor crashes and leaks. However, Kyle's original patch is the one that we really need. Can we *please* do whatever it takes to get that landed? This is a really important bug, and it's getting killed because of slow reviews.
+1 to Bill's comment. This old quote (apparently from George Bosworth) is worth repeating:

"A modern GC is a heuristics-based resource manager.  The resources it manages generally have very low individual value (a few dozen bytes of memory) and exist in vast numbers.  There is a wide distribution of life-times of these resources, but the majority are highly ephemeral. The average latency of resource recovery is important but the recovery latency of any individual resource is generally unimportant. The heuristics of a great GC take all of these characteristics into account.  When you piggy-back upon a GC  (via finalization, or equivalent mechanism) the management of a different kind of resource you are applying the heuristic of memory resource management to the management of the piggy-backed resources. This is typically a poor fit.  For example, the piggy-backed resource may be of high individual value and exist in limited numbers (George's used file descriptors as an example).  A good GC will be a bad resource manager for such resources."
Attached patch context-fix — — Splinter Review 
I took a look at this patch and I think I understand what's going on.

The whole problem this patch tries to fix is that calling WebGLMemoryTracker::Contexts() causes us to create a WebGLMemoryTracker instance that could then be leaked if no contexts are created or destroyed after that point. Benoit wanted to fix this by moving the creation of the WebGLMemoryTracker outside of WebGLMemoryTracker::Contexts(), but then that required a lot of checks before calling Contexts() to see if the object existed yet, and Jeff didn't like.

Jeff suggested that Contexts() should return a dummy empty array if no WebGLMemoryTracker has been created yet. I tried to do that, but I had trouble figuring out where to store the array. I thought about making it global, but then we'd have to run the nsTArray constructor when the program is loaded, and I think we're trying to avoid that.

So instead I just removed Contexts() and replaced it with a GetContext(i) method. We already have a GetContextCount() method. This new scheme seems pretty simple to me.
Attachment #8337887 - Attachment is obsolete: true
Attachment #8337888 - Attachment is obsolete: true
Attachment #8446608 - Flags: review?(jgilbert)
I pushed this patch to try. Everything looks pretty good except the gl tests on Android 2.3 opt. Do you know what might be happening there Benoit?
https://tbpl.mozilla.org/?tree=Try&rev=e94e7ecdd676
Flags: needinfo?(bjacob)
The logcat.log for this test job clearly shows that a WebGL context loss occurs just before the unexpected-fail and is its cause (first we see WebGL(0x58eaf400)::ForceLoseContext, then the driver notifies us that the drawElements call has no data to source, which is typical of a lost context, and finally we get the test failure complaining that drawElements didn't renderer what it should have).

So it seems that this patch caused us to lose webgl contexts more aggressively than the test currently allows. Now, webgl contexts are absolutely supposed to be losable at any time, so arguably a webgl conformance test that assumes otherwise, is not correct.

06-26 23:14:22.381 I/GeckoDump(  577): 314 INFO TEST-START | /tests/content/canvas/test/webgl-mochitest/test_highp_fs.html
06-26 23:14:24.429 E/GeckoConsole(  577): [JavaScript Warning: "The character encoding of a framed document was not declared. The document may appear different if viewed without the document framing it." {file: "http://mochi.test:8888/tests/content/canvas/test/webgl-mochitest/test_highp_fs.html" line: 0}]
06-26 23:14:24.439 E/GeckoConsole(  577): Info: GL vendor: Google (VMware, Inc.)
06-26 23:14:24.449 E/GeckoConsole(  577): Info: GL renderer: Android Emulator OpenGL ES Translator (Gallium 0.4 on llvmpipe (LLVM 0x300))
06-26 23:14:24.449 E/GeckoConsole(  577): Info: OS detected as: android
06-26 23:14:24.459 E/GeckoConsole(  577): Info:   Version: 10
06-26 23:14:24.469 E/GeckoConsole(  577): Info: GL driver detected as: mesa
06-26 23:14:24.829 I/GeckoDump(  577): 315 INFO TEST-INFO | MEMORY STAT vsize after test: 464777216
06-26 23:14:24.862 I/GeckoDump(  577): 316 INFO TEST-INFO | MEMORY STAT residentFast after test: 184762368
06-26 23:14:24.880 I/GeckoDump(  577): 317 INFO TEST-INFO | MEMORY STAT heapAllocated after test: 56514652
06-26 23:14:25.141 I/GeckoDump(  577): 318 INFO TEST-END | /tests/content/canvas/test/webgl-mochitest/test_highp_fs.html | finished in 2768ms
06-26 23:14:25.621 D/GeckoTabs(  577): handleMessage: SessionHistory:New
06-26 23:14:25.659 D/GeckoTabs(  577): handleMessage: SessionHistory:Purge
06-26 23:14:25.741 I/Gecko   (  577): WebGL(0x58eaf400)::ForceLoseContext
06-26 23:14:26.153 E/GeckoConsole(  577): [JavaScript Warning: "The character encoding of a framed document was not declared. The document may appear different if viewed without the document framing it." {file: "http://mochi.test:8888/tests/SimpleTest/iframe-between-tests.html" line: 0}]
06-26 23:14:26.290 I/GeckoDump(  577): 319 INFO TEST-START | /tests/content/canvas/test/webgl-mochitest/test_no_arr_points.html
06-26 23:14:28.419 I/SUTAgentAndroid(  311): 10.0.2.2 : activity
06-26 23:14:28.569 D/dalvikvm(  311): GC_EXPLICIT freed 10K, 52% free 2814K/5767K, external 716K/1038K, paused 140ms
06-26 23:14:28.739 E/emuglGLESv2_enc(  577): glDrawElements: no data bound to the command - ignoring
06-26 23:14:28.779 I/GeckoDump(  577): 320 INFO TEST-INFO | dumping last 4 message(s)
06-26 23:14:28.779 I/GeckoDump(  577): 321 INFO TEST-INFO | if you need more context, please use SimpleTest.requestCompleteLog() in your test
06-26 23:14:28.799 I/GeckoDump(  577): 322 INFO TEST-PASS | /tests/content/canvas/test/webgl-mochitest/test_no_arr_points.html | `aPosition` should be valid.
06-26 23:14:28.809 I/GeckoDump(  577): 323 INFO TEST-PASS | /tests/content/canvas/test/webgl-mochitest/test_no_arr_points.html | [no-attrib] drawArrays should color pixels.
06-26 23:14:28.809 I/GeckoDump(  577): 324 INFO TEST-PASS | /tests/content/canvas/test/webgl-mochitest/test_no_arr_points.html | [no-attrib] drawArrays[huge first] should color pixels.
06-26 23:14:28.819 I/GeckoDump(  577): 325 INFO TEST-PASS | /tests/content/canvas/test/webgl-mochitest/test_no_arr_points.html | [no-attrib] gl.getError should be 0, was 0x0.
06-26 23:14:28.819 I/GeckoDump(  577): 326 INFO TEST-UNEXPECTED-FAIL | /tests/content/canvas/test/webgl-mochitest/test_no_arr_points.html | [no-attrib] drawElements[0] should color pixels.
06-26 23:14:28.829 E/emuglGLESv2_enc(  577): glDrawElements: no data bound to the command - ignoring
06-26 23:14:28.839 I/GeckoDump(  577): 327 INFO TEST-UNEXPECTED-FAIL | /tests/content/canvas/test/webgl-mochitest/test_no_arr_points.html | [no-attrib] drawElements[1] should color pixels.
06-26 23:14:28.839 E/emuglGLESv2_enc(  577): glDrawElements: no data bound to the command - ignoring
06-26 23:14:28.839 I/GeckoDump(  577): 328 INFO TEST-UNEXPECTED-FAIL | /tests/content/canvas/test/webgl-mochitest/test_no_arr_points.html | [no-attrib] drawElements[huge offset] should color pixels.
06-26 23:14:28.920 E/emuglGLESv2_enc(  577): glDrawElements: no data bound to the command - ignoring
06
Flags: needinfo?(bjacob)
Attachment #8446608 - Flags: review?(jgilbert) → review+
Alright, here's a thing to try: [1]

[DEFAULT]
run-sequentially = "Parallel runs can cause context-loss when we run out of contexts and kill the LRU'd one."

[1] Based on https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/buildsystem/test_manifests.html
Priority: -- → P3
Type: defect → enhancement
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: