Closed Bug 1006957 Opened 6 years ago Closed 6 years ago

Handle buffer ownership correctly between SurfaceStream and CanvasClient.

Categories

(Core :: Graphics: Layers, defect, P1, major)

ARM
Gonk (Firefox OS)
defect

Tracking

()

RESOLVED FIXED
mozilla32
blocking-b2g 1.4+
Tracking Status
firefox30 --- wontfix
firefox31 --- wontfix
firefox32 --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: sotaro, Assigned: sotaro)

References

Details

Attachments

(3 files, 18 obsolete files)

80.43 KB, patch
sotaro
: review+
Details | Diff | Splinter Review
920 bytes, patch
sotaro
: review+
Details | Diff | Splinter Review
81.06 KB, patch
sotaro
: review+
Details | Diff | Splinter Review
+++ This bug was initially created as a clone of Bug #950079 +++

This bug is created based on Bug 950079 Comment 17.

Buffer ownership handling between SurfaceStream and CanvasClient has a problem. It could cause the problem to Fence delivery from Compositor to SurfaceStream.
blocking-b2g: --- → 2.0?
blocking-b2g: 2.0? → ---
Assignee: nobody → sotaro.ikeda.g
Blocks: 1006164
blocking-b2g: --- → 1.4?
CanvasClientSurfaceStream does not explicitly handle buffer return to SurfaceStream. Post new buffer to Compositor side by the following call implicitly expect synchronous buffer return to the SurfaceStream. But the following call requests async transaction.

> GetForwarder()->UseTexture(this, mBuffer);
Bug 988956 might be necessary to fix the problem.
I am going to use AsyncTransactionTracker::WaitComplete() to wait transaction complete.

http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/AsyncTransactionTracker.h
Depends on: 984434
Status: NEW → ASSIGNED
Can we please get:

1) STRs
2) DUT
3) User impact of not taking fix
4) Regression or not from previous releases
Flags: needinfo?(sotaro.ikeda.g)
(In reply to Preeti Raghunath(:Preeti) from comment #5)
> Can we please get:
> 
> 1) STRs

  Same to Bug 1006164.

> 2) DUT

 What is DUT?

> 3) User impact of not taking fix.

  Rarely saw black flicker during WebGL like WMW app. 

> 4) Regression or not from previous releases
  
  This is a regression caused by new b2g hardware specfic characteristic.
Flags: needinfo?(sotaro.ikeda.g)
Blocks: 1002776
No longer blocks: 1002776
Blocking for 1.4.

Can we please discuss low risk fix here and low risk landing?
blocking-b2g: 1.4? → 1.4+
Duplicate of this bug: 988956
(In reply to Preeti Raghunath(:Preeti) from comment #7)
> Blocking for 1.4.
> 
> Can we please discuss low risk fix here and low risk landing?

Bug 950079 is low risk solution for WMW. About this bug, I am thinking only one way of the fix. I think there are no other choice for low risk fix.
Confirmed the patch black flickering is fixed.
Attachment #8424186 - Flags: feedback?(nical.bugzilla)
Comment on attachment 8424186 [details] [diff] [review]
patch - Handle buffer ownership between SurfaceStream and CanvasClient.

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

I am struggling a bit with the logic around process ID, I suppose there is always one parent process so we don't really need to track its ID, so I suppose we are looking at the the child process ID here. But we create the LayerTransactionParent querying the current process ID, which makes it look like we are tracking the parent ID, so I am a bit confused. I think it would help a lot if you renamed all the [m|a]ProcessId and aOtherProcessID variables into [m|a][Child|Parent]ProcessId to make it clear which side's ID we are tracking.

I'll catch up with you on irc or skype today to get a better understanding of the overall thing.

::: gfx/layers/client/TextureClient.h
@@ +297,5 @@
>      return mReleaseFenceHandle;
>    }
>  
>    /**
> +   * Set AsyncTransactionTracker of RemoveTextureFromCompositableAsync() transaction. 

nit: trailing space

::: gfx/layers/ipc/CompositableTransactionParent.cpp
@@ +187,5 @@
> +                             GetProcessId(),
> +                             OpReplyRemoveTexture(true, // isMain
> +                                                  op.holderId(),
> +                                                  op.transactionId()));
> +        

nit: trailing spaces
(In reply to Nicolas Silva [:nical] from comment #11)
> Comment on attachment 8424186 [details] [diff] [review]
> patch - Handle buffer ownership between SurfaceStream and CanvasClient.
> 
> Review of attachment 8424186 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I am struggling a bit with the logic around process ID, I suppose there is
> always one parent process so we don't really need to track its ID, so I
> suppose we are looking at the the child process ID here. But we create the
> LayerTransactionParent querying the current process ID, which makes it look
> like we are tracking the parent ID, so I am a bit confused. I think it would
> help a lot if you renamed all the [m|a]ProcessId and aOtherProcessID
> variables into [m|a][Child|Parent]ProcessId to make it clear which side's ID
> we are tracking.

It is tracking LayerTransactionchild's process id. I am going to update the code to make it clear.

> 
> I'll catch up with you on irc or skype today to get a better understanding
> of the overall thing.
> 
> ::: gfx/layers/client/TextureClient.h
> @@ +297,5 @@
> >      return mReleaseFenceHandle;
> >    }
> >  
> >    /**
> > +   * Set AsyncTransactionTracker of RemoveTextureFromCompositableAsync() transaction. 
> 
> nit: trailing space
> 
> ::: gfx/layers/ipc/CompositableTransactionParent.cpp
> @@ +187,5 @@
> > +                             GetProcessId(),
> > +                             OpReplyRemoveTexture(true, // isMain
> > +                                                  op.holderId(),
> > +                                                  op.transactionId()));
> > +        
> 
> nit: trailing spaces

Will update in a next patch.
(In reply to Nicolas Silva [:nical] from comment #11)
> Comment on attachment 8424186 [details] [diff] [review]
> patch - Handle buffer ownership between SurfaceStream and CanvasClient.
> 
> Review of attachment 8424186 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I am struggling a bit with the logic around process ID, I suppose there is
> always one parent process so we don't really need to track its ID, so I
> suppose we are looking at the the child process ID here. But we create the
> LayerTransactionParent querying the current process ID, which makes it look
> like we are tracking the parent ID, so I am a bit confused. I think it would
> help a lot if you renamed all the [m|a]ProcessId and aOtherProcessID
> variables into [m|a][Child|Parent]ProcessId to make it clear which side's ID
> we are tracking.

The patch tracks child side's process id. When LayerTransactionParent(CompositableParentManager) receives an async transaction message, it sends back an async transaciton response message via ImageBridge parent. The messge is handled to ImageBridgeChild. ImageBridgeChild notify the transaction complete to AsyncTransactionTrackersHolder.

By this way, AsyncTransactionTracker provide a sync wait capability by using async transaction. By changing the sync wait place from gecko ipc transaction to AsyncTransactionTracker, we could put off sync wait.
Apply the comments.
Attachment #8424186 - Attachment is obsolete: true
Attachment #8424186 - Flags: feedback?(nical.bugzilla)
Attachment #8425469 - Flags: feedback?(nical.bugzilla)
nical, can I get the feedback to the patch soon?
Flags: needinfo?(nical.bugzilla)
Comment on attachment 8425469 [details] [diff] [review]
patch v2 - Handle buffer ownership between SurfaceStream and CanvasClient

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

Thanks for renaming the ProcessIds, I think it makes things clearer
Attachment #8425469 - Flags: feedback?(nical.bugzilla) → feedback+
Thank for the quick feed back! I am going to update the patch for a review until tomorrow.
Flags: needinfo?(nical.bugzilla)
Some nits update.
Attachment #8425469 - Attachment is obsolete: true
This bug fix seems to have a good effect to the performance.
Fix build failure in some platforms.
Attachment #8426727 - Attachment is obsolete: true
Fix build failure.
Attachment #8426760 - Attachment is obsolete: true
Attachment #8426766 - Flags: review?(nical.bugzilla)
Fix windows build failure.
Attachment #8426766 - Attachment is obsolete: true
Attachment #8426766 - Flags: review?(nical.bugzilla)
Attachment #8426779 - Flags: review?(nical.bugzilla)
Fix build failure on ICS.
Attachment #8426779 - Attachment is obsolete: true
Attachment #8426779 - Flags: review?(nical.bugzilla)
Attachment #8426897 - Flags: review?(nical.bugzilla)
Attachment #8426897 - Flags: review?(nical.bugzilla) → review+
Revert ConnectImageBridgeInParentProcess()'s argument name. Carry "r=nical".
Attachment #8426897 - Attachment is obsolete: true
Attachment #8427024 - Flags: review+
A patch for b2g v1.4. Carry "r=nical".
Attachment #8427041 - Flags: review+
On master, the problem is fixed. But on v1.4, the problem is exist on hw composer composition:-( On OpenGL composition case, the problem is fixed even in b2g v1.4.

On current master, hw composer is not used in almost all situations by some reasons. On b2g v1.4, Hw composer is used in WMW app. If we disable the hw composer, the problem is gone with the patch.
Release Fences are always sent on main thread, but RemoveTextureAsync transaction response is sent via ImageBridge. Therefore, release fence is arrived to child side after the transaction response's receival in child side.
Need to send related Fence object via ImageBridge too.
I locally fixed the black flash problem in Comment 31. But it change how to deliver Fence from compositor to child side. More code change becomes necessary. I am updating the patch.
Patch for b2g v1.4. Fix flickering problem on HWComposer composition.
Attachment #8427041 - Attachment is obsolete: true
Sorry, this patch is correct patch for b2g v1.4.
Attachment #8427311 - Attachment is obsolete: true
Un-bitrot.
Attachment #8427469 - Attachment is obsolete: true
Attachment #8427321 - Attachment description: patch v9 for b2g v1.4 - Handle buffer ownership between SurfaceStream and CanvasClient → patch v10 for b2g v1.4 - Handle buffer ownership between SurfaceStream and CanvasClient
Comment on attachment 8427506 [details] [diff] [review]
patch v10 - Handle buffer ownership between SurfaceStream and CanvasClient

Nical, can you review again? I changed how to deliver fence.
Attachment #8427506 - Flags: review?(nical.bugzilla)
Fix build failure on other platforms.
Attachment #8427506 - Attachment is obsolete: true
Attachment #8427506 - Flags: review?(nical.bugzilla)
Attachment #8427668 - Flags: review?(nical.bugzilla)
Attachment #8427668 - Flags: review?(nical.bugzilla) → review+
Update the patch for b2g v1.4. Carry "r=nical".
Attachment #8427321 - Attachment is obsolete: true
Attachment #8427739 - Flags: review+
Wait check-in until Bug 924622's check-in result becomes clear. This bug's patch conflicts with Bug 924622's patch.
Blocks: 767484
Duplicate of this bug: 988135
By the Bug 924622 fix, shutdown sequence is changed, it seems to be affected to the crash.
Need to move layers::AsyncTransactionTrackersHolder::Finalize() call to more later than nsCycleCollector_shutdown() in mozilla::ShutdownXPCOM().
Change shutdown. Carry "r=nical".
Attachment #8427668 - Attachment is obsolete: true
Attachment #8428256 - Flags: review+
Update the patch for b2g v1.4.
Attachment #8427739 - Attachment is obsolete: true
Attachment #8428271 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/436860482387
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
This is causing a B2G OS crash when I try to make a webrtc call using H.264 OMX.  It works on the checkin before this landed (my patches for OMX H.264 cleanup landed a few hours after this, and had been tested before this landed).  I reverified using the pre-checkin patches and this rev and the previous rev; previous rev works, this one crashes the phone.

You need this:
pref("media.peerconnection.video.h264_enabled", true);
or equivalent user pref to enable it.

We'll need to back this out or land a fix very soon.
Thanks for the notification. I am going to check it soon.
Attachment #8428271 - Attachment is obsolete: true
I locally confirmed the fix. I am going to upload the patch soon.
Attached patch WebRTC crash fixSplinter Review
WebRTC crash fix. Carry "r=nical".
Attachment #8428805 - Flags: review+
set REOPENED depend on Comment 56.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #8428805 - Attachment description: patch_1006957_fix → WebRTC crash fix
:jesup, can you confirm the fix by attachment 8428805 [details] [diff] [review]?
Flags: needinfo?(rjesup)
Confirmed: inbound now works.  Thanks!
Flags: needinfo?(rjesup)
Thanks for the confirmation!
https://hg.mozilla.org/mozilla-central/rev/fdf86352fdb6
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Hmm, b2g v1.4 does not have Bug 924622 fix. It might affect to the crash.
FWIW, I'm trying to talk nical into writing backport patches for 30 and 31 :)
The crash happens because there is a cases that ImageBridgeParent is not destroyed until nsCycleCollector_shutdown(). I am going to add a workaround to prevent the crash for b2g-v1.4.
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #70)
> FWIW, I'm trying to talk nical into writing backport patches for 30 and 31 :)

Thanks!
(In reply to Sotaro Ikeda [:sotaro] from comment #71)
> The crash happens because there is a cases that ImageBridgeParent is not
> destroyed until nsCycleCollector_shutdown(). I am going to add a workaround
> to prevent the crash for b2g-v1.4.

I am just going to add a pointer check to AsyncTransactionTrackersHolder::ClearAllAsyncTransactionTrackers().
Add pointer check to AsyncTransactionTrackersHolder::ClearAllAsyncTransactionTrackers().
Attachment #8428859 - Attachment is obsolete: true
The following is the crash log that got from Comment 68. On gecko 30, ImageBridgeParent is destroyed by using Task. ImageBridge is not deleted within ShutdownXPCOM(). By Bug 924622, ImageBridgeParent becomes to be deleted within ShutdownXPCOM().

08:14:42     INFO -  Crash dump filename: /var/folders/Qp/Qp6yrDnSFsmnaUw0Wilc2k+++-k/-Tmp-/tmpa_1xFr.mozrunner/minidumps/F152F458-763B-47A7-A999-3340310D2F72.dmp
08:14:42     INFO -  Operating system: Mac OS X
08:14:42     INFO -                    10.6.8 10K549
08:14:42     INFO -  CPU: amd64
08:14:42     INFO -       family 6 model 23 stepping 10
08:14:42     INFO -       2 CPUs
08:14:42     INFO -  Crash reason:  EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
08:14:42     INFO -  Crash address: 0x8
08:14:42     INFO -  Thread 10 (crashed)
08:14:42     INFO -   0  XUL!mozilla::BlockingResourceBase::CheckAcquire(mozilla::CallStack const&) [BlockingResourceBase.cpp:6e420584d8bf : 94 + 0x0]
08:14:42     INFO -      rbx = 0x0000000000000000   r12 = 0x000000011c97a198
08:14:42     INFO -      r13 = 0x000000011c97a180   r14 = 0x000000011e080a60
08:14:42     INFO -      r15 = 0x000000011c0c6088   rip = 0x00000001019123f3
08:14:42     INFO -      rsp = 0x000000011e0809c0   rbp = 0x000000011e080a50
08:14:42     INFO -      Found by: given as instruction pointer in context
08:14:42     INFO -   1  XUL!mozilla::OffTheBooksMutex::Lock() [BlockingResourceBase.cpp:6e420584d8bf : 224 + 0x7]
08:14:42     INFO -      rbx = 0x0000000000000000   r12 = 0x000000011c97a198
08:14:42     INFO -      r13 = 0x000000011c97a180   r14 = 0x0000000000000000
08:14:42     INFO -      r15 = 0x000000011c0c6088   rip = 0x00000001019129ae
08:14:42     INFO -      rsp = 0x000000011e080a60   rbp = 0x000000011e080a70
08:14:42     INFO -      Found by: call frame info
08:14:42     INFO -   2  XUL!mozilla::layers::AsyncTransactionTrackersHolder::ClearAllAsyncTransactionTrackers() [Mutex.h:6e420584d8bf : 173 + 0x7]
08:14:42     INFO -      rbx = 0x000000011c0c6088   r12 = 0x000000011c97a198
08:14:42     INFO -      r13 = 0x000000011c97a180   r14 = 0x0000000000000000
08:14:42     INFO -      r15 = 0x000000011c0c6088   rip = 0x00000001022d6e27
08:14:42     INFO -      rsp = 0x000000011e080a80   rbp = 0x000000011e080aa0
08:14:42     INFO -      Found by: call frame info
08:14:42     INFO -   3  XUL!mozilla::layers::AsyncTransactionTrackersHolder::~AsyncTransactionTrackersHolder() [AsyncTransactionTracker.cpp:6e420584d8bf : 185 + 0x7]
08:14:42     INFO -      rbx = 0x000000011c0c6088   r12 = 0x000000011c97a198
08:14:42     INFO -      r13 = 0x000000011c97a180   r14 = 0x000000011c0c6050
08:14:42     INFO -      r15 = 0x000000011c0c5d60   rip = 0x00000001022d6926
08:14:42     INFO -      rsp = 0x000000011e080ab0   rbp = 0x000000011e080ac0
08:14:42     INFO -      Found by: call frame info
08:14:42     INFO -   4  XUL!mozilla::layers::ImageBridgeParent::~ImageBridgeParent() [CompositableTransactionParent.h:6e420584d8bf : 29 + 0xb]
08:14:42     INFO -      rbx = 0x000000011c0c5d60   r12 = 0x000000011c97a198
08:14:42     INFO -      r13 = 0x000000011c97a180   r14 = 0x000000011c0c6050
08:14:42     INFO -      r15 = 0x000000011c0c5d60   rip = 0x00000001022e84a4
08:14:42     INFO -      rsp = 0x000000011e080ad0   rbp = 0x000000011e080b10
08:14:42     INFO -      Found by: call frame info
08:14:42     INFO -   5  XUL!_ZThn752_N7mozilla6layers17ImageBridgeParentD0Ev [ImageBridgeParent.cpp:6e420584d8bf : 63 + 0x7]
08:14:42     INFO -      rbx = 0x000000011c0c5d60   r12 = 0x000000011c97a198
08:14:42     INFO -      r13 = 0x000000011c97a180   r14 = 0x00007fff5fbfe497
08:14:42     INFO -      r15 = 0x00007fff5fbfe498   rip = 0x00000001022e8368
08:14:42     INFO -      rsp = 0x000000011e080b20   rbp = 0x000000011e080b30
08:14:42     INFO -      Found by: call frame info
08:14:42     INFO -   6  XUL!mozilla::layers::DeleteImageBridgeSync [StaticPtr.h:6e420584d8bf : 158 + 0xb]
08:14:42     INFO -      rbx = 0x0000000000009403   r12 = 0x000000011c97a198
08:14:42     INFO -      r13 = 0x000000011c97a180   r14 = 0x00007fff5fbfe497
08:14:42     INFO -      r15 = 0x00007fff5fbfe498   rip = 0x00000001022e5410
08:14:42     INFO -      rsp = 0x000000011e080b40   rbp = 0x000000011e080b60
08:14:42     INFO -      Found by: call frame info
08:14:42     INFO -   7  XUL!MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) [message_loop.cc:6e420584d8bf : 344 + 0x8]
08:14:42     INFO -      rbx = 0x000000011e080cf8   r12 = 0x000000011c97a198
08:14:42     INFO -      r13 = 0x000000011c97a180   r14 = 0x0000000158a00c10
08:14:42     INFO -      r15 = 0x000000011e080bb0   rip = 0x0000000101ca3079
08:14:42     INFO -      rsp = 0x000000011e080b70   rbp = 0x000000011e080ba0
08:14:42     INFO -      Found by: call frame info
08:14:42     INFO -   8  XUL!MessageLoop::DoWork() [message_loop.cc:6e420584d8bf : 430 + 0xa]
08:14:42     INFO -      rbx = 0x000000011e080cf8   r12 = 0x000000011c97a198
08:14:42     INFO -      r13 = 0x000000011c97a180   r14 = 0x000000011e080bb8
08:14:42     INFO -      r15 = 0x000000011e080bb0   rip = 0x0000000101ca338a
08:14:42     INFO -      rsp = 0x000000011e080bb0   rbp = 0x000000011e080be0
08:14:42     INFO -      Found by: call frame info
08:14:42     INFO -   9  XUL!base::MessagePumpDefault::Run(base::MessagePump::Delegate*) [message_pump_default.cc:6e420584d8bf : 34 + 0x8]
08:14:42     INFO -      rbx = 0x000000011e080c18   r12 = 0x000000011c97a198
08:14:42     INFO -      r13 = 0x000000011c97a180   r14 = 0x000000011e080cf8
08:14:42     INFO -      r15 = 0x000000011e080c20   rip = 0x0000000101ca5e51
08:14:42     INFO -      rsp = 0x000000011e080bf0   rbp = 0x000000011e080c70
08:14:42     INFO -      Found by: call frame info
08:14:42     INFO -  10  XUL!MessageLoop::Run() [message_loop.cc:6e420584d8bf : 226 + 0x8]
08:14:42     INFO -      rbx = 0x000000011e080cf8   r12 = 0x000000011e080df8
08:14:42     INFO -      r13 = 0x0000000000009403   r14 = 0x000000011e080cf8
08:14:42     INFO -      r15 = 0x000000011c07d5e8   rip = 0x0000000101ca29a6
08:14:42     INFO -      rsp = 0x000000011e080c80   rbp = 0x000000011e080cc0
08:14:42     INFO -      Found by: call frame info
08:14:42     INFO -  11  XUL!base::Thread::ThreadMain() [thread.cc:6e420584d8bf : 162 + 0x7]
08:14:42     INFO -      rbx = 0x000000011c07d5c0   r12 = 0x000000011e080df8
08:14:42     INFO -      r13 = 0x0000000000009403   r14 = 0x000000011e080cf8
08:14:42     INFO -      r15 = 0x000000011c07d5e8   rip = 0x0000000101ca8ca0
08:14:42     INFO -      rsp = 0x000000011e080cd0   rbp = 0x000000011e080f00
08:14:42     INFO -      Found by: call frame info
08:14:42     INFO -  12  XUL!ThreadFunc [platform_thread_posix.cc:6e420584d8bf : 39 + 0x5]
08:14:42     INFO -      rbx = 0x000000011e081000   r12 = 0x0000000000000000
08:14:42     INFO -      r13 = 0x0000000000009403   r14 = 0x0000000101c93150
08:14:42     INFO -      r15 = 0x000000011c07d5c0   rip = 0x0000000101c9315a
08:14:42     INFO -      rsp = 0x000000011e080f10   rbp = 0x000000011e080f10
08:14:42     INFO -      Found by: call frame info
08:14:42     INFO -  13  libSystem.B.dylib + 0x39fd5
08:14:42     INFO -      rbx = 0x000000011e081000   r12 = 0x0000000000000000
08:14:42     INFO -      r13 = 0x0000000000009403   r14 = 0x0000000101c93150
08:14:42     INFO -      r15 = 0x000000011c07d5c0   rip = 0x00007fff86a74fd6
08:14:42     INFO -      rsp = 0x000000011e080f20   rbp = 0x000000011e080f50
08:14:42     INFO -      Found by: call frame info
08:14:42     INFO -  14  libSystem.B.dylib + 0x39e88
08:14:42     INFO -      rip = 0x00007fff86a74e89   rsp = 0x000000011e080f60
08:14:42     INFO -      rbp = 0x000000011e080f78
08:14:42     INFO -      Found by: stack scanning
08:14:42     INFO -  15  XUL + 0x39314f
08:14:42     INFO -      rip = 0x0000000101c93150   rsp = 0x000000011e081050
08:14:42     INFO -      Found by: stack scanning
(In reply to Sotaro Ikeda [:sotaro] from comment #76)
> https://tbpl.mozilla.org/?tree=Try&rev=dadffb68157d

tryserver result is not good. Need to add more pointer check.
Add more pointer checks.
Attachment #8430199 - Attachment is obsolete: true
Attachment #8430338 - Flags: review+
Depends on: 924622
FYI, you can safely ignore the mochitest-e10s and Android debug results (they were never intended to run on Gecko 30 anyway). As a general rule of thumb, you can safely ignore any test results for things you don't see running on a normal b2g30 run on TBPL.
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #80)
> FYI, you can safely ignore the mochitest-e10s and Android debug results
> (they were never intended to run on Gecko 30 anyway). As a general rule of
> thumb, you can safely ignore any test results for things you don't see
> running on a normal b2g30 run on TBPL.

Thanks. From it, attachment 8430338 [details] [diff] [review] seems good enough to check-in without bug 924622.
Keywords: checkin-needed
No longer depends on: 924622
See Also: → 1006164
Bug 1006164 is now resolved for us. Thanks Sotaro.
Depends on: 1019877
Depends on: 1020003
Depends on: 1022167
Depends on: 1029719
You need to log in before you can comment on or make changes to this bug.