Closed
Bug 580197
Opened 14 years ago
Closed 14 years ago
Closing one tab for a site opened in multiple tabs causes application to freeze.
Categories
(Firefox for Android Graveyard :: General, defect)
Firefox for Android Graveyard
General
Tracking
(fennec2.0a1+)
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
fennec | 2.0a1+ | --- |
People
(Reporter: ahoza, Assigned: jdm)
References
Details
(Whiteboard: closetab)
Attachments
(2 files, 1 obsolete file)
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
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.
Summary: Closing about:fennec after previously opening it via "Go to page" in Options|Preferences causes application to freeze → Closing one tab for a site opened in multiple tabs causes application to freeze.
Assignee | ||
Comment 2•14 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 3•14 years ago
|
||
Assignee | ||
Comment 4•14 years ago
|
||
Whoops, wrong backtrace attached.
Attachment #458702 -
Attachment is obsolete: true
Assignee | ||
Comment 5•14 years ago
|
||
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.
Assignee | ||
Updated•14 years ago
|
OS: Android → All
Hardware: ARM → All
Assignee | ||
Comment 6•14 years ago
|
||
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
Updated•14 years ago
|
tracking-fennec: --- → 2.0a1+
Assignee | ||
Comment 7•14 years ago
|
||
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.
Assignee | ||
Comment 8•14 years ago
|
||
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.
Assignee | ||
Comment 9•14 years ago
|
||
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.
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → josh
Assignee | ||
Comment 10•14 years ago
|
||
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.
Assignee | ||
Comment 11•14 years ago
|
||
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.
Updated•14 years ago
|
Whiteboard: closetab
Comment 12•14 years ago
|
||
not seeing this in today's build.
Comment 13•14 years ago
|
||
wfm. please reopen if someone can still reproduce
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Comment 14•14 years ago
|
||
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
Status: RESOLVED → VERIFIED
Comment 15•14 years ago
|
||
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)
Reporter | ||
Comment 16•14 years ago
|
||
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.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Comment 17•14 years ago
|
||
(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.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Comment 18•14 years ago
|
||
I filed bug 590848 for the the new freeze from comment 15. Thanks for catching it!
Comment 19•14 years ago
|
||
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
Status: RESOLVED → VERIFIED
Updated•14 years ago
|
Assignee: josh → ayanshah62
Updated•14 years ago
|
Assignee: ayanshah62 → josh
Flags: in-litmus? → in-litmus?(ayanshah62)
Comment 21•14 years ago
|
||
Litmus test case added - https://litmus.mozilla.org/show_test.cgi?id=13531
Flags: in-litmus?(ayanshah62) → in-litmus+
You need to log in
before you can comment on or make changes to this bug.
Description
•