Closed Bug 40218 Opened 25 years ago Closed 17 years ago

js code hangs onto channels too long

Categories

(SeaMonkey :: UI Design, defect, P3)

All
Windows NT
defect

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()
Keywords: mlk
=> Stephen Cox @ AOL
Assignee: ben → stephncox1
Stephen: You need to visit a jar: url like the one above.
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
Mitch can probably help with that problem.
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.
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.
QA Contact: sairuh → paw
paw, i don't think this belongs to me. perhaps cathy? should it remain in xp apps, or go over to another component? thx!
the problem is fixed, it is working. verified
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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 → ---
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
Please read the description of this bug.
Blocks: 92580
No longer blocks: 92580
Product: Core → Mozilla Application Suite
(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
^
actually, it was stephncox1@aol.com ^ but this is sufficiently old to close out
Status: NEW → RESOLVED
Closed: 24 years ago17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.