1060091 - Crash while setting release fence of FB layer.

Status: RESOLVED DUPLICATE of bug 1054929

(Core :: Graphics: Layers, defect)

Description

[Sushil]

On overlay device, we are seeing a crash in the call which sets the release fence of FrameBuffer layer.

Here is crash signature:
326: [@ ? | pthread_kill | raise | __libc_android_abort | ? | close | android::Fence::~Fence() ]

Here is the stack trace:
bionic/libc/bionic/abort.cpp|55
bionic/libc/bionic/close.c|46
frameworks/native/libs/ui/Fence.cpp|44
system/core/include/utils/RefBase.h|183
system/core/include/utils/StrongPointer.h|152
frameworks/native/libs/gui/ConsumerBase.cpp|226
frameworks/native/libs/gui/ConsumerBase.cpp|200
gecko/widget/gonk/libdisplay/FramebufferSurface.cpp|159
gecko/widget/gonk/HwcComposer2D.cpp|610
gecko/widget/gonk/HwcComposer2D.cpp|813

The automation build has the patch which does an abort() if close(fd) returns error, given that fd != -1, which means someone else has already closed this fd.

The crash is at: ConsumerBase::addReleaseFenceLocked() at line # 226, which has Fence assignment statement:

mSlots[slot].mFence = mergedFence;

It would call ~Fence() on existing mSlots[slot].mFence object (before assignment), hence ~Fence() calls close() on corresponding fd, which is leading to crash. It means someone has already destroyed that Fence object and hence closed its corresponding fd.

Sotaro, can you please check the other possible paths in this file which can modify mSlots[slot].mFence ?

Comment 1

[Sushil]

Sotaro, can you please check this stack trace ?

Comment 2

[bhargavg1]

[Blocking Requested - why for this release]:MTBF Stability issue

Comment 3

[bhargavg1]

Sotaro this issue was seen when we landed the patch from Bug 1048639 to catch any wrong fd closures

Comment 4

[bhargavg1]

(In reply to bhargavg1 from comment #3)
> Sotaro this issue was seen when we landed the patch from Bug 1048639 to
> catch any wrong fd closures

Oops I meant Bug 1057220

Comment 5

[Sushil]

Attachment: bug_1060091_stack_trace

I have attached stack trace file of this crash.

Comment 6

[cafbot (PoC: ggrisco)]

Observed on: 

Device: msm8226
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.6.01.04.00.000.073
Moz BuildID: 20140826000204
B2G Version: 2.0
Gecko Version: 32.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=a51633e29a7826b6bf07cb1c5ad81b3217b9820a
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=8f121f8fa5fa1a3e82967f91e2afe337465fc593

Comment 7

[Sotaro Ikeda [:sotaro]]

(In reply to Sushil from comment #0)
> Sotaro, can you please check the other possible paths in this file which can
> modify mSlots[slot].mFence ?

I do not think the android's ConsumerBase and BufferQueue have a problem. I assume that actual invalid cause is different like Bug 1054929 Comment 41.

The crash of comment 6 still do not have a fix of 1054929. Does a rom of causing the crash have fixes of Bug 1058366 and bug 1054929?

Comment 8

[Sotaro Ikeda [:sotaro]]

Bug 1058366 and bug 1054929 could cause this crash like Bug 1054929 Comment 41.

Comment 9

[Sotaro Ikeda [:sotaro]]

And to analyze this problem only crash log does not help so much in some cases. A logcat log also becomes necessary.

Comment 10

[Sotaro Ikeda [:sotaro]]

From comment 7, it seems better to wait all other invalid fd bugs fixes, I think.

Comment 11

[Sushil]

Sotaro,

Yes, I also believe so. If someone else in b2g process is closing an fd which is stale or which it should not close, then such an issue can cause this crash in b2g process. This crash looks consequence of that.

Tapas & Bhargav,

Does the build have fixes from Bug 1058366 and 1054929 ?

Comment 12

[bhargavg1]

(In reply to Sushil from comment #11)
> Sotaro,
> 
> Yes, I also believe so. If someone else in b2g process is closing an fd
> which is stale or which it should not close, then such an issue can cause
> this crash in b2g process. This crash looks consequence of that.
> 
> Tapas & Bhargav,
> 
> Does the build have fixes from Bug 1058366 and 1054929 ?

Fix for bug 1058366 has landed in the build when the issue was seen. 

I believe even the bug 1054929 has landed bug would like to have Tapas confirm on the same

Comment 13

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to bhargavg1 from comment #12)
> I believe even the bug 1054929 has landed bug would like to have Tapas
> confirm on the same

Bug 1054929 has landed in AU74. We should wait to see if it comes in >= AU74

Interesting point is that close() stack trace is different here than what we we saw in bug 1058368 (dup of Bug 1054929)

Comment 14

[Milan Sreckovic [:milan] (needinfo for best results)]

We could leave this as 2.0?, but it's either going to be fixed by AU74 (bug 1054929), in which case 2.0+ won't hurt, or, if it isn't fixed by that, we still need to fix it.  So, I think 2.0+ is the right flag for it now, even if it isn't actionable until we get AU74 results back.  Tapas, when do we expect those?

Comment 15

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

This bug is not reproducible after landing fix from bug 1054929