in nsHttpHandler::NewProxiedChannel: 1346 NS_NEWXPCOM(httpChannel, nsHttpChannel); 1347 if (!httpChannel) 1348 return NS_ERROR_OUT_OF_MEMORY; 1349 NS_ADDREF(httpChannel); 1350 1351 nsresult rv; 1352 1353 PRBool https; 1354 rv = uri->SchemeIs("https", &https); 1355 if (NS_FAILED(rv)) return rv; so if SchemeIs fails, httpChannel will never get deleted. I'd suggest moving the schemeIs call above NS_NEWXPCOM.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8alpha2
15 years ago
Attachment #150524 - Flags: review?(cbiesinger) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
It is a fixed memory leak bug, could it be considered for 1.7.1 ?
Comment on attachment 150524 [details] [diff] [review] v1 patch sr/a=sspitzer for 1.7.1. curious, did someone actually see this leak, or did someone find it while looking at the code? my guess is that if they saw it in action, we passed in null for the first arg, which sounds like broken code.
someone found this while looking at the code. > my guess is that if they saw it in action, we passed in null for the first arg, actually no, since _that_ would've lead to a crash. well... I guess you could call this a shutdown leak of this channel. ;)
It does not chekin to AVIARY_1_0_20040515_BRANCH.
You need to log in before you can comment on or make changes to this bug.