Im trying to use the NSLog, to print console messages. The problem is sometimes i receive a "EXC_BAD_ACCESS" error when calling it
-(void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration
{
NSLog(#"Working test %d", toInterfaceOrientation);
NSLog(#"EXC_BAD_ACCESS %#", toInterfaceOrientation);
}
Here i simply want to see what the arguments passed into the function contain. The first NSLog works fine. The second causes an "EXC_BAD_ACCESS" and i dont understand why?.
%# only works with objects. And toInterfaceOrientation is not an object.
As you can see in the documentation for UIInterfaceOrientation it's just an enum.
The second NSLog crash because you try to print an integer as a NSObject (%# instead of %d). UIInterfaceOrientation is a enum it doesn't work.
EXC_BAD_ACCESS usually means you're trying to call an object that's been released from memory. Try turning on NSZombies in your environment variables to see where it's causing the problem
Answer in a similar question here:
How to use NSzombie in xcode?
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html
%# is for objects only.
UIInterfaceOrientation is an enum:
http://developer.apple.com/library/ios/#documentation/uikit/reference/UIDevice_Class/Reference/UIDevice.html#//apple_ref/doc/c_ref/UIDeviceOrientationPortrait
When you use %# it is basically calling:
[UIInterfaceOrientation descriptionWithLocale]
Obviously this will cause a EXC_BAD_ACCESS
toInterfaceOrientation is a enum variable... so if you want to print log of it you have to use %d ...... . and %# mostly used for objects ...
Use this Code :
NSLog(#"EXC_BAD_ACCESS :%d",toInterfaceOrientation);
EXC_BAD_ACCESS means your code is pointing to inaccessible memory address.
Such as:
Make a pointer point to an invalid memory address
Write to read-only memory
Jump to an instruction at an invalid memory address
Access a released object's property(send message to released object)
Your second line code causes a crash because of "%#". iOS thinks that the pointer you sent to it is an object, it access the property of that object, which doesn't exist, then it throws the EXC_BAD_ACCESS.
reference: Apple's Investigating Memory Access Crashes
Related
I have problem with Thread 1: EXC_BAD_ACCESS (code=1, address=0xf00000c) and I don't know how to resolve it.
It appeared when I change some object in core date and save it and I try to pop this controller to parent.
This error is in main() with retVal.
here is some code
int retVal;
#try {
retVal = UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
*/\ error is here**
}
#catch (NSException *exception) {
NSLog(#"%#", [exception callStackSymbols]);
#throw exception;
}
return retVal;
After re-runing app all my changes are in core data. What is more this problem is only on iOS 7. iOS 6.1 is ok.
Does someone have idea how to resolve it?
As a comment said this error is likely to be deep in your code. If the culprit is a zombie, the easiest way to find it is to run it (preferably in the latest Xcode, currently Xcode 5, as it has been improved) in profiler and choose "Zombies". When it fails, you can see the history of everything that has happened to the object.
Also, set an exception breakpoint. You may get a break when the error happens instead of in main, where the exception gets passed up.
I just had the exact same problem.
Looked here and found nothing so I started backtracking until I thought, maybe I should try Clean Build Folderš¤
I was glad it was as easy as CLEAN BUILD FOLDER!!!
Product- Clean Build Folder(ā§ ā K)
š
I resolved this problem with "Zombies" and the problem was with
[UIScrollView(UIScrollViewInternal) _notifyDidScroll]
I added
- (void)dealloc {
self.tableView.delegate = nil;
}
This problem was only in iOS 7.
Thanks for help!
I have resolve this issue only by debugging the source code and re-analyze my logic.
Below are some reference that help me lot.
EXC_BAD_ACCESS means that message was sent to a point in the memory where thereās no instance of a class to execute it. Thus ābad accessā.
You will get EXC_BAD_ACCESS in 3 cases:
An object is not initialized
An object is already released
Something else that is not very likely to happen
Thatās already a good starting point. Start using the debugger, if you recently added a new object to the class youāre working on, put a breakpoint at the line before the freshly added object is used for the first time and check the values in the debugger.
Whatās happening most though is that you will be sending a message to an overreleased object ā i.e. object that is gone from the call stack. In this cases everything (and indeed everything) you will get in the console will be just :EXC_BAD_ACCESS
This is because the object is gone, there is no information what class was it, or what source file or anything else.
Please try to avoid using zombies for this.
EXC_BAD_ACCESS means there is no instance of a class to execute it.
There are 2 or more possibilities:
An object is not initialized
An object is already released
Please debug application carefully and analyze each object carefully. That might solve your issue.
I solved the same problem by finding out that the name of one of my NSString variables had the same name as one of the frameworks' class variables. Took seconds to change the name a little and problem disappeared.
With such a huge number of class variables in frameworks, it is very likely that once in a while, every programmer just by coincidence names some variable in his class exactly the same as one used somewhere in framework classes.
So it doesn't have to be Xcode bug in most cases.
In my case, I was using third-party library and I forgot to set custom-class name in Storyboard Identity Inspector
And there may be another issue which I faced today:
I had a mutable dictionary with a non-object entry try. There was a code snippet with adding a BOOL value to the dictionary. So no wonder that I got this error =).
In my case it was trying to log an Int32 with %s in print statement
in my view this is the equivalent of every other language NullPointerException,
but unlike other languages there are no hellping pointers (class name / method or line of the occurrence / god forbid a Stacktrace),
so the only thing i could do to solve it fast is to start printing main functions and views, (a very primitive solution),
create a swift: Debug.swift
add this function into Debug.swift:
public func trace(_ message: String = "", file: String = #file, function: String = #function, line: Int = #line)
{
print("**** \(file).\(function)[\(line)]: \(message)")
}
then you can use it like this:
trace("initializing")
to use it inside a var do this:
let _ = trace("initializing")
this should print something similar to this:
**** /path/to/my/file/MyFile.swift.someFunc()[18]: initializing
this is how i started adding debug lines to gain some flow record, so next time i have a EXC_BAD_ACCESS i will have a clue where the problem leis
don't forget to disable the prints during production deployment
I want to test my app's crash reporting out in the field by deliberately having it crash when the user performs a particular action that a real user is unlikely to do accidentally.
But what's a good reliable way of making the app crash that doesn't create a warning at compile time?
Edit: Note that many seemingly obvious answers to this question result in exceptions that get caught by Cocoa and thus don't result in the app crashing.
in Objective-C use C directly to cause a bad access
strcpy(0, "bla");
Note: while this works on any system I know -- in a future version of the C runtime OR the compiler this might not lead to a crash anymore. see Is null pointer dereference undefined behavior in Objective-C?)
(in swift you would have to bridge to objC to do this)
My current favourite:
assert(! "crashing on purpose to test <insert your reason here>");
A classic:
kill( getpid(), SIGABRT );
And some pr0n:
*(long*)0 = 0xB16B00B5;
All of them generate crashes captured by my crash reporting tool.
Since we all use Clang for iOS, this is fairly reliable:
__builtin_trap();
This has the benefit that it's designed for exactly this purpose, so it shouldn't generate any compiler warnings or errors.
How about a good old stack overflow :)
- (void)stackOverflow
{
[self stackOverflow];
}
abort(); causes abnormal terminationā¦ That is a crash.
Most popular one - unrecognised selector crash:
NSObject *object = [[NSObject alloc] init];
[object performSelector:#selector(asfd)];
Make sure you don't have -asdf method implemented in that class haha
Or index beyond bound exception:
NSArray * array = [NSArray array];
[array objectAtIndex:5];
And of course
kill( getpid(), SIGABRT );
I think in Swift you could easily throw a fatal error:
func foo() {
fatalError("crash!")
}
It is actually even intended to use this feature in case something goes wrong in order to make the app crash.
To avoid an if statement in a special case, you could use precondition, too. It's similar to assert, makes thus the intention (if wanted) pretty clear and is not removed in the final release as assert. It is used like precondition(myBoolean, "This is a helpful error message for debugging.").
Send a message to a deallocated object
exit(0);
(must... type... 30 characters)
You can also raise an exception:
[NSException raise:NSInternalInconsistencyException
format:#"I want to test app crashes!."];
Add a gesture recognizer to a view that recognizes a 10 finger tap (5 fingers for iPhone as 10 can get a bit crowded). The GR has a method attached to it that executes anyone of the previously mentioned surefire ways to get your app to crash. Most users are not going to lay 10 fingers down on your app, so you're safe from the general user accidentally causing the crash.
However you should be able to use something like Testflight or just deploying it to personal devices and test in the wild before ever submitting it to Apple. Having a forced crash could get your app rejected by Apple.
could try something like
NSArray* crashingArray = [NSArray arrayWithCapacity:1];
[crashingArray release];
should crash on an EXC_BAD_ACCESS (might need to release it a second time but normaly it should crash like this already)
I will go with:int raise(int sig);
To get more info >man raise
I would just kill the process normally:
kill(getpid(), SIGKILL);
So if you install a handler with signal you can also handle the crash, finishing to write opened files and these things.
I use
[self doesNotRecognizeSelector:_cmd];
When working with RubyMotion I use this:
n=Pointer.new ('c', 1)
n[1000] ='h'
Try this:
- (IBAction)Button:(id)sender
{
NSArray *array = [NSArray new];
NSLog(#"%#",[array objectAtIndex:8]);
}
a wrong NSLog statement will do it
NSLog(#"%#",1);
i've got the following crash log error in my app:
-[NSNull length]: unrecognized selector sent to instance 0x194adc8
How do i read this? Does it mean that:
I sent a 'length' message to a 'NSNull' object?
The 'length' method in the 'NSNull' class crashed when trying to call a selector on another class?
Also, if it is the former option, how can i get the stack trace to see which function caused this crash? That top line is the only error in my log.
Thanks
Door 1
NSNull does not respond to length
You can check the documentation for NSNull to see that this is the case.
Without having an idea of what your code base is doing I am not sure where to look, you must be calling [NSNull null]; at some point to get the NSNull object or you are using a framework somewhere that returns this.
It means you sent 'length' to NSNull and NSNull doesn't have a 'length' function.
Turning on NSZombies might help you (it keeps deallocated objects around so it can tell you which object you tried to access) but I think in this case you probably set an object to NSNull at some point (or it was returned from a function).
Anyway to turn on NSZombies, go to Project > Edit Active Executable > Arguments tab > Then add a variable called NSZombieEnabled and set the value to YES. Make sure you turn it off when you're done though because it can cause memory issues.
It means that you are using a Length method for calculating the string length
Like
If([strText Length]>0)
{
//do something here----
}
else
{
//Do somethig here--
}
So in above case- strText is NSNull then definitely a crash will accure and GDB will show a message like:
[NSNull length]: unrecognized selector sent to instance
As above told already Null don't have Length method.
For rescue:
check first:
if ((NSNull *)strText == [NSNull null])
{
return strText=#"";
}
This will prevent for crash for NSNULL
Zombies won't help in this case. As Paul.s said, NSNull is a valid object. You should get the stack trace when the app stops. Do you have the debugger pane open? Make sure it is. I'm pretty sure Xcode 4 always stops on exceptions with the stack trace. If for some reason you're still not seeing it, if you are at the (gdb) prompt, you can type 'bt' (backtrace) to get the trace.
Because you are coparing NSNull class to lenth
check before fo that
if ([NSString *str isKindOfClass:[NSNull null]]){
str=#"";
}
then check length for the str.
it works!thx
I have an app that appears to run without problems in normal use. The Clang Static Analyzer reports no problems either. When I try to run it in Instruments, it fails with an unrecognized selector exception.
The offending line is a simple property setter of the form:
self.bar = baz;
To figure out what's going on, I added an NSLog() call immediately above it:
NSLog(#"class = %# responds = %d", [self class], [self respondsToSelector:#selector(setBar:)]);
self.bar = baz;
On the emulator (without Instruments) and on a device, this shows exactly what I'd expect:
class = Foo responds = 1
When running under Instruments, I get:
class = Foo responds = 0
I'm stumped as to what could cause this. Perhaps a different memory location is getting tromped on when it's in the Instruments environment? Can anyone suggest how I might debug this?
If bar belongs to self, can't you do bar=baz; ?
Check your properties.
Perhaps to you need a cast on baz?
There's not enough information here to know what's going on, but then, if you knew what information to provide you'd probably have already fixed it. So. A few things to check:
Is the "self" pointer being swizzled in any way? Try printing out the value of self at various points just for sanity's sake
When your code runs in Instruments, is it running in a different mode? (32-bit vs. 64-bit, Garbage collected vs. Retain-Release, etc.) I'm not sure why any of those would have an effect, but if it's running in a different mode, that's something to look into.
Are you synthesizing the setter correctly? Or is it being provided dynamically (via Core Data, etc.)? If you manually specify a setBar: method, do you still get the error?
I appear to have some overzealous releasing going on in my obj-C app - getting error message
"-[myobj release]: message sent to deallocated instance 0x5633b0"
. I know the class of the object instance causing the problem, but this class is used all over to create many instances.
My thought is I could put some logging in the init method of the class to log whatever "0x5633b0" corresponds to which should help me track down where the instance is being created.
What exactly is the "0x5633b0" and is there any way I can get access to that value in the code to log it?
Thanks.
What worked best for me when I ran into similar problems recently was the following:
Under under Project->Edit Active Executable -> Arguments tab -> Environment variables section I added and set to YES the following variables: NSAutoreleaseFreedObjectCheckEnabled, NSZombieEnabled and NSDebugEnabled.
Under the Run menu, I selected Enable Guard Malloc.
With these settings the debugger provided more hints on what's wrong with my code.
(I found these tips here)
Good luck,
Ori
0x5633b0 is likely the address of object in question (the value of self). You can use NSLog or printf with %p to print it.
0x5633b0 is likely the address of the deallocated object (the value of myobj). You can use NSLog or printf with %p to print it.
You can also use the instruments profiler to find the deallocated object.
1. Start the profiler:
2. Select the "Zombies" and start the profiler.
3. Click through the simulator until you hit your "deallocated error case"
In the debugger, type info symbol 0x5633b0 and you'll get some indication as to what object it is. One other thing that might be helpful is backtrace which will give you a stack trace. All in all, this blog entry has some great tips.
you can also add these to environment variables:
MallocStackLoggingNoCompact 1
and write in the gdb console:
info malloc-history <paste-address-here>
Reference: here
Consider using the NSZombieEnabled flag.
You will then know what is this deallocated object you're sending a message.
You're not managing your memory properly -- you're calling release/autorelease on some object more times than you're calling retain. Make sure you're following all of the rules laid out in the Memory Management Programming Guide for Cocoa.
0x5633b0 is just the address of the memory location at which the object is stored. One thing you can try to do is to add some code to the init method:
- (void) init
{
if(self == (MyClass*)0x5633b0)
NSLog(#"Allocated object at address 0x5633b0"); // put a breakpoint on this line
// do rest of init...
}
If you have any other init methods (e.g. initWithCoder:, which is called for objects instantiated from a XIB), make sure to put this snippet in those methods as well. Put a breakpoint on the NSLog line, and then see when it gets hit. Note that it may get hit several times, if an object is allocated at that address, deallocated, and then another object happens to be reallocated at the same address. The last hit before the crash is the one you want.