Closed Bug 606055 Opened 14 years ago Closed 14 years ago

Memory leaks on google.com with the Web Console open

Categories

(DevTools :: General, defect, P1)

Product:
DevTools
Component:
General
Type:
defect

Tracking

(blocking2.0 final+)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: pcwalton, Assigned: pcwalton)

References

(
URL
)

Details

(Keywords: memory-leak, perf, Whiteboard: [hardblocker]) 

STR:
(1) Open the Web Console. Make sure all filters are on.
(2) Load google.com.
(3) Press Cmd+Q to quit Firefox while a network request is going on.

Leaks result:

     |<----------------Class--------------->|<-----Bytes------>|<----------------Objects---------------->|<--------------References-------------->|
                                              Per-Inst   Leaked    Total      Rem      Mean       StdDev     Total      Rem      Mean       StdDev
   0 TOTAL                                          30      328  1110233        7 ( 2018.67 +/-  2543.38)  1162253        7 ( 1994.72 +/-  3597.43)
 345 nsDOMStorage                                  208      208        2        1 (    1.33 +/-     0.58)       14        1 (    3.33 +/-     1.27)
 348 nsDOMStorageItem                               80       80        2        1 (    0.67 +/-     0.58)       13        1 (    1.56 +/-     0.71)
 688 nsStringBuffer                                  8       40    34132        5 ( 7775.68 +/-  3343.51)    63776        5 (12355.03 +/-  4889.72)

nsTraceRefcntImpl::DumpStatistics: 866 entries
nsStringStats
 => mAllocCount:          30660
 => mReallocCount:         3472
 => mFreeCount:           30655  --  LEAKED 5 !!!
 => mShareCount:          29644
 => mAdoptCount:           2085
 => mAdoptFreeCount:       2085

---

Will need to diagnose more to figure out what's going on.
I don't think we're listening for browser shutdown events. The webconsole stays open and any network listeners we have registered stay active during the shutdown.
requesting blocking final.
blocking2.0: --- → ?
OS: Mac OS X → All
Hardware: x86 → All
Blocks: devtools4b8
(In reply to comment #3)
> we need to add the companion removeObserver to
> http://mxr.mozilla.org/mozilla-central/source/toolkit/components/console/hudservice/HUDService.jsm?force=1#2577

On topic "quit-application-granted" perhaps?
Depends on: 574127
blocking2.0: ? → final+
Assignee: nobody → mihai.sucan
David, if that's what we need to do to fix this memory leak, then I have a patch which does this in bug 597151.
(In reply to comment #5)
> David, if that's what we need to do to fix this memory leak, then I have a
> patch which does this in bug 597151.

perhaps we mark this as a dupe?
I have to first check if bug 597151 really solves this bug as well.
( please see bug 597151 comment 15 which tells the result of testing for this bug ... with the patch from 597151 applied )

Follow up: pulled from m-c today, removed my fx objdirs, and I get the same results. Not sure what to do. Any ideas?
Assignee: mihai.sucan → pwalton
Status: NEW → ASSIGNED
mass change: filter on PRIORITYSETTING
Blocks: devtools4
Priority: -- → P1
mass change: filter mail on BLOCKERSETTING
Severity: normal → blocker
ping. need an update on this blocker.
WFM now.

on shutdown I see this:

WARNING: nsExceptionService ignoring thread destruction after shutdown: file /home/ddahl/code/moz/mozilla-central/mozilla-central/xpcom/base/nsExceptionService.cpp, line 197
--DOMWINDOW == 4 (0xb395b7a4) [serial = 3] [outer = (nil)] [url = about:blank]
WARNING: not an nsIRDFRemoteDataSource: 'remote != nsnull', file /home/ddahl/code/moz/mozilla-central/mozilla-central/rdf/datasource/src/nsLocalStore.cpp, line 312
--DOMWINDOW == 3 (0xa3f638c4) [serial = 18] [outer = (nil)] [url = about:blank]
--DOMWINDOW == 2 (0xad74de24) [serial = 13] [outer = (nil)] [url = http://www.google.com/]
--DOMWINDOW == 1 (0xad74e7e4) [serial = 15] [outer = (nil)] [url = about:blank]
--DOMWINDOW == 0 (0xa3f62f04) [serial = 16] [outer = (nil)] [url = http://www.google.com/]
WARNING: NS_ENSURE_TRUE(!(mAsyncExecutionThread)) failed: file /home/ddahl/code/moz/mozilla-central/mozilla-central/storage/src/mozStorageConnection.cpp, line 656
WARNING: NS_ENSURE_TRUE(factory) failed: file /home/ddahl/code/moz/mozilla-central/mozilla-central/docshell/base/nsDocShell.cpp, line 10693
--DOCSHELL 0xae323a00 == 1
--DOCSHELL 0xad430800 == 0
nsStringStats
 => mAllocCount:          59609
 => mReallocCount:         3843
 => mFreeCount:           59609
 => mShareCount:          37950
 => mAdoptCount:           2737
 => mAdoptFreeCount:       2737

There is also this:

************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIObserverService.removeObserver]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource:///modules/HUDService.jsm :: HWO_uninit :: line 5588"  data: no]
************************************************************

Which is this line:  Services.obs.removeObserver(this, "content-document-global-created");
Mihai: do you see this problem? You were the last to reproduce it, but nearly a month ago...
I just got a leak on gmail.com, when quitting with the Web Console open while "Loading..." is on the screen:

 => mAllocCount:          68888
 => mReallocCount:         6944
 => mFreeCount:           68868  --  LEAKED 20 !!!
 => mShareCount:          88105
 => mAdoptCount:           7635
 => mAdoptFreeCount:       7635
Just reproduced on gmail.com, before logging in.
Mihai tells me that bug 599725 will probably fix this problem, so marking it as a dependency.
Depends on: 599725
We briefly discussed this on IRC, and I mentioned that the patch in bug 599725 does this.openRequests = {} (which clears any open requests), when the Web Console suspends / closes. This change may or may not solve this bug.

Patrick: please test with that patch applied and see if this issue is fixed. Thanks!
Severity: blocker → normal
Keywords: mlk
This seems to be fixed in bug 599725. Marking as a dependency.
How strongly do we believe that "seems to be"? Strongly enough to resolve this bug?
(In reply to comment #19)
> How strongly do we believe that "seems to be"? Strongly enough to resolve this
> bug?

Once bug 599725 lands, yes. I was the only one able to reproduce this AFAIK.
Fixed by bug 599725.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [hardblocker]
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.