[taskValues count] is 5 under iOS6.0 and 4 under iOS5.1. Help :)
NSArray *taskValues = [NSArray arrayWithObjects:task.name, task.description,
task.duration, task.notification, task.notificationThereafter, nil];
EDIT:
Solved. It's embarrassing. Of course you are correct. The persisted state on the iOS5 emulator was different from the state on the iOS6 emulator, the underlying data model changed long ago and the iOS5 emulator was never reset. I'm taking an iOS6 app and backing it to work for iOS5.1. You helped me see the light!
My most probable guess is that task.notificationThereafter is nil when you're running your app under iOS 5.1. Of course, I don't know your application enough to know the cause of that.
Related
Many crashes happened below the iOS9.3 (which means devices with iOS10 are OK)..
The crash logs seem to show that it's not a problem about API that can only be used below iOS 9.3 .
But I have no idea about the crash logs. ( I'm sorry ...for I just start to study iOS development for only 2 month )
Could you please help me analyze the crash logs ?
Really Thanks !
crash log 1
crash log 2
AXE_BAD_ACCESS - this is problem with memory. One of function tried to use variable which already released. I think you need to check use your TableView and cells for this table.
Also to find problem with memory you can try to use zombies
Used to have the similar strange crashes in my app. And only in production, when testing from TestFlight. Building on device with ios 9 caused no problems.
Maybe it sounds strange, but try to convert all images you use in app to images with included sRGB color profile. For me it helped.
In my app, I would like to know if the user has setup a passcode or fingerprint (touchID). There's a pretty easy method just for that: [LAContext canEvaluatePolicy:LAPolicyDeviceOwnerAuthentication error:error].
However, Apple's docs say LAPolicyDeviceOwnerAuthentication is only available on iOS9 and above. I would rather not crash iOS 8 users without explanation, even if it is getting older. The thing is, I've tried it on an iOS8.4 simulator, and it seems to compile and just work.
What ill effects can happen if I use LAPolicyDeviceOwnerAuthentication on iOS 8?
I use code similar to this:
LAPolicy localAuthPolicy = LAPolicyDeviceOwnerAuthenticationWithBiometrics;
if (![[UIDevice currentDevice].systemVersion hasPrefix:#"8."]) {
localAuthPolicy = LAPolicyDeviceOwnerAuthentication;
}
This ensures I only use LAPolicyDeviceOwnerAuthentication on iOS 9 and later.
It's undocumented what actually happens on an iOS 8 device when you attempt to use LAPolicyDeviceOwnerAuthentication. It's very unlikely anything will crash but the authentication may return NO due to an unknown value or it may succeed because iOS 8 only had one valid value and it may not do any checking.
Unfortunately Objective-C doesn't provide any runtime checks for valid enum values like you can do with constants, methods, and classes.
If you use LAPolicyDeviceOwnerAuthentication on anything below iOS 9, the app will crash. That is what happened to my app when I didn't realize that this was not available on anything below iOS 9, but my app supported iOS 8.x as its minimum supported OS version.
NOTE: I have seen many other posts on Stack Overflow about NSUserDefaults being renamed to UserDefaults in Swift or not working on simulator until a restart. This is not a duplicate by anyway. Many of the questions SO is tagging against is from 4 years ago. My question is specific to iOS 10 from this year as this has always worked in older versions. I have mentioned in my question already that my question is not a duplicate of those questions as those were simulator bugs in swift and my issue is on device objective C bug. Please read the questions before marking as duplicate
My issue is different as I am able to reproduce this on objective C and on physical device itself.
I created a brand new project from scratch for this test. I placed this code in the viewDidLoad of a view controller:
if (![[NSUserDefaults standardUserDefaults] valueForKey:#"checkIfInitialized"]){
NSLog(#"setting checkIfInitialized as not exist");
[[NSUserDefaults standardUserDefaults] setValue:#"test" forKey:#"checkIfInitialized"];
[[NSUserDefaults standardUserDefaults] synchronize];
self.view.backgroundColor=[UIColor redColor];
self.mylabel.text=#"NSUserDefaults was NOT there, try running again";
} else {
NSLog(#"checkIfInitialized exists already");
self.view.backgroundColor=[UIColor blueColor];
self.mylabel.text=#"NSUserDefaults was already there this time, try running again";
}
Now if I run the app about 10 times, few times it finds the checkIfInitialized and sometimes it doesn't. No exact number on how many times it fails as it might work 3 times then fail next 2 times then work 4 times and fail once and so on.
Now something I have noticed (not 100% sure though) that the issue only seems to happen when I am testing connected via Xcode. If I run by launching the app by clicking the app icon on device without Xcode, then it seems to work fine but I can't be 100% sure.
I noticed this error occur sometimes:
[User Defaults] Failed to write value for key checkIfInitialized in CFPrefsPlistSource<0x1700f7200> (Domain: com.xxxx.appname, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null)): Path not accessible, switching to read-only
I have this very simple project on my dropbox if you want to test it out.
I would suggest testing about 10-15 times to reproduce this issue.
https://www.dropbox.com/s/j7vbgl6e15s57ix/nsuserdefaultbug.zip?dl=0
This works completely fine on iOS 9 so definitely something to do with iOS 10.
EDIT
Bug logged: 28287988
Response from apple DTS team:
First off, you should first determine whether standardUserDefaults or
valueForKey is failing. My guess is that “standardUserDefaults” is
returning NULL and, if that’s the case, then that’s something you
should be guarding against generally. Notably, standardUserDefaults
will return NULL if the preference file is encrypted in the
environment the app is currently running in (for example, preferences
is set to “NSFileProtectionComplete” and the app is running in the
background). That shouldn’t be an issue for standard foreground-only
apps, but it’s something to be aware of anyway.
It’s very likely that Xcode is actually inducing the problem here.
Xcode vastly complicates the app launching environment in a way that’s
VERY different than a standard app launch. My guess is that this is
basically being triggered by Xcode’s timing inducing an an expected
situation during the app launch, but if you want a more formal test of
that try setting a single breakpoint in applicationDidFinishLaunching
and continuing in the debugger as soon as you hit it. My guess is
just adding that disrupts the timing enough to stop the problem from
happening. Sort of. It’s iOS 10 only in the sense that iOS 9 will
never print that log message, but that’s because the log message was
added in iOS 10. The code itself is similar enough to iOS 9.3 that I
suspect exactly the same behavior is (at least in theory) possible in
iOS 9.
Yes, this is definitely a reproducible bug.
It happens with the GM release of Xcode 8 and iOS 10.
It is not the linked question referring to Swift.
It is not the linked question referring to beta versions of the Simulator.
The bug happens on devices and on the Simulator. It is intermittent: saving will work six times and then fail. Unlike you, I did not get the "failed to write key" message.
The bug also occurs when operating directly on the device without Xcode. This is in fact how I discovered it.
You should report a bug to Apple, especially since you have a short program that will reproduce it. I will do the same.
One key difference: In my case the failure is in writing the default. The previously written value remains in NSUserDefaults. Sometimes one key is successfully written while another is unchanged.
A similarly very intelligent DTS response from my own support request. Basically, killing using Xcode is more murderous than anything that would naturally happen on the device (even the double-Home-click-and-upswipe method) and since everything is abruptly crashed when Xcode halts it, the lazy writing of NSUserDefaults can fail, or be only half completed.
And indeed, pure on-device testing of the app, without Xcode involved, shows that everything does get correctly written to NSUserDefaults when the app is terminated.
I have closed my own bug report.
This issue strangely only occurs on iOS simulator.
After I make a change and save my data, and then try and access the controller's fetchedObjects I get a bad access error.
Even if I just try and check if fetchedObjects is nil, I get the EXC_BAD_ACCESS access. The controller definitely exists and I can print the description of it or for example the fetchRequest property. It's just when accessing the fetchedObjects array it errors.
I'm not sure how to debug this as it seems to come from the SDK.
Any help would be greatly appreciated.
I've experienced something similar and I think it might be an issue in the latest Xcode betas. If you are using batched fetched requests and are on the Xcode 6.3 (and possibly 6.2) then I think it's just a bug. You'll have to work around it and hope it's fixed soon.
Try removing your batching and seeing if this still happens.
FYI, I filed a bug report to Apple for this, and if it's also the case for you then you should do the same. More bug reports = more attention!
I’ve had a similar issue in iOS 9.1.
Turns out I needed to turn ON batching on the NSFetchRequest and set it to a number larger than the fetchedObjects count to fix it:
fetchRequest.fetchBatchSize = 1_000_000
I got a similar issue too. ios 10 , xcode 8.3.3. In simulator and real device.
when I set myFetchRequest.fetchBatchSize = 30 // not 0
then in tableViewController. access to myFetchResutlController.fetchedObejcts will get that error.
I have being seeing crashes in my iOS app, when opening LA Times (www.latimes.com). The crash happens in WebCore somewhere and I have no clue where. Profiling with both "Zombie" or "leaks" do not return anything for this "EXE_BAD_ADDRESS" error.
I also checked with a small, bare UIWebView app and I could reproduce the effects.
Right now, I see this happening only with LA times, but I am not sure if there are other sites as well.
Can someone check on and guide me in what could be the possible error/source for this crash?
EDIT: I have added a small UIWebView project demonstrating this bug at
github
EDIT 2: The app (include the demo at github) works perfectly fine on iOS 7.0, but crashes in iOS 7.1 ... seems a recent bug with iOS 7.1. I have issued a bug report to Apple and will keep updated.
Thanks in advance,
Nikhil
I happened to bump into that same issue with one of my apps in iOS>7.0 only.
It seems to be a sync issue which can be fixed by creating the webview from the main thread only.
As a fix I just wrapped my UIWebView creation in a dispatch_sync(dispatch_get_main_queue(), ^{ ... });
And it solved the problem.
Of course if your code is running on the main thread you shouldn't wrap it this way ;)