Since my latest update of Xcode, I get repeatedly the following log in my Coredata based app:
[logging] flag(s) 0x00000020 are reserved for VFS use and do not affect behaviour when passed to sqlite3_open_v2
Is this simply log noise or is it in any way relevant to me?
Update:
This happens under Xcode 13.2.1 on an iPhone with iOS 15.4. It does not happen on a Simulator with iOS 15.2.
I'm pretty sure this is something you can ignore, that will probably be fixed when iOS 15.4 is out of beta.
According to the SQLite file-open flag documentation,
Flag value 0x00000020 is SQLITE_OPEN_AUTOPROXY, for what that's worth
This flag is one of several flags that "...have historically been ignored by sqlite3_open_v2()", however...
"...future versions of SQLite might change so that an error is raised if any of the disallowed bits are passed into sqlite3_open_v2()"
What this seems to say is that the flag has no effect and hasn't had one for a while, so it doesn't matter if Core Data is using it internally. The message probably means that iOS 15.4 has a newer version of SQLite which has started to print warnings about it but hasn't started causing errors yet.
I'd expect this to be fixed when 15.4 is released, and in the meantime I encourage you to file a bug with Apple just in case.
Related
Recently updated to iOS 12.1 (from 12.0), Xcode 10.1 (from 10.0) and seeing a flood of error messages in the Xcode console when debugging on my physical device like the following:
[NetworkInfo] Signal strength query returned error: Error Domain=NSPOSIXErrorDomain Code=13 "Permission denied", descriptor: <CTServiceDescriptor 0x28051d700, domain=1, instance=1>
I get a couple of these logs every couple seconds, the only thing that changes is the hex value for the CTServiceDescriptor. There have been no code changes so I have to assume its related to the iOS or Xcode updates.
As far as I can tell it doesn't appear to have any performance impact, the app is operating as expected and my phone is working (its even updating its signal strength!). I've been unable to find anything helpful/relevant across Stack Overflow, Google, or the Apple Developer forums though I made a similar post to the latter that I'll link here once the post is approved.
Any suggestions/insight into how I could troubleshoot this further or resolve would be greatly appreciated. Thanks!
It seems to be a side-effect of calling [CTTelephonyNetworkInfo new]; under newer versions of iOS and can be safely ignored, I think. I'm not sure there's anything app developers can do to fix this, it appears to be a side-effect that signalStrength inside CTTelephonyNetworkInfo is hidden from public apps in recent versions of iOS (9+). This is nothing new, but it's noisier about the permissions error here under iOS 12.1 (maybe other versions?).
CTTelephonyNetworkInfo appears to be a hastily-revised API, for public use at least: For example, it had bugs in v12 when returning carrier info that was fixed in v12.1. why do serviceSubscriberCellularProviders return nil? (in iOS 12)
I'm also reminded of the extraneous permissions errors that appear frequently in macOS console logs - https://eclecticlight.co/2016/09/23/sierras-console-promising-but-incomplete/ - or the Xcode 8 bug where in an early beta the Simulator was extremely noisy. Sometimes the internal chatter slips out to an external release, and there's not much anyone outside Apple can do about it...
I get this error in the debugger everytime core data is used (so if I make 3 calls I get the warning 3 times).
CoreData: annotation: Failed to load optimized model at path '/var/containers/Bundle/Application/0B6C2326-D8D5-47B3-8C68-7693C16A0806/liveDemo.app/liveDemo.momd/liveDemo.omo'
It does not cause any instant problem, but whilst they add up, it gradually slows down the app until it crashes with a NSException (it's irrelevant what the user does at the time, it will just lag more and more then come to a crash at whatever point in the app).
I have tested the app on 3 devices (iPhone 7+ - iOS 11, iPhone 7 - iOS 11, iPad Aid - iOS 10.3) and it ONLY occurs on the iPad. However when I started the project one of the phones had a version of iOS 10 installed and it did not cause any issues so although I can't fully exclude it, it seems unlikely it's the OS version to blame.
Steps tried
Uninstall and install app, so the device clears core data file, also tried restarting with and without the app installed - FAILED
Remove and rewrite the Scheme in Xcode - FAILED
Recreate the NSManagedObjectSubclass of the datamodel - FAILED
Has anyone encountered anything similar with recent versions of Xcode and managed to fix it? This is a 2 year old similar problem, but none of the answers have helped.
So, after a few days I have managed to solve it. I'm not familiar enough with the insides of Xcode, but all I had to do was rewrite the CoreData Model. Best to make a back up before trying this!
Take a screenshot of current attributes and delete the CoreDataModel ( .xcdatamodeld file)
Add a new file to project (Data Model template)
Write old attributes
Recompile and build
My assumption would be that the problem was caused after migrating a project started in Xcode 8 (written in Swift 3) to Xcode 9 (upgraded to Swift 4). It had no problem with devices running iOS 11 (same upgrade level as Xcode 9), but found it to consistently cause lag and eventually crashes in older iOS versions.
I don't understand why simply modifying file properties did not fix it, but I'm happy to have fixed it and move on.
After migration to new swift 3we've got a lot of automatic syntax changes among which:
DispatchQueue.main.async(execute: {
// Do something
})
documentation says that it's available in iOS 10 and later.
So I expected to see unrecognized selector error when running on iOS 8 but it still works.
So I'm just wondering if it would affect some users since our deployment target is iOS 8?
I just tested it on an iPod touch running 8.4 and DispatchQueue.main.async{} works just fine.
The docs are misleading (wrong?)
I went to log a documentation problem, but wait, among lots of other stuff that's been removed from the Xcodebuilt-in documentation system, you can't log issues with the docs anymore!
I suggest filing a radar bug, then.
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.
I've got an app that crashes even before the debugger can connect.
I placed a break point on the first line of main(). (I added an NSLog statement as very first statement in main() and set the break point there.
The app seems to start. The main screen with some ui elements becomes visible on the screen. Then it disappears.
There is no crash log found on the devices.
Xcode message:
Could not launch "appname"
process launch failed: failed to get the task for process xyz
Debugging is enabled of course.
The same for the profiler Instruments.
Code signing works fine so that the app can be deployed to the devices.
(Same for enterprise distribution. And the app validates for store submission.)
It does work on the simulator though.
The app used to work fine. I was just about to build it for the store. For final tests on iOS 8.1 I upgraded to Xcode 6.1 with SDK 8.1. But the problem did not occur directly after the upgrade. It worked just fine.
Then it crashed when building for release for enterprise distribution.
The AppStore build crashed in the same manner (according to Apple, the app was rejected of course.)
But it ran nicely in debug modes.
Now I was trying whether compiler options for optimization may make all the difference and I was trying to build in release mode with debugging enabled etc and end up with a debug build crashing as well. (No optimization in debug).
So it may well be that the migration to Xcode 6.1 did cause it but the problem may have come effective only after Xcode cleaned and rebuild the project in response to changes to compiler settings for code optimization.
Sorry for the long text. I tried to put everything in that may be of importance.
Reason is most likely some incompatibility of Crackify and iOS 8.1.
Therefore it may be of interest for others, altough my problem along with these symptoms may be very special.
Very early within AppDelegate didFinishLaunchingWithOptions we have had the following statement.
if ([Crackify isCracked] || [self isCertificateUnvalid])
exit(173);
That, as such, is not really well designed. The app is just terminated rather than any error message displayed to the user. Thus, it appears as if the app has crashed. But it has not crashed and therefore no crashlog is provided.
For reasons which I don't yet understand and which may not be related to this error, my debugger did not manage to hook up into the executed app. Once that was overcome (suddenly the debugger worked without any changes made to any of the debugging related settings) the error was found rather quickly.
This is Crackify: https://github.com/itruf/crackify
Within Crackify it was this code sniplet that caused the problem:
static NSString *str2 = #"ResourceRules.plist";
BOOL fileExists3 = [manager fileExistsAtPath:([NSString stringWithFormat:#"%#/%#", bundlePath, str2])];
if (!fileExists3) {
return YES;
}
For reasons that I did not further investigate, the file, that is tested here, apparently does not exist in iOS 8.1 any more.