why does apple suck?

[stupidregister]

I can't believe I read all this. Who cares?

Apparently you do.

 

[gr8tfly]

Of course it is deallocated on exit. Memory deallocation on exit is handled by the operating system. Memory leaks typically refer to unneeded memory that is not deallocated while the program is still running, not when it exits. If the memory stayed allocated even after program exit, that would lead to major problems and the OS would be to blame.

Ok. I'm not entirely sure what your point is, since you're contradicting yourself by first saying deallocation's a given when the process exits, then acknowledging leaks can also occur in the OS.

What's does it have to do with the OP, who was blowing a single application issue out of proportion? I was pointing out the problem doesn't seem to exist at the OS level - it becomes a non-issue as soon as the process exits.

Leaks can happen anywhere. In this case, we're most likely talking about a leak caused by TextEdit.

 

[mkrishnan]

Are you kidding? This calls for wiping the hard drive and reinstalling everything!

I'm going to do it right now, while I'm thinking about it.

Good idea. Take a bath also!

 

[stupidregister]

Ok. I'm not entirely sure what your point is, since you're contradicting yourself by first saying deallocation's a given when the process exits, then acknowledging leaks can also occur in the OS.

How did I contradict myself? The keyword in my post was "typically". As in memory leaks typically refer to leaks in the program.

What's does it have to do with the OP, who was blowing a single application issue out of proportion? I was pointing out the problem doesn't seem to exist at the OS level - it becomes a non-issue as soon as the process exits.

Actually, after reading your post again, I think I misread it the first time. When I read "However, it's all deallocated upon exit", I thought you were saying that because of that it would not be considered a memory leak.

This is significant because for example, Firefox is criticized for leaking memory. But it does not leak memory to the point that the memory is lost even after its exit. The memory is only lost while the program is running.

 

[gr8tfly]

How did I contradict myself? The keyword in my post was "typically". As in memory leaks typically refer to leaks in the program.

Actually, after reading your post again, I think I misread it the first time. When I read "However, it's all deallocated upon exit", I thought you were saying that because of that it would not be considered a memory leak.

This is significant because for example, Firefox is criticized for leaking memory. But it does not leak memory to the point that the memory is lost even after its exit. The memory is only lost while the program is running.

I guess it was the "Of course". It sounded as if you were saying leaks were always in a process and fixed on exit, then brought up the OS as a source too. Sorry if I took it too literally.

Sounds like we have the same point to make here - if the leak is confined to the process, it's much less of a concern. Certainly, nothing to reflect on the entire OS. S*** happens.

 

[Veri]

3) Observe ~6 megs of "real memory" usage.
4) Create 900 empty new text windows.
5) Observe approx ~780 MB of real memory usage. (Again, this is still ok.)
6) Option-click a close box and watch all windows close.
7) Observe ~49 MB of memory usage.

First, a simple counterexample to the leak assertion:

1) int main() {
2) // Observe 288KB usage.
3) buf = malloc(32*MB);
4) // Observe 4KB usage increase.
5) for (i=0; i<5*MB; i++) buf=0x69;
6) // Observe 5MB usage increase.

It's almost as if OS X has demand paging, so it's safe to preallocate a large buffer at startup which isn't actually going to take up any memory until you write to it. We could even make it as large as, say, 43MB?

Taking advantage of this, perhaps the ObjC garbage collecting memory manager sometimes reserves and frees large chunks at once. Why make repeated expensive calls to the OS to alloc/dealloc teensy little blocks when your user appears to be madly increasing usage, then madly decreasing? Especially when the machine has loadsa free physical RAM cos the user is using his C2D MBP to do nothing but open 900 TextEdit windows.

Point is, your illustration does not prove that TextEdit has a memory hole, let alone that "apple sucks" . If you want to do more than make unjustified extrapolation, Apple provides the source for TextEditPlus and the swanky TextEdit with a Quartz Composer About dialog.

If you find a leak in TextEdit, never mind, it's just a toy editor, but it's worth reporting the bug. If you can isolate the behaviour as being due to a leak in some shared framework, well done, and please also report it. Until then, you'd be well advised to browse to this helpful list and read rules 26, 27, 44, 55, but take rule 35 less literally. For future complaints, observe rule 10. And then, to assist in dismounting the high horse, 24 and 30 might help.

 

[cmaier]

After reading all of this, I am still trying to figure out how this is being called a memory leak. Oh, its not.

This is a rather common "issue", although its not, with ALL OSs. Even OS 9 on back did this.

A memory leak is when a program starts using RAM when not called for and keeps doing so even until there is even no RAM available. Its like overfilling a bath tub.

Um, no it's not. You are confused.

This is a memory leak:

char *x;
for (unsigned i=0;i<10;i++) {
x=new char[100];
}

I allocate but don't deallocate memory, so it remains unavailable until the program ends. Regardless of whether or not I use all the memory.

 

[gr8tfly]

First, a simple counterexample to the leak assertion:

1) int main() {
2) // Observe 288KB usage.
3) buf = malloc(32*MB);
4) // Observe 4KB usage increase.
5) for (i=0; i<5*MB; i++) buf=0x69;
6) // Observe 5MB usage increase.

It's almost as if OS X has demand paging, so it's safe to preallocate a large buffer at startup which isn't actually going to take up any memory until you write to it. We could even make it as large as, say, 43MB?

Taking advantage of this, perhaps the ObjC garbage collecting memory manager sometimes reserves and frees large chunks at once. Why make repeated expensive calls to the OS to alloc/dealloc teensy little blocks when your user appears to be madly increasing usage, then madly decreasing? Especially when the machine has loadsa free physical RAM cos the user is using his C2D MBP to do nothing but open 900 TextEdit windows.

Point is, your illustration does not prove that TextEdit has a memory hole, let alone that "apple sucks" . If you want to do more than make unjustified extrapolation, Apple provides the source for TextEditPlus and the swanky TextEdit with a Quartz Composer About dialog.

If you find a leak in TextEdit, never mind, it's just a toy editor, but it's worth reporting the bug. If you can isolate the behaviour as being due to a leak in some shared framework, well done, and please also report it. Until then, you'd be well advised to browse to this helpful list and read rules 26, 27, 44, 55, but take rule 35 less literally. For future complaints, observe rule 10. And then, to assist in dismounting the high horse, 24 and 30 might help.

I had the same thoughts. Without knowing the design and/or having access to the code, you can only say there's a possible leak. The memory usage data in Activity Monitor is only a coarse indication of what's actually going on in the application.

 

[darkwing]

So much to reply to, and far too much laziness to quote:

I've already submitted bugs before. They obviously have too many to deal with.

gr8tfly, In any operating system with memory management, there is no such thing as "garbage collection" on exit of a program. The OS simply releases all pages assigned to that program (and decreases reference counts on shared pages such as shared libraries, etc.) This is not a new feature. This is a very old concept. If a program allocates stuff during its use and can't return to its original state of memory usage, then it has a leak. This means that the program cannot run for an indefinite time. All programs should be able to do that, except little chips that fire detonators. This issue isn't single to TextEdit, btw. TextEdit was used as an example because the entire program is (mostly) written using Cocoa controls and little code. This is a Cocoa problem.

psychofreak, I'm not a troll except that I like pointing out flaws and watching people drink the cool-aid. I have a masters in computer science and have been in the industry for over 10 years, and simply hate what I see. I'm not bitter that Apple didn't hire me when I sent them a resume. I included a cover letter listing a lot of reasons why their code sucks and how I can make it better. Their loss, not mine.

tyr2, I agree that some aspects feel faster. I find that WindowServer now has a glitch where if something happens on the screen (opening a new window or something) then scrolling in another window will glitch. It used to be smoother. While the thread creation won't be a lot for you to notice with Cocoa apps (that use only a few threads each) certain types of servers (which should be using thread pools anyway!) may create/destroy thousands of threads every second. The extra CPU cycles will take their toll.

unity, A memory leak occurs when a program creates some state, which requires memory, and then when it returns to its original state, doesn't release all memory used for the previous state back to the operating system. I ran into these cases many times with Cocoa programming. I actually thought it was my fault until I started doing tests like these. When you run out of memory and swapfile space, the OS will have to kill whatever program it thinks is the worst offender. Linux used to refer to this as the OOM (out of memory) killer.

stupidregister gets it.

Veri, I've done what you're talking about years ago. OSX does in fact use a form of demand paging. You can allocate up to your 2 GB per process of RAM on a 32-bit OS (haven't tried Leopard's 64-bit support yet) and those pages will show up in ActivityMonitor's "VSIZE field but not in the "RM" field. However, what your test fails to notice is that once you free that memory, the RM decreases. You may notice when starting up TextEdit, the VSIZE is actually almost 1 GIG of memory, while only 6 megs of real memory are being used. If you seriously believe that after opening and then closing a ton of windows TextEdit has any business not freeing the extra memory it used, then I feel sorry for you. I should have made myself clear in my original post that I'm pointing out leaks in the Cocoa framework and not in TextEdit itself. Thanks for helping me realize that. BTW, if you do my test, you'll notice that once you close all the Windows the VSIZE field also shows leaks. This contradicts your assertion that it's only because it's used memory that it was allocated, and this memory is only available to the system until used once.

gr8tfly, to understand what the RM field in ActivityMonitor is, I suggest looking at the source code to "top" from opendarwin. It's actually statistics on paging as collected by Mach.

I love how all the Mac fans are making excuses for Apple. Warms my heart every time. All praise be to the mighty bitten fruit.

 

[adrianblaine]

I love how all the Mac fans are making excuses for Apple. Warms my heart every time. All praise be to the mighty bitten fruit.

Life is full of choices. Unfortunately, most of the time it comes down to choosing the lesser of two evils. Issues like the one you were describing does not matter to the average person. Most people just want a computer that is easy to use and just works. Apple supplies that better than some others. That's not defending or making excuses, it's just the way it is.

 

[kresh]

never mind, not worth it

 

[cmaier]

So much to reply to, and far too much laziness to quote:

I've already submitted bugs before. They obviously have too many to deal with.

gr8tfly, In any operating system with memory management, there is no such thing as "garbage collection" on exit of a program. The OS simply releases all pages assigned to that program (and decreases reference counts on shared pages such as shared libraries, etc.) This is not a new feature. This is a very old concept. If a program allocates stuff during its use and can't return to its original state of memory usage, then it has a leak. This means that the program cannot run for an indefinite time. All programs should be able to do that, except little chips that fire detonators. This issue isn't single to TextEdit, btw. TextEdit was used as an example because the entire program is (mostly) written using Cocoa controls and little code. This is a Cocoa problem.

psychofreak, I'm not a troll except that I like pointing out flaws and watching people drink the cool-aid. I have a masters in computer science and have been in the industry for over 10 years, and simply hate what I see. I'm not bitter that Apple didn't hire me when I sent them a resume. I included a cover letter listing a lot of reasons why their code sucks and how I can make it better. Their loss, not mine.

tyr2, I agree that some aspects feel faster. I find that WindowServer now has a glitch where if something happens on the screen (opening a new window or something) then scrolling in another window will glitch. It used to be smoother. While the thread creation won't be a lot for you to notice with Cocoa apps (that use only a few threads each) certain types of servers (which should be using thread pools anyway!) may create/destroy thousands of threads every second. The extra CPU cycles will take their toll.

unity, A memory leak occurs when a program creates some state, which requires memory, and then when it returns to its original state, doesn't release all memory used for the previous state back to the operating system. I ran into these cases many times with Cocoa programming. I actually thought it was my fault until I started doing tests like these. When you run out of memory and swapfile space, the OS will have to kill whatever program it thinks is the worst offender. Linux used to refer to this as the OOM (out of memory) killer.

stupidregister gets it.

Veri, I've done what you're talking about years ago. OSX does in fact use a form of demand paging. You can allocate up to your 2 GB per process of RAM on a 32-bit OS (haven't tried Leopard's 64-bit support yet) and those pages will show up in ActivityMonitor's "VSIZE field but not in the "RM" field. However, what your test fails to notice is that once you free that memory, the RM decreases. You may notice when starting up TextEdit, the VSIZE is actually almost 1 GIG of memory, while only 6 megs of real memory are being used. If you seriously believe that after opening and then closing a ton of windows TextEdit has any business not freeing the extra memory it used, then I feel sorry for you. I should have made myself clear in my original post that I'm pointing out leaks in the Cocoa framework and not in TextEdit itself. Thanks for helping me realize that. BTW, if you do my test, you'll notice that once you close all the Windows the VSIZE field also shows leaks. This contradicts your assertion that it's only because it's used memory that it was allocated, and this memory is only available to the system until used once.

gr8tfly, to understand what the RM field in ActivityMonitor is, I suggest looking at the source code to "top" from opendarwin. It's actually statistics on paging as collected by Mach.

I love how all the Mac fans are making excuses for Apple. Warms my heart every time. All praise be to the mighty bitten fruit.

Yeah, it sounds like the framework. Assuming that textedit was compiled with garbage collection, "release" won't do anything until it decides to collect garbage. I haven't seen any technical discussion yet of the the garbage collection algorithm.

When I get my mac i'll compile some code with and without garbage collection turned on and see if i can figure out the behavior.

 

[Rodimus Prime]

It is easier to look at memory useage in windows I think just because I can see the exact amount of ram being used by each program but this is beside the point more using it just to explain some things.
I noticed in Windows that some programs will eat up a lot of ram over time (outlook, word, itunes) the thing is it will hold on to that memory until it is needed. It seems until system free ram drops below around 30% of max ram windows does little about clearing it. It is not because of poor coding and memory leaks windows does this but it good coding in the OS. It is a waste of time and processor cycles to free up the ram when there is still a lot of free unused ram there. Now when it is gets to the point it need to free some up yeah it goes though and just does it pretty quickly.

Same with apple why waste the time cleaning up the ram if there is still a lot open to be used. At a certain point the OS will make a point of cleaning the ram but not until at least the 30-40% range.

 

[gr8tfly]

So much to reply to, and far too much laziness to quote:

I've already submitted bugs before. They obviously have too many to deal with.

gr8tfly, In any operating system with memory management, there is no such thing as "garbage collection" on exit of a program. The OS simply releases all pages assigned to that program (and decreases reference counts on shared pages such as shared libraries, etc.) This is not a new feature. This is a very old concept. If a program allocates stuff during its use and can't return to its original state of memory usage, then it has a leak. This means that the program cannot run for an indefinite time. All programs should be able to do that, except little chips that fire detonators. This issue isn't single to TextEdit, btw. TextEdit was used as an example because the entire program is (mostly) written using Cocoa controls and little code. This is a Cocoa problem.

gr8tfly, to understand what the RM field in ActivityMonitor is, I suggest looking at the source code to "top" from opendarwin. It's actually statistics on paging as collected by Mach.

I love how all the Mac fans are making excuses for Apple. Warms my heart every time. All praise be to the mighty bitten fruit.

Releasing allocated memory IS garbage collection. It doesn't matter who does it. If you read my other post here, you would have known I already know what a memory leak is. Whatever.

Since you're a frequent poster, you must know it's near impossible to know the level of knowledge or experience of another poster. It's usually better to start of at the highest level and work down. I have no idea what your experience is and you have no idea of mine. There are many that panic when just looking at the VM size in Activity Monitor, without understanding its meaning. It's just as easy to make the assumption that data taken from a cursory test done on the application (TextEdit in this case) could be misinterpreted. I agree, if you had pointed out you had an idea of where the leak was originating (i.e. Cocoa), beyond just "TextEdit has a memory leak", there would have been different responses by myself and others.

As for the memory data - I'm well aware of "top". Again, I have no idea what your experience is, so I can't make the assumption you know anything beyond Activity Monitor. There's no purpose in discussing "top".

The argument I have (and others) is the thread title and your leap to condemning the entire engineering staff (and company) because they let loose with a bug. Since you do claim to have software development experience and "a solid computer science background", that leap makes no sense whatsoever. There are extremely few examples of bugs that can be directly related to a design, let alone a complete design philosophy ("...they clearly have no interest in making...").

I would defend any engineering effort the same way - this isn't a "fan boy" thing.

Hummm - I just re-read another part of your last response. You have a masters, plus 10 years experience, and yet start a thread with the title "Why does apple suck?". :/ ok. edit: sorry - if that came across wrong. The background didn't seem to mix with the title.

 

[doobi18]

oh you are so right. this is definately going to be a serious probelm for all of those hardcore textedit users who frequently open up more than a few docs at a time, let alone, say, 1000!



i guess i'd better go buy vista instead


</sarcasm>

 

[darkwing]

Life is full of choices. Unfortunately, most of the time it comes down to choosing the lesser of two evils. Issues like the one you were describing does not matter to the average person. Most people just want a computer that is easy to use and just works. Apple supplies that better than some others. That's not defending or making excuses, it's just the way it is.

This is a very good point. I redact my cool-aid statement. Especially since it should have been spelled "kool-aid."

Yeah, it sounds like the framework. Assuming that textedit was compiled with garbage collection, "release" won't do anything until it decides to collect garbage. I haven't seen any technical discussion yet of the the garbage collection algorithm.

When I get my mac i'll compile some code with and without garbage collection turned on and see if i can figure out the behavior.

This is a good point. However, no matter how long you let it sit there, the GC doesn't run. If the GC is running in a mode where it sits there with the memory taken, then the pages weren't freed anyway. If it works where the OS eventually signals the application to begin GC, then this is a crappy method. The fact that the memory does decrease (albeit it not to the correct point) as each window vanishes this tells me that there is either no GC being used, or it's being freed anyway. Keep in mind that Cocoa wasn't re-written for Leopard, and it's probably not likely that Apple would choose to re-write it to use GC when that has additional overhead.

Also, this is in Leopard's "man gcc" page:

-fobjc-gc
Enable garbage collection (GC) for Objective-C objects. The
resulting binary requires additional runtime support which is not
present in any released version of Mac OS X.

It's possible that this is old, however.

Also, previous versions of Mac OSX have this problem.

It is easier to look at memory useage in windows I think just because I can see the exact amount of ram being used by each program but this is beside the point more using it just to explain some things.
I noticed in Windows that some programs will eat up a lot of ram over time (outlook, word, itunes) the thing is it will hold on to that memory until it is needed. It seems until system free ram drops below around 30% of max ram windows does little about clearing it. It is not because of poor coding and memory leaks windows does this but it good coding in the OS. It is a waste of time and processor cycles to free up the ram when there is still a lot of free unused ram there. Now when it is gets to the point it need to free some up yeah it goes though and just does it pretty quickly.

I submit that it'd take more overhead to free a page but mark it as "takeable" by the application allocator and keep it active. This yields the same functionality as the OS allocator anyway, and basically amounts to duplicate code. I've already done experiments that when I malloc something and fill it, my RM goes up. When I free it, my RM drops immediately.

gr8tfly, I love the title of my post! Apple tells us constantly of all the problems with Microsoft while they continue to have the same problems themselves. (Sometimes worse!) I agree that it's better to work your way down, but you started that process by posting. While I agree my approach may not have been the best one to take in my post, I think I still make a valid argument. We should discuss that issue and not reduce it to arguing about the argument.

BTW, garbage collection is, by definition, an automatic freeing of allocated memory. If you explicitly free pages, then you aren't using GC. You use GC so you don't have to do that. The OS isn't doing it either, as it's wiping out everything. GC is selective! If it wiped out everything while the program is running you'd have a frustrated user.

Personally, I think that programs that rely on GC should self delete. Until then, I won't ever like GC. (but that's another debate)

 

[dukebound85]

as long as stuff works im a happy camper

 

[gr8tfly]

gr8tfly, I love the title of my post! Apple tells us constantly of all the problems with Microsoft while they continue to have the same problems themselves. (Sometimes worse!) I agree that it's better to work your way down, but you started that process by posting. While I agree my approach may not have been the best one to take in my post, I think I still make a valid argument. We should discuss that issue and not reduce it to arguing about the argument.

BTW, garbage collection is, by definition, an automatic freeing of allocated memory. If you explicitly free pages, then you aren't using GC. You use GC so you don't have to do that. The OS isn't doing it either, as it's wiping out everything. GC is selective! If it wiped out everything while the program is running you'd have a frustrated user.

Personally, I think that programs that rely on GC should self delete. Until then, I won't ever like GC. (but that's another debate)

Yea, I think it was more the way it started that evoked the reactions.

Glad you clarified the relation to MS. It is a bit embarrassing for those of us who like to stand behind Apple when they "call the kettle black".

I agree one shouldn't rely on an automatic solution, but I still have to argue (I like to argue) with the definition. It was still called "garbage collection" long before becoming "automatic".

 

[Wayfarer]

I only got to 345 and got bored...

 

[Nutter]

AFAIK, the only app shipping with Leopard that uses garbage collection is Xcode.

 

[Bigtree]

And his computer didn't FREEZE? I would say, that's pretty good!!!!

 

[aceducy]

You're just hateful. That's all. All of you that say bad things about Apple are just Apple haters. All of you Microsoft people just hate everything, and are hate mongererrerrrrs. All of you Apple haters just hate Apple. You never have anything nice to thsay [getting red faced]. You just HATE everything [tears dripping pretty good now]. ALL YOU MICROSOFT PEOPLE JUST HATE THINGS [fists clinched]. [screaming] Why must you bash things you just hate? Why? That does it - I'm going to call Hillary and Bill - and tell someone that CARES [knuckles whiter]! I'm sick of all you haters, I hate all you haters - this is it - I'm going to tell the teacher - you're all done for you wait till I go a...
---
[1011982.82 COREDUMP, libarary memory leak - executable abend] [8837.292 Post dump analysis/suggestion - go back to Tiger] [8837.293 Or wait for 10.5 update in early March]

 

[Veri]

gr8tfly, In any operating system with memory management, there is no such thing as "garbage collection" on exit of a program.The OS simply releases all pages assigned to that program (and decreases reference counts on shared pages such as shared libraries, etc.)

Define "any". It's perfectly feasible to have an operating system (e.g. Java-based) which handles fine-grained memory management and releases pages after process teardown via garbage collection. Consider a multiprocessing Lisp machine, where sharing is par for the course. You forgot to read rule 55: "Does it have to be done this way? Does it have to be done at all?"

If a program allocates stuff during its use and can't return to its original state of memory usage, then it has a leak. This means that the program cannot run for an indefinite time.

For second sentence to follow from first, the leaking routine must be executed sufficiently often; it is quite possible to run software usefully without invoking every path of code proportionally often to runtime. This is an important distinction because much of the difficulty in identifying leaks comes down to actually observing them.

I have a masters in computer science and have been in the industry for over 10 years, and simply hate what I see.

Fallacies: appeal to authority. Many people here may have multiple degrees and accolades, but only quality of argument matters.

I'm not bitter that Apple didn't hire me when I sent them a resume. I included a cover letter listing a lot of reasons why their code sucks and how I can make it better.

Rules 6, 10:

• Don't get so engrossed in the details that you forget to check what's happening around you.
• There's no point in having great ideas if you don't communicate them effectively.

certain types of servers (which should be using thread pools anyway!) may create/destroy thousands of threads every second. The extra CPU cycles will take their toll.

Name one server targeted at OS X which creates/destroys thousands of threads every second, and explain why a thread pool is not a viable option. VMS' heydey was clearly before your time, but it should rile you. VMS process creation made NT look lightweight, but no-one cared (until Unix developers came onto the scene and insisted upon doing things the Unix way), because the engineering priority was nearly always stability, not artificial benchmarks (as opposed to benchmarking of the software we're actually using, in the way we're using it, rule 27). Study your target demographic. Rule 6 again.

unity, A memory leak occurs when a program creates some state, which requires memory, and then when it returns to its original state, doesn't release all memory used for the previous state back to the operating system.

A process either returns all the allocated memory to the operating system, or it hasn't returned to its original "state". Your loose redefinition of "state" is significant, because there are cases when the app proper may act as if things are right back to how they started, but e.g. the runtime knows they aren't - consider garbage collection, or thread pooling.

Veri, I've done what you're talking about years ago. OSX does in fact use a form of demand paging... However, what your test fails to notice is that once you free that memory, the RM decreases.

My first aim in giving this snippet was to show that there are other ways of explaining the observed behaviour than a leak. My second aim was to demonstrate the feasibility of allocation of large chunks in a demand paging system - I even clarified this in my little "edit", in case you missed the point and built precisely the strawman you've built. Deallocation is discussed later in the post.

I should have made myself clear in my original post that I'm pointing out leaks in the Cocoa framework and not in TextEdit itself. Thanks for helping me realize that.

No problem; I recommend, then, that you stop giving the example of TextEdit, and start giving code-level demonstrations of leaks to developer forums, where people with better understanding of the Cocoa frameworks than both of us can tackle the problems you've found. Such people are easy to find, since Apple's own developers hang out there. Please display less hubris than you have here if you want to be taken seriously.

BTW, if you do my test, you'll notice that once you close all the Windows the VSIZE field also shows leaks. This contradicts your assertion that it's only because it's used memory that it was allocated, and this memory is only available to the system until used once.

See my two aims above. To clarify:

• "My first aim" was to help you see that you need to present a lot more evidence before even discounting the simplest explanations, let alone making an angry condemnation. Yesterday I had a discussion with someone who was convinced that Hans Reiser is a murderer, and his argument was based on Reiser allegedly neglecting his wife and wanting her to be a stay-at-home mother. Both traits might be disagreeable, and both might be relevant to analysing his character, but neither of them come close to implying murder. In this reply, you're coming closer to understanding that "he neglected his wife" does not imply "guilty of murder" - this is progress.
• Your evidence doesn't discount it anyway, as it's quite possible that TextEdit is allocating a large amount (not in a single large chunk) for each new window it opens - the first of which occurs at startup - and that some of each amount hasn't yet been garbage collected. Or perhaps it has been left in a process-specific pool to prevent having to make an expensive call to the OS when more memory is needed, and because you've done something very atypical for a user of the app, the pool has grown very large. "Second aim".

You might want to continue by writing something which slowly increases physical memory usage, and see if [edit: awful initial instruction, sorry] your RSIZE/VSIZE creep down together. If they don't, but swapping starts to occur, you have a good case that something is awry with memory management. Maybe Leopard's GC isn't being invoked as often as it should, maybe the afore mentioned pool exists and is not being pruned in response to low memory conditions. But you/I still won't have proven a memory leak.

[edit] I've just created a simple physical memory eater, having opened then closed 899 windows, and observed by the time I got bored that TextEdit's RSIZE had gone down from 45 to 43MB - swapping out? (prove this - these are questions you need to answer to back up your assertion of poor memory management) But VSIZE, which was a good 960MB before I started the eater, has flown down to 392MB (points for explaining this), approaching the 358MB VSIZE that TextEdit appears to start up with. Now 393-358 is not far off 45-6 (6 being startup RSIZE), so it's possible there is a stubborn pool of 35-40MB.

[edit] Simple evidence in favour of the pooling explanation is that if I repeatedly create, destroy, create, destroy 100 windows at once, I always end up with about the same RSIZE when only one window remains open. The minimum pool size is likely just increasing when Cocoa/TextEdit learns that the user wants to go wild'n'crazy.

I love how all the Mac fans are making excuses for Apple. Warms my heart every time. All praise be to the mighty bitten fruit.

Flamebait. Following several years' hiatus, I've only come back to using an Apple as a desktop in the past couple of months, and almost all my work is on Linux, FreeBSD or Windows. I have no particular love for any of the mainstream operating systems (Plan 9, otoh...). My aim is to tackle your lack of evidence and imprecise language, not to cheerlead Apple; I see you have skills and understanding but lack the ability to apply them to the extent needed and to effectively communicate your results. I'm trying to help.

 

[cmaier]

Plan 9 and VMS in the same post. Nice.

I actually used vms in a post the other day (specifically "prune").

I smell a trend

 

[saltyzoo]

Please forward me to the full featured GUI operating system with 0 bugs. I will install it today.

A tiny memory leak in one application is not worthy of serious criticism.

Frankly, if these are the best criticisms you can muster, that says a lot about how solid OSX is.

Thanks,
bye