App crashes from app store, but not in development version - swift

This is a question/answer. I found my issue which i will explain here hopefully for others to learn from as well, but i also have some questions regarding why.
I implemented IAP in my app and tested all of them in sandbox mode and everything worked as planned with no crashes anywhere. I eventually uploaded my app to the app store and after approval, i removed the development version from my device and installed the app store version. At which point, when i tried to go to my menu to test my Remove Ads IAP in production, the app crashes when loading the VC.
So i looked at my devices logs in Xcode...
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x0000000100054a34
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [0]
Triggered by Thread: 0
Filtered syslog:
None found
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 Connectify 0x0000000100054a34 specialized SettingsTableViewController.(viewDidLoad() -> ()).(closure #1) (SettingsTableViewController.swift:40)
1 Connectify 0x0000000100054e00 partial apply for SettingsTableViewController.(viewDidLoad() -> ()).(closure #1) (SettingsTableViewController.swift:0)
2 Connectify 0x00000001000283d0 thunk (IAPHelper.swift:0)
3 Connectify 0x000000010002b990 specialized IAPHelper.productsRequest(SKProductsRequest, didReceive : SKProductsResponse) -> () (IAPHelper.swift:0)
4 Connectify 0x0000000100028738 #objc IAPHelper.productsRequest(SKProductsRequest, didReceive : SKProductsResponse) -> () (IAPHelper.swift:0)
5 StoreKit 0x000000019ae39dbc __34-[SKProductsRequest _handleReply:]_block_invoke + 512
6 libdispatch.dylib 0x000000018d229200 _dispatch_call_block_and_release + 24
7 libdispatch.dylib 0x000000018d2291c0 _dispatch_client_callout + 16
8 libdispatch.dylib 0x000000018d22dd6c _dispatch_main_queue_callback_4CF + 1000
9 CoreFoundation 0x000000018e34bf2c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
10 CoreFoundation 0x000000018e349b18 __CFRunLoopRun + 1660
11 CoreFoundation 0x000000018e278048 CFRunLoopRunSpecific + 444
12 GraphicsServices 0x000000018fcfe198 GSEventRunModal + 180
13 UIKit 0x00000001942642fc -[UIApplication _run] + 684
14 UIKit 0x000000019425f034 UIApplicationMain + 208
15 Connectify 0x0000000100021248 main (AppDelegate.swift:16)
16 libdyld.dylib 0x000000018d25c5b8 start + 4
Which lead me to believe it has to do with IAP's. This code is in viewDidLoad of my SettingsTableViewController.
products = []
Products.store.requestProducts{success, products in
if success {
self.products = products!
for i in 0...products!.count - 1{
print("Index \(i): \(products![i].productIdentifier)")
}
if !IAPHelper.canMakePayments() || Products.store.isProductPurchased(Products.RemoveAds){
self.cell1.textLabel?.textColor = UIColor.gray
self.cell1.isUserInteractionEnabled = false
self.cell1.accessoryType = .none
self.cell2.textLabel?.textColor = UIColor.gray
self.cell2.isUserInteractionEnabled = false
self.cell2.accessoryType = .none
}
}else{
print("Not success")
}
}
But i can't decipher enough of the crash log to determine what the issue is, only that it probably has to do with this block of code.
The revalation
So, at a loss, i had my wife download the app from the store and test for this crash. It did not! No crash at all. It was at this point I thought to try removing my device from the Dev Portal. And of course, that fixed it.
Conclusion/Questions
If you're using IAP's, which work in debug build testing, but not in production release on the same device. Disable your device in the Dev Portal and re-install from the store.
1) How is Apple deciding when the IAP should be sandboxed? Is it certificate based? Is it if the device ID is registered as a development device?
2) Why would this IAP code work in a debug build on my development device, but not with a release build? (Until i disabled the device in the DevPortal)
3) What information can be gathered from the crash log that would pin point this issue more accurately?
UPDATE
After reading more into EXC_BREAKPOINT (SIGTRAP) when it comes to Swift, i think it it's most likely related to an index out of bounds exception in the Products array. Specifically, as the crash report says, this line...
for i in 0...products!.count - 1{
But why would products be nil just because the development device is requesting IAPs from the production server?

Related

Issues with RxSwift and AVKit

I am building what I hope to be a simple macOS application that will locally stored videos selected from a popUP button.
The application is two windows 1) the AVPlayerView and 2) a simple control panel that allows the user to select and play the flagged videos on the other window.
All of this works very well in XCode. When the saved URL is selected, it is made into an AVAsset which is it turn made into an AVPlayerItem. The next process I have tried successfully(in Xcode) two ways: create a 1) PublishSubect or a 2) PublishSubject. In the view controller for the AVPlayerview window, I subscribe to the control panel's publish subject and either update the AVplayerView's player with the AVPlayerItem
destinationVC.videoSubject.subscribe(
onNext: { [weak self] item in
self?.player.replaceCurrentItem(with: item)
}
).disposed(by: bag)
or I inject the player in a similar fashion. Either of these options works flawlessly when I run the application in XCode. The issue that I have is when I archive it to run the app on my computer, when I select the video to be played, the app crashes.
I isolated this task to a background thread with the hopes of better sniffing out an error but the resulting crash report does not make much sense to me:
Thread 2 Crashed:: Dispatch queue: Background
0 [myinfo].STSVideoPlayer 0x000000010e655476 closure #1 in closure #1 in VideoViewController.prepare(for:sender:) + 134 (VideoViewController.swift:40)
1 [myinfo].STSVideoPlayer 0x000000010e655499 thunk for #escaping #callee_guaranteed () -> () + 25
2 libdispatch.dylib 0x00007fff6e6d56c4 _dispatch_call_block_and_release + 12
3 libdispatch.dylib 0x00007fff6e6d6658 _dispatch_client_callout + 8
4 libdispatch.dylib 0x00007fff6e6dbc44 _dispatch_lane_serial_drain + 597
5 libdispatch.dylib 0x00007fff6e6dc5d6 _dispatch_lane_invoke + 363
6 libdispatch.dylib 0x00007fff6e6e5c09 _dispatch_workloop_worker_thread + 596
7 libsystem_pthread.dylib 0x00007fff6e930a3d _pthread_wqthread + 290
8 libsystem_pthread.dylib 0x00007fff6e92fb77 start_wqthread + 15
I am, obviously, over my head here. Any insight that you may have would be much appreciated!
I found a more detailed crash report, and it turns out that I was force-unwrapping some nils. I am not sure how that got through in XCode, but now everything is working swimmingly.

App crashed on iOS 7 for Map functionality developed using MKAnnotation, CGBitmapContextCreate and NSOperationQueue

Our App has Map and GPS based location tracking functionality. This app is already uploaded on Apple Store. The App contains following feature:
Map Shows real-time traffic data Shows real-time traffic event (Accident, Traffic Jam etc.)
User’s GPS location tracking
The application runs fine for the iOS versions 5 and 6.
We are facing following crashing issue for iOS 7 Beta while operating Map functionality in the app. We have used the following features of iOS to render the traffic data and traffic event on Map:
MKAnnotation to render the traffic event
To render the traffic data, app is using the CGBitmapContextCreate function.
context = CGBitmapContextCreate (NULL,
self.mapView.frame.size.width,
self.mapView.frame.size.height,
8,// bits per component
bitmapBytesPerRow,
colorSpace,
kCGImageAlphaPremultipliedLast);
CGContextSetAllowsAntialiasing (context,YES)
Draw the line to display the traffic data on the Bitmap context.
Created bitmap context will be displayed on map using the MKAnnotation API.
App uses the NSOperationQueue to render the traffic and event data because the user interaction with map is smooth. Following is the snippet of the code:
[queue addOperationWithBlock:^{ [Set the required data], [Update the UI] }];
Following are two crash logs which gets generated while random operation n of the Map functionality.
Crash Log - 1
Incident
Identifier: 471EAE21-E118-4E3D-AAAE-D7D82B1D6326
CrashReporter
Key:
bdbf75eb30240449214769478f38830aa7a14f7f
Hardware
Model: iPhone5,2
Process: {Application Name} [246]
Path: /var/mobile/Applications/4FA0A7F2-4998-4F8F-A4C6-66D849D074B8/{Application Name}.app/{Application Name}
Identifier: {Application bunald name}
Version: X.X.X.X
Code
Type: ARM (Native)
Parent
Process: launchd [1]
Date/Time: 2013-08-30 14:21:24.523 +0530
OS
Version: iOS 7.0 (11A4449d)
Report
Version: 104
Exception
Type: EXC_BAD_ACCESS (SIGSEGV)
Exception
Subtype: KERN_INVALID_ADDRESS at 0x8000000c
Triggered
by Thread: 0
Thread
0 Crashed:
0 libobjc.A.dylib 0x38ed3b66
objc_msgSend + 6
1 CoreFoundation 0x2ede773c -[__NSSetM removeObject:] + 92
2 MapKit 0x3002de96 -[MKAnnotationManager
_removeRepresentationForAnnotation:fromCull:] + 490
3 MapKit 0x3004bc54 -[MKAnnotationManager
_removeAnnotation:updateVisible:removeFromContainer:] + 272
4 MapKit 0x3004bb38 -[MKAnnotationManager removeAnnotation:] + 24
5 SLIM 0x00165828 -[TravelStarViewController
mapView:viewForAnnotation:] (TravelStarViewController.m:1735)
6 MapKit 0x3005ea86 -[MKMapView
annotationManager:representationForAnnotation:] + 74
7 MapKit 0x3002a136 -[MKAnnotationManager _addRepresentationForAnnotation:]
+ 362
8 MapKit 0x30028c4a -[MKAnnotationManager updateVisibleAnnotations] +
1034
9 Foundation 0x2f876358 __NSFireTimer + 60
10 CoreFoundation 0x2ee7ae84 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
+ 12
11 CoreFoundation 0x2ee7aa9e __CFRunLoopDoTimer + 790
12 CoreFoundation 0x2ee78e26 __CFRunLoopRun + 1214
13 CoreFoundation 0x2ede353c CFRunLoopRunSpecific + 520
14 CoreFoundation 0x2ede331e CFRunLoopRunInMode + 102
15 GraphicsServices 0x3387733e
GSEventRunModal + 134
16 UIKit 0x313fc7b0 UIApplicationMain + 1132
17 SLIM 0x000f3fa6
main (main.m:15)
18 SLIM 0x000f3efc start + 36
I think it may be that traffic events are coming in and taking to long in NSOperation. The operation could start, and then be referencing map graphical elements that no longer exist in the MapView. For instance, the user could be scrolling the map, and the NSOperation could "queue" up, and then end when the target region is out of view. The crash is clearly a memory violation. Commonly caused by code trying to access memory that was freed.
I would suggest that you look into your use of NSOperationQueue. I can see how it would make the map interaction smoother, and that part may be OK, but coupled with the "events" could be causing problems.
From the crash I can see that it is running on a CFRunLoop and a NSTimer is firing. NSTimers are notorious for not stopping fully in Objective C. When they finally fire off, the elements they work with are commonly done and freed their memory.

iOS crash in CFStringGetLength in CoreFoundation

I'm getting a crash that, to me, seems as though it is a bug in the way that Apple is handling the goToDefaultLocation message of MKMapView. That message in turn calls [ALCityManager localeWithCode:], which calls [NSLocale componentsFromLocaleIdentifier:] which calls CFLocaleCreateComponentsFromLocaleIdentifier which calls CFStringGetLength and the crash occurs.
Can someone help to point me in the direction of either fixing the bug, if it is my code that is causing this, or, helping me find a workaround if, in fact, this is a bug in Apple's code (unlikely??).
Crash log below:
Incident Identifier: 84198BB6-45BD-493B-955F-75CCB5246DDD
CrashReporter Key: 7dbf53bf1f1a3635d7c3c49e726dedc609ed9f3a
Hardware Model: iPhone3,1
Process: MyApp [340]
Path: /var/mobile/Applications/DCE9A5A1-8E24-4D4F-A1ED-9855C6CA1742/MyApp.app/MyApp
Identifier: MyApp
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2011-03-25 10:36:06.382 -0700
OS Version: iPhone OS 4.3 (8F190)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 CoreFoundation 0x00009a66 CFStringGetLength + 6
1 CoreFoundation 0x0002f994 CFLocaleCreateComponentsFromLocaleIdentifier + 60
2 CoreFoundation 0x000483b8 +[NSLocale componentsFromLocaleIdentifier:] + 12
3 AppSupport 0x00016eee -[ALCityManager localeWithCode:] + 130
4 MapKit 0x00038488 -[MKMapView goToDefaultLocation] + 80
5 Foundation 0x000907c6 __NSFireTimer + 130
6 CoreFoundation 0x00075a40 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 8
7 CoreFoundation 0x00077ec4 __CFRunLoopDoTimer + 844
8 CoreFoundation 0x0007883e __CFRunLoopRun + 1082
9 CoreFoundation 0x00008ebc CFRunLoopRunSpecific + 224
10 CoreFoundation 0x00008dc4 CFRunLoopRunInMode + 52
11 GraphicsServices 0x00004418 GSEventRunModal + 108
12 GraphicsServices 0x000044c4 GSEventRun + 56
13 UIKit 0x0002ed62 -[UIApplication _run] + 398
14 UIKit 0x0002c800 UIApplicationMain + 664
15 MyApp 0x000023f0 main (main.m:34)
16 MyApp 0x00002370 start + 44
I got exactly the same crash reports, ONLY with iOS 4.3 / 4.3.1 AND iPhone 3GS/4 (armv7)
I think it is an Apple Bug, iOS4.3 has others ugly regressions concerning MapKit. (like the MKReverseGeocoder early releasing crash...)
An easy workaround would be to override -[MKMapView goToDefaultLocation] but at the risk of an Apple rejection since it is a private API... (Rejected for a bug workaround... I know... People are mean)
Another solution would be to analyze (reverse...) CFLocaleCreateComponentsFromLocaleIdentifier and componentsFromLocaleIdentifier: and [ALCityManager localeWithCode:] to understand how it can crash, being called with a nil locale identifier and maybe fix application locale programmatically, since it looks like the error coming from determining user's locale from device settings (or worse, from city/geolocation)... or at least WARN user that its locale settings might cause troubles...
Something I just can not(/want to) do, not being able to reproduce that bug.
Well your exception code is EXC_BAD_ACCESS. This is generally a memory-management error (i.e. some bit of code tried to access an object that had already been released/dealloc'ed).
It is possible but very unlikely that this is a bug in Apple/framework code. It's more likely that somewhere in your code you are either over-releasing something or hanging on to an auto-released object instance or otherwise accessing something that shouldn't be accessed.
Given that the crash happened in MapKit, I'd recommend looking at your map-related code for possible sources of this crash. Note that MapKit can be a bit tempermental; I've seen crashes in cases such as attempting to access the LocationManager's current-location when the user has location-services turned off. I'd expect such a case to fail (for instance, by returning a nil location), but not to crash the app.

iPhone Crash stack trace VS Crash report

Just spent some time... on a crash, without understanding it. That's a classic:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000010
Which leads me to a memory issue, addressing the invalid adress 0x10
What bothers me is that I have crash report and stack trace, which differ:
The crash report, sent by user (symbolicated successfully, that happens) :
Thread 0 Crashed:
0 libobjc.A.dylib 0x000027d8 objc_msgSend + 16
1 UIKit 0x0005e9d2 -[UIViewAnimationState animationDidStop:finished:] + 54
2 QuartzCore 0x0002d8c2 run_animation_callbacks(double, void*) + 286
3 QuartzCore 0x0002d764 CA::timer_callback(__CFRunLoopTimer*, void*) + 116
4 CoreFoundation 0x000567f4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 8
5 CoreFoundation 0x000562a6 __CFRunLoopDoTimer + 854
6 CoreFoundation 0x0002779e __CFRunLoopRun + 1082
7 CoreFoundation 0x00027270 CFRunLoopRunSpecific + 224
8 CoreFoundation 0x00027178 CFRunLoopRunInMode + 52
9 GraphicsServices 0x000045ec GSEventRunModal + 108
10 GraphicsServices 0x00004698 GSEventRun + 56
11 UIKit 0x0000411c -[UIApplication _run] + 396
12 UIKit 0x00002128 UIApplicationMain + 664
13 MyApp 0x00003158 main (main.m:13)
14 MyApp 0x00003120 0x1000 + 8480
The crash stack trace (catched live by an Exception Handler)
0 MyApp 0x000d79c3 0x0 + 883139
1 MyApp 0x000d790b 0x0 + 882955
2 libSystem.B.dylib 0x302765d3 _sigtramp + 42
3 UIKit 0x31eab9d9 -[UIViewAnimationState animationDidStop:finished:] + 60
4 QuartzCore 0x33a178c9 _ZL23run_animation_callbacksdPv + 292
5 QuartzCore 0x33a1776b _ZN2CAL14timer_callbackEP16__CFRunLoopTimerPv + 122
6 CoreFoundation 0x3084e7fb __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 14
7 CoreFoundation 0x3084e2ad __CFRunLoopDoTimer + 860
8 CoreFoundation 0x3081f7a5 __CFRunLoopRun + 1088
9 CoreFoundation 0x3081f277 CFRunLoopRunSpecific + 230
10 CoreFoundation 0x3081f17f CFRunLoopRunInMode + 58
11 GraphicsServices 0x31e445f3 GSEventRunModal + 114
12 GraphicsServices 0x31e4469f GSEventRun + 62
13 UIKit 0x31e51123 -[UIApplication _run] + 402
14 UIKit 0x31e4f12f UIApplicationMain + 670
15 MyApp 0x0000315f 0x0 + 12639
16 MyApp 0x00003128 0x0 + 12584
Both differ, and the stack trace points to the crash in my code, but at addresses I can neither symbolicate nor identify. I think the crash report indicates that a message was sent to a released instance... Probably related to the use of :
+ (void)setAnimationDelegate:(id)delegate
+ (void)setAnimationDidStopSelector:(SEL)selector
So here (finally!) are my questions:
What explains the differences between logs? (libobjc.A vs libSystem.B ??)
Does the SIGBUS comes from my code or from UIKit?
How can I decipher the stack trace upper addresses (0x000d79??, which atos doesn't resolve)
Is that what I think, an issue related to an animation failing to end? similar to this > How to unset delegate on UIView setAnimationDelegate: call?
AFAIK, setAnimationDelegate is supposed to retain delegate... Someone to confirm?
EDIT: I can't use NSZombiesEnabled, this is a crash report from a published app, a crash that I didn't manage to reproduce on development environment. I just have these logs to diagnose.
Whenever I see objc_msgSend at the top, my trust of the remaining stack is low, as the error that gives this tends to do bad things to the stack.
GuardMalloc is good for this since the attempt to do anything with deallocated space will crash the app immediately in the debugger. The stack will be intact. (This makes the app very slow, but it is a very powerful tool.)
The two stacks are the same up to the UIViewAnimationState method call. The version that came from your exception handler is showing C++ mangled names instead of the regular names shown in the crash log.
(As I understand it) _sigtramp is the system's method of calling your signal handler and is short for Signal Trampoline. The stack entries beyond that are probably your signal-handler code.
Answering my own question, weeks laters, since I had no relevant answers, most are guesses, I wished I had more precise answers, but I guess my question was unclear :
Difference is coming from the origin of the log, a sighandler vs CrashReporter service, which are happening at different times, then the stack traces are slightly different.
SIGBUS comes from UIKit, but chances are big that's on a callback initiated from my code that ends on a released object. These kind of stack traces are a pain to debug when you can't reproduce the issue, since it basically tells you "I'm crashing somewhere because of an animation", which one, where... I still didn't figured precisely. Could be anywhere, and also could be an Apple iOS bug.
The first addresses in the stack are just a dead-end where any SIGBUS stack-trace ends when a released object is called. They differs across compilations (versions), but are the same on any device, That's why they can't be symbolicated. (I would love to have a technical explanation of this, instead of my guess)
& 5. I guess I solved this bug byt being more "agressive" on canceling animations in certain cases like on deallocation of some Views...
Hope that helps someone.
You should try NSZombie, to get information about what object you've released. This is a very useful tool when you get EXC_BAD_ACCESS.
To activate NSZombie do the following:
Get info of the executable.
Go to the arguments tab.
In the "Variables to be set in the environment:" section add:
Name: NSZombieEnabled
Value: YES
Then run your app as usual and when it crashes it should tell you which deallocated object received the message.
1. I'm not 100% sure but I think the discrepancy is due to how the application is being run. In the second log it looks like you're running the application via XCode in debug mode, a sigtramp signal has been sent to indicate a EXC_BAD_ACCESS error.
2. Your code - the error may come from the UIKit library but it's a result of a problem with your usage.
3. This is where NSZombieEnabled will make your life a lot easier! If you run your application with the NSZombieEnabled flag set XCode will keep 'zombie' objects in place of deallocated objects. When a zombie object is sent a message the process will trap the error and let you know exactly what object was sent the message.
If you're using XCode 4 enable NSZombieEnabled using the following instructions...
How do I set up NSZombieEnabled in Xcode 4?
For older versions follow these instructions...
http://www.cocoadev.com/index.pl?NSZombieEnabled
4. It does indeed appear that your animation delegate has been deallocated prior to the animation completing.

Crash invalidates url for NSPersistentStoreCoordinator

I have a Core Data app that has a bug that causes the app to crash and I have not tracked down its cause yet. One of the results of the crash is that the next time the app is started up it can not open the persistent store used by the application previously. The following error is returned from the addPersistentStoreWithType: method:
NSUnderlyingException = Error validating url for store;
And, of course, it cannot retrieve any of the objects previously stored by the app. Does anyone know what can cause an app to no longer be able to find its persistent store?
The crash that causes the app to shut down prior to all this happening produces the following crash log:
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread: 0
Thread 0 Crashed:
0 libSystem.B.dylib 0x0007e98c __kill + 8
1 libSystem.B.dylib 0x0007e97c kill + 4
2 libSystem.B.dylib 0x0007e96e raise + 10
3 libSystem.B.dylib 0x0009361a abort + 34
4 libstdc++.6.dylib 0x000453b0 __gnu_cxx::__verbose_terminate_handler() + 376
5 libobjc.A.dylib 0x00005858 _objc_terminate + 104
6 libstdc++.6.dylib 0x00043776 __cxxabiv1::__terminate(void (*)()) + 46
7 libstdc++.6.dylib 0x000437ca std::terminate() + 10
8 libstdc++.6.dylib 0x00043896 __cxa_throw + 74
9 libobjc.A.dylib 0x00004714 objc_exception_throw + 64
10 Foundation 0x000013c2 __NSThreadPerformPerform + 570
11 CoreFoundation 0x00056a96 CFRunLoopRunSpecific + 1834
12 CoreFoundation 0x00056356 CFRunLoopRunInMode + 42
13 GraphicsServices 0x00003b2c GSEventRunModal + 108
14 GraphicsServices 0x00003bd8 GSEventRun + 56
15 UIKit 0x00002768 -[UIApplication _run] + 384
16 UIKit 0x0000146c UIApplicationMain + 688
17 Meetchu 0x00002568 main (main.m:14)
18 Meetchu 0x0000251c start + 32
I cannot figure out what is happening from this information. Can anyone help with either of these errors?
Many thanks in advance.
If you're storing the actual URL to a file in the app's directory instead of regenerating it each time relative to the app directory, then the invalid URL is the result of the simulator/device changing the name of the app directory to a random UUID. It does that sometimes in response to crashes.
The obvious first step is the log the URL and see if the store is actually at that location.
Drew,
Without seeing some code, I can tell you that one source of agony to me when I first started with Core Data was versioning your models. If you have changed your managed object model in any way, this will cause your app to crash without some versioning (i.e., lightweight) code in place.
This may not be the source of your problem, but one thing you can try is to either remove your app from your iPhone Simulator or use "Reset Contents and Settings" from the iPhone simulator menu. If this fixes the problem, then you're looking at a migrations issue.
Cheers.