nsDataChannel::ParseData leaks on various failures

VERIFIED FIXED in mozilla1.1alpha

Status

()

Core
Networking
P1
normal
VERIFIED FIXED
16 years ago
15 years ago

People

(Reporter: bz, Assigned: bz)

Tracking

Trunk
mozilla1.1alpha
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

dataToWrite is leaked on all those wonderful |if (NS_FAILED(rv)) return rv;|
blocks that come after it has been allocated.  If we're dealing with non-text
data, dataBuffer is leaked as well.
Created attachment 79735 [details] [diff] [review]
Patch v1.0
to me
Assignee: new-network-bugs → bzbarsky
Priority: -- → P1
Target Milestone: --- → mozilla1.1alpha

Updated

16 years ago
Attachment #79735 - Flags: review+

Comment 3

16 years ago
Comment on attachment 79735 [details] [diff] [review]
Patch v1.0

Index: protocol/data/src/nsDataChannel.cpp

>@@ -204,12 +211,18 @@

>+        // XXX PL_Base64Decode will return a null pointer for decoding
>+        // errors.  Since those are more likely than out-of-memory,
>+        // should we return NS_ERROR_MALFORMED_URI instead?

how about NS_ERROR_UNEXPECTED?

nice work! sr=darin
Attachment #79735 - Flags: superreview+
Checked in on trunk, with NS_ERROR_UNEXPECTED as the error.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
This does not build on Windows, apparently.  I backed it out and will work on a
different fix.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
OK, this builds on windows if I move the      

PRUint32 dataLen = PL_strlen(dataBuffer);

line to before the goto that's above it.  So I'll be relanding this with that
change...
relanded
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 8

15 years ago
Verified per bzbarsky's comments.
Status: RESOLVED → VERIFIED
QA Contact: benc → junruh
You need to log in before you can comment on or make changes to this bug.