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)

x86_64
Linux
defect
Not set
normal

Tracking

(blocking-basecamp:-, firefox18 fixed, firefox19 fixed, firefox20 fixed)

RESOLVED FIXED
B2G C2 (20nov-10dec)
blocking-basecamp -
Tracking Status
firefox18 --- fixed
firefox19 --- fixed
firefox20 --- fixed

People

(Reporter: dhylands, Assigned: dhylands)

Details

Attachments

(3 files, 1 obsolete file)

Attached file backtrace
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.
Attached file logcat
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: nobody → dhylands
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.
I filed bug 814783 to cover the segfault in comment 4
Attachment #684609 - Attachment is obsolete: true
Summary: Segfault when closing OOP app → nsAppShell destructor segfaults when no input reader thread is created (as happens in an OOP app)
Attachment #684804 - Flags: review?(jones.chris.g)
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+
https://hg.mozilla.org/mozilla-central/rev/11d3d401116b
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
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: --- → ?
Why should this block? I think you want an approval here.
a=me
blocking-basecamp: ? → -
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?
Attachment #684804 - Flags: approval-mozilla-beta?
Attachment #684804 - Flags: approval-mozilla-beta+
Attachment #684804 - Flags: approval-mozilla-aurora?
Attachment #684804 - Flags: approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.