Re: Allocating too much memory kills my App rather than returning NULL
Re: Allocating too much memory kills my App rather than returning NULL
- Subject: Re: Allocating too much memory kills my App rather than returning NULL
- From: Don Quixote de la Mancha <email@hidden>
- Date: Wed, 09 Nov 2011 00:08:01 -0800
On Tue, Nov 8, 2011 at 11:46 PM, Greg Parker <email@hidden> wrote:
> On Nov 8, 2011, at 10:56 PM, Don Quixote de la Mancha wrote:
>> On Tue, Nov 8, 2011 at 10:49 PM, Kyle Sluder <email@hidden> wrote:
> No, the reason is that most end-users do not want to pay Space Shuttle prices (high) for Space Shuttle capability and flexibility (low).
>
> Note that Shuttle missions carried ordinary laptops running ordinary operating systems to do the science work other than flying the spacecraft. The scientists couldn't afford Shuttle-grade development costs nor Shuttle-grade development schedules.
One really doesn't have to pay Space Program prices for decent
software. Improved development methodologies can actually save both
the developer and end-user money.
Xcode has a built in unit testing framework. How many of us are
actually using it? On StackExchange a while back some coder bemoaned
the fact that his employer specifically forbid him to spend time
writing unit tests!
The Code Red worm replaced damn near every Windows Internet
Information Server website with a plain white web page that said
simply "Hacked by Chinese". It was estimated at the time that that
one worm cost the world economy ten billion dollars. A self-employed
friend who ran Windows Server 2003 at the time prepared an online
presentation for a potential client. When the client went to view my
friend's presentation, he got just "hacked by Chinese".
Would IIS really have had to cost as much as a Space Shuttle for
Microsoft's coders not to have made IIS exploitable that way?
While the iOS and Mac OS X do have a better security track record than
Windows does, I'm quite certain that's because "The Scene" has been
focussing on Windows due to its greater numbers. With Apple's
increasing financial success, malware such as Mac Defender is starting
to crop up.
Apple's security update to fix the Mac Defender exploit was a gigabyte
download - compressed! That suggests that whatever holes Apple
plugged were all over creation.
>> That's just it. I DON'T receive any memory warnings. As far as I can tell, neither does the system send my App a UNIX signal.
>
> Go back to Dave Zarzycki's message earlier in the thread. There are two resources called "memory" that you can exhaust.
>
> Physical pages. If you use too many physical pages, then iOS will send you memory warnings and, if you don't relinquish enough memory in response, kill you.
That would be great if I actually received any memory warnings. I don't.
I had not yet implemented the memory warning delegate methods when I
first experienced the iOS killing my App when I allocate too much
memory, so implementing them was the very first thing I tried. There
are two kinds of memory warning methods, one for your App Delegate,
the other for each of your UIViewControllers. All of my view
controllers now inherit from a common base class, with the memory
warning being sent to the base class.
Both of my methods set a global flag. Instead of calling calloc()
directly I instead call a wrapper function that checks this flag, and
returns NULL if it is set. Only after deleting ALL of the new
allocations do a clear this flag.
I wasn't sure that would actually work because I don't actually free
memory in response to the memory warnings. I only prevent further
allocations. It is when the next allocation fails that I free all
that memory.
However, I did set a breakpoint at both methods. That breakpoint was never hit.
> Virtual address space. If you fill your virtual address space, then malloc and mmap may fail and other frameworks may crash.
The Simulator does the right thing: calloc I'm sure calls through to
malloc, which itself calls mmap. mmap fails when I run out of virtual
memory space. That can happen either because there is no more room in
the backing store files, but not in my case as Mac OS X grows the
backing store as needed. In my case I'm pretty sure I did run out of
virtual address space.
But then Mac OS X did the right thing, by having calloc return NULL.
That enables my simulated App to unwind all those allocations to fail,
then advise the user to try a smaller grid size.
With both my App Warp Life, and the minimal test case that I attached
to my bug report, the Simulator does the right thing while on an iOS
device, the iOS just kills my process. I do not receive memory
warnings, the process is killed before calloc returns anything at all,
and I do not receive a UNIX signal.
I would have expected the Cocoa Touch memory warnings to be
implemented by UNIX signal handlers but that does not seem to be the
case. If it were, I could write my own signal handler that would
allow me to free up the memory.
I don't have a problem with your assertion that my App should not
allocate boatloads of memory. What I do have a problem with is that
my App is terminated without it being given the opportunity to free
any of the memory I have allocated.
--
Don Quixote de la Mancha
Dulcinea Technologies Corporation
Software of Elegance and Beauty
http://www.dulcineatech.com
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden