In my experience the #1 cause of "crashes" is being killed by the memory watchdog. An app I publish deals with photos, and I ran into such a problem with people trying to load in massive photos that I had to enforce an artificial pixel-size cap to stop it.
The iPad has a memory fragmentation problem. The longer the unit is up, the less you can guarantee that a request for a large amount of memory won't be met with a watchdog kill. What works once when it's from a fresh boot may not work a few days or a few weeks later.
We deal with large photos as well, and it's usually just a matter of making sure the only thing in memory is what's currently showing on the screen, and optimizing which size of photos we're using so that we can use as little memory as possible. It's a pain though. We also run into problems with orientation changes, because the animation for the orientation change gets very, very choppy if you're using too much memory.
Your experience echoes mine. There are only two situations where I use the full-resolution image, and I had to go to great lengths to make sure NOTHING else was loaded. The rest of the time it uses pre-rendered representations at various smaller sizes.
Why do apps get killed for requesting memory? Can't malloc return NULL and the app act accordingly ("your picture is too big, so i am not going to edit it").
Now, it seems most people never handle malloc returning NULL, and "you can't do this today" is a bad user experience. But crashing is what happens in the first case anyway, and being auto-killed is a bad experience too.
Apps don't get killed for requesting memory. They get killed when they're running in the background and other apps request memory.
Can't malloc return NULL and the app act accordingly ("your picture is too big, so i am not going to edit it").
Thats exactly what happens. You're free to run:
void *foo = malloc(INT_MAX);
foo will be NULL. The rest of the app will continue to run without any problems.
// edit: Here's what happens when you do run that (the last line is a NSLog() to show the address of foo):
Malloc(4972,0x3e088868) malloc: *** mmap(size=2147483648) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
2010-09-12 19:44:59.154 Malloc[4972:307] malloc: 0x0
I don't know. But it'll usually give you the memory, send the level 2 memory warning (level 3 is kill), and then kill you shortly after. The memory warning is supposed to be a warning to release cached data, so it's sort of hard to release the data you're working on right at that point in time gracefully.
Ok I don't know a lot about iOS development or ARM development in general, but there's something I don't understand. I had the impression that the ARM architecture uses a memory paging system not unlike the one used by x86. This would imply that memory fragmentation shouldn't be an issue, unless we're talking about in-process logical memory address space fragmentation, which would be largely the developer's fault anyway. Am I missing something here?
I haven't done any real investigation on the whole thing, but the general feeling I get about the whole thing is that over time, system-related processes may hold on to more and more memory. I don't know what specifically is doing it or why it's doing it, but the end result is that trying to load a 2048x2048 pixel image will work one time and the next time your app will get killed for it.
iOS devices have NO virtual memory at the OS level. Once it's out of physical RAM, that's when it really begins to clamp down on app memory usage. There's only 256 MB of RAM on the iPad, so loading that one image needs at least 40 MB of that. If a bunch of the Apple-originated processes are resident in memory, and it seems like it hangs on to a bunch of them even after the app is closed, then it may or may not let you use that much memory.
The iPad has a memory fragmentation problem. The longer the unit is up, the less you can guarantee that a request for a large amount of memory won't be met with a watchdog kill. What works once when it's from a fresh boot may not work a few days or a few weeks later.