580197 - Closing one tab for a site opened in multiple tabs causes application to freeze.

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[ahoza]

User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; en-US; rv:2.0b2pre) Gecko/20100718 Minefield/4.0b2pre
Build Identifier: Mozilla/5.0 (Android; Linux armv7l;en-US;rv:2.0b2pre) Gecko/20100717 Namoroka / 4.0b2pre Fennec/2.0a1pre

Fennec doesn't respond when closing "about:fennec" tab

Reproducible: Always

Steps to Reproduce:
Device: HTC Desire A8181

1.Launch Fennec.
2.Open yahoo.com in a new tab
3.Go to Options|Preferences and select "Go to page" button.
4.Slide screen to right to reveal tabs panel and close the one with "about:fennec"
Actual Results:  
Focus is on "yahoo.com" tab but "about:fennec" page content is displayed.
Cannot access Options menu nor to run the application in background with "Back" button.

Expected Results:  
Focus is on "yahoo.com" tab and displays proper information.
User should be able to access Options menu, open new tabs, send application in background

Comment 1

[ahoza]

Actually the problem is somewhere else:

1. Launch Fennec.
2. Open the same page in 2 different tabs.
3. Close one of the tabs.

Fennec freezes.

Comment 2

[Josh Matthews [:jdm]]

Confirmed.  I see a couple problems here - the child process crashes due to bug 579959, then warnings like this show up in the parent output:

###!!! ASSERTION: Recursive GetService!: 'Error', file /home/t_mattjo/src/firefox/mobilebase/xpcom/components/nsComponentManager.cpp, line 1629

and memory usage skyrockets.  I'm attaching the backtrace I get from the parent when I attach to it in gdb.

Comment 3

[Josh Matthews [:jdm]]

Attachment: Backtrace from parent

Comment 4

[Josh Matthews [:jdm]]

Attachment: Backtrace from parent

Whoops, wrong backtrace attached.

Comment 5

[Josh Matthews [:jdm]]

Attachment: Problem backtrack

The previous backtrace didn't look particularly suspicious, so I let it run some more.  This is the backtrace I got this time - the remaining several hundred frames are all CreateStack calls.  I assume this is an OOM problem, but I'm still not sure what caused it.

Comment 6

[Josh Matthews [:jdm]]

Whoops, I left off the top bit:


#0  0x08057566 in arena_bin_nonfull_run_get (arena=0xb777c040, bin=0xb777c1f8) at /home/t_mattjo/src/firefox/mobilebase/memory/jemalloc/jemalloc.c:3481
#1  0x08057840 in arena_bin_malloc_hard (arena=0xb777c040, bin=0xb777c1f8) at /home/t_mattjo/src/firefox/mobilebase/memory/jemalloc/jemalloc.c:3531
#2  0x08057fbe in arena_malloc_small (arena=0xb777c040, size=32, zero=false) at /home/t_mattjo/src/firefox/mobilebase/memory/jemalloc/jemalloc.c:3722
#3  0x080584be in arena_malloc (arena=0xb777c040, size=32, zero=false) at /home/t_mattjo/src/firefox/mobilebase/memory/jemalloc/jemalloc.c:3796
#4  0x0805859d in imalloc (size=32) at /home/t_mattjo/src/firefox/mobilebase/memory/jemalloc/jemalloc.c:3808
#5  0x0805cdc1 in malloc (size=32) at /home/t_mattjo/src/firefox/mobilebase/memory/jemalloc/jemalloc.c:5816
#6  0x00404b60 in moz_xmalloc (size=32) at /home/t_mattjo/src/firefox/mobilebase/memory/mozalloc/mozalloc.cpp:98
#7  0x01dab2a9 in operator new (cx=0xb45d2800, fp=0xb472657c, stack=0xa6d5afec) at ../../../../dist/include/mozilla/mozalloc.h:226
#8  XPCJSStackFrame::CreateStack (cx=0xb45d2800, fp=0xb472657c, stack=0xa6d5afec) at /home/t_mattjo/src/firefox/mobilebase/js/src/xpconnect/src/xpcstack.cpp:138

Comment 7

[Josh Matthews [:jdm]]

I was only able to reproduce this without the patch from bug 579959 applied, by closing a tab (thus crashing the child) and then closing another.  I was able to cause the memory spike to occur, then received some slow script warnings (apparently it is a larger issue than just bug 580474), and was finally able to open about:memory.  This caused the extreme memory usage to disappear, but not before showing me that content/canvas/2d_pixel_bytes is taking up 285,283,808 bytes, which looks much larger than I would expect.

Comment 8

[Josh Matthews [:jdm]]

The canvas appears to take up about 11 or 12mb in other non-triggering runs that I've investigated it, so that does look like a likely culprit.  I've also interrupted the grinding process in the middle of hundreds of XPCJSStackFrame::CreateStack calls with memory on the rise, as well as in the middle of hundreds of XPCJSStackFrame::~XPCJSStackFrame with memory pressure on a sharp decrease.  I'm still really stumped about the overall cause, other than a lack of content processes and a couple orphaned tabs.

Comment 9

[Josh Matthews [:jdm]]

More context on the CreateStack calls:

#911 0x01c1f34a in XPCJSStackFrame::CreateStack (cx=0xb66f5c00, fp=0xb461259c, stack=0xa220ab8c) at /home/t_mattjo/src/firefox/mobilebase/js/src/xpconnect/src/xpcstack.cpp:146
#912 0x01c1f34a in XPCJSStackFrame::CreateStack (cx=0xb66f5c00, fp=0xb46125f4, stack=0xa220ab6c) at /home/t_mattjo/src/firefox/mobilebase/js/src/xpconnect/src/xpcstack.cpp:146
#913 0x01c1f34a in XPCJSStackFrame::CreateStack (cx=0xb66f5c00, fp=0xb4612670, stack=0xbfd3b660) at /home/t_mattjo/src/firefox/mobilebase/js/src/xpconnect/src/xpcstack.cpp:146
#914 0x01c1ef59 in XPCJSStack::CreateStack (cx=0xb66f5c00, stack=0xbfd3b660) at /home/t_mattjo/src/firefox/mobilebase/js/src/xpconnect/src/xpcstack.cpp:90
#915 0x01bed232 in nsXPConnect::GetCurrentJSStack (this=0xb7515a50, aCurrentJSStack=0xbfd3b6c4) at /home/t_mattjo/src/firefox/mobilebase/js/src/xpconnect/src/nsXPConnect.cpp:1789
#916 0x01c13220 in nsXPCException::NewException (aMessage=0xa2245200 "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMCanvasRenderingContext2D.asyncDrawXULElement]", aResult=2147500037, 
    aLocation=0x0, aData=0x0, exceptn=0xbfd3b734) at /home/t_mattjo/src/firefox/mobilebase/js/src/xpconnect/src/xpcexception.cpp:466

#917 0x01c22015 in XPCThrower::BuildAndThrowException (cx=0xb66f5c00, rv=2147500037, sz=
    0xa2245200 "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMCanvasRenderingContext2D.asyncDrawXULElement]")
    at /home/t_mattjo/src/firefox/mobilebase/js/src/xpconnect/src/xpcthrower.cpp:232
#918 0x01c59cc5 in ThrowCallFailed (cx=0xb66f5c00, rv=2147500037, ifaceName=0xb67a1c65 "nsIDOMCanvasRenderingContext2D", memberName=0xa9e03760 "asyncDrawXULElement")
    at /home/t_mattjo/src/firefox/mobilebase/js/src/xpconnect/src/xpcquickstubs.cpp:588
#919 0x01c59d6f in xpc_qsThrowMethodFailed (cx=0xb66f5c00, rv=2147500037, vp=0xb46126b8) at /home/t_mattjo/src/firefox/mobilebase/js/src/xpconnect/src/xpcquickstubs.cpp:610
#920 0x01c6cb75 in nsIDOMCanvasRenderingContext2D_AsyncDrawXULElement (cx=0xb66f5c00, argc=7, vp=0xb46126b8) at dom_quickstubs.cpp:3496

AsyncDrawXULElement fails, and we spiral into badness, apparently.

Comment 10

[Josh Matthews [:jdm]]

Just to clarify, the frontend currently just calls this.render() again if AsyncDrawXULElement fails, which will endlessly recurse if the content process is dead.  This is obviously unacceptable.

Comment 11

[Josh Matthews [:jdm]]

I keep hearing reports of people being able to reproduce this, but I cannot.  I would really appreciate specific STR if this keeps cropping up.

Comment 12

[Doug Turner (:dougt)]

not seeing this in today's build.

Comment 13

[Stuart Parmenter]

wfm.  please reopen if someone can still reproduce

Comment 14

[Aakash Desai [:aakashd]]

WFM on build:

Mozilla/5.0 (X11; U; Linux armv71; Nokia N900; en-US; rv:2.0b4pre) Gecko/20100810 Namoroka/4.0b4pre Fennec/2.0a1pre

Comment 15

[Ioana Chiorean]

This is reproducible always with the build id : Mozilla /5.0 (X11;Linux
armv7l; rv:2.0b5pre)Gecko/20100825 Namoroka/4.0b5pre Fennec /2.0b1pre
Device: Nokia N900  
Prerequisites: Home Page is an about page (e.q.: about:home, about:firstrun, about:rights etc.)

Steps to Reproduce:
1.Open Fennec
2.Slide the webpage to the left to reveal the control tab, press the gear icon
3.In preferences press About Fennec -> Go to Page
4.Slide the webpage to the right to reveal tabs and close last tab (about:Fennec)

Comment 16

[ahoza]

Reproducible on HTC Desire A8181 as well with the above scenario. BuildID:Mozilla /5.0 (Android;Linux
armv7l; rv:2.0b5pre)Gecko/20100825 Namoroka/4.0b5pre Fennec /2.0b1pre

Reopen the bug.

Comment 17

[Matt Brubeck (:mbrubeck)]

(In reply to comment #15)
Those steps produce a crash on desktop and Android too.  The error is:

> chrome://browser/content/browser.js, line 861: this._selectedTab.isLoading is not a function"

This is a different bug than the one above, and should be filed separately.

Comment 18

[Matt Brubeck (:mbrubeck)]

I filed bug 590848 for the the new freeze from comment 15.  Thanks for catching it!

Comment 19

[Aakash Desai [:aakashd]]

verified FIXED on builds (using testcases reported in comment #0 and #1):

Mozilla/5.0 (X11; U; Linux armv71; Nokia N900; en-US; rv:2.0b5pre) Gecko/20100830 Namoroka/4.0b5pre Fennec/2.0a1pre

and

Mozilla/5.0 (Android; Linux armv71; Nokia N900; en-US; rv:2.0b5pre) Gecko/20100830 Namoroka/4.0b5pre Fennec/2.0a1pre

Comment 20

[Aakash Desai [:aakashd]]

We should add a testcase in our FFTs for this case.

Comment 21

[Ayan Shah[:ashah]]

Litmus test case added - https://litmus.mozilla.org/show_test.cgi?id=13531