Re: After Autoreleasing Still Getting Leaked
Re: After Autoreleasing Still Getting Leaked
- Subject: Re: After Autoreleasing Still Getting Leaked
- From: Marcus Karlsson <email@hidden>
- Date: Thu, 16 Jun 2011 13:49:54 +0200
On Jun 16, 2011, at 12:33 PM, Bing Li wrote:
> Dear Conrad, Jens, Tony, Scott, Wade and all,
>
> I appreciate so much for your replies. I learn a lot from the interactions
> with you. Since I am new, your patience is so valuable to me!
>
> I just got the problem. At least, right now, there is no the leak. When
> receiving messages, I put them into a queue. However, I forgot implementing
> a dealloc for it and I also did not release it when the connection was
> disconnected. After the bug was fixed, the leaking issue was solved.
Well done.
> But I still have a question. The queue is actually derived from NSArray. It
> should be empty after when the connection was disconnected. Why was there
> such a huge leak?
In your snippet that you sent earlier you allocated memory in an infinite loop. It's not uncommon that such loops keeps going for a large number of iterations when things goes wrong. Even if you leak just a little bit of data for each iteration, the sum of leaked memory can become very big.
> For the TCP issues, I planned to change my current solution. I will send the
> length of the buffer first and then send the real data. I have ever done
> that on .NET. The difference is that this time I need to exchange messages
> among different OSs (Java/Linux and iOS). So XML is used. On .NET, I just
> use its serialization technique. I am not sure if I need to consider little
> endian/big endian issues? My iMac is an Intel CPU. I don't need to do that,
> right? What about iPad/iPhone?
It's not uncommon that network protocols have the length included somewhere in the beginning. But it's not a bullet-proof solution and you still have to handle the possibility of getting fragmented data. If you're not dealing with persistent connections then maybe an even simpler approach could be to just keep reading until he remote socket is closed.
XML is already encoded so you don't need to convert it according to endianness. It's only when you're transmitting raw bytes directly over the network when you need to do that. As long as you have defined your protocol and how you encode and decode the transmitted data it doesn't matter which operating system or CPU architecture is on each end. The serialization you've used earlier is just one way of doing that. In the end it's just bits that goes over the wire, whether it's XML or your own binary format doesn't matter.
> When implementing multi-threading, NSOperationQueue is used in my system. I
> don't create threads explicitly unless in some specific cases, for example,
> a streaming control thread pool.
>
> The major reason I intend to use sockets is that I attempt to design a P2P
> communication protocol when transmitting data over the Internet. I also did
> that successfully on .NET. I think a controllable socket is more flexible
> although its programming is difficult a little bit.
I'm not particularly familiar with NSOperationQueue and don't know how well it works for network operations. I often use the CFNetwork API:s which I recommend that you take a look at.
> I will learn Cocoa programming continually and carefully. Thanks so much for
> your help again!
>
> Best regards,
> Bing
>
>
>
> On Thu, Jun 16, 2011 at 4:10 AM, Conrad Shultz <
> email@hidden> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 6/15/11 12:50 PM, Bing Li wrote:
>>> Jens,
>>>
>>> Thanks so much for your suggestions!
>>>
>>> I wonder why it works fine according to Activity Monitor if such a huge
>> leak
>>> exists. The consumed memory in the Activity Monitor is stable and much
>>> smaller unless some threads are created at a high concurrent moment.
>> After
>>> the threads are dead, the consumed memory becomes stable and small. I
>> feel
>>> weird for this.
>>
>> Honestly, I feel like you are not listening to the excellent responses
>> people are giving you.
>>
>> 1) Activity Monitor is not a profiling tool. Don't use it as such. Use
>> Leaks/Allocations, maybe with some heapshot analysis thrown in as I
>> believe I mentioned a while back.
>>
>> 2) Analyze your code with the Clang static analyzer ("Build & Analyze").
>> This will shake out many common memory issues (and more).
>>
>> 3) Recognize that posting snippets of the code that you THINK might be
>> responsible for a leak does not mean that people on the list can
>> actually help you find it. For example, even if you are doing
>> everything completely properly inside a function, if that function
>> returns some object, the calling code can still leak that object.
>>
>> 4) It seems as if much of your code is multi-threaded. All else being
>> equal, this makes such problems even harder to debug. If I were having
>> such serious issues, I would probably spend some time trying to get the
>> task to work on the main thread and only once that is thoroughly
>> debugged would I break it up across threads. (This won't work for every
>> type of problem, but if it can work for you, I'd do it.)
>>
>> 5) As others have commented, there is substantial evidence that your
>> code probably has issues other than memory management. If you are, for
>> example, smashing the stack in your C code, all bets are off and you
>> really need to fix that first.
>>
>> It's been so long since you first started posting that I've forgotten
>> what you are trying to do. You are communicating in a high level format
>> (XML), yet all your code seems to concern very low level network
>> behaviors (opening sockets, reading bytes, et cetera). I wonder whether
>> you are over-engineering all this. What is your goal?
>>
>> - --
>> Conrad Shultz
>>
>> Synthetiq Solutions
>> www.synthetiqsolutions.com
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.7 (Darwin)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iD8DBQFN+RG8aOlrz5+0JdURAjRNAJ9YCKwfHbB6iICdmKARupttOoJkMQCdG5TT
>> ZAaJuogqgVGHjKxS4sqA8pw=
>> =RkC+
>> -----END PGP SIGNATURE-----
>>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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