Closed
Bug 814549
Opened 8 years ago
Closed 8 years ago
nsAppShell destructor segfaults when no input reader thread is created (as happens in an OOP app)
Categories
(Firefox OS Graveyard :: General, defect)
Tracking
(blocking-basecamp:-, firefox18 fixed, firefox19 fixed, firefox20 fixed)
People
(Reporter: dhylands, Assigned: dhylands)
Details
Attachments
(3 files, 1 obsolete file)
2.69 KB,
text/plain
|
Details | |
39.39 KB,
text/plain
|
Details | |
1.41 KB,
patch
|
cjones
:
review+
gal
:
approval-mozilla-aurora+
gal
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
Device: otoro gaia: git://github.com/mozilla-b2g/gaia gaia: e1448496e18fd51aa79429617af99639e94828cb gecko: git://github.com/mozilla/releases-mozilla-central gecko: e5d9537ac01ac0da5dbb8cc73e2e2c7a80a30d46 I was using a debug build. I happened to be testing the same app when run in-process and it doesn't segfault when run in-process. STR: - Launch App (I tried Music and Calculator) - Once the app has finished displaying, press the HOME button - Back at the home screen, long press the home button. This brings up the thumbnail of whichever app you launched - swipe up to terminate the app. While terminating, the app will crash. This seems to be very close to the end of normal termination. It hits a segfault in nsAppShell destructor due to mReadThread being NULL. backtrace and logcat attached.
Assignee | ||
Comment 1•8 years ago
|
||
Assignee | ||
Comment 2•8 years ago
|
||
This bug has been around for a while, since it also happens in my other tree, which is currently based around Nov 9. The above backtrace was from a Nov 22 tree.
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → dhylands
Assignee | ||
Comment 3•8 years ago
|
||
Assignee | ||
Comment 4•8 years ago
|
||
After fixing the null mReaderThread, I now get the following: Program received signal SIGSEGV, Segmentation fault. android::SharedBuffer::release (this=0xfffffff0, flags=0) at frameworks/base/include/utils/SharedBuffer.h:139 139 return (mRefs == 1); (gdb) bt #0 android::SharedBuffer::release (this=0xfffffff0, flags=0) at frameworks/base/include/utils/SharedBuffer.h:139 #1 0x422490ac in android::terminate_string16 () at frameworks/base/libs/utils/String16.cpp:55 #2 0x422483a8 in ~LibUtilsFirstStatics (this=0xfffffff0, __in_chrg=<value optimized out>) at frameworks/base/libs/utils/Static.cpp:38 #3 0x4010bc34 in __cxa_finalize (dso=0x0) at bionic/libc/stdlib/atexit.c:158 #4 0x4010bfd0 in exit (status=0) at bionic/libc/stdlib/exit.c:57 #5 0x4010bfd0 in exit (status=0) at bionic/libc/stdlib/exit.c:57 Backtrace stopped: previous frame identical to this frame (corrupt stack?) which looks like a pointer with a negative index.
Assignee | ||
Comment 5•8 years ago
|
||
I filed bug 814783 to cover the segfault in comment 4
Assignee | ||
Comment 6•8 years ago
|
||
Attachment #684609 -
Attachment is obsolete: true
Assignee | ||
Updated•8 years ago
|
Summary: Segfault when closing OOP app → nsAppShell destructor segfaults when no input reader thread is created (as happens in an OOP app)
Assignee | ||
Updated•8 years ago
|
Attachment #684804 -
Flags: review?(jones.chris.g)
Assignee | ||
Comment 7•8 years ago
|
||
Related bugs (which also cause segfaults at app close time) are bug 814769 and bug 814783
Comment on attachment 684804 [details] [diff] [review] Patch to fix null mReaderThread dereference - v2 Oy, this code is so scary. Bug 783750 can't come soon enough :/.
Attachment #684804 -
Flags: review?(jones.chris.g) → review+
Assignee | ||
Comment 9•8 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/11d3d401116b
Comment 10•8 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/11d3d401116b
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 11•8 years ago
|
||
When I discovered this bug, the crash in bug 816671 was one of the segfaults I also encountered as a related problem. At the time I was only seeing the crash in debug builds, so I didn't nom it. But since we are in fact seeing the crash in bug 816671, I'm noming this one. There should be no risk associated with taking this patch for non-B2G platforms. The if statement that was introduced only prevents a segfault. Right now the only conditions for the segfault occuring are on B2G child content processes.
blocking-basecamp: --- → ?
Comment 12•8 years ago
|
||
Why should this block? I think you want an approval here.
Comment 13•8 years ago
|
||
a=me
Updated•8 years ago
|
blocking-basecamp: ? → -
Assignee | ||
Comment 14•8 years ago
|
||
Comment on attachment 684804 [details] [diff] [review] Patch to fix null mReaderThread dereference - v2 [Approval Request Comment] Bug caused by (feature/regressing bug #): User impact if declined: Crash reports Testing completed (on m-c, etc.): https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=11d3d401116b Risk to taking this patch (and alternatives if risky): almost none. The fix only prevents a segfault. So far the segfault is only observed in content children running as part of a debug build, but related crash from bug 816671 is now being observed on unagi devices. String or UUID changes made by this patch: None
Attachment #684804 -
Flags: approval-mozilla-beta?
Attachment #684804 -
Flags: approval-mozilla-aurora?
Updated•8 years ago
|
Attachment #684804 -
Flags: approval-mozilla-beta?
Attachment #684804 -
Flags: approval-mozilla-beta+
Attachment #684804 -
Flags: approval-mozilla-aurora?
Attachment #684804 -
Flags: approval-mozilla-aurora+
Comment 15•8 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/4e1ff094f22b https://hg.mozilla.org/releases/mozilla-beta/rev/25ec34410885
status-firefox18:
--- → fixed
status-firefox19:
--- → fixed
status-firefox20:
--- → fixed
Target Milestone: --- → B2G C2 (20nov-10dec)
You need to log in
before you can comment on or make changes to this bug.
Description
•