Re: NSSpellChecker crashes after 64k words

FROM : Denis Stanton
DATE : Wed Apr 13 06:20:16 2005

Hi Louis

Thanks for your help.  I seem to have missed out on an earlier response
from you but I see enough of it contained in the clipping below to
realise where my error lay.

I was not managing the auto release pool at all.  I'm only part way
through learning Obj-C from a book and that area hasn't been covered
yet, or at least not enough for me to see what was missing.

Simple bracketing each of my nested loops with :
   NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
   .....
   [pool release];

has solved the immediate problem.  My apologies to the authors of
NSSpellChecker for implying that that code had a flaw.  The failure
occurred while NSSpellChecker was in control, but it was not caused by
NSSpellChecker.

Denis

On Apr 13, 2005, at 11:02 AM, Louis C. Sacha wrote:

> Hello...
>
> I didn't mean to imply that there is a 64k hard limit to the total
> number of autoreleased objects. What I meant is that any code that
> does a significant amount of work without being integrated into the
> runloop needs to manage it's own autorelease pool(s).
>
>
> First, it isn't safe to assume that the only autoreleased objects
> being created are those which you explicitly create yourself. In my
> example, the code being executed in the loop
>
>     found = [checker checkSpellingOfString:testString startingAt:0];
>
> doesn't explicitly create any autoreleased objects itself, but there
> could be any number or kind of autoreleased objects being created
> behind the scenes in the implementation of that method.
>
> If the code was doing something other than busy work, it would
> probably also be creating several autoreleased objects of its own each
> time through the loop (as I expect the original poster's code does).
>
> In this particular case, it's unlikely that enough autoreleased
> objects are being created to hit a limit related to the total
> available memory, but good management of autoreleased objects can
> still have a significant effect. The peak number of autoreleased
> objects that exist at any time has a direct impact on the amount of
> memory that your application uses, which has a direct impact on the
> speed of your code because of the hit from reading and writing to
> virtual memory.
>
> Since the vast majority of the autoreleased objects being created in a
> loop like this are only used for that particular iteration of the
> loop, the time spent writing that memory out to disk is basically
> wasted since they will never be used again. Creating and destroying
> autorelease pools does add a small bit of overhead, but at a certain
> point that small cost becomes significantly less than what is required
> to to deal with a large amount of virtual memory. You can use the
> Activity Monitor program to keep an eye on how much real and virtual
> memory is being used by your program.
>
>
> Second, to paraphrase George Orwell, "all objects are created equal,
> but some objects are more equal than others". As Evan's example would
> eventually show, you can create a staggering number of some kinds of
> autoreleased objects without causing a fatal error (although his
> example using instances of NSString _would_ crash eventually). There
> are however a few types of objects that have some sort of limit to the
> number that can exist at one time. These types of objects are
> generally related to interprocess communication, threads, etc... and
> there is usually some sort of inherent limitation in the lower level
> APIs that these objects are built on top of.
>
> I would guess that the crash when using NSSpellchecker is related to
> the accumulation of one of these types of objects. The spell checker
> runs as a separate process, so the likely suspects would be
> communication related. You can run your program from ObjectAlloc (in
> the Performance Tools included with the Developer install) to see how
> many of a particular kind of object exist at any particular time, as
> well as the peak number and total created.
>
>
> The autorelease pool that the main thread's run loop manages is
> normally enough for simple event driven code, and most code is
> implemented in a way that assumes that some sort of regular cleanup is
> being done. If you end up doing a lot of work in a loop of your own,
> it's important to make sure that this cleanup is still being done in
> order to maintain the best level of performance and to avoid some of
> the more obscure issues that could otherwise arise.
>
> Hope that helps,
>
>     Louis
>
>

>> If what your saying is true than basically any app with 64K
>> auto-released objects should crash and that seems like a much more
>> heinous oversight than NSSpellChecker having a 64K word limit.
>>
>> Have you tried this with code that just creates auto-released objects?
>>
>> -Karl
>>
>> On Apr 12, 2005 6:07 AM, Louis C. Sacha <<email_removed>>
>> wrote:

>>>  Hello...

>>  >

>>>  I don't think your problem is specifically related to
>>> NSSpellchecker,
>>>  it's probably just that too many autoreleased objects are being

>>  > created within your loop.
>>  >
>> ...

> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list      (<email_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>
>

Denis Stanton
Orcon Internet Limited
(09) 480 9299
http://www.orcon.net.nz