1000525 - "pipe error: Bad file number" happens during running WindowTest app

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Sotaro Ikeda [:sotaro]]

During running "WindowTest" app. pipe connection of the app is broken.

STR:
* Run the test app at bug 964386 attachment 8366455 [details] on master b2g device.

Logcat log has the following log.

> 04-23 17:15:37.809   183   507 I Gecko   : [Parent 183] WARNING: pipe error: Bad file number: file ../../../gecko/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 709
> 04-23 17:15:37.809   183   507 I Gecko   : [Parent 183] WARNING: pipe error: Bad file number: file ../../../gecko/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 709
> 04-23 17:15:37.809   183   507 I Gecko   : [Parent 183] WARNING: pipe error: Bad file number: file ../../../gecko/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 709

Comment 1

[Sotaro Ikeda [:sotaro]]

The problem seems to be related too much file descriptors especially around code of Fence and gralloc. But each process does not open a lot of file descriptors.

Comment 2

[Sotaro Ikeda [:sotaro]]

I checked the file descriptor by using the following commands. The file descriptor number and "sync" seem not have a problem.

- | adb shell ls /proc/<b2g_pid>/fd | wc -w |
- | adb shell lsof | grep "sync" |

Comment 3

[Sotaro Ikeda [:sotaro]]

I tested on master nexus-4 and master nexus-5. On nexus-5, the problem seems to happen more easily.

Comment 4

[Sotaro Ikeda [:sotaro]]

When tiling is disabled, the problem seems not happens.

Comment 5

[Sotaro Ikeda [:sotaro]]

Nominate to 1.4+. When Bug 998504 is fixed on b2g v1.4, this problem becomes to happen on b2g v1.4

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

But the WindowTest app does not OOM?  What about the fd count for that process?

Comment 7

[Sotaro Ikeda [:sotaro]]

I already confirmed that SendCompositorRecycle() in TextureParent::CompositorRecycle() causes the problem. By commenting out the following, I confirmed that the problem does not happen.

>>    mozilla::unused << SendCompositorRecycle(handle);

http://mxr.mozilla.org/mozilla-central/source/gfx/layers/composite/TextureHost.cpp#643

Comment 8

[Sotaro Ikeda [:sotaro]]

"pipe error: Bad file number"  seems to happen that android::Fence is destroyed in b2g process side, before the Fence is delivered to client side.

Comment 9

[Sotaro Ikeda [:sotaro]]

Attachment: logcat log with enabling IPC log

Before "pipe error: Bad file number" happened, a lot of the following logout are present in the logcat. They were not reached to Child side.

> [PTextureParent] Sending Msg_CompositorRecycle([TODO])

Comment 10

[Sotaro Ikeda [:sotaro]]

By enabling IPC message log, I faced the b2g process crash because of PTexture protocol's problem. I am going to create a bug for it.

Comment 11

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #10)
> By enabling IPC message log, I faced the b2g process crash because of
> PTexture protocol's problem. I am going to create a bug for it.

Bug 1000660 is created for it.

Comment 12

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #8)
> "pipe error: Bad file number"  seems to happen that android::Fence is
> destroyed in b2g process side, before the Fence is delivered to client side.

android::Fence is kernel reference counted object, it needs to be keep alive in b2g process until the Fence is delivered to client side.

Comment 13

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #12)
> 
> android::Fence is kernel reference counted object, it needs to be keep alive
> in b2g process until the Fence is delivered to client side.

In current gecko, previous Fence is hold by TextureHostOGL.

Comment 14

[Sotaro Ikeda [:sotaro]]

(In reply to Ben Kelly [:bkelly] from comment #6)
> But the WindowTest app does not OOM?  What about the fd count for that
> process?

The app is not OOM. The following is b2g-procrank. Just pipe connection is broken. The fd count was 110.

--------------------------------
APPLICATION        PID       Vss      Rss      Pss      Uss  cmdline
b2g                184   268320K   90436K   74620K   67592K  /system/b2g/b2g
WindowTest        1168   112464K   43844K   31232K   28736K  /system/b2g/plugin-container
Homescreen         865    81072K   34188K   18600K   13836K  /system/b2g/plugin-container
Settings          1075    80476K   29692K   15791K   12660K  /system/b2g/plugin-container
Built-in Keyboa    966    66152K   21456K    8978K    6508K  /system/b2g/plugin-container
(Preallocated a   1344    59968K   18804K    7799K    5720K  /system/b2g/plugin-container
(Nuwa)             836    53776K   19584K    6678K    2348K  /system/b2g/plugin-container

Comment 15

[Sotaro Ikeda [:sotaro]]

I understand the cause of the problem. There is a case that Fence's file descriptor is still in IPC transter between TextureParent and TextureChild even after TextureParent is deleted. This happens because IPC message is async. Fence object is kept alive by TextureHost. But IPC's fence delivery is still in progress even after TextureHost is deleted.

Comment 16

[Sotaro Ikeda [:sotaro]]

Attachment: patch - Defer Fence release until IPC delivery complete

The patch defer Fence objects release until IPC delivery complete. If IPC connection is removed during delivery, defer Fence objects release some enough time for IPC message delivery complete.

Comment 17

[Sotaro Ikeda [:sotaro]]

attachment 8412960 [details] [diff] [review] borrows some code from 984434.

Comment 18

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #17)
> attachment 8412960 [details] [diff] [review] borrows some code from 984434.

Correction:
Bug 984434.

Comment 19

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #17)
> attachment 8412960 [details] [diff] [review] borrows some code from 984434.

The patch seems to fix the problem for the time being.

Comment 20

[Preeti Raghunath(:Preeti)]

(In reply to Sotaro Ikeda [:sotaro] from comment #19)
> (In reply to Sotaro Ikeda [:sotaro] from comment #17)
> > attachment 8412960 [details] [diff] [review] borrows some code from 984434.
> 
> The patch seems to fix the problem for the time being.

Are we saying bug 998504 has been fixed with this patch? Please confirm.

Comment 21

[Sotaro Ikeda [:sotaro]]

(In reply to Preeti Raghunath(:Preeti) from comment #20)
> (In reply to Sotaro Ikeda [:sotaro] from comment #19)
> > (In reply to Sotaro Ikeda [:sotaro] from comment #17)
> > > attachment 8412960 [details] [diff] [review] borrows some code from 984434.
> > 
> > The patch seems to fix the problem for the time being.
> 
> Are we saying bug 998504 has been fixed with this patch? Please confirm.

Yes. But the patch is not committable patch. Need to update it.

Comment 22

[Sotaro Ikeda [:sotaro]]

Attachment: patch v2 - Defer Fence release until IPC delivery complete

Some clean up.

Comment 23

[Sotaro Ikeda [:sotaro]]

attachment 8414487 [details] [diff] [review] has the following concerns.
- [1] To create AsyncTransactionTracker' serial ID, global mutex is used.
  Use the mutex because, gecko does not support 64bit atomic operation
- [2] To track Fence delivery, uses a lot of IPC message
- [3] Use timeout to defer releasing Fence objects, if there are in transit Fence objects when TextureParent is deleted.

Comment 24

[Sotaro Ikeda [:sotaro]]

Comment on attachment 8414487 [details] [diff] [review]
patch v2 - Defer Fence release until IPC delivery complete

nical, can I have a feedback to the patch?

Comment 25

[Sotaro Ikeda [:sotaro]]

> - [2] To track Fence delivery, uses a lot of IPC message

It might be better to defer [2] to a new bug.

Comment 26

[Sotaro Ikeda [:sotaro]]

Attachment: patch v3 - Defer Fence release until IPC delivery complete

un-bitrot.

Comment 27

[Sotaro Ikeda [:sotaro]]

Attachment: patch v4 - Defer Fence release until IPC delivery complete

Add missing files

Comment 28

[Sotaro Ikeda [:sotaro]]

Attachment: patch v5 - Defer Fence release until IPC delivery complete

Fix nits.

Comment 29

[Nicolas Silva [:nical]]

Comment on attachment 8414729 [details] [diff] [review]
patch v5 - Defer Fence release until IPC delivery complete

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

I am a little bit worried about the volume ipc messages this is adding (especially if we have a lot of tiles on the screen), but I don't know exactly how much overhead it will be.
I have an alternative proposition:
You want to receive a notification from the child side after it has received the fences so as to know that you can destroy them safely. The tricky thing is that PTexture is "short lived" in that we tend to create and destroy them often, so we need to be very careful about this notification not racing with PTexture deletion as well. But maybe we don't actually need to send this notification at the PTexture level. We could send a message from parent to child at the end of the composition, the child would send a reply and the deletion of fence objects could wait for this reply (a bit like this patch, but instead of doing it for each Texture, do it once per CompositableTransactionParent).
It might make things simpler because PCompositable and PImageBridge have synchronous shutdowns so it's easier to not race with that (compared to PTexture that is almost fully async), and it would reduce the volume of IPC messages (1 extra message per channel instead of one per texture). Also I think that if you do it this way you won't have to do the PostDelayedTask hack. 
How do you feel about this?

I'll set feedback- because I would prefer something along the lines of what I proposed above, but you can still convince me that we need your solution in the short term.

::: gfx/layers/client/TextureClient.cpp
@@ +105,5 @@
> +        FenceHandle fence = op.fence();
> +        if (mTextureClient) {
> +          mTextureClient->SetReleaseFenceHandle(fence);
> +        }
> +        if (IPCOpen()) {

If the child receives this after it sent SendRemove, the ChildAsyncMessage will reach a dead parent actor. If mTextureClient is null you are sure that SendRemove already happened but you could still get into trouble if ForceRemove was called manually on the TextureClient.

So my suggestion: turn this into

if (IPCOpen() && mTextureClient) 

and null out TextureChild::mTextureClient in ForceRemove.

Comment 30

[Sotaro Ikeda [:sotaro]]

(In reply to Nicolas Silva [:nical] from comment #29)
> Comment on attachment 8414729 [details] [diff] [review]
> patch v5 - Defer Fence release until IPC delivery complete
> 
> Review of attachment 8414729 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I am a little bit worried about the volume ipc messages this is adding
> (especially if we have a lot of tiles on the screen), but I don't know
> exactly how much overhead it will be.
> I have an alternative proposition:
> You want to receive a notification from the child side after it has received
> the fences so as to know that you can destroy them safely. The tricky thing
> is that PTexture is "short lived" in that we tend to create and destroy them
> often, so we need to be very careful about this notification not racing with
> PTexture deletion as well. But maybe we don't actually need to send this
> notification at the PTexture level. We could send a message from parent to
> child at the end of the composition, the child would send a reply and the
> deletion of fence objects could wait for this reply (a bit like this patch,
> but instead of doing it for each Texture, do it once per
> CompositableTransactionParent).
> It might make things simpler because PCompositable and PImageBridge have
> synchronous shutdowns so it's easier to not race with that (compared to
> PTexture that is almost fully async), and it would reduce the volume of IPC
> messages (1 extra message per channel instead of one per texture). Also I
> think that if you do it this way you won't have to do the PostDelayedTask
> hack. 
> How do you feel about this?

Yeah, I agree. I also thought same thing. But if we want to move both sending Fence and receiving the send result on CompositableTransactionParent level, the change could becomes very larger for b2g v1.4. So, I commented as in Comment 25. If we limit the change only to "receiving the send result on CompositableTransactionParent level" part, the change might be minimum.

Comment 31

[Nicolas Silva [:nical]]

(In reply to Sotaro Ikeda [:sotaro] from comment #30)
> (In reply to Nicolas Silva [:nical] from comment #29)
> > Comment on attachment 8414729 [details] [diff] [review]
> > patch v5 - Defer Fence release until IPC delivery complete
> > 
> > Review of attachment 8414729 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > I am a little bit worried about the volume ipc messages this is adding
> > (especially if we have a lot of tiles on the screen), but I don't know
> > exactly how much overhead it will be.
> > I have an alternative proposition:
> > You want to receive a notification from the child side after it has received
> > the fences so as to know that you can destroy them safely. The tricky thing
> > is that PTexture is "short lived" in that we tend to create and destroy them
> > often, so we need to be very careful about this notification not racing with
> > PTexture deletion as well. But maybe we don't actually need to send this
> > notification at the PTexture level. We could send a message from parent to
> > child at the end of the composition, the child would send a reply and the
> > deletion of fence objects could wait for this reply (a bit like this patch,
> > but instead of doing it for each Texture, do it once per
> > CompositableTransactionParent).
> > It might make things simpler because PCompositable and PImageBridge have
> > synchronous shutdowns so it's easier to not race with that (compared to
> > PTexture that is almost fully async), and it would reduce the volume of IPC
> > messages (1 extra message per channel instead of one per texture). Also I
> > think that if you do it this way you won't have to do the PostDelayedTask
> > hack. 
> > How do you feel about this?
> 
> Yeah, I agree. I also thought same thing. But if we want to move both
> sending Fence and receiving the send result on CompositableTransactionParent
> level, the change could becomes very larger for b2g v1.4. So, I commented as
> in Comment 25. If we limit the change only to "receiving the send result on
> CompositableTransactionParent level" part, the change might be minimum.

Ah yes sorry I wasn't clear. I meant to only move the "ok you are good to remove the fences" notification to the CompositableTransactionParent level for now. Sending the fence object to the TextureClient would still remain at the Texture level, so that you can fix this bug without having to rewrite too much of the existing code.

Comment 32

[Sotaro Ikeda [:sotaro]]

During debugging, I found strange symptom. LayerTransactionChild, ShadowLayerForwarder, LayerTransactionParent are increased for each window.open() and never destructed.

Comment 33

[Sotaro Ikeda [:sotaro]]

ShadowLayerForwarder leak seeem to be injected by Bug 933082. But LayerTransactionChild and LayerTransactionParent leaks seems to be present since Compositor were enabled.

LayerTransactionChild and LayerTransactionParent shutdowns are triggered from RenderFrameChild and RenderFrameParent. But this pass can be used only when LayerTransactionChild/LayerTransactionParent are generated via RenderFrameChild/RenderFrameParent. They create LayerTransactionChild/LayerTransactionParent only when CompositorChild is not present.

http://mxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.cpp#2434

Comment 34

[Sotaro Ikeda [:sotaro]]

I am going to create a bug for Comment 33.

Comment 35

[Sotaro Ikeda [:sotaro]]

Attachment: patch v6 - Defer Fence release until IPC delivery complete

Apply the comment.

Comment 36

[Sotaro Ikeda [:sotaro]]

Attachment: roll-up patch.

Update nits.

Comment 37

[Sotaro Ikeda [:sotaro]]

Attachment: patch part 1 - Add AsyncTransactionTracker

Comment 38

[Sotaro Ikeda [:sotaro]]

Attachment: patch part 2 - Change to TextureChild and TextureParent

Comment 39

[Sotaro Ikeda [:sotaro]]

Attachment: patch part 3 - Change around IPC code

Comment 40

[Sotaro Ikeda [:sotaro]]

Attachment: patch part 4 - Change to IPDL

Comment 41

[Sotaro Ikeda [:sotaro]]

Attachment: patch part 5 - Change to moz.build

Comment 42

[Nicolas Silva [:nical]]

Comment on attachment 8416000 [details] [diff] [review]
patch part 1 - Add AsyncTransactionTracker

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

::: gfx/layers/ipc/AsyncTransactionTracker.h
@@ +102,5 @@
> +  void ClearAllAsyncTransactionTrackers();
> +
> +  void DestroyAsyncTransactionTrackersHolder();
> +
> +protected:

nit: you don't need to write protected twice

Comment 43

[Sotaro Ikeda [:sotaro]]

Current patches has a dependency to Bug 1004191. It seem better to remove it. Bug 1004191 seems not easy to fix soon.

Comment 44

[Sotaro Ikeda [:sotaro]]

By only the current patch the following case is not handled correctly. On child side, ShadowLayerForwarder is destroyed without sending response to some FenceHandles deliveries.
- AsyncTransactionTrackers sent by parent since last CompositableParentManager::ReceiveCompositableUpdate().

Bug 1004191 covers this use case by killing LayerTransactionParent/LayerTransactionChild.

To remove the dependency, ShadowLayerForwarder or ClientLayerManager needs to send pending responses before their destruction.

Comment 45

[Sotaro Ikeda [:sotaro]]

The current patches store the pending transaction response Ids in CompositableForwarder. This seems not a good place to store them. The transaction lifetimes are tide to IPC protocol. It's better to store them on IPC object.

ImageBridggeChild is IPC object and derived from CompositableForwarder. ShadowLayerForwarder is derived from CompositableForwarder. But it is not IPC object and it's lifetime is shorter than LayerTransactionChild.

Comment 46

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #45)
> The current patches store the pending transaction response Ids in
> CompositableForwarder. This seems not a good place to store them. The
> transaction lifetimes are tide to IPC protocol. It's better to store them on
> IPC object.

I re-think about it. we do not need to change this. ShadowLayerForwarder is not destroyed until all TextureClients are destroyed.

Comment 47

[Sotaro Ikeda [:sotaro]]

> 
> I re-think about it. we do not need to change this. ShadowLayerForwarder is
> not destroyed until all TextureClients are destroyed.

Hmm, there is still a possibility that TOpDeliverFence message is received after ShadowLayerForwarder if we do not expect LayerTransactionChild shutdown.

Comment 48

[Sotaro Ikeda [:sotaro]]

> ::: gfx/layers/ipc/AsyncTransactionTracker.h
> @@ +102,5 @@
> > +  void ClearAllAsyncTransactionTrackers();
> > +
> > +  void DestroyAsyncTransactionTrackersHolder();
> > +
> > +protected:
> 
> nit: you don't need to write protected twice

It is just my preference to make clear the border beween functions and variables. It seems not common in gecko. I am going to update it in next patch.

Comment 49

[Sotaro Ikeda [:sotaro]]

Attachment: patch part 1 v2 - Add AsyncTransactionTracker

Apply the comment. Carry r=nical.

Comment 50

[Sotaro Ikeda [:sotaro]]

Attachment: patch part 3 v2 - Change around IPC code

Remove dependency to bug 1004191.

Comment 51

[Sotaro Ikeda [:sotaro]]

Attachment: patch part 4 v2 - Change to IPDL

Remove dependency to bug 1004191.

Comment 52

[Sotaro Ikeda [:sotaro]]

Attachment: patch part 3 v3 - Change around IPC code

Fix nits.

Comment 53

[Sotaro Ikeda [:sotaro]]

Attachment: roll-up patch

Comment 54

[Sotaro Ikeda [:sotaro]]

Comment on attachment 8416681 [details] [diff] [review]
patch part 4 v2 - Change to IPDL

nical, can you review the patch again. After the review, I added relatively big change.

Comment 55

[Sotaro Ikeda [:sotaro]]

Remove dependency to bug 1004191.

Comment 56

[Sotaro Ikeda [:sotaro]]

From Bug 1004191 Comment 31, attachment 8416681 [details] [diff] [review] seem to have a problem to ShadowLayerForwarder::~ShadowLayerForwarder(). Need to update it.

Comment 57

[Sotaro Ikeda [:sotaro]]

Attachment: patch part 3 v4 - Change around IPC code

Fix comment 56.

Comment 58

[Sotaro Ikeda [:sotaro]]

Attachment: roll-up patch

Comment 59

[Nicolas Silva [:nical]]

Comment on attachment 8416681 [details] [diff] [review]
patch part 4 v2 - Change to IPDL

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

r=me with the comment below addressed

::: gfx/layers/ipc/LayersMessages.ipdlh
@@ +440,5 @@
>  
> +union AsyncMessage {
> +  OpDeliverFence;
> +  OpReplyDeliverFence;
> +};

Please add two separate unions for child vs parent async messages, since the content of the messages are different.

Comment 60

[Nicolas Silva [:nical]]

Comment on attachment 8417020 [details] [diff] [review]
patch part 3 v4 - Change around IPC code

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

looks good to me

::: gfx/layers/ipc/ShadowLayers.cpp
@@ +702,3 @@
>  }
>  
> +void ShadowLayerForwarder::StopHandlePendingAsyncMessge()

nit: I was confused by the name of this method. Not sure about a better name. Maybe you could just put the two calls directly in ShadowLayerForwarder's destructor since it is the only user of this method.
Actually, maybe it's not that bad of a name, up to you. But since it is a short method and only called once I feel like it's just more readable to place its two lines directly in the caller. Not a big deal anyway.

Comment 61

[Sotaro Ikeda [:sotaro]]

(In reply to Nicolas Silva [:nical] from comment #60)
> Comment on attachment 8417020 [details] [diff] [review]
> patch part 3 v4 - Change around IPC code
> 
> Review of attachment 8417020 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> looks good to me
> 
> ::: gfx/layers/ipc/ShadowLayers.cpp
> @@ +702,3 @@
> >  }
> >  
> > +void ShadowLayerForwarder::StopHandlePendingAsyncMessge()
> 
> nit: I was confused by the name of this method. Not sure about a better
> name. Maybe you could just put the two calls directly in
> ShadowLayerForwarder's destructor since it is the only user of this method.

From Bug 1004191 Comment 31, we can not put the StopHandlePendingAsyncMessge() call to ShadowLayerForwarder's destructor. There is a risk that LayerTransactionChild is already closed, if the destructor is triggered by CompositorChild::Destroy().

Comment 62

[Sotaro Ikeda [:sotaro]]

I am going to add a comment about comment 61.

Comment 63

[Sotaro Ikeda [:sotaro]]

Attachment: patch v10 - Defer Fence release until IPC delivery complete

Apply the comments. Carry "r=nical".

Comment 64

[Sotaro Ikeda [:sotaro]]

https://tbpl.mozilla.org/?tree=Try&rev=88876aea53af

Comment 65

[Sotaro Ikeda [:sotaro]]

Attachment: patch v11 - Defer Fence release until IPC delivery complete

Un-bitrot. Carry "r=nical".

Comment 66

[Sotaro Ikeda [:sotaro]]

Attachment: patch v11 - Defer Fence release until IPC delivery complete

Un-bitrot. Carry "r=nical".

Comment 67

[Sotaro Ikeda [:sotaro]]

https://tbpl.mozilla.org/?tree=Try&rev=6e7e5dc4f059

Comment 68

[Sotaro Ikeda [:sotaro]]

Attachment: patch v12 - Defer Fence release until IPC delivery complete

Fix build failure on some platforms and add pointer checks. Carry "r=nical".

Comment 69

[Sotaro Ikeda [:sotaro]]

 https://tbpl.mozilla.org/?tree=Try&rev=06c4ce8f7392

Comment 70

[Sotaro Ikeda [:sotaro]]

Attachment: patch v13 - Defer Fence release until IPC delivery complete

Fix build failures on some platforms. Carry "r=nical".

Comment 71

[Sotaro Ikeda [:sotaro]]

https://tbpl.mozilla.org/?tree=Try&rev=fd97b23bc34e

Comment 72

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #71)
> https://tbpl.mozilla.org/?tree=Try&rev=fd97b23bc34e

Mutex leak is detected. It seems AsyncTransactionTracker's global mutex.

Comment 73

[Sotaro Ikeda [:sotaro]]

Attachment: patch v14 - Defer Fence release until IPC delivery complete

Fix Mutex leak.

Comment 74

[Sotaro Ikeda [:sotaro]]

https://tbpl.mozilla.org/?tree=Try&rev=619a0e0c17b6

Comment 75

[Sotaro Ikeda [:sotaro]]

https://hg.mozilla.org/integration/b2g-inbound/rev/4502fc99eb82

Comment 76

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/4502fc99eb82

Comment 77

[Sotaro Ikeda [:sotaro]]

I am going to create a patch for b2g v1.4.

Comment 78

[Sotaro Ikeda [:sotaro]]

Attachment: patch v14 for b2g v1.4 - Defer Fence release until IPC delivery complete

Patch for b2g v1.4.

Comment 79

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/bc284ce5dce4

Comment 81

[Ben Kelly [:bkelly, not reviewing]]

As far as I know this is an issue with fences which weren't introduced until JB.  Since tarako is based on ICS it should be unaffected.

Comment 82

[cafbot (PoC: ggrisco)]

Crash observed on: 

Device: msm8226
Firmware: AU_LABEL
Moz BuildID: 20140505000201
B2G Version: 1.4
Gecko Version: 30.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=fccb15d6940db51615545574877a62d69406b1c2
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=3ed3bbf1941e608bc9630942c7063a8b818f36bc

Comment 83

[Sotaro Ikeda [:sotaro]]

(In reply to caf-b2g-bot (PoC: ggrisco) from comment #82)
> Crash observed on: 
> 
> Device: msm8226
> Firmware: AU_LABEL
> Moz BuildID: 20140505000201
> B2G Version: 1.4
> Gecko Version: 30.0
> Gaia: 
> http://git.mozilla.org/?p=releases/gaia.git;a=commit;
> h=fccb15d6940db51615545574877a62d69406b1c2
> Gecko:
> http://git.mozilla.org/?p=releases/gecko.git;a=commit;
> h=3ed3bbf1941e608bc9630942c7063a8b818f36bc

The above liks's gecko does not include this bug's fix.