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
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
