We have an iOS application for the iPad that is having strange behavior. We store the state of the app in an XML file in the documents folder. Every once in a while our testers are reporting that when the application crashes the file on the disk gets deleted as well. This is very strange, since I can't figure out what can be causing this. Any pointers to how I can debug this issue.
The problem is complicated by the fact that this happens randomly and only on certain ipads(generally iPad2). We are using NSData initWithcontentOfFile.
By any chance can this be related to memory mapping of the files.
Make sure you are writing atomically
Related
I get the following error during a build.
"API Misuse: Attempt to serialize store access on non-owning coordinator (PSC = 0x7fb5ae208890, store PSC = 0x0) CoreData
Why am I getting a CoreData error in my app? I'm not using CoreData!
This message is not referring to your use of CoreData, rather it is referring to Xcode's internal use in order to manage part of your project.
One possibility (it happened to me) is that there is corruption in one of the .xcassets files in your project.
In my case a problem with git-lfs meant that the .xcasset file did not have contents. Correcting this (in my case with a git-lfs pull) meant that once the assets within the .xcassets file were available, the compilation error was fixed.
So in general check .xcassets files and any other Xcode managed project resources that might require use of CoreData internally to XCode
I found the same issue in Xcode 14 and noticed I added only one app icon image of 1024x1024.
Though it was an Xcode feature, still digging into the problem of why this failed.
I just wasted two days to this.
It seems to be triggered when using Xcode 14 1024 pt single size icon xcassets alongside certain other assets.
Workaround was to go back to the old multiple size icon assets.
The other weird thing is that it only gives the error when archiving.
I was getting the same error in XCode 12.5.1. It might occur in other situations also, but in my case, it turned out to be due to having two assets in the same asset library with the same name. The two assets had different file extensions, and the error occurred even when they were in different directories in the same asset library. I fixed it by giving all of the assets unique names.
I had a very similar problem, but in my case it turned out to be 3 things:
Outdated pods, that were using Core Data (had to remove them);
Lottie added a file to the Assets folder, which triggered this error.
I had a couple of broken files in the Assets folder (no idea why). I needed to remove all assets, and manually readd all of them in order to localise the corrupted ones, and replace them with new instances.
This fixed the issue for me.
The following use case:
create a strings file (not localized) and deploy the application to your test device
localize the file (en.lproj or similar), make some changes to the new file and remove the original file
deploy the application on the device
What I noticed that very often (always?) the application will still use the old non-localized file. The reason is that apparently the file is still in somewhere the application bundle, even though it has been removed from the project. iOS's logic is that if a file of a specific type is looked up, it first checks in the root of the bundle for the non-localized version, and only if it doesn't find it does it go deeper into the localized folders. (Is it just me, or is this logic kind of backwards? I'm used to first looking for language specific file, and then falling back to some defaults, but it might be my Java background.)
Sometimes (always?) removing the app from the device completely doesn't help either. What does in this case is a CMD+SHIFT+K, which cleans the build folder, and after the app is built and deployed again, the correct file is used.
A worse problem would be if such a thing leads to an app crash, like some strange issues with Nibs or whatever - I have seen those as well...
The question is: what would happen if the first version of my app in the apple store had the non-localized file, and the second version localized it? When the user upgrades the app, would they get the same behavior as me during development (i.e. outdated, non-localized file used)?
I can't imagine because I think this would be a cause of a lot of grieving and bug requests, but I can't tell for sure as I haven't yet published any iOS app.
If the behavior is correct when upgrading from the store, why is it? What is so different? Are the files stored locally on my computer somewhere and used when I deploy?
Can anybody share their experiences?
We are developing an iOS app with Enterprise distribution.
It ran well in hundreds of devices, but we found some iOS 6.1.3 devices failed to launch it hours later the first run, because the App's Documents directory became a file !
Our App did nothing special except it was downloading about 80MB MP4 files from a remote HTTP server.
I assumed that something wrong when it operated the Documents directory, but so far have little clue to identify what's 'dangerous' usage in our codes.
Did you have encountered similar problems? How did you fix it?
Thanks a lot to anybody kindly helping to figure it out.
What I suggest doing is for your app to test for this when it launches, and if there is a file there, move it to some other place (like the temp folder), then create the Documents directory, then move the file back into that directory with the same name (or change the name). That will at least prevent your app from stalling.
If you have any means of remote logging, you could bin hex the first 64 bytes of the file and send it to your service for analysis (if you know what's in the file it should help you figure out who created it.)
Original post:
I've got an iOS app which happily loads files successfully a few times and then all of a >sudden, with no apparent reason, fails to load the files again. The paths all seem correct >seeing as they load successfully to start with... does any one know of any reason this could >happen?
I first noticed this running the app on an ipod touch but it also happens in the iphone >simulator as well. I'm using XCode 4.2 and iOS6.
Edit:
It turns out that the audio system I was using wasn't releasing the audio player objects properly so presumably they ended up keeping file handles open or something, resulting in new files failing to open. Adding in a release to the audio players when they finished seems to have solved the problem or at least significantly reduced the likelihood of it happening!
If you run into similar problems where files won't open you can check to make sure file handles aren't being left open (each fopen should have a fclose with it when the file is no longer needed).
I'm having a severe problem using the new versions of Xcode (4.4 & 4.5) in that, my project has a very large .sql database file stored in the project. This file cannot change, for many reasons... but it is +270Mb in size. This causes Xcode to hang on 'Indexing File...' and becomes completely slow and unresponsive to the point that I have to force quit the app, and cannot actually get any coding done. I have raised a bug report with Apple several times, but it is seemingly being ignored!
I do not want to disable Xcode indexing entirely as i find the code completion features incredibly useful.
My question is: Can i remove the database from the Xcode bundle resources, and then add it automatically at compile time?
Would appreciate any and all advice on how I could get round this problem.
Regards,
Sam
Incase anyone comes across this problem of Xcode indexing a huge unwanted file... I fixed it by setting the file type in Xcode to an 'MP3 Audio file'...
Doesn't seem to have any effect on the function of the .sql file once it's in the App, but stops Xcode trying to index it.
If anyone has a better solution for this, i'd love to hear it!