I got this error only if I select Release or Distribution configuration on Device, on the Simulator it works well... please, where I mistake?
cc1obj(4113) malloc: *** mmap(size=429379584) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
cc1obj: out of memory allocating 429376832 bytes after a total of 0 bytes
{standard input}:13160:non-relocatable subtraction expression,
Thanks for your help! :)
Probably because your simulator is able to allocate ~500Mb of memory while your iPhone is not able to do it. I think you should rethink what you are doing
do you really need so much memory?
isn't it just a calculating bug? (maybe a wrong sizeof or whatever)
in any case this is really too much data to be handled
It looks like you're trying to allocate 429 MB. iPhones don't have that much RAM. I suggest you look at what you're allocating to see why it's so big.
Related
malloc: *** mmap(size=16777216) failed (error code=12)
*** error: can't allocate region
In my code I get this error when I use the stringByAppendingString function. I did build & analyze and found no memory leaks. I built a quick sort program for sorting a suffix array of about 10,000 characters. When I do about 8000 characters it works fine so I am assuming this is a memory issue. Is their any way to fix this?
PS: I can't use Apple's standard quick sort function because I am doing an internship and the place I am working at wants me to build my own (For learning purposes).
I've had my project implemented with core data, however, whenever I tried to call save to a NSManagedObjectContext, the application goes on running for a long time and something like this appears:
Call(51871,0xb03e6000) malloc: *** mmap(size=2097152) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Call(51871,0xb03e6000) malloc: *** mmap(size=2097152) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Call(51871,0xb03e6000) malloc: *** mmap(size=2097152) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
My app runs 12 threads at the time this happens. Is this possibly because of a memory leak?
My app runs 12 threads at the time this happens. Is this possibly
because of a memory leak?
That you are running threads is irrelevant (except that it isn't•). And, yes, this is most likely due to a memory leak or, at the least, abuse of memory.
It won't take very many 2,097,152 byte allocations for you to exhaust all available memory. And it may not be leaks; if you simply have a long running process that accretes lots of memory before cleaning up at the end, that can cause this behavior.
Without knowing more, it is very hard to say what is going on. Certainly, setting a breakpoint as instructed and seeing where the failed allocation is occurring would be interesting.
• 12 threads is an awful lot in an iPhone app. There is only one core (2 if on an iPad 2), memory I/O bandwidth isn't that great, and, thus, 12 threads competing for resources are very likely going to run a heck of lot slower than a couple of threads.
Furthermore, you shouldn't be spawning threads at all (outside of rare circumstances). You should be using queues (GCD or NSOperationQueue) instead as they are far better integrated with the OS.
I noticed quite a strange thing while trying to allocate a lot of memory on my iPhone 3G running iOS 4.2.1.
When I call malloc(512 * 1024) in a loop it returns a valid pointer for about 1500 times after which I get a NULL and
app(2032,0x3e7518b8) malloc: *** mmap(size=524288) failed (error code=12)
*** error: can't allocate region
It surprised me, since I think my iPhone doesn't 750 MB of RAM. Then I added a memset after the malloc and it brought the number of allocations down to 120, which makes much more sense.
Here's the super-simple code that I used:
for (int i = 1; ; ++i)
{
void *p = malloc(512 * 1024);
NSLog(#"%d %p", i, p);
memset(p, 0, 512 * 1024);
}
I though iPhone didn't have any virtual memory system that could explain behavior similar to this. What would be a reasonable explanation for this?
On iOS (and many other systems), a call to malloc() doesn't actually allocate memory. It requests memory from the OS/kernel, but the request is not satisfied until the memory is written to (e.g. with memset().) This allows for greater efficiency in the system's memory management, but it can result in misleading malloc() behaviour.
The iPhone definitely has a virtual memory system. What it's missing is the ability to page memory out to disk. In other words, it's missing swap space.
What does that mean? Getting this in the console during usage of my app in debug mode:
malloc: * error for object
0x103f000: pointer being freed was not
allocated
* set a breakpoint in malloc_error_break to debug
Does that mean I'm over-releasing something?
Take a look at this and this.
Looks like you may be dereferencing something that's null, or something similar. I suggest that you post your code here to get some more helpful responses. I'm not too familiar with the iPhone API, so this may not be much help...
I have this line of code (splits is an instance variable):
splits = [[NSMutableArray alloc] initWithObjects:[NSMutableArray array]];
This code is obviously wrong (it should be nil-terminated), however it runs fine in the simulator, even though it throws an EXC_BAD_ACCESS on the device. My question is why does the simulator not throw an error?
Kyle
The actual outcome depends on the memory contents. It is quite possible that the memory layout on the simulator contains a zero right after the address of the first parameter (the anonymous array). This zero gets interpreted as if you would close the argument list with nil and everything works fine. (P.S. There is an interesting macro called NS_REQUIRES_NIL_TERMINATION for such cases, although it obviously would not help here.)
The iPhone has much less memory than your computer. The area in memory for the stack could have been set to 0x00 (nil) before being used by the initWithObjects function. When the parameters are sent to the initWithObjects function and the stack is alloated, that memory space on the computer is more likely to be preset to 0x00 than the iPhone because the same memory space is used less often. So it is likely that the nil is being read from a spot in memory set to 0 already.
If you fill up your memory on your computer, and then run the simulator, the simulator may be more likely to crash like the iPhone.
Buffer overflows result in undefined behavior. They are not guaranteed to cause an access violation (or even a noticeable bug). On modern machines, they will cause an access violation if you happen to step on "someone else's" memory, but probably not if you're just reading junk from your own stack.
Basically, you just need to be careful, and can try tools like Mudflap and Valgrind to help you out (these particular two are more meant for C/C++, and I don't know how well they apply to Obj-C).