In my iCloud-based app, I noticed that if a crash were to occur while a UIDocument is open (and has not yet been closed), the status of the document sometimes becomes UIDocumentStateSavingError and it never opens successfully again.
When I run [UIDocument openWithCompletionHandler:] after this, the document never opens, returning NO for success and 5 (UIDocumentStateClosed and UIDocumentStateSavingError) for documentState.
On iOS 5, I also observed that NSMetadataQueryDidUpdateNotification is constantly being called (every second) until the file is deleted and the app is restarted. This causes additional usability problems in the app.
One more thing, on developer.icloud.com I noticed that the file is showing a second, conflicted version existing. This conflict isn't found on any of my devices, though, not even if the app is restarted or reinstalled.
What do I do to get the UIDocument to open normally?
Here is what I tried so far:
Checking [NSFileVersion unresolvedConflictVersionsOfItemAtURL:] for conflicts and removing all older version using [NSFileVersion removeOtherVersionsOfItemAtURL:].
Calling [[NSFileManager defaultManager] evictUbiquitousItemAtURL:] before calling [UIDocument openWithCompletionHandler:] to re-download the file to the device.
Downloading the main and conflicted versions from developer.icloud.com to see if any of them are corrupt or partial files. Both open fine.
Banging my head against my desk. Preliminary results are unsuccessful.
Related
Question:
When iOS device is tethered to Xcode and crashed after building (app loaded in, was not a crash ON build), where is the crash log saved to?
Here's my predicament with some context:
I pulled a user's crashlog of EXC_BAD_ACCESS for my app. I symbolicated and I've narrowed it down to get a rough idea but now I'm trying to re-create the issue via building in Xcode to my iOS device (not simulator). Normally the app does not crash on load in (this crash isn't easy to replicate) but I've been able to have the app crash consistently with Address Sanitizer enabled, and it always crashed and points to a line in a thread with an men address -- not anything I don't already have from previous debugging.
However, one time I had a crash occur where it highlighted what func was called as well as every func called in the stack trace and what file this was all occurring in. In haste I hit build again in Xcode before I saved the output however... and now I cannot replicate.
The crashlog wasn't saved locally to my iOS device as I was still tethered to Xcode, and I checked ~Library/Logs/CrashReporter/MobileDevice but that did not contain them either.
I need find where Xcode would've saved these logs on my mac (if it did at all)?
Typically all the crash dumps are stored in Settings -> Privacy -> Diagnostics & Usage -> Diagnostics & Usage Data
Scroll down the list and find the crash file with your app name.
This link might be helpful - https://developer.apple.com/library/content/qa/qa1747/_index.html
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.
For some reason when I call let realm = Realm() it stops processing (doesn't crash) my code. My app is still running, but the screen keep frozen.
When I try to open default.realm using realm browser app, it shows me:
Again, it doesn't crash my app. It is a kind of pause.
No braekepoints
I've already tried: cocoapods and xcode install
I've already tried run on simulator and device (iPad)
App already deleted
Project cleaned up
Derived data cleaned up
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.
I can't record audio using the SpeakHere example app from apple. When I run the app in Simulator from within Xcode, it starts up normally, but when I press the record button, the error "Thread 1: EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)" occurs:
The log message about the missing root view controller at app startup is already there BEFORE the above error occurs and it is probably not connected to my problem.
I have downloaded the SpeakHere example project from the linked website (see top of this question), opened the fresh download in Xcode and directly started the app. I did not modify any setting and not any line of code. I've also searched on google and stackoverflow for this problem and didn't find a solution, although this problem must be very general.
I use Xcode Version 4.5.2 (4G2008a) and a MacBook Pro from late 2009 with Mac OS X 10.8.
I've also had a friend try this on his computer and he has the very same problem. He has the same OS and his XCode version is also 4.5.2.
I would now try older Xcode versions, but right now I don't like to download a few gigabytes for a trial'n'error approach on my connection.
Any help appreciated, including reports like "works for me with Xcode version ...". Thanks!
The problem occurs because in the method AQRecorder::StartRecord(CFStringRef inRecordFile), the function CFURLCreateWithString() fails and returns a pointer to nil. This is not detected and later on the code calls CFRelease() on this nil pointer, which causes the EXC_BREAKPOINT.
The purpose of the method CFURLCreateWithString() basically is to take a url string as input and return a pointer to a CFURL object as output. The problem here is that the input is not a url string. Instead, it's simply a path on the local file system without file:/ or the like as prefix. For this reason, this method fails.
The solution is to remove the not-working call to the method CFURLCreateWithString() and instead call a related method, namely CFURLCreateWithFileSystemPath(), which is prepared to take a local file system path and convert it to a CFURL:
In the method AQRecorder::StartRecord(CFStringRef inRecordFile), replace or comment out the line
url = CFURLCreateWithString(kCFAllocatorDefault, (CFStringRef)recordFile, NULL);
and insert
url = CFURLCreateWithFileSystemPath(kCFAllocatorDefault, (CFStringRef)recordFile, kCFURLPOSIXPathStyle, false);
at its place.
url = CFURLCreateWithFileSystemPath(kCFAllocatorDefault, (CFStringRef)recordFile, kCFURLPOSIXPathStyle, false);
The code above made my xcoce 4.6 compile and run in simulator, but it doesnot record my voice from my usb microphone, I test my microphone in the garash band application and sucessfully record and play my voice, and the dbmeter does not move at all, any way when I port it to the real device it work, it just can't record and play voice in my simulator.