Re: R: Running out of VM
Re: R: Running out of VM
- Subject: Re: R: Running out of VM
- From: Jonathan del Strother <email@hidden>
- Date: Sun, 25 Dec 2005 11:57:46 +0000
On 25 Dec 2005, at 11:17, Alastair Houghton wrote:
On 23 Dec 2005, at 09:04, Markus Hitter wrote:
Am 23.12.2005 um 05:25 schrieb Phill Kelley:
The documentation for NSAllocateObject says "Returns nil on
failure".
I would have thought that running out of VM constituted a "failure".
Obviously, object allocation doesn't work as documented. Time to
file a Radar.
The only workaround I can think of, is to try to allocate memory
using the regular malloc() first, then to relase this chunk and to
allocate the real object according to the result. A malloc() of
length+1024 bytes should be enough for all situations.
That won't necessarily work... many platforms nowadays do lazy
allocation of backing store, so if the problem is running out of
actual memory rather than virtual address space, you'll often find
that malloc() will happily allocate and return a pointer, and then
your program will crash when it tries to write to it because the
system can't get any more pages.
I don't know whether OS X does lazy allocation or not. AFAIK both
Linux and Windows do, and it certainly wouldn't surprise me if OS X
did as well.
I'm pretty sure it does - I was trying this out yesterday afternoon.
I could cheerfully malloc() up to around 3.4GB, but the process only
showed about 500K in use. It was only when I did malloc() then memset
() that the process actually started taking up memory. (That was a
really unpleasant afternoon. Eating up the memory got exponentially
slower as the process gets above something like 800MB, and it brought
my system to its knees, even hard-locking at one point, forcing a
reset.)
Anyway, I don't think it's worth fussing too much about running out
of RAM on a modern system with lots of RAM and disk space. Unless
your program is going to e.g. control an aeroplane or a nuclear
reactor (in which case you shouldn't be using OS X---at the very
least you're breaching the license agreement), the fact is that the
consequences of your program failing are probably less severe than
other problems that the machine will suffer elsewhere. Given that
fact, the best thing most programs can do is exit as fast as
possible (there is an argument for trying to save any modified data
to some sort of recovery file, but only if this can be done quickly
and without allocating memory).
There are some notable exceptions; obviously, programs that might
have to deal with very large data sets may need to have some sort
of mechanism in place to deal with this problem, but relying on
e.g. malloc() to return NULL isn't sufficient I don't think.
Finally, if you *really* want to catch the allocation failure, you
should be able to handle the SIGTRAP signal, or alternatively use
the Mach functions to handle exceptions. It's a processor
exception, so an NS_DURING, @try or C++ try won't catch it.
I rather suspect that the sporadic crashes I'm seeing in my CoverFlow
app are caused by users with not enough free memory. It's causing
crashes in the most unlikely spots - often buried deep within AppKit,
at places beyond my control, and I'm still not sure quite how to
handle it. Would be interested in anyone else's thoughts on this
matter...
Jon
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden