Closed
Bug 814549
Opened 10 years ago
Closed 10 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•10 years ago
|
||
Assignee | ||
Comment 2•10 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•10 years ago
|
Assignee: nobody → dhylands
Assignee | ||
Comment 3•10 years ago
|
||
Assignee | ||
Comment 4•10 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•10 years ago
|
||
I filed bug 814783 to cover the segfault in comment 4
Assignee | ||
Comment 6•10 years ago
|
||
Attachment #684609 -
Attachment is obsolete: true
Assignee | ||
Updated•10 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•10 years ago
|
Attachment #684804 -
Flags: review?(jones.chris.g)
Assignee | ||
Comment 7•10 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•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/11d3d401116b
Comment 10•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/11d3d401116b
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 11•10 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•10 years ago
|
||
Why should this block? I think you want an approval here.
Comment 13•10 years ago
|
||
a=me
Updated•10 years ago
|
blocking-basecamp: ? → -
Assignee | ||
Comment 14•10 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•10 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•10 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
•