Open
Bug 938411
Opened 11 years ago
Updated 2 years ago
Lose WebGLContexts from nsGlobalWindow::FreeInnerObjects
Categories
(Core :: Graphics: CanvasWebGL, enhancement, P3)
Core
Graphics: CanvasWebGL
Tracking
()
People
(Reporter: mccr8, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [MemShrink:P2][leave open])
Attachments
(3 files, 2 obsolete files)
6.38 KB,
patch
|
Details | Diff | Splinter Review | |
716 bytes,
patch
|
jgilbert
:
review+
lsblakk
:
approval-mozilla-aurora+
lsblakk
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
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.
Comment 1•11 years ago
|
||
'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
Attachment #832041 -
Flags: review?(bjacob)
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 6•11 years ago
|
||
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.
Updated•11 years ago
|
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
Comment 8•11 years ago
|
||
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?
Updated•11 years ago
|
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)
Comment 10•11 years ago
|
||
Oh, OK, that makes sense. I'll take a closer look then.
Comment 11•11 years ago
|
||
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
Comment 12•11 years ago
|
||
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)
Updated•11 years ago
|
Attachment #8333808 -
Flags: review?(jgilbert) → review+
Comment 15•11 years ago
|
||
Pushed to try on top of http://hg.mozilla.org/integration/mozilla-inbound/rev/531204b8d760 : https://tbpl.mozilla.org/?tree=Try&rev=66b58c60e67d
Comment 16•11 years ago
|
||
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)
Reporter | ||
Comment 17•11 years ago
|
||
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. ;)
Updated•11 years ago
|
Whiteboard: [MemShrink] → [MemShrink][leave open]
Reporter | ||
Comment 18•11 years ago
|
||
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.
Comment 20•11 years ago
|
||
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!
Comment 21•11 years ago
|
||
Does this need uplifting? :-)
Comment 22•11 years ago
|
||
Uplifting 531204b8d760 would be a good idea, as it fixes a real crash.
Comment 23•11 years ago
|
||
That method has been around since bug 716859, so cautiously setting all channels as affected - bjacob could you write the approval request text? :-)
Comment 25•11 years ago
|
||
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)
Comment 26•11 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=a44c2344be6e
Reporter | ||
Updated•11 years ago
|
Attachment #8337888 -
Flags: review?(continuation) → review+
Comment 27•11 years ago
|
||
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 28•11 years ago
|
||
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+
Reporter | ||
Comment 29•11 years ago
|
||
I don't think that patch will help OOMs.
Comment 30•11 years ago
|
||
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.
Comment 31•11 years ago
|
||
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.
Updated•11 years ago
|
Flags: needinfo?(bjacob)
Updated•11 years ago
|
status-b2g-v1.2:
--- → fixed
Comment 33•11 years ago
|
||
(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)
Comment 34•11 years ago
|
||
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.
Updated•11 years ago
|
Whiteboard: [MemShrink][leave open] → [MemShrink:P2][leave open]
Updated•11 years ago
|
Flags: needinfo?(jgilbert)
Comment 35•10 years ago
|
||
Oops, wasn't supposed to put it off this long. Why can't/shouldn't Contexts() auto-create sUniqueInstance?
Flags: needinfo?(jgilbert) → needinfo?(bjacob)
Comment 36•10 years ago
|
||
(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)
Comment 37•10 years ago
|
||
(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)
Comment 38•10 years ago
|
||
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 39•10 years ago
|
||
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-
Comment 40•10 years ago
|
||
Sorry, I have totally lost track of this bug. Happy to help with any specific question.
Comment 41•10 years ago
|
||
(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.
Comment 43•10 years ago
|
||
+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."
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)
Comment 46•10 years ago
|
||
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)
Updated•10 years ago
|
Attachment #8446608 -
Flags: review?(jgilbert) → review+
Comment 47•10 years ago
|
||
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
Updated•5 years ago
|
Priority: -- → P3
Updated•5 years ago
|
Type: defect → enhancement
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•