Crash in GraphicBuffer::flatten()

RESOLVED FIXED

Status

defect
--
critical
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: mikeh, Assigned: mikeh)

Tracking

({crash})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [b2g-crash], crash signature)

Attachments

(1 attachment, 2 obsolete attachments)

I'm filing this bug so that any discussions/findings/comments/reviews will be free from >600 TBPL notifications.

What we know so far (thanks, :marshall_law):
- crash only happens on TBPL, so far unable to reproduce locally
- with this patch[1] applied,
- we see this output[2] (scroll to the bottom for logcat output)

1. https://hg.mozilla.org/try/rev/16abce400930
2. https://tbpl.mozilla.org/php/getParsedLog.php?id=21950180&tree=Try&full=1#error1

- crash happens when we call |flattenable->flatten(data, nbytes, fds, nfds)| [3], which is part of the AOSP layer
- TBPL uses a custom toolchain that we can't easily modify (see [4])

3. https://hg.mozilla.org/try/rev/16abce400930#l1.41
4. https://bugzilla.mozilla.org/show_bug.cgi?id=818103#c416
Status: NEW → ASSIGNED
Crash Signature: [@ libui.so@0xfadd]
Keywords: crash
Whiteboard: [b2g-crash]
I noticed that the crash is occuring at address 0x44400000

It would be useful to know if this is supposed to be beginning of the buffer (which would indicate that it was probably already freed), or if the buffer is earlier in memory and we're going past the end (and triggering the segfault on the first byte of a non-mapped page).
dhylands, that's easy enough to test.

Another data point: apparently this doesn't happen on the b2g18 branch, only on mozilla-central.
Another data point, we started seeing this sometime around New Years +/- a week. We didn't have crash detection back then, but I think it was the same problem. All I know for sure is that this didn't use to happen, and then it did.
dhylands, the buffer that the header+data is written into is allocated on the stack:
https://hg.mozilla.org/try/rev/16abce400930#l1.37

I've looked through this code a dozen times, and it seems to me that unless one of the GraphicBuffer members is modified asynchronously, this crash can't happen.
Bug 820316 might be related.
(In reply to Kan-Ru Chen [:kanru] from comment #5)
>
> Bug 820316 might be related.

I can't see that bug. CC me?
Posted patch Emulator patch (obsolete) — Splinter Review
Drop this patch into $B2G/development and:

patch -p1 < 867996_2013-05-13.patch
Attachment #748961 - Flags: feedback?(jgriffin)
Comment on attachment 748961 [details] [diff] [review]
Emulator patch

Never mind--git grabbed the wrong file. Stand by.
Attachment #748961 - Attachment is obsolete: true
Attachment #748961 - Flags: feedback?(jgriffin)
Posted patch Emulator patch (v2) (obsolete) — Splinter Review
Drop this patch into $B2G/development and:

patch -p1 < 867996_2013-05-13.patch
Attachment #748964 - Flags: feedback?(jgriffin)
Attachment #748964 - Attachment description: Emulator patch → Emulator patch (v2)
Depends on: 871795
Comment on attachment 748964 [details] [diff] [review]
Emulator patch (v2)

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

Clearing f? since I've made the emulator with this patch.
Attachment #748964 - Flags: feedback?(jgriffin)
Migrate the fix to this bug, since bug 818103's history is pretty messy.
Attachment #748964 - Attachment is obsolete: true
Attachment #749432 - Flags: review?(mwu)
Blocks: 872167
Attachment #749432 - Flags: review?(mwu) → review+
Duplicate of this bug: 820316
Bug 818103 will remain open to track uploading a new emulator build to the tinderbox.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.