Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#12152 closed bug (fixed)

Memory is not released after a failed call to realloc()

Reported by: philcostin Owned by: axeld
Priority: normal Milestone: Unscheduled
Component: Network & Internet/Stack Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

Please see attached patch.

Attachments (4)

patch.diff (554 bytes ) - added by philcostin 9 years ago.
improvedpatch.diff (682 bytes ) - added by philcostin 9 years ago.
Please review this. Thanks.
0001-When-realloc-address-size-returns-NULL-address-must-.patch (1.0 KB ) - added by philcostin 9 years ago.
0001-When-realloc-address-size-returns-NULL-address-must-.2.patch (1.0 KB ) - added by philcostin 9 years ago.
patch with suggestions from Janus

Download all attachments as: .zip

Change History (20)

by philcostin, 9 years ago

Attachment: patch.diff added

comment:1 by philcostin, 9 years ago

patch: 01

comment:2 by waddlesplash, 9 years ago

Resolution: junk
Status: newclosed

That's not a memory leak. Also, do you realize you're literally calling free(NULL) there?

comment:3 by philcostin, 9 years ago

I see what I've done there now yes, disregard the patch. However, the issue (although small) remains.

The first parameter to realloc() is not freed when the function returns null. The patch needs changing.

comment:4 by Janus, 9 years ago

Resolution: junk
Status: closedreopened

There is a memory leak.

comment:5 by Janus, 9 years ago

I can't remove "has a patch". If somebody has the proper permissions please remove it.

by philcostin, 9 years ago

Attachment: improvedpatch.diff added

Please review this. Thanks.

comment:6 by Janus, 9 years ago

Hi philcostin, you should use git format-patch to submit patch. (https://dev.haiku-os.org/wiki/CodingGuidelines/SubmittingPatches#Preparingtocreatepatchfile).

comment:7 by Janus, 9 years ago

For the Haiku guidelines:

sockaddr *resized -> sockaddr* resized

You can remove the else

if (resized == NULL) { 
	free(address); 
	return NULL; 
} 
address = resized; 

The patch with this changes looks good to me. Has somebody more to say?

by philcostin, 9 years ago

patch with suggestions from Janus

comment:8 by Janus, 9 years ago

Hi philcostin, I saw the full code of InterfaceAddress maybe this is not a memory leak. I leave the decision to someone who know the network stack better. The freed address is a member of the Interface class and could be used after the invalidation.

comment:9 by pulkomandy, 9 years ago

Hi,

Janus: you can't remove "has a patch" directly. The idea is that you mark the patch as "obsolete" and the "has a patch" will be removed automatically.

comment:10 by axeld, 9 years ago

Patch looks good, although I would remove the blank line between the allocation, and the check for its success. Thanks philcostin!

comment:11 by Janus, 9 years ago

Hi Axel,

I'm afraid that the code that invoke the Prepare doesn't check if the realloc worked. If the realloc fail, I think there are other problems other than the memory leak. The address passed as a parameter is still used. Am I wrong?

comment:12 by axeld, 9 years ago

I can't follow you there. There are three calls to Prepare(), one checks the result against NULL directly, the other two pass their result to the address module's set_to_defaults() which does check the parameters against NULL, too.

comment:13 by Janus, 9 years ago

Thanks Axel, that's all I want to know.

comment:14 by Barrett, 8 years ago

Just for the sake of not keeping one line patches open I'm going to apply it in the next days, if philcostin want can submit an updated patch :-) so that I don't have to add a follow-up fix.

comment:15 by Barrett, 8 years ago

Resolution: fixed
Status: reopenedclosed

Patch applied in hrev49985 with a follow-up fix with the intent to still reward you.

Version 0, edited 8 years ago by Barrett (next)

comment:16 by philcostin, 8 years ago

Not sure what happened there but so long as everyone agreed what the fix was, if indeed one ended up being needed at all then that's fine by me - I just re-found this ticket by accident :-)

Note: See TracTickets for help on using tickets.