Webshell leak on browser startup

RESOLVED DUPLICATE of bug 41172

Status

()

P3
normal
RESOLVED DUPLICATE of bug 41172
19 years ago
19 years ago

People

(Reporter: rusty.lynch, Assigned: rusty.lynch)

Tracking

Trunk
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Assignee)

Description

19 years ago
On browser startup, a webshell is leaked when running mozilla, but not
viewer.  Also, if auto-detection for character sets is turned on, two
webshells are leaked.  

To reproduce: 
	1. Startup the browser on any webpage (even about:blank) on
           a debug build. 
	2. exit and notice the debug message for the number of 
           webshells leaked. On at least Linux and Mac, a single
           webshell is leaked if character set auto-detection
           (as controled from the 'View'->'Character Coding' menu
            item) is turned off, but two shells leak if any character
            set auto-detection scheme is turned on.

NOTE: At least on Linux, viewer does not leak any webshells using
      the same test case.
(Assignee)

Comment 1

19 years ago
Actually, this bug covers more then one bug.  One of the webshell leaks
is dependant on character set auto-detection being turned on, it is 
reproducable even on about:blank. That bug is covered on bug #40149.

Although, even after #40149 is fixed as described in the bug report, another
webshell leak exist indepenant to character set auto-detection if a page
other then about:blank is visited.  I opened 10 top level windows from the
'File->New Navigator Window' menu and observed 5 webshell leaks on exit.

NOTE: The above test are after the fixing patch at bug #39796 has been applied
      to cut out some other webshell leaks.
Depends on: 39796, 40149
(Assignee)

Comment 2

19 years ago
Ok, found the problem.  The reason this webshell leak doesn't show up in viewer
is because viewer doesn't use cache (since viewer currently doesn't know where
to find the cache directory.)  

The problem comes up when the cache manager isn't able to initialize a new
listener in nsCachedNetData::InterceptAsyncRead() to replace the original 
listener.  A listener was directly created with a 'new' call, but if a 
call to the listener's Init() method fails, the InterceptAsyncRead() just
returns Init()'s return value, forgeting about the newly created listener.

Also, while I was rooting around in the protocol code looking for this guy, I
found a small problem in nsHTTPChannel.cpp that complicates the matter.
(Basicly, since InterceptAsyncRead() wasn't deleting the foobar listener
before returning a failure code, a call from the channel code that ignored
the return value and instead just tested for a non-null listener was fooled
into thinking the cache manager was successfull.)

This bug also shed light on another elusive bug, the cache is getting corrupted
somehow on (at least) a couple of my Linux builds (but not the one off the tip).
After all, if the cache works without a problem, the webshell leak will not show
up.  So, if you want to expose this webshell leak, you need to screw up the
cache.  (I've found that playing with the file permissions does the trick.)

I am attaching a patch.
(Assignee)

Comment 3

19 years ago
Created attachment 9257 [details]
tarball containing patch for nsHTTPChannel.cpp and nsCachedNetData.cpp
(Assignee)

Comment 4

19 years ago
changed component to Networking:Cache
Component: Browser-General → Networking: Cache

Comment 5

19 years ago
Sorry for the spam.  New QA Contact for Browser General.  Thanks for your help
Joseph (good luck with the new job) and welcome aboard Doron Rosenberg
QA Contact: jelwell → doronr

Comment 6

19 years ago
Can you reattach your patch? I cannot open it

Thanks,
Neeti
(Assignee)

Comment 7

19 years ago
Created attachment 9850 [details] [diff] [review]
patch for nsCachedNetData.patch
(Assignee)

Comment 8

19 years ago
Created attachment 9851 [details] [diff] [review]
patch for nsHTTPChannel.cpp
(Assignee)

Comment 9

19 years ago
It looks like some other people have been duplicating effort at bug #41172

*** This bug has been marked as a duplicate of 41172 ***
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 10

19 years ago
for http r=gagan
(Assignee)

Comment 11

19 years ago
patch checked in for http code.

Comment 12

19 years ago
my bad. See bug 43958 for the corrected HTTP patch. 
You need to log in before you can comment on or make changes to this bug.