Closed
Bug 40218
Opened 25 years ago
Closed 17 years ago
js code hangs onto channels too long
Categories
(SeaMonkey :: UI Design, defect, P3)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: warrensomebody, Assigned: jag+mozilla)
References
()
Details
(Keywords: memory-leak)
I've noticed that channels are being released when JS_GC runs instead of when
you go to the next page. Could there be some global in js that is hanging on to
channels too long? If so, this should be nulled out when you go to the next page
rather than waiting for gc. Here's where I caught it:
nsJARChannel::Close(nsJARChannel * const 0x03668758, unsigned int 0x00000000)
line 949
nsFileTransport::DoClose() line 857 + 33 bytes
nsFileTransport::~nsFileTransport() line 134
nsFileTransport::`scalar deleting destructor'(unsigned int 0x00000001) + 15
bytes
nsFileTransport::Release(nsFileTransport * const 0x03535b90) line 153 + 135
bytes
nsXPCWrappedNative::~nsXPCWrappedNative() line 390 + 27 bytes
nsXPCWrappedNative::`scalar deleting destructor'(unsigned int 0x00000001) + 15
bytes
nsXPCWrappedNative::Release(nsXPCWrappedNative * const 0x02e0f7e0) line 71 + 31
bytes
nsXPCWrappedNative::JSObjectFinalized(JSContext * 0x02d9fc70, JSObject *
0x02528718) line 96
WrappedNative_Finalize(JSContext * 0x02d9fc70, JSObject * 0x02528718) line 691
js_FinalizeObject(JSContext * 0x02d9fc70, JSObject * 0x02528718) line 1489 + 114
bytes
js_GC(JSContext * 0x02d9fc70) line 1035 + 11 bytes
js_ForceGC(JSContext * 0x02d9fc70) line 770 + 9 bytes
JS_GC(JSContext * 0x02d9fc70) line 1152 + 9 bytes
nsJSContext::GC(nsJSContext * const 0x02d9f200) line 1067 + 13 bytes
GlobalWindowImpl::SetNewDocument(GlobalWindowImpl * const 0x02d9f260,
nsIDOMDocument * 0x00000000) line 280
DocumentViewerImpl::~DocumentViewerImpl() line 406
DocumentViewerImpl::`scalar deleting destructor'(unsigned int 0x00000001) + 15
bytes
DocumentViewerImpl::Release(DocumentViewerImpl * const 0x0353f680) line 344 +
154 bytes
nsCOMPtr<nsIContentViewer>::assign_assuming_AddRef(nsIContentViewer *
0x00000000) line 449
nsCOMPtr<nsIContentViewer>::assign_with_AddRef(nsISupports * 0x00000000) line
820
nsCOMPtr<nsIContentViewer>::operator=(nsIContentViewer * 0x00000000) line 559
nsDocShell::SetupNewViewer(nsDocShell * const 0x02db6650, nsIContentViewer *
0x03532cf0) line 2256
nsWebShell::SetupNewViewer(nsWebShell * const 0x02db6650, nsIContentViewer *
0x03532cf0) line 559 + 13 bytes
nsDocShell::CreateContentViewer(nsDocShell * const 0x02db6650, const char *
0x0012f92c, nsIChannel * 0x035985d0, nsIStreamListener * * 0x0012f96c) line 2145
+ 24 bytes
nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x02db7260,
const char * 0x0012f92c, int 0x00000001, const char * 0x10099aa8
gCommonEmptyBuffer, nsIChannel * 0x035985d0, nsIStreamListener * * 0x0012f96c,
int * 0x0012f910) line 100 + 33 bytes
nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x035985d0, nsISupports *
0x00000000) line 326 + 109 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x03598500,
nsIChannel * 0x035985d0, nsISupports * 0x00000000) line 175 + 16 bytes
nsHTTPFinalListener::OnStartRequest(nsHTTPFinalListener * const 0x0359d840,
nsIChannel * 0x035985d0, nsISupports * 0x00000000) line 1146
InterceptStreamListener::OnStartRequest(InterceptStreamListener * const
0x03678220, nsIChannel * 0x035985d0, nsISupports * 0x00000000) line 1140
nsHTTPServerListener::FinishedResponseHeaders() line 1071 + 48 bytes
nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x036bdd80,
nsIChannel * 0x036be4e4, nsISupports * 0x035985d0, nsIInputStream * 0x036bcaec,
unsigned int 0x00000000, unsigned int 0x00000438) line 405 + 8 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x03677ab0)
line 406 + 47 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03677a60) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x03677a60) line 575 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x010791a0) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x002f03e4, unsigned int 0x0000c0fb, unsigned int
0x00000000, long 0x010791a0) line 1030 + 9 bytes
USER32! 77e71820()
Reporter | ||
Comment 2•24 years ago
|
||
Stephen: You need to visit a jar: url like the one above.
Comment 3•24 years ago
|
||
I can't seem to get the attached URL to load up. Mozilla spits out a failed
assertion and then promptly crashes. Here is the assertion:
"You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0'"
A closer trace shows that I get a seg fault when I'm in nsJARChannel::GetOwner
where GetCeritifcatePrincipal is called and then the failed assertion occurs.
Any ideas what is going on? Can someone verify this? I didn't see a bug report
posted anywhere concerning the problem I am having.
Status: NEW → ASSIGNED
Reporter | ||
Comment 4•24 years ago
|
||
Mitch can probably help with that problem.
Comment 5•24 years ago
|
||
Stephen,
I've seen the problem you're describing. I'm working on it this week;
basically, Warren and I are using the jar channel for different purposes and the
code has gotten a bit muddled. I may need to enlist his help in fixing this.
Comment 6•24 years ago
|
||
I don't know about the original problem here (about hanging onto channels too
long) but the problem mentioned in Stephen's post of 6/28 has been fixed, so this
testcase should work as described now.
Updated•24 years ago
|
QA Contact: sairuh → paw
Comment 7•24 years ago
|
||
paw, i don't think this belongs to me. perhaps cathy? should it remain in xp
apps, or go over to another component? thx!
Comment 8•24 years ago
|
||
the problem is fixed, it is working. verified
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 9•24 years ago
|
||
How do you know this is fixed? I'm willing to bet it isn't since we're leaking
channels now (e.g. file transport on shutdown). Fixing this would mean all
channels are being destroyed consistently from c++, not released when js runs
its gc.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 10•24 years ago
|
||
the page is loaded OK, displaying: "set your linker setup to link with the
winmm.lib windows multimedia library", no hangs, is it expected? I can't see the
source code to tell what it is suppose to do
Reporter | ||
Comment 11•24 years ago
|
||
Please read the description of this bug.
Comment 12•23 years ago
|
||
warren@zodiacnetworks.com / tephncox1@aol.com : Is this still a problem ?
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 13•17 years ago
|
||
(In reply to comment #12)
> warren@zodiacnetworks.com / tephncox1@aol.com : Is this still a problem ?
Matti, tephncox1 address is invalid. And afaict reporters, warren's, is also.
Assignee: stephncox1 → jag
Status: REOPENED → NEW
QA Contact: pawyskoczka
Comment 14•17 years ago
|
||
^
Comment 15•17 years ago
|
||
actually, it was stephncox1@aol.com
^
but this is sufficiently old to close out
Status: NEW → RESOLVED
Closed: 24 years ago → 17 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•