Related
Seeking for help for an issue, apologize if it is obvious as I am not experienced. My environment is Xcode 10.1 and Swift.
weak var node = Label(geometry: label, labelType: labelType, index: index)
if node != nil {
transformTextNodeCenter(for: node!) //move pivot to center
node!.scale = SCNVector3(x: parameters.textScaleRatio, y: parameters.textScaleRatio, z: parameters.textScaleRatio) //rescale the textnode
print(node!) //print no.1
print(node!.labelType, node!.index, node!.boundingBox) //print no.2
let textWidth = node!.boundingBox.max.x - node!.boundingBox.min.x //<- This is the line generate error
let textHeight = node!.boundingBox.max.y - node!.boundingBox.min.y
let maxWidth = max(textWidth, recordedWidth)
node!.position = position + SCNVector3(x: extra.x * textWidth, y: extra.y * textWidth, z: extra.z * textWidth)
node!.eulerAngles = eulerAngles
node!.name = String("\(name)\(text)")
self.label[labelArray].append(node!)
//self.label.insert(node)
self.addChildNode(node!)
} else {
print("node == nil")
}
The purpose of the function is to add SCNText into my scene, but there is a possibility my textnode will be deallocated in the middle of function (I put it in a for loop and it runs randomly several loop before crash) see pic. 1
It looks like the node initialed properly as it can pass the if node != nil" statement, and print no.2 as follows
"row 0 (min: __C.SCNVector3(x: 0.7861328, y: 1.2421875, z: 0.0), max: __C.SCNVector3(x: 18.325195, y: 10.211914, z: 0.0))"
This makes me believe I have successfully receive boundingBox of the textnode. But it failed at the next line "let textHeight = node!.boundingBox.max.y - node!.boundingBox.min.y".
When crashed, I try to trace it and it shows the node is nil as pic. 2
& pic. 3.
I read some post on so and follow the instruction to set break point on objc_overrelease_during_dealloc_error, but it leads me to "SCNBoundingVolume.boundingBox.getter"
libswiftSceneKit.dylib(extension in SceneKit):__C.SCNBoundingVolume.boundingBox.getter : (min: __C.SCNVector3, max: __C.SCNVector3):
0x10205167c <+0>: sub sp, sp, #0x30 ; =0x30
0x102051680 <+4>: stp x29, x30, [sp, #0x20]
0x102051684 <+8>: add x29, sp, #0x20 ; =0x20
0x102051688 <+12>: nop
0x10205168c <+16>: ldr x8, #0x29d4 ; (void *)0x000000021e95aa28: SCNVector3Zero
0x102051690 <+20>: ldp w9, w10, [x8]
0x102051694 <+24>: ldr w8, [x8, #0x8]
0x102051698 <+28>: stp w9, w10, [sp, #0x10]
0x10205169c <+32>: str w8, [sp, #0x18]
0x1020516a0 <+36>: stp w9, w10, [sp]
0x1020516a4 <+40>: str w8, [sp, #0x8]
0x1020516a8 <+44>: nop
0x1020516ac <+48>: ldr x1, #0x2e9c ; "getBoundingBoxMin:max:"
0x1020516b0 <+52>: add x2, sp, #0x10 ; =0x10
0x1020516b4 <+56>: mov x3, sp
0x1020516b8 <+60>: mov x0, x20
0x1020516bc <+64>: bl 0x102053310 ; symbol stub for: objc_msgSend
0x1020516c0 <+68>: ldr w1, [sp, #0x18]
0x1020516c4 <+72>: ldr x0, [sp, #0x10]
0x1020516c8 <+76>: ldr w8, [sp]
0x1020516cc <+80>: ldur x2, [sp, #0x4]
0x1020516d0 <+84>: bfi x1, x8, #32, #32
0x1020516d4 <+88>: ldp x29, x30, [sp, #0x20]
0x1020516d8 <+92>: add sp, sp, #0x30 ; =0x30
0x1020516dc <+96>: ret
And I can't find a way to interpret it.
P.S. strong var still result to crash but with different error message "EXC_BAD_ACCESS" as pic4.
Created a simple app which prototype works on virtual SE and 8 plus however i can not build it on a physical iPhone8Plus ..i only get while screen, and this error message
dyld`__abort_with_payload:
0x104d8af14 <+0>: mov x16, #0x209
0x104d8af18 <+4>: svc #0x80
-> 0x104d8af1c <+8>: b.lo 0x104d8af34 ; <+32>
0x104d8af20 <+12>: stp x29, x30, [sp, #-0x10]!
0x104d8af24 <+16>: mov x29, sp
0x104d8af28 <+20>: bl 0x104d8a5b0 ; cerror_nocancel
0x104d8af2c <+24>: mov sp, x29
0x104d8af30 <+28>: ldp x29, x30, [sp], #0x10
0x104d8af34 <+32>: ret
one one with the arrow is displayed red and i also get this in my debug
dyld: Library not loaded: #rpath/libswiftCore.dylib
Referenced from: /var/containers/Bundle/Application/73798F76-73E4-49C3- B36F-7DD3F61F8A4F/BodyBeats.app/BodyBeats
Reason: no suitable image found. Did find:
/private/var/containers/Bundle/Application/73798F76-73E4-49C3-B36F-7DD3F61F8A4F/BodyBeats.app/Frameworks/libswiftCore.dylib: code signature invalid for '/private/var/containers/Bundle/Application/73798F76-73E4-49C3-B36F-7DD3F61F8A4F/BodyBeats.app/Frameworks/libswiftCore.dylib'
(lldb)
i tried restarting both iPhone and my MacBook...any ideas?
tl;dr - The code in the question is correct. Reason for crash at another party.
The challenge is to control an Elgato Eve Energy HomeKit enabled outlet.
Up til where the code starts, everything is working OK, so the correct room, accessory and so on is selected. The code does turn off the outlet, but right afterwards the app crashes.
guard let services = accessory?.services else {
print("No Service")
return
}
for service in services {
if service.serviceType == HMServiceTypeOutlet {
for characteristic in service.characteristics {
print(characteristic.characteristicType)
if characteristic.characteristicType == HMCharacteristicTypePowerState {
print(characteristic.metadata!)
dump(characteristic)
// Turning off the outlet
characteristic.writeValue(false, completionHandler: { (error: Error?) -> Void in
if error == nil {
print("Yep")
} else {
print("Nop")
}
})
}
}
}
}
Log
00000023-0000-1000-8000-0026BB765291
00000025-0000-1000-8000-0026BB765291
[%# Format: bool, Manufacturer Description: Power State ]
- <HMCharacteristic: 0x1702c23e0> #0
- super: NSObject
00000026-0000-1000-8000-0026BB765291
E863F10A-079E-48FF-8F27-9C2605A29F52
E863F126-079E-48FF-8F27-9C2605A29F52
E863F10D-079E-48FF-8F27-9C2605A29F52
E863F10C-079E-48FF-8F27-9C2605A29F52
2017-02-07 23:19:59.725340 POS[499:100178] -[__NSDate length]: unrecognized selector sent to instance 0x170007710
2017-02-07 23:19:59.725767 POS[499:100178] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSDate length]: unrecognized selector sent to instance 0x170007710'
*** First throw call stack:
(0x188a291b8 0x18746055c 0x188a30268 0x188a2d270 0x18892680c 0x1895be458 0x1895be350 0x1895be698 0x1006328f8 0x1a249ac8c 0x199674f34 0x19966c588 0x1a249d194 0x101951258 0x101951218 0x10195eaec 0x101954ce0 0x10195f088 0x101960e2c 0x101960b78 0x187abb2a0 0x187abad8c)
libc++abi.dylib: terminating with uncaught exception of type NSException
Sym
2017-02-08 10:17:47.804825 POS[602:171994] -[__NSDate length]: unrecognized selector sent to instance 0x1740169c0
iZettlePayments`-[NSDictionary(Fractionized) dateForKey:]:
0x100973d88 <+0>: stp x22, x21, [sp, #-48]!
0x100973d8c <+4>: stp x20, x19, [sp, #16]
0x100973d90 <+8>: stp x29, x30, [sp, #32]
0x100973d94 <+12>: add x29, sp, #32 ; =32
0x100973d98 <+16>: mov x19, x0
0x100973d9c <+20>: nop
0x100973da0 <+24>: ldr x20, #861056 ; (void *)0x00000001ad8966b8: NSDateFormatter
0x100973da4 <+28>: nop
0x100973da8 <+32>: ldr x21, #851248 ; "izDateFormatterUsingISO8601"
0x100973dac <+36>: mov x0, x2
0x100973db0 <+40>: bl 0x1009e9b54 ; symbol stub for: objc_retain
0x100973db4 <+44>: mov x22, x0
0x100973db8 <+48>: mov x0, x20
0x100973dbc <+52>: mov x1, x21
0x100973dc0 <+56>: bl 0x1009e9b30 ; symbol stub for: objc_msgSend
0x100973dc4 <+60>: mov x29, x29
0x100973dc8 <+64>: bl 0x1009e9b78 ; symbol stub for: objc_retainAutoreleasedReturnValue
0x100973dcc <+68>: mov x20, x0
0x100973dd0 <+72>: nop
0x100973dd4 <+76>: ldr x1, #849044 ; "valueForKey:"
0x100973dd8 <+80>: mov x0, x19
0x100973ddc <+84>: mov x2, x22
0x100973de0 <+88>: bl 0x1009e9b30 ; symbol stub for: objc_msgSend
0x100973de4 <+92>: mov x19, x0
0x100973de8 <+96>: mov x0, x22
0x100973dec <+100>: bl 0x1009e9b48 ; symbol stub for: objc_release
0x100973df0 <+104>: mov x0, x19
0x100973df4 <+108>: bl 0x1009e9b78 ; symbol stub for: objc_retainAutoreleasedReturnValue
0x100973df8 <+112>: mov x19, x0
0x100973dfc <+116>: nop
0x100973e00 <+120>: ldr x1, #851168 ; "dateFromString:"
0x100973e04 <+124>: mov x0, x20
0x100973e08 <+128>: mov x2, x19
0x100973e0c <+132>: bl 0x1009e9b30 ; symbol stub for: objc_msgSend
0x100973e10 <+136>: mov x29, x29
0x100973e14 <+140>: bl 0x1009e9b78 ; symbol stub for: objc_retainAutoreleasedReturnValue
0x100973e18 <+144>: mov x21, x0
0x100973e1c <+148>: mov x0, x19
0x100973e20 <+152>: bl 0x1009e9b48 ; symbol stub for: objc_release
0x100973e24 <+156>: mov x0, x20
0x100973e28 <+160>: bl 0x1009e9b48 ; symbol stub for: objc_release
0x100973e2c <+164>: mov x0, x21
0x100973e30 <+168>: ldp x29, x30, [sp, #32]
0x100973e34 <+172>: ldp x20, x19, [sp, #16]
0x100973e38 <+176>: ldp x22, x21, [sp], #48
0x100973e3c <+180>: b 0x1009e9ac4 ; symbol stub for: objc_autoreleaseReturnValue
Browsing the Elgato Eve services and characteristics, shows the first characteristic in the array is the one holding the name, and the second one is the one I need to manipulate. The printed metadata shows its a bool, and confirms its the Power State, and its both readable and writable, as described in the table linked to before.
Since I write a false to the correct characteristic, the outlet turns off, but a couple of seconds later, the app crashes. I have removed any observers and delegate methods that could interfere. This really baffles me.
Further, the code does not crash on iOS 9, just iOS 10.2, as well as the 10.3 betas
Solution
Sorry guys, after a whole lot of swearing, a bruised toe, and a lot less hair, and 24 hours later, I found the culprit. Im using iZettle, a payment device, and as soon as the libraries was added to the project, it crashed. The guys over at iZettle admitted they had an extension on NSDictionary
#interface NSDictionary (Fractionized)
- (NSDate *)dateForKey:(id)aKey;
#end
This one collides with an extension in HomeKit, so thats the reason for the problem. The result is they have to add a prefix to their extension and compile the libraries again.
While a symbolicated stack trace would help, there is one symbol in your logs that may provide a useful hint: something is trying to ask an NSDate for length. In my experience, this happens when a library expects something to be an NSString and it's about to parse it or print it or what have you.
Perhaps you know where NSDates are being used. It will also help to know if the crash is on the same thread that is executing your above code. Given that you are experiencing a slight delay, it's hard to say if it is related to that code at all! Perhaps elsewhere in your app, you are responding to the device itself giving you a status update, and maybe printing a value that you think is a string but is really a date?
I am getting this exception thrown at a certain point in the App but can't track down the cause. I assume its simply a UI call being made from a background thread but I can't find any UI calls that are not made on the main thread.
BTW all UI calls are wrapped in DispatchQueue.main.async{}, presumably I missed something but can't figure out how to track it down.
Any suggestion how to figure out what call is leading to this - there are a few background threads running concurrently as well as events from SNS and Bluetooth.
This application is modifying the autolayout engine from a background thread after the engine was accessed from the main thread. This can lead to engine corruption and weird crashes.
Stack:(
0 CoreFoundation 0x000000018fc8e1d8 <redacted> + 148
1 libobjc.A.dylib 0x000000018e6c855c objc_exception_throw + 56
2 CoreFoundation 0x000000018fc8e108 <redacted> + 0
3 Foundation 0x0000000190875ea4 <redacted> + 192
4 Foundation 0x00000001906bd3fc <redacted> + 36
5 UIKit 0x0000000196434770 <redacted> + 72
6 UIKit 0x0000000195ae61e8 <redacted> + 1140
7 QuartzCore 0x0000000192fa6188 <redacted> + 148
8 QuartzCore 0x0000000192f9ae64 <redacted> + 292
9 QuartzCore 0x0000000192f9ad24 <redacted> + 32
10 QuartzCore 0x0000000192f177ec <redacted> + 252
11 QuartzCore 0x0000000192f3ec58 <redacted> + 512
12 QuartzCore 0x0000000192f3f124 <redacted> + 660
13 libsystem_pthread.dylib 0x000000018ed22fbc <redacted> + 572
14 libsystem_pthread.dylib 0x000000018ed22ce4 <redacted> + 200
15 libsystem_pthread.dylib 0x000000018ed22378 pthread_mutex_lock + 0
16 libsystem_pthread.dylib 0x000000018ed21da4 start_wqthread + 4
)
OK So I added the Breakpoint but I just get the following on thread 10 (!) I can't figure out what could be running on Thread 10 or what UI code is being called.
libobjc.A.dylib`objc_exception_throw:
-> 0x18e6c8524 <+0>: stp x28, x27, [sp, #-64]!
0x18e6c8528 <+4>: stp x22, x21, [sp, #16]
0x18e6c852c <+8>: stp x20, x19, [sp, #32]
0x18e6c8530 <+12>: stp x29, x30, [sp, #48]
0x18e6c8534 <+16>: add x29, sp, #48 ; =48
0x18e6c8538 <+20>: sub sp, sp, #4032 ; =4032
0x18e6c853c <+24>: mov x20, x0
0x18e6c8540 <+28>: orr w0, wzr, #0x20
0x18e6c8544 <+32>: bl 0x18e6b6c24 ; __cxa_allocate_exception
0x18e6c8548 <+36>: mov x19, x0
0x18e6c854c <+40>: adrp x8, 157305
0x18e6c8550 <+44>: ldr x8, [x8, #408]
0x18e6c8554 <+48>: mov x0, x20
0x18e6c8558 <+52>: blr x8
0x18e6c855c <+56>: mov x20, x0
0x18e6c8560 <+60>: adrp x8, 151285
0x18e6c8564 <+64>: ldr x1, [x8]
0x18e6c8568 <+68>: bl 0x18e6daf20 ; objc_msgSend
0x18e6c856c <+72>: str x20, [x19]
0x18e6c8570 <+76>: adrp x8, 151286
0x18e6c8574 <+80>: add x8, x8, #160 ; =160
0x18e6c8578 <+84>: add x8, x8, #16 ; =16
0x18e6c857c <+88>: mov x21, x19
0x18e6c8580 <+92>: str x8, [x21, #8]!
0x18e6c8584 <+96>: mov x0, x20
0x18e6c8588 <+100>: bl 0x18e6c681c ; object_getClassName
0x18e6c858c <+104>: str x0, [x19, #16]
0x18e6c8590 <+108>: cbnz x20, 0x18e6c859c ; <+120>
0x18e6c8594 <+112>: movz x8, #0
0x18e6c8598 <+116>: b 0x18e6c85e0 ; <+188>
0x18e6c859c <+120>: tbz x20, #63, 0x18e6c85d8 ; <+180>
0x18e6c85a0 <+124>: lsr x8, x20, #60
0x18e6c85a4 <+128>: cmp x8, #15 ; =15
0x18e6c85a8 <+132>: lsr x8, x20, #57
0x18e6c85ac <+136>: and x8, x8, #0x78
0x18e6c85b0 <+140>: adrp x9, 157305
0x18e6c85b4 <+144>: add x9, x9, #544 ; =544
0x18e6c85b8 <+148>: add x8, x9, x8
0x18e6c85bc <+152>: lsr x9, x20, #52
0x18e6c85c0 <+156>: adrp x10, 157305
0x18e6c85c4 <+160>: add x10, x10, #672 ; =672
0x18e6c85c8 <+164>: add x9, x10, w9, uxtb #3
0x18e6c85cc <+168>: csel x8, x8, x9, lo
0x18e6c85d0 <+172>: ldr x8, [x8]
0x18e6c85d4 <+176>: b 0x18e6c85e0 ; <+188>
0x18e6c85d8 <+180>: ldr x8, [x20]
0x18e6c85dc <+184>: and x8, x8, #0xffffffff8
0x18e6c85e0 <+188>: str x8, [x19, #24]
0x18e6c85e4 <+192>: adrp x22, 151466
0x18e6c85e8 <+196>: add x22, x22, #1958 ; =1958
0x18e6c85ec <+200>: ldrb w8, [x22]
0x18e6c85f0 <+204>: cbz w8, 0x18e6c8610 ; <+236>
0x18e6c85f4 <+208>: mov x0, x20
0x18e6c85f8 <+212>: bl 0x18e6c681c ; object_getClassName
0x18e6c85fc <+216>: stp x20, x0, [sp, #8]
0x18e6c8600 <+220>: str x19, [sp]
0x18e6c8604 <+224>: adrp x0, 29
0x18e6c8608 <+228>: add x0, x0, #2192 ; =2192
0x18e6c860c <+232>: bl 0x18e6c7f00 ; _objc_inform
0x18e6c8610 <+236>: adrp x8, 151466
0x18e6c8614 <+240>: add x8, x8, #1959 ; =1959
0x18e6c8618 <+244>: ldrb w8, [x8]
0x18e6c861c <+248>: cbz w8, 0x18e6c8674 ; <+336>
0x18e6c8620 <+252>: ldrb w8, [x22]
0x18e6c8624 <+256>: cbnz w8, 0x18e6c8644 ; <+288>
0x18e6c8628 <+260>: mov x0, x20
0x18e6c862c <+264>: bl 0x18e6c681c ; object_getClassName
0x18e6c8630 <+268>: stp x20, x0, [sp, #8]
0x18e6c8634 <+272>: str x19, [sp]
0x18e6c8638 <+276>: adrp x0, 29
0x18e6c863c <+280>: add x0, x0, #2192 ; =2192
0x18e6c8640 <+284>: bl 0x18e6c7f00 ; _objc_inform
0x18e6c8644 <+288>: movz w1, #0x1f4
0x18e6c8648 <+292>: add x0, sp, #32 ; =32
0x18e6c864c <+296>: bl 0x18eb7709c ; backtrace
0x18e6c8650 <+300>: mov x22, x0
0x18e6c8654 <+304>: adrp x8, 132269
0x18e6c8658 <+308>: ldr x8, [x8, #48]
0x18e6c865c <+312>: ldr x0, [x8]
0x18e6c8660 <+316>: bl 0x18eb7a548 ; fileno
0x18e6c8664 <+320>: mov x2, x0
0x18e6c8668 <+324>: add x0, sp, #32 ; =32
0x18e6c866c <+328>: mov x1, x22
0x18e6c8670 <+332>: bl 0x18eb86804 ; backtrace_symbols_fd
0x18e6c8674 <+336>: mov x0, x20
0x18e6c8678 <+340>: nop
0x18e6c867c <+344>: adrp x2, 0
0x18e6c8680 <+348>: add x2, x2, #1680 ; =1680
0x18e6c8684 <+352>: mov x0, x19
0x18e6c8688 <+356>: mov x1, x21
0x18e6c868c <+360>: bl 0x18e6e4764 ; symbol stub for: +[NSObject resolveInstanceMethod:]
EDIT:
OK I got lucky and found a notification that was not wrapped in a main thread call. Turns out it was a property changed from a background thread triggering a notification. Surprisingly difficult to find the UI Code that was being called. I must be doing something wrong.
Try implementing UI changes in main queue.
Swift 3:
OperationQueue.main.addOperation({
// Update UI
})
Did you add all exception break point? It can help.
You are right, it's due to UI modification from background. Can you add an exception breakpoint in xCode and try to determine, where is this call?
After that, you can place this call in
DispatchQueue.main.async { your call }
for swift, or gcd version for Objective C
I'll add a few steps to #mkeremkeskin's answer:
Step by step:
Go to the Breakpoint Navigator: Breakpoint Navigator
Add an Exception Breakpoint: Exception Breakpoint
Make it throw on All Exceptions
You should be able to track down the exception now.
You shouldn't do any changes related to UIKit objects in background thread. They should be done in main thread as stated by Apple in it's developer documentation.
Note
For the most part, use UIKit classes only from your app’s main thread. This is particularly true for classes derived from UIResponder or that involve manipulating your app’s user interface in any way.
If you're doing some operations in background thread and need to update UIKit elements. You can do it in the following way
dispatch_async(dispatch_get_main_queue(), ^{
});
[[NSOperationQueue mainQueue] addOperationWithBlock:^{
}];
In swift3,
DispatchQueue.main.async {
}
OperationQueue.main.addOperation {
}
For detecting where you're getting exception, you can do that using exception breakpoint. You can do that as shown in the pictures given below:
I use 2 SQLite databases: one is part of the bundle and stores static/read-only data (called Seed.sqlite), the other is created on first launch (or auto-migrated) and is used to save the user data (User.sqlite).
The persistent store managing the read-only database (Seed.sqlite) is setup with the following options:
options[NSReadOnlyPersistentStoreOption] = true
options[NSSQLitePragmasOption] = ["journal_mode": "DELETE"]
It works fine under iOS 9.x and under iOS 10 within the simulator, but it crashes when used on a device running iOS 10 (beta 4 and 8, at least).
I don't have any issue whatsoever with the User.sqlite database.
Up until now, the above configuration was making CoreData complying with the restrictions on a device (ie: bundle files can't be edited).
On iOS 10, it still seems like this is the case: when the above options are removed, temporary files are created (when ran in the simulator, since in that case the bundle is writable), and otherwise, the file is left untouched.
So it seems to behave as it did before, but it still crashes on the device.
Here's where the exception happens. There's a mention of "PFUbiquityTransactionHistoryCache writePendingEntries:". Trying to write something in the bundle might explain the crash, but I don't see why it would be called.
Calling po $arg1 from the exception returns "Can't create support directory (can't create directory)
(null)"
CoreData`developerSubmittedBlockToNSManagedObjectContextPerform:
0x189f45ad0 <+0>: stp x28, x27, [sp, #-96]!
0x189f45ad4 <+4>: stp x26, x25, [sp, #16]
0x189f45ad8 <+8>: stp x24, x23, [sp, #32]
0x189f45adc <+12>: stp x22, x21, [sp, #48]
0x189f45ae0 <+16>: stp x20, x19, [sp, #64]
0x189f45ae4 <+20>: stp x29, x30, [sp, #80]
0x189f45ae8 <+24>: add x29, sp, #80 ; =80
0x189f45aec <+28>: mov x20, x0
0x189f45af0 <+32>: ldp x21, x19, [x20]
0x189f45af4 <+36>: ldr x23, [x20, #16]
0x189f45af8 <+40>: tbz w23, #2, 0x189f45b08 ; <+56>
0x189f45afc <+44>: bl 0x186629c74 ; objc_autoreleasePoolPush
0x189f45b00 <+48>: mov x22, x0
0x189f45b04 <+52>: b 0x189f45b0c ; <+60>
0x189f45b08 <+56>: movz x22, #0
0x189f45b0c <+60>: tbz w23, #13, 0x189f45b14 ; <+68>
0x189f45b10 <+64>: dmb ish
0x189f45b14 <+68>: mrs x8, TPIDRRO_EL0
0x189f45b18 <+72>: and x26, x8, #0xfffffffffffffff8
0x189f45b1c <+76>: ldr x25, [x26, #712]
0x189f45b20 <+80>: ldr x24, [x20, #24]
0x189f45b24 <+84>: cmp x25, x19
0x189f45b28 <+88>: b.eq 0x189f45b3c ; <+108>
0x189f45b2c <+92>: cbz x24, 0x189f45b44 ; <+116>
0x189f45b30 <+96>: ldr x27, [x24, #8]
0x189f45b34 <+100>: str x19, [x24, #8]
0x189f45b38 <+104>: b 0x189f45b48 ; <+120>
0x189f45b3c <+108>: movz x27, #0
0x189f45b40 <+112>: b 0x189f45b4c ; <+124>
0x189f45b44 <+116>: movz x27, #0
0x189f45b48 <+120>: str x19, [x26, #712]
0x189f45b4c <+124>: adrp x8, 140081
0x189f45b50 <+128>: add x8, x8, #2616 ; =2616
0x189f45b54 <+132>: ldrb w8, [x8]
0x189f45b58 <+136>: cbnz w8, 0x189f45cb8 ; <+488>
0x189f45b5c <+140>: ldr x8, [x21, #16]
0x189f45b60 <+144>: mov x0, x21
0x189f45b64 <+148>: blr x8
0x189f45b68 <+152>: and x8, x23, #0x4
0x189f45b6c <+156>: tbnz w23, #12, 0x189f45b9c ; <+204>
0x189f45b70 <+160>: tbnz w23, #1, 0x189f45bf4 ; <+292>
0x189f45b74 <+164>: cbz x8, 0x189f45c24 ; <+340>
0x189f45b78 <+168>: cbz x22, 0x189f45b84 ; <+180>
0x189f45b7c <+172>: mov x0, x22
0x189f45b80 <+176>: bl 0x18a0a76ac ; symbol stub for: -[PFUbiquitySwitchboardCacheWrapper init]
0x189f45b84 <+180>: adrp x8, 134549
0x189f45b88 <+184>: ldr x1, [x8, #1568]
0x189f45b8c <+188>: movz w2, #0
0x189f45b90 <+192>: mov x0, x19
0x189f45b94 <+196>: bl 0x186622f20 ; objc_msgSend
0x189f45b98 <+200>: b 0x189f45c24 ; <+340>
0x189f45b9c <+204>: cmp x8, #0 ; =0
0x189f45ba0 <+208>: cset w8, eq
0x189f45ba4 <+212>: cbz x22, 0x189f45bb4 ; <+228>
0x189f45ba8 <+216>: tbnz w8, #0, 0x189f45bb4 ; <+228>
0x189f45bac <+220>: mov x0, x22
0x189f45bb0 <+224>: bl 0x18a0a76ac ; symbol stub for: -[PFUbiquitySwitchboardCacheWrapper init]
0x189f45bb4 <+228>: and x22, x23, #0x1000
0x189f45bb8 <+232>: tbz w23, #0, 0x189f45bcc ; <+252>
0x189f45bbc <+236>: mov x0, x21
0x189f45bc0 <+240>: bl 0x186ab6998 ; _Block_release
0x189f45bc4 <+244>: mov x0, x20
0x189f45bc8 <+248>: bl 0x18a0a71fc ; symbol stub for: -[PFUbiquityTransactionHistoryCache writePendingEntries:]
0x189f45bcc <+252>: movz w21, #0
0x189f45bd0 <+256>: cbz x22, 0x189f45c3c ; <+364>
0x189f45bd4 <+260>: cmp x25, x19
0x189f45bd8 <+264>: b.eq 0x189f45ca0 ; <+464>
0x189f45bdc <+268>: str x25, [x26, #712]
0x189f45be0 <+272>: cbz x24, 0x189f45c78 ; <+424>
0x189f45be4 <+276>: cmp x27, x19
0x189f45be8 <+280>: csel x8, xzr, x27, eq
0x189f45bec <+284>: str x8, [x24, #8]
0x189f45bf0 <+288>: b 0x189f45c78 ; <+424>
0x189f45bf4 <+292>: adrp x8, 134548
0x189f45bf8 <+296>: ldr x1, [x8, #3312]
0x189f45bfc <+300>: mov x0, x19
0x189f45c00 <+304>: bl 0x186622f20 ; objc_msgSend
0x189f45c04 <+308>: cbz x22, 0x189f45c10 ; <+320>
0x189f45c08 <+312>: mov x0, x22
0x189f45c0c <+316>: bl 0x18a0a76ac ; symbol stub for: -[PFUbiquitySwitchboardCacheWrapper init]
0x189f45c10 <+320>: adrp x8, 134549
0x189f45c14 <+324>: ldr x1, [x8, #1568]
0x189f45c18 <+328>: movz w2, #0
0x189f45c1c <+332>: mov x0, x19
0x189f45c20 <+336>: bl 0x186622f20 ; objc_msgSend
0x189f45c24 <+340>: tbnz w23, #0, 0x189f45c30 ; <+352>
0x189f45c28 <+344>: movz w21, #0
0x189f45c2c <+348>: b 0x189f45c3c ; <+364>
0x189f45c30 <+352>: mov x0, x21
0x189f45c34 <+356>: bl 0x186ab6998 ; _Block_release
0x189f45c38 <+360>: movz w21, #0
0x189f45c3c <+364>: cmp x25, x19
0x189f45c40 <+368>: b.eq 0x189f45c50 ; <+384>
0x189f45c44 <+372>: str x25, [x26, #712]
0x189f45c48 <+376>: cbz x24, 0x189f45c50 ; <+384>
0x189f45c4c <+380>: str x27, [x24, #8]
0x189f45c50 <+384>: tbnz w23, #0, 0x189f45c68 ; <+408>
0x189f45c54 <+388>: adrp x8, 134548
0x189f45c58 <+392>: ldr x1, [x8, #32]
0x189f45c5c <+396>: mov x0, x19
0x189f45c60 <+400>: bl 0x186622f20 ; objc_msgSend
0x189f45c64 <+404>: b 0x189f45c78 ; <+424>
0x189f45c68 <+408>: mov x0, x19
0x189f45c6c <+412>: bl 0x187aae3e8 ; CFRelease
0x189f45c70 <+416>: mov x0, x20
0x189f45c74 <+420>: bl 0x18a0a71fc ; symbol stub for: -[PFUbiquityTransactionHistoryCache writePendingEntries:]
0x189f45c78 <+424>: tbz w23, #13, 0x189f45c80 ; <+432>
0x189f45c7c <+428>: dmb ish
0x189f45c80 <+432>: cbnz w21, 0x189f45cdc ; <+524>
0x189f45c84 <+436>: ldp x29, x30, [sp, #80]
0x189f45c88 <+440>: ldp x20, x19, [sp, #64]
0x189f45c8c <+444>: ldp x22, x21, [sp, #48]
0x189f45c90 <+448>: ldp x24, x23, [sp, #32]
0x189f45c94 <+452>: ldp x26, x25, [sp, #16]
0x189f45c98 <+456>: ldp x28, x27, [sp], #96
0x189f45c9c <+460>: ret
0x189f45ca0 <+464>: str xzr, [x26, #712]
0x189f45ca4 <+468>: cbz x24, 0x189f45c78 ; <+424>
0x189f45ca8 <+472>: cmp x27, x25
0x189f45cac <+476>: b.ne 0x189f45c78 ; <+424>
0x189f45cb0 <+480>: str xzr, [x24, #8]
0x189f45cb4 <+484>: b 0x189f45c78 ; <+424>
0x189f45cb8 <+488>: adrp x8, 134550
0x189f45cbc <+492>: ldr x1, [x8, #2768]
0x189f45cc0 <+496>: mov x0, x19
0x189f45cc4 <+500>: bl 0x189f3ea64 ; _PFAssertSafeMultiThreadedAccess_impl
0x189f45cc8 <+504>: b 0x189f45b5c ; <+140>
0x189f45ccc <+508>: bl 0x186610720 ; objc_begin_catch
0x189f45cd0 <+512>: and x22, x23, #0x1000
0x189f45cd4 <+516>: orr w21, wzr, #0x1
0x189f45cd8 <+520>: b 0x189f45bd0 ; <+256>
0x189f45cdc <+524>: bl 0x1866106f0 ; objc_exception_rethrow
0x189f45ce0 <+528>: b 0x189f45c84 ; <+436>
0x189f45ce4 <+532>: mov x19, x0
0x189f45ce8 <+536>: b 0x189f45cf4 ; <+548>
0x189f45cec <+540>: mov x19, x0
0x189f45cf0 <+544>: tbz w21, #0, 0x189f45cf8 ; <+552>
0x189f45cf4 <+548>: bl 0x186610768 ; objc_end_catch
0x189f45cf8 <+552>: mov x0, x19
0x189f45cfc <+556>: bl 0x186ca4ed4 ; _Unwind_Resume
0x189f45d00 <+560>: bl 0x186610794 ; objc_terminate
And here's the device crash log:
0 CoreFoundation 0x187bd81c0 __exceptionPreprocess + 124
1 libobjc.A.dylib 0x18661055c objc_exception_throw + 56
2 CoreData 0x189f9ff14 -[NSSQLCore externalDataReferencesDirectory] + 992
3 CoreData 0x18a05ef44 -[NSSQLFetchRequestContext initWithRequest:context:sqlCore:] + 424
4 CoreData 0x189f9eba4 -[NSSQLCore processFetchRequest:inContext:] + 76
5 CoreData 0x189ea1510 -[NSSQLCore executeRequest:withContext:error:] + 504
6 CoreData 0x189f8183c __65-[NSPersistentStoreCoordinator executeRequest:withContext:error:]_block_invoke + 4512
7 CoreData 0x189f79f88 -[NSPersistentStoreCoordinator _routeHeavyweightBlock:] + 276
8 CoreData 0x189ea11c4 -[NSPersistentStoreCoordinator executeRequest:withContext:error:] + 408
9 CoreData 0x189e9fbec -[NSManagedObjectContext executeFetchRequest:error:] + 572
10 CoreData 0x189f50b88 -[NSManagedObjectContext(_NestedContextSupport) _parentObjectsForFetchRequest:inContext:error:] + 456
11 CoreData 0x189f51390 __82-[NSManagedObjectContext(_NestedContextSupport) executeRequest:withContext:error:]_block_invoke + 584
12 CoreData 0x189f53638 internalBlockToNSManagedObjectContextPerform + 92
13 libdispatch.dylib 0x186a611c0 _dispatch_client_callout + 16
14 libdispatch.dylib 0x186a6e860 _dispatch_barrier_sync_f_invoke + 84
15 CoreData 0x189f409a8 _perform + 232
16 CoreData 0x189f51080 -[NSManagedObjectContext(_NestedContextSupport) executeRequest:withContext:error:] + 188
17 CoreData 0x189e9fbec -[NSManagedObjectContext executeFetchRequest:error:] + 572
18 MagicalRecord 0x101b5b274 0x101b48000 + 78452
19 CoreData 0x189f45b68 developerSubmittedBlockToNSManagedObjectContextPerform + 152
20 CoreData 0x189f45a48 -[NSManagedObjectContext performBlockAndWait:] + 260
…
Edit
Re-creating the Seed database under iOS 10 doesn't solve the issue
Copying the file from the bundle into the app container (with NSFileManager) on first launch and then using that one solves the issue. But then it takes twice the space (database in the bundle + copy), it's the solution I managed to avoid up until now (at least it proves everything else works as expected)
The answer is no, you can still do that… BUT if you have a Binary Data attribute with Allows External Storage, then it will crash.
Because of that, a .Seed_SUPPORT folder with a _EXTERNAL_DATA subfolder is created, even if the models that allow external storage are not in the Seed configuration.
So to fix it:
create a .xxx_SUPPORT folder (replace xxx with the name of your sqlite file), next to your xxx.sqlite seed file
create a subfolder named _EXTERNAL_DATA inside
BONUS: create a .gitkeep file inside _EXTERNAL_DATA, so that git commits the folder
add that folder to XCode, make sure to add it with "Create folder references", not "Create Groups"
You'll probably need to see hidden files in the Finder, for that just run:
defaults write com.apple.finder AppleShowAllFiles YES
killall Finder
You can set it back to NO afterwards.