My iOS app is randomly crashing but I don't get any warning/error in the console. I think it might be a memory leak but shouldn't I receive a EXC_BAD_ACCESS error at least ?
The other thing might be a memory overloading, but I don't get any memory warning and I've just tested the app with the instruments tool.
So why does it crash without printing anything in the console ?
Thanks
UPDATE:
I'm actually getting a memory warning in the instruments although I don't see the memory to increase. COuld be the cause of the crash ? How do i know where is the memory warning generated ? (See screenshot: )
Tell your program to print a backtrace every time it receives a low memory warning.
From Apple documentation:
UIKit provides several ways to receive low-memory notifications, including the following:
Implement the applicationDidReceiveMemoryWarning: method of your
application delegate.
Override the didReceiveMemoryWarning method in
your custom UIViewController subclass.
Register to receive the
UIApplicationDidReceiveMemoryWarningNotification notification.
Enable Zombie objects and try again. https://stackoverflow.com/a/8050701/1271579
Edit: If the device runs out of memory, you will recieve a few memory warnings before crashing so you should probably optimize it.
Related
Is there a way to prevent an EXC_BAD_ACCESS from crashing an app, like with #try..#catch you can handle an exception gracefully.
Update:
The code crashes when it attempts to dereference an invalid pointer. This is a third party library and it interfaces with external hardware so I can't debug locally. I am trying to prevent it from crashing and output data to a debugging console on my app.
In ObjC, try/catch do not handle exceptions particularly gracefully. You will still leak memory and leave the system in an undefined state. With rare exception, the expectation is that you are simply catching so you can log some things before crashing. And in general, you should not use #catch anywhere but at the top level of your program for this purpose. There are some extraordinary situations where limited use of exceptions may be appropriate, but they are rare in ObjC. See the Exception Programming Guide for some more information. See especially the following from the ObjC ARC documentation:
The standard Cocoa convention is that exceptions signal programmer error and are not intended to be recovered from. Making code exceptions-safe by default would impose severe runtime and code size penalties on code that typically does not actually care about exceptions safety. Therefore, ARC-generated code leaks by default on exceptions, which is just fine if the process is going to be immediately terminated anyway. Programs which do care about recovering from exceptions should enable the option [-fobjc-arc-exceptions, which imposes speed and memory penalties on your program].
The same is true of EXC_BAD_ACCESS. You can catch it with a signal handler for the purpose of recording some information and then finishing your crash. For a good tool for doing this see PLCrashReporter. It is very difficult to write such a handler correctly, so I strongly recommend using an existing framework. You can easily get into deadlocks that drain the user's battery if you catch EXC_BAD_ACCESS incorrectly.
You get EXC_BAD_ACCESS often because you sent a message to a released object. Then you can examine the NSZombie. What is an NSZombie? You can see : this. It will catch the
EXC_BAD_ACCESS because of sent a message to the released object.
You can set NSZombie like this : Check the Enable Zombie Objects
And you can also get EXC_BAD_ACCESS because of the memory warnings level is too high , or your memory is too high , so the apple will shut your app down. This EXC_BAD_ACCESS is too hard to prevent . I think the only way is to manage your memory as low as you can , sometimes you can see the log where is receive memory warning , when the level is high, it may getEXC_BAD_ACCESS
You can rewrite your code to not have these errors. Try not to reference any null pointers and keep references to any object that you want to have access to.
I have written a objective-c wifi library and a c wrapper around it to call from my c++ code using corewlan framework.I have setup timers and on expiry of the timer i call scanwifi function of the library which gives details of all the wifi network details.The program keeps crashing by giving malloc error incorrect check sum for freed object. The crash is not consistent,keeps appearing a random places. I tried guard malloc to find the memory bug, left the program running for more than 10 hours but it didn't crash. as soon as i removed guard malloc and executed the program and boom there was the crash. Can anyone please tell ways to catch this memory bug
Thanks
Memory management errors can be particularly difficult to track down; without seeing code it's hard to say.
You mentioned GuardMalloc—have you tried enabling other Diagnostics?
Scribble
Guard Edges
Guard Malloc
Zombie Objects
This can help debugging by making your code crash more predictably—hopefully closer to the source of the error.
(In Xcode 4.4.1, these are set via "Product"->"Edit scheme"->"Run"->"Diagnostics".)
My Mac app is crashing with exc_bad_access on the run loops.
So I enabled NSZombies, and Now I don't see such error as expected ( As the objects are not de-allocated).
But, I don't find any useful NSZombie Log in the console.
Is there a way to identify the issue ?
It's challenging. The most common cause of this error in Cocoa is directly accessing your ivars rather than using accessors. Accessors make the vast majority of memory crashes go away.
That said, they're not the only cause of memory errors. You may be accessing memory other ways. NSZombie does one specific thing: When you deallocate an object, NSZombie says "don't actually deallocate the object." Instead it turns the object into a zombie object that prints an error if you send it messages. But that only helps if the crash is due to sending a message to a deallocated instance. It could be lots of other things.
You should start first with the crash stack itself. Look up the stack and see what kind of object it might be, or who might be calling it.
Read TN2124, particularly the section on the BSD Memory Allocator, and the Enabling the Malloc Debugging Features section of the memory Usage Performance Guidelines. There are lower-level tools than NSZombie that you can use. MallocScribble is often the most useful. It overwrites deallocated memory with 0x55 so that you're more likely to crash sooner, and to make it easier to detect deallocated memory in the debugger. MallocPreScribble is useful for finding uninitialized memory, but this really only helps if you do raw malloc calls. ObjC objects are always pre-initialized.
And of course you have to put on your detective hat. What parts of your program are most suspicious? Are you doing multi-threaded work (that can cause memory crashes if you don't lock correctly).
If it reproduces easily, then you'll figure it out. If it only happens occasionally, well... I've hunted bugs like that for many months sometimes. Sometimes it's just hard.
You need to use memory profiler for that. Just build with Profile option and select Leaks.
I have a very strange problem and no idea what creates it nor how to solve it.
The app works fine under 10.5 and 10.6.
Under 10.7 the app start fine but crashes after about 15 secs later without any user interaction.
In the debugger console i see Program received signal: “EXC_BAD_ACCESS”.
I made a screenshot of the stacktrace and it seems as if it has something to do with NSPersistentUI.
So any hints and tips would be very appreciated.
I would try running with zombies enable, you haven't really given us enough information, I would guess you are not handling retain of objects between thread correctly, for example methods that are called by thread to get access to objects in another thread you should do a [myObject retains] autorelease] so to add the object to the calling threads autorelease pool.
Do you have Garbage Collector activated? Have you tried without it? I would suggest that. It is clearly MM problem and I would suggest you stick with retain/release.
I'm having a problem with a Cocoa application I am writing. It has to parse a timestamped file that is updated every hour, and during testing it keeps crashing consistently at around 11:45 PM due to a segmentation fault. I'm assuming I must be messaging an object that has been deallocated. What tools are provided with the Xcode install to track object allocations and (hopefully) tell me if I am messaging an object that has been deallocated?
I am using Mac OS X 10.5.
I would recommend the following:
Use NSZombieEnabled to monitor when messages are sent to deallocated NSObjects
Use Instruments to track object allocations and/or memory leaks
The way I do it is by using a command line tool called gdb. Here is a tutorial on how to use it. You'll have to learn a few of it's commands, but once you do it's almost a pleasure to use.
Note: gbd can be used on C, C++, and Objective-C programs.
Have you run the program under gdb? This should allow you to inspect the stack and variables when it SIGSEGVs.
To track allocations, use malloc_history. This requires the MallocStackLogging environment variable to be set.
A quick point: using a deallocated memory location usually results in a EXC_BAD_ACCESS exception. If that's the crash reason you're seeing then you're correct in assuming it's a deallocation problem.
Run it in Xcode's debugger (which is gdb with a GUI on top) and reproduce the crash. Then, look at the stack trace.
Messaging a deallocated object usually has the top frame in objc_msgSend. The next step then is to run the app with NSZombieEnabled and reproduce the crash; the zombie will identify itself.