Re: After Autoreleasing Still Getting Leaked
Re: After Autoreleasing Still Getting Leaked
- Subject: Re: After Autoreleasing Still Getting Leaked
- From: Scott Ribe <email@hidden>
- Date: Wed, 15 Jun 2011 10:21:29 -0600
On Jun 15, 2011, at 10:02 AM, Bing Li wrote:
> char buffer[1024];
> ssize_t numberBytesReceived;
> while (true)
> {
> NSAutoreleasePool *loopPool = [[NSAutoreleasePool alloc]
> init];
> numberBytesReceived = recv(clientSocket, buffer, 1024, 0);
> if (numberBytesReceived > 0)
> {
> buffer[numberBytesReceived] = '\0';
So, if you receive 1024 bytes, you write past the end of the buffer. Now granted, you're only writing a 0 onto the least significant (assuming Intel) byte of numberBytesReceived, so it's not the source of your leak, but it's a pretty bad bug that's going to mess up your buffer contents for any buffer that's not a multiple of 256 bytes in length.
> for (int i = 0; i < 1024; i ++)
> {
> buffer[i] = '\0';
> }
That's pretty pointless isn't it?
> if (buffer[0] != '\0')
> {
> free(buffer);
> }
Seriously??? Freeing a stack buffer? Ouch. And the test? Why would you decide whether to free the block based on its contents?
I don't see offhand anything in this method that would cause a leak. But if this code is typical of the rest of the program, then you have bugs all over the place that corrupt memory which can lead to all sorts of things failing--including memory reclamation.
--
Scott Ribe
email@hidden
http://www.elevated-dev.com/
(303) 722-0567 voice
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden