That just has to be a bug. Exceeding the available memory of the garbage collector should not crash, instead your allocations should fail.
Failing allocations should be handled by some kind of error recovery code. Unfortunately Objective-C provides the "convenience" that it's Totally Cool to send a message to nil. The problem is that the message you sent to an object whose allocation failed might have been a message that really, really needed to be received. Having random object instantiations failing while continuing to run your app while messaging nil hither and yon makes for a really flaky app. It might not be a bug in your code though. Perhaps you've found a bug in OS X' allocator. If that's the case and you can prove it, file a report at http://bugreport.apple.com/ Try testing your app with GuardMalloc and the other memory tests. Add assert calls at all of the entry points of functions or methods that expect valid pointers. If such code gets a pointer and does not explicitly test whether it is nil, then add an assert. Any functions or methods that return pointers that must be valid should have asserts added just before their return statement. The valgrind memory debugger now works on Mac OS X, but it is a new port so it may not be up to the quality that you need for debugging your code. Give it a try anyway: http://valgrind.org/info/platforms.html Don Quixote Dulcinea Technologies Corporation Software of Elegance and Beauty http://www.dulcineatech.com/ quix...@dulcineatech.com On Wed, Sep 21, 2011 at 10:26 AM, Sean McBride <s...@rogue-research.com> wrote: > Hi folks, > > I seem to recall that with GC, one is limited to some amount of 'collectable' > memory, but I can no longer find what that limit is. IIRC, it's like 30 GB? > > My 64 bit-only, GC-only app is crashing when I use "lots" of memory. > > I can repro in a test app with this pseudo code: > > - IBAction method for an NSButton: > - create 10 MB NSMutableData > - loop 20 times > - use mutableCopy on the NSData > > In a retain-release app, I can click this button many times, exhaust physical > RAM, thrash, and get Activity Monitor's 'virtual memory' column up to at > least 12 GB. No crash. > > In a GC app, it crashes every time Activity Monitor shows around 4 GB usage: > > #0 0x7fff81cfc4fe in -[NSConcreteMutableData > initWithBytes:length:copy:freeWhenDone:bytesAreVM:] > #1 0x7fff81cfc454 in -[NSData(NSData) initWithData:] > #2 0x10000174c in -[TestAppDelegate handleButton:] > ... > > Surely this should not be so? > > Thanks for any suggestions, > > -- > ____________________________________________________________ > Sean McBride, B. Eng s...@rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montréal, Québec, Canada > > > _______________________________________________ > > 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/quixote%40dulcineatech.com > > This email sent to quix...@dulcineatech.com > -- Don Quixote de la Mancha quix...@dulcineatech.com Custom Software Development for the iPhone and Mac OS X http://www.dulcineatech.com/custom-software-development/ _______________________________________________ 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
