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)

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: 10 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.