On debug B2G emulators, the test dom/media/tests/mochitest/test_getUserMedia_playVideoAudioTwice.html fails and then crashes: 15:28:01 INFO - 10-10 22:24:22.381 709 709 I GeckoDump: 11633 ERROR TEST-UNEXPECTED-FAIL | /tests/dom/media/tests/mochitest/test_getUserMedia_playVideoAudioTwice.html | Unexpected callback with message = 'undefined' at: ["@http://mochi.test:8888/tests/dom/media/tests/mochitest/test_getUserMedia_playVideoAudioTwice.html:36","MSP_playMedia/<@http://mochi.test:8888/tests/dom/media/tests/mochitest/mediaStreamPlayback.js:39","MSP_startMedia/canPlayThroughCallback/timeUpdateCallback@http://mochi.test:8888/tests/dom/media/tests/mochitest/mediaStreamPlayback.js:110",""] 15:28:01 INFO - 10-10 22:24:22.451 666 690 I Gecko : [Parent 666] WARNING: could not find a compositor to schedule composition: file ../../../gecko/gfx/layers/ipc/CompositableTransactionParent.cpp, line 225 15:28:01 INFO - 10-10 22:24:22.541 666 690 I Gecko : [Parent 666] WARNING: could not find a compositor to schedule composition: file ../../../gecko/gfx/layers/ipc/CompositableTransactionParent.cpp, line 225 15:28:01 INFO - 10-10 22:24:22.640 666 690 I Gecko : [Parent 666] WARNING: could not find a compositor to schedule composition: file ../../../gecko/gfx/layers/ipc/CompositableTransactionParent.cpp, line 225 ... 15:28:01 INFO - 10-10 22:26:31.170 666 690 I Gecko : ###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv 15:28:01 INFO - 10-10 22:26:31.170 666 690 I Gecko : 15:28:01 INFO - 10-10 22:26:31.231 666 690 I Gecko : [Parent 666] ###!!! ABORT: bad Shmem: file PImageBridgeParent.cpp, line 737 15:28:01 INFO - 10-10 22:26:31.281 666 666 I Gecko : 15:28:01 INFO - 10-10 22:26:31.281 666 666 I Gecko : ###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv 15:28:01 INFO - 10-10 22:26:31.281 666 666 I Gecko : 15:28:01 INFO - 10-10 22:26:31.431 666 690 E Gecko : mozalloc_abort: [Parent 666] ###!!! ABORT: bad Shmem: file PImageBridgeParent.cpp, line 737 15:28:01 INFO - 10-10 22:26:31.431 666 690 F MOZ_CRASH: Hit MOZ_CRASH() at ../../../gecko/memory/mozalloc/mozalloc_abort.cpp:30 full log: https://tbpl.mozilla.org/php/getParsedLog.php?id=28953771&tree=Cedar&full=1#error9

Maire, can someone from the WebRTC team take a look here? Thanks.

I couldn't find that result in the push (https://tbpl.mozilla.org/?rev=e7d8e030bb06&tree=Cedar) - is it hidden? B2G opt m4 is green. Is this debug only? Does this run correctly on real devices? it appears to wait for timeupdate on the video, and waits for >1 minute (but should timeout after ~10 seconds), then dies. The reason is totally unclear. Since the first part of the test is where it failed (not the resume part), this should be equivalent to the test_basicVideo/etc tests that already ran, so why the different result? One thing I notice is that the getUserMedia call does not have "fake:true" like the test_basicVideo/etc calls do. I know the bug that is referenced in the test mentions defaulting fake to true, but is that happening correctly?

As far as I know the faked streams are enabled by default and also used: http://mxr.mozilla.org/mozilla-central/source/dom/media/tests/mochitest/head.js#10 http://mxr.mozilla.org/mozilla-central/source/dom/media/tests/mochitest/head.js#99 But more I can't really say given that I haven't had my eyes on it for a while now.

I think Henrik already answered the question in comment 3. FWIW - looking at the logs included, this looks like a gfx layers crash, not a webrtc crash. We should have someone from Milan's team look into this.

Milan - The debug crash we're seeing here looks related to gfx layers potentially. Is there someone you could suggest that could look into this?

(In reply to Randell Jesup [:jesup] from comment #2) > I couldn't find that result in the push > (https://tbpl.mozilla.org/?rev=e7d8e030bb06&tree=Cedar) - is it hidden? B2G > opt m4 is green. Is this debug only? Does this run correctly on real > devices? Yes, this is debug only, which is hidden by default on TBPL (for being very broken). Use https://tbpl.mozilla.org/?rev=e7d8e030bb06&tree=Cedar&showall=1 to see these.

FYI: If Milan's guys determine this is not gfx but a gUM issue specifically on B2G, then the best person to look at this would probably be SC from CJ Ku's team. However, I would do a needinfo to CJ and ask CJ who on his team is the best choice for this. (If this were a platform gUM bug, not b2G specific, Randell would be the best choice.)

In recent Cedar builds this is burning on another bug, but before that it appears to be failing consistently.

Nicolas, is hitting this assertion a sign that something is wrong in the image bridge, and a graphics issue?

The workweek is keeping me very busy so I'll leave the needinfo flag on for me to spend some more time on that next Monday. Hitting this assertion can mean that we are trying to send an invalid shmem, be it because the shmem was uninitialized or that it was deallocated (use after free \o/). The warning "could not find a compositor to schedule composition" can in some rare case happen but it should not happen 3 times in a row like that, so it is valuable information. It most likely means that we could not connect the video stream with a layer.

nical: test_getUserMedia_basicVideo.html is where the "could not find a compositor" errors started, 10 minutes before this, and there are tons of them, so I think something when very wrong with <video> early on. We may have exhausted some resource by the time we hit this error.

The code in CompositableTransactionParent.cpp is used by both layers transactions and ImageBridge transactions. However the ScheduleComposition function is only useful for ImageBridge and only works with ImageBridge. This means that when we call it with layers transactions it generates useless warnings (potentially a lot of them if you have a non-accelerated canvas2d or an ImageLayer that is updated often from the main thread). This patch checks that the transaction is Async before calling ScheduleComposition. This should not change Gecko's behavior apart from not generating the useless warnings. This will not fix the bug but the extra warnings are getting in the way of diagnosing the problem.

Nick has a patch in Bug 907463 that deals with a case where we double delete shmems on abnormal IPC shutdowns, which seems to be the case here. It may fix the Compositor process crashing in this test case. However there will most likely still be the problem of the content process crashing which is a separate thing.

Comment on attachment 828003 [details] [diff] [review] Only schedule composition in async transactions Review of attachment 828003 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/layers/ipc/CompositableTransactionParent.cpp @@ +220,5 @@ > > MOZ_ASSERT(tex.get()); > compositable->UseTextureHost(tex); > > + if (IsAsync() && !ScheduleComposition(op)) { As discussed on IRC we shouldn't have warnings for thing that can happen. At the same time I don't like mixing getters with calls that have side effects so let's rewrite this similar to the above ScheduleComposition: if (IsAsync()) { ScheduleComposition(op); }

Just to be clear - this does not need the patch from bug 907463?

updated patch

(In reply to Milan Sreckovic [:milan] from comment #15) > Just to be clear - this does not need the patch from bug 907463? Sorry, I missed this comment. The patch here does not depend on any other patch, it just removes warnings that should not be there in the first place. But it does not fix the bug, which I expect to be fixed by the landing of bug 907463.

The test is now passing properly. I suppose it has been fixed by bug 907463.