Closed
Bug 1060091
Opened 10 years ago
Closed 10 years ago
Crash while setting release fence of FB layer.
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1054929
blocking-b2g | 2.0+ |
People
(Reporter: sushilchauhan, Assigned: sotaro)
References
Details
(Keywords: crash, Whiteboard: [caf-crash 337][caf priority: p1][CR 716734][b2g-crash])
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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 ?
Sotaro, can you please check this stack trace ?
Flags: needinfo?(sotaro.ikeda.g)
[Blocking Requested - why for this release]:MTBF Stability issue
Blocks: CAF-v2.0-CC-metabug
blocking-b2g: --- → 2.0?
Sotaro this issue was seen when we landed the patch from Bug 1048639 to catch any wrong fd closures
(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
Updated•10 years ago
|
Severity: normal → critical
Updated•10 years ago
|
Whiteboard: [CR 716734][b2g-crash] → [caf priority: p1][CR 716734][b2g-crash]
Updated•10 years ago
|
Whiteboard: [caf priority: p1][CR 716734][b2g-crash] → [caf-crash 337][caf priority: p1][CR 716734][b2g-crash]
Comment 6•10 years ago
|
||
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
Assignee | ||
Comment 7•10 years ago
|
||
(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?
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → sotaro.ikeda.g
Flags: needinfo?(sushilchauhan)
Assignee | ||
Comment 8•10 years ago
|
||
Bug 1058366 and bug 1054929 could cause this crash like Bug 1054929 Comment 41.
Assignee | ||
Comment 9•10 years ago
|
||
And to analyze this problem only crash log does not help so much in some cases. A logcat log also becomes necessary.
Assignee | ||
Comment 10•10 years ago
|
||
From comment 7, it seems better to wait all other invalid fd bugs fixes, I think.
Reporter | ||
Comment 11•10 years ago
|
||
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 ?
Flags: needinfo?(tkundu)
Flags: needinfo?(sushilchauhan)
Flags: needinfo?(bhargavg1)
Comment 12•10 years ago
|
||
(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
Flags: needinfo?(bhargavg1)
(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)
Flags: needinfo?(tkundu)
Comment 14•10 years ago
|
||
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?
blocking-b2g: 2.0? → 2.0+
Flags: needinfo?(tkundu)
This bug is not reproducible after landing fix from bug 1054929
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(tkundu)
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•