Re: Process (Xcode): 68 leaks for 3312 total leaked bytes.
Re: Process (Xcode): 68 leaks for 3312 total leaked bytes.
- Subject: Re: Process (Xcode): 68 leaks for 3312 total leaked bytes.
- From: Tom Bernard <email@hidden>
- Date: Sun, 09 Nov 2008 22:40:25 -0700
- Thread-topic: Process (Xcode): 68 leaks for 3312 total leaked bytes.
I have filed bug report 6356325
Xcode 3.1.1 leaks memory on launch
True that Xcode is a GUI over gcc etc. I am now motivated to generate a
really long compile task to run leaks on gcc. Is there a better way to do
this with a UNIX script? And are gcc, the compiler and linker also garbage
collected?
on 11/6/08 9:22 AM, j o a r at email@hidden wrote:
> On Nov 6, 2008, at 1:25 AM, Tom Bernard wrote:
>
>> $ leaks 192
>> Process 192: 140682 nodes malloced for 10482 KB
>> Process 192: 68 leaks for 3312 total leaked bytes.
>> ...
>>
>> This is immediately after launching Xcode shortly after power-up, no
>> projects open.
>>
>> Is this typical?
>
>
> If this sample is indeed taken right after starting Xcode, then per
> definition it probably have to be considered typical... Memory leaks
> is never a problem caused by the user, always an indication of a
> problem in the software product.
>
> That said, as a result of the development tools and technologies used
> in the industry today, I think that it's fair to say that all software
> have memory leaks. Some have less, some have more. Larger software
> products will have more leaks, simply because they contain more code.
> With this in mind, finding 68 leaks in Xcode, and with no indication
> that they have any other negative side effects, is not that big of a
> deal. Should these leaks still be hunted down and fixed? Absolutely,
> no doubt about that.
>
> Finally, Xcode is a garbage collected application nowadays (not sure
> which version you're using). The definition of what constitutes a
> memory leak is for the most part different between reference counted
> applications and garbage collected applications. In the former you
> typically refer to unreachable memory, and in the latter "unwanted
> subgraphs". While you can run the "leaks" command line tool on garbage
> collected applications, it's much less useful, and the interpretation
> of the results much more difficult.
on 11/6/08 2:39 AM, Lennart Thelander at email@hidden wrote:
> On 08-11-06 10.25, "Tom Bernard" <email@hidden> wrote:
>
> ... the app will
>> deliver solid code in spite of these leaks, then I am content to use it.
>
> The app doesn't deliver any code at all. It's just a GUI over gcc and other
> open source compilers and linkers.
on 11/6/08 2:30 AM, Thomas Davie at email@hidden wrote:
> On 6 Nov 2008, at 10:25, Tom Bernard wrote:
>
>> $ leaks 192
>> Process 192: 140682 nodes malloced for 10482 KB
>> Process 192: 68 leaks for 3312 total leaked bytes.
>> ...
>
> You should remember that no tool can accurately determine what is or
> isn't a leak -- they can only make conservative estimates and show you
> where you might want to look.
>
> It may be that Xcode is leaking, in which case I'm sure the Xcode team
> will look into it if you file a bug at radarweb.
> On the other hand, it may be that these aren't really leaks, but
> instead, the tool is being overly conservative in trying to figure out
> what is a leak.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden