So I'm using AWS Cognito to authenticate my users from my iOS application. However in a small bit of code, I've narrowed down an extremely odd problem while making some minor changes.
I noticed that I was receiving this error:
Unable to refresh. Error is [Error
Domain=com.amazonaws.AWSCognitoCredentialsProviderErrorDomain Code=1
"identityId shouldn't be nil"
UserInfo={NSLocalizedDescription=identityId shouldn't be nil}]
After debugging, I've noticed the identityId actually does not get set:
_identityId = [jsonDict objectForKey:#"IdentityId"];
self.keychain[EncryptionKeyKey] = self.identityId;
return [AWSTask taskWithResult:nil];
Though I clearly set it in the above code block, and checked to make sure that [jsonDict objectForKey:#"IdentityId"] did produce some value, I found through the debugger that a "po self.identityId" before and after the assignment is still nil. NSString isn't something that needs to be allocated, and what's weirder is that this used to work. I switched some statements up because of my current use of UICkeychainstore but that shouldn't affect anything. In addition, I disposed of my changes and saw that the problem still exists. Please let me know if you have any ideas.
I'm also noticing this error shortly after the previous error:
This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes. This will cause an exception in a future release.
any ideas would be very helpful
Turns out that I had both a login method and a getToken method. In the getToken method I wasn't doing something right based on some changes I had made to the code to use keychain instead of nsuserdefaults for security reasons. After fixing the getToken it worked. After further debugging though, I saw that identityId still doesn't get set regardless of it working or not. I guess it might be some sort of block variable s.t. the assignment doesn't happen immediately. At least that's my theory. All in all it works though.
Related
I'm using MKNetworkkit to parse XML data to the server. Before Entering into the success block its gets crash with EXC_BAD_ACCESS with out any reason and am already done with NSZombieEnabled like all the stuffs.![Below is the screen shot of where its getting crash.][1][1]: http://i.stack.imgur.com/FL3l9.png
You may find this useful to help debug http://subhb.org/2012/07/02/how-to-debug-exc_bad_access-error/
You will get EXC_BAD_ACCESS error mostly in the following scenarios:
You are trying to access an object that is not initialized.
You are trying to access an object that no longer exists. Either it’s being released or it’s nil. In ARC mode, make sure you take
ownership of the object that you want to use.
You are passing an message to an object that the object doesn’t understand. It can also happen for bad typecast.
Have you tried running breakpoints on your code and stepping through your program line by line and seeing if any of the above match the result?
Testing my app which gets location data from an api and displays in a table view. Was testing something else today and app crashed - EXC_BAD_ACCESS (code=1, address=0X0). What does this mean and how do I read the information provided by Xcode to figure out how to fix?
EXEC_BAD_ACCESS usually means that you are trying to access an object which is not in memory or probably not properly initialized.
Check in your code,
if you are accessing your Dictionary variable after it is somehow removed?
is your variable properly initialized? You might have declared the variable but did not initialize it and accessing it.
There could be a ton of reasons and cant say much without seeing any code.
Try to turn on NSZombieOjects - this might provide you more debug information. Refer to here How to enable NSZombie in Xcode?
IF you would like to know where and when exactly is the error occurring, you could check for memory leaks using instruments. This might be helpful http://www.raywenderlich.com/2696/instruments-tutorial-for-ios-how-to-debug-memory-leaks
Based on the information you provided. My guess is that the library is calling out to a block you provided. Inside that block is a Dictionary which has something wrong with it.
Good luck!
I had a rather interesting exc_bad_access crash today. After a lot of digging, I came up with the following information (running in simulator):
If I just ran the code, the app would randomly crash at a random point while loading data into my managed object. From what I could tell, it was always crashing when I loaded data into the managed object -- not on the sections that converted from my JSON dict to data to the object actually used (from strings and NSNulls to ints/floats and nils)
Random crashes are, of course, evil, so I tried to step through the process in the debugger, but that didn't prove practical -- I was processing a LOT of objects, so stepping through them one-by-one just didn't work. So I decided to add some NSLogs to track the process and try to spot a pattern that way.
Instantly solved the crash.
Just one NSLog, anywhere in the process, prevented the crash.
I eventually tracked my way up the stack trace and found the actual issue: I was accessing the managed object in a threaded environment, but NOT from within the associated MOC's performBlockAndWait: method. At that point, the crash was incredibly obvious to me -- I'm shocked I didn't have more issues earlier. I'm willing to bet that between having a 'small' test data set of 2-3 objects and having debug code in there with NSLogs, the error was pretty effectively masked earlier... but the question remains:
Why does an NSLog prevent the app from crashing? How on earth could a piece of code without side effects change the execution of the rest of the app? This makes no sense!
Amazingly enough, this is a fairly common situation: I have seen it more than once when enabling logging in a seemingly unrelated place would instantly solve a timing issue somewhere else.
The reason for this is that NSLog, just like many other output functions, has internal synchronization. There is a mutex somewhere that protects access to the internal buffers of NSLog, either in the NSLog itself or in one of the I/O libraries that it uses. This synchronization enables callers to use NSLog from multiple threads. It is this synchronization that changes the timing of your program, affecting a race condition and ultimately solving a crash.
Why does an NSLog prevent the app from crashing? How on earth could a
piece of code without side effects change the execution of the rest of
the app? This makes no sense!
Indeed this makes a sense. Really.
A single NSLog forces to print something to your console, it takes some fraction of seconds and in between your processing on somethread gets finished and the crash (might be due to un-availability of input is) no-more.
Your error may be due to async call. Your next process starts before finishing previous one. And your next process need data from previos process. NSLog consumes some time.
I'm having issues with my NSFetchedResultsController, which seem to be fixed by turning IncludesPendingChanges on, and this worries me. (I've found this to not be true, including pending changes does not help.)
What happens is that my Fetched Results Controller correctly fetches and displays my objects on a full API refresh. Stepping through, I have confirmed that this full API refresh's temporary context is saved and merged without error.
However, if I then return to a view which does this same fetch request from a different navigation flow, only one partially complete object is returned and displayed, rather than the complete set of objects. If I then do a full API Refresh at this point, the refresh displays the correct objects.
I believe my issue may be that mergeChangesFromContextDidSaveNotification is not propagating to the main context, but from my logs and stepping through, it seems to me that it is saving correctly. I'm not sure where to go from here. While IncludesPendingChanges fixes the symptom, I don't believe it fixes the underlying issue.
As some added information, I'm using this framework for my Core Data Management: https://github.com/vokalinteractive/CoreDataManager-iOS
I am turning on includesPendingChanges by adding on line 156 of VIFetchedResultsController.m
[fetchRequest setIncludesPendingChanges:YES]
Edit Whatever fluke caused me to believe includesPendingChanges to YES fixed the problem is no longer present. Turns out this project had some seriously hairy memory management, and after spending all day cleaning that up, I'm still not closer to making this work. Still at the same point though, it looks like the changes are not propagating to the main datastore, or aren't sticking.
As a hint, like I mentioned in my comment below, even when I specify "includePendingChanges:YES", Logging out my fetched objects with:
[self.fetchedResultsController.fetchedObjects description]
ends with "includesPendingChanges: NO". Any idea what can cause this?
Perhaps you got it the wrong way round. The default of includesPendingChanges is YES, as this is the behavior you usually want. That your UI updates getting corrupted is sort of expected.
Setting this attribute to NO is really just meant to facilitate fetches with NSDictionaryResultType, especially when including simple aggregations that can be dealt with on the database level.
I suspect this is by no means an error by you, but a possible flaw of the framework you are using. Anyway, what you identify as an issue, is really just expected behavior.
See the two short paragraphs in the documentation where this is explained quite well.
I have been having a bit of a bug while testing on iOS 6 with my current iOS 5 app.
We have experienced a lock up on a method return for an innocuous method that internally used blocks, but not as properties. The issue is that calling the method works, so does every line of code within the method (including the block utilizing code)
I tried using [block copy] before calling the block, but there was absolutely no change.
turns out the function definition of my code was declared in an internal interface and did not have a return type.
Here are some graphics to illustrate this issue.
The Initial Error
The Stack Track
The Method in Question (isolated from self to determine the issue exact location)
The Function Implementation (this is what is called, and returned)
The Definition in the Private Interface
I decided to look at the function call, and noticed it returning (id) rather than void
And Finally the only code change that alleviated this bug.
Explanation
This bug reared its ugly head when my client called me saying our app does not run on ios 6
I was forced to download iOS 6 and Xcode 4.5 for testing this out.
I did indeed crash every time the app was run.
After hunting down this bug on stack overflow among other sites linked to by Google, I tried the block issue that some others are experiencing. And did a copy wherever I could to try to alleviate the issue of retained object falling off the stack.
I was not using block properties so I just called copy on the blocks themselves.
This did not help.
Finally with another developer going over it with me. I was stepping back and looking at it from another angle, and decided to try to determine what the heck was being retained.
It turned out the result of the function was being retained. And the only way I figured that out was to look at the value that auto complete showed me as the return type.
I knew the return type to be void, however it was telling me that the return type was id and that is what sparked the investigation into the method definition.
I hope this helps others that have this issue as I spent about 2 hours hunting it down and it turned out to be a semantic issue between a result type that should never have existed.