Removing SCNNode nodes from scene.rootNode is causing a crash, in SceneKit - ios

I am trying to remove set of nodes from my scene which represent a path. They are a combination of SCNSphere geometry nodes, and custom geometry representing lines, created using SCNGeometrySource and SCNGeometryElement.
I am not retaining these nodes in any kind of array. Instead, I search the first level of the node tree of the rootNode in the scene for these nodes, by their name, and the subsequent call an action sequence that makes them fade out, and they should remove themselves from the root node.
The code is as follows:
func clearPath() {
//
let disappear = SCNAction.fadeOut(duration: 0.1)
let remove = SCNAction.removeFromParentNode()
let sequence = SCNAction.sequence([disappear, remove])
if let pathNodesToRemove = pathNodes() {
//
for node in pathNodesToRemove {
//
node.removeAllActions()
node.runAction(sequence)
}
}
if let lineNodesToRemove = lineNodes() {
for node in lineNodesToRemove {
//
node.removeAllActions()
node.runAction(sequence)
}
}
path.removeAll()
}
where:
func pathNodes() -> [SCNNode]? {
//
...
let nodes = rootNode.childNodes.filter { (node) -> Bool in
//
guard let name = node.name else { return false }
if name.hasPrefix(configurationComponent.id) &&
name.range(of:"_PATH") != nil {
return true
} else {
return false
}
}
return nodes
}
The lineNodes() function is basically the same.
I switched on Zombie Objects to trace where the error is coming from, and I always get the same error: a reference to SceneKit`C3DNodeRemoveFromParentNode as the last thing to call on the thread, and a EXC_BAD_ACCESS (code=1, address... ).
The clearPath() function is the only place in the entire app that I am calling 'RemoveFromParentNode'.
The nodes don't have physics bodies on them and are not being retained anywhere elsewhere.
Any thoughts as to how to resolve this?
EDIT 28/4/18:
Here is a crash report of the thread where it occurs. It would appear that removeObjectFromChildNodesAtIndex is being called twice...
Thread 9 name: Dispatch queue: com.apple.scenekit.renderingQueue.Air_Relay.ARTCSCNView0x104126720
Thread 9 Crashed:
0 SceneKit 0x00000001957d668c C3DNodeRemoveFromParentNode + 40
1 SceneKit 0x0000000195826e28 -[SCNNode __removeObjectFromChildNodesAtIndex:] + 184
2 SceneKit 0x0000000195826e28 -[SCNNode __removeObjectFromChildNodesAtIndex:] + 184
3 SceneKit 0x0000000195827350 -[SCNNode removeFromParentNode] + 396
4 SceneKit 0x000000019593e9fc -[SCNActionRemove updateWithTarget:forTime:] + 92
5 SceneKit 0x0000000195907cb8 SCNCActionSequence::cpp_updateWithTargetForTime+ 2202808 (SCNNode*, double) + 316
6 SceneKit 0x00000001957bcfb0 SCNActionApply + 112
7 SceneKit 0x0000000195853d2c _applyActions + 236
8 CoreFoundation 0x00000001814dccbc __CFDictionaryApplyFunction_block_invoke + 24
9 CoreFoundation 0x00000001814c3f98 CFBasicHashApply + 132
10 CoreFoundation 0x00000001814cdb64 CFDictionaryApplyFunction + 288
11 SceneKit 0x0000000195853b5c C3DAnimationManagerApplyActions + 92
12 SceneKit 0x000000019583b054 -[SCNRenderer _update:] + 656
13 SceneKit 0x000000019583d018 -[SCNRenderer _drawSceneWithNewRenderer:] + 252
14 SceneKit 0x000000019583d69c -[SCNRenderer _drawScene:] + 84
15 SceneKit 0x000000019583daa0 -[SCNRenderer _drawAtTime:] + 728
16 SceneKit 0x00000001958e446c -[SCNView _drawAtTime:] + 512
EDIT 30/04/18
I continued to add other features to the app, where I needed to remove nodes using SCNAction.removeFromParentNode(). I isolated those as well to cause the problem independently of the above code.
These are called more frequently on the SCNRendererDelegate update as each new nodes are generated.
I also tried to use removeFromParentNode() directly on the node using SCNAction.run block, and the same issue occurs.

When you use SCNAction.removeFromParentNode() you aren't removing the node, you have to remove the node it's self. If you remove the path or action you are essentially make a value nil so when the path or action is called there is now a nil value and it crashes.

Related

Invalid Mutability Exception when using background threads in KMM project on iOS

I am working on a KMM project and am currently developing a model layer. In order to work with data I was planning to create a singleton like so:
#ThreadLocal object Repository {
private var dao: DataAccessObject? = null
private val scope = CoroutineScope(Dispatchers.Main)
fun injectDao(dao: DataAccessObject) {
scope.async {
Repository.dao = dao
}
}
suspend fun create(dataObjectType: TypeOfDataObject): DataObject? {
var dataObject: DataObject? = null
val job = scope.async {
dataObject = dao?.create(dataObjectType = dataObjectType)
}
job.await()
return dataObject
}
}
In such implementation as you see the request to the database is handled in Main thread, which's quite not good. But it works and the data is returned from the function correctly. The next obvious step is to try to run it in background scope. To make it we should just redeclare scope:
private val scope = CoroutineScope(Dispatchers.Default)
When we run the code and call create function from somewhere it falls with
Uncaught Kotlin exception: kotlin.native.concurrent.InvalidMutabilityException: mutation attempt of frozen kotlin.native.internal.Ref#5761ad88
2021-02-02 23:54:50.408645+0300 Plendy[28960:2893398] [] nw_protocol_get_quic_image_block_invoke dlopen libquic failed
at 0 Shared 0x000000010d51640f kfun:kotlin.Throwable#<init>(kotlin.String?){} + 95 (/Users/teamcity/buildAgent/work/f01984a9f5203417/runtime/src/main/kotlin/kotlin/Throwable.kt:23:37)
at 1 Shared 0x000000010d50f0bd kfun:kotlin.Exception#<init>(kotlin.String?){} + 93 (/Users/teamcity/buildAgent/work/f01984a9f5203417/runtime/src/main/kotlin/kotlin/Exceptions.kt:23:44)
at 2 Shared 0x000000010d50f32d kfun:kotlin.RuntimeException#<init>(kotlin.String?){} + 93 (/Users/teamcity/buildAgent/work/f01984a9f5203417/runtime/src/main/kotlin/kotlin/Exceptions.kt:34:44)
at 3 Shared 0x000000010d5448cd kfun:kotlin.native.concurrent.InvalidMutabilityException#<init>(kotlin.String){} + 93 (/Users/teamcity/buildAgent/work/f01984a9f5203417/runtime/src/main/kotlin/kotlin/native/concurrent/Freezing.kt:22:60)
at 4 Shared 0x000000010d5460af ThrowInvalidMutabilityException + 431 (/Users/teamcity/buildAgent/work/f01984a9f5203417/runtime/src/main/kotlin/kotlin/native/concurrent/Internal.kt:92:11)
at 5 Shared 0x000000010d6470b0 MutationCheck + 128
at 6 Shared 0x000000010d5640f8 kfun:kotlin.native.internal.Ref#<set-element>(1:0){} + 104 (/Users/teamcity/buildAgent/work/f01984a9f5203417/runtime/src/main/kotlin/kotlin/native/internal/Ref.kt:12:5)
at 7 Shared 0x000000010d4a1d5b kfun:com.plendy.PlendyCore.Model.KNPlendyData.$create$lambda-1COROUTINE$4.invokeSuspend#internal + 779 (/Users/petr/Documents/Projects/Plendy/Android/Plendy/PlendyCore/src/commonMain/kotlin/com/plendy/PlendyCore/Model/KNPlendyData.kt:23:13)
at 8 Shared 0x000000010d537958 kfun:kotlin.coroutines.native.internal.BaseContinuationImpl#resumeWith(kotlin.Result<kotlin.Any?>){} + 760 (/Users/teamcity/buildAgent/work/f01984a9f5203417/runtime/src/main/kotlin/kotlin/coroutines/ContinuationImpl.kt:30:39)
at 9 Shared 0x000000010d6d7a78 kfun:kotlinx.coroutines.DispatchedTask#run(){} + 2680 (/opt/buildAgent/work/44ec6e850d5c63f0/kotlinx-coroutines-core/common/src/internal/DispatchedTask.kt:106:71)
at 10 Shared 0x000000010d687fb8 kfun:kotlinx.coroutines.EventLoopImplBase#processNextEvent(){}kotlin.Long + 840 (/opt/buildAgent/work/44ec6e850d5c63f0/kotlinx-coroutines-core/common/src/EventLoop.common.kt:274:18)
at 11 Shared 0x000000010d6efbbb kfun:kotlinx.coroutines#runEventLoop(kotlinx.coroutines.EventLoop?;kotlin.Function0<kotlin.Boolean>){} + 843 (/opt/buildAgent/work/44ec6e850d5c63f0/kotlinx-coroutines-core/native/src/Builders.kt:80:40)
at 12 Shared 0x000000010d6f8d39 kfun:kotlinx.coroutines.WorkerCoroutineDispatcherImpl.start$lambda-0#internal + 409 (/opt/buildAgent/work/44ec6e850d5c63f0/kotlinx-coroutines-core/native/src/Workers.kt:49:17)
at 13 Shared 0x000000010d6f8f30 kfun:kotlinx.coroutines.WorkerCoroutineDispatcherImpl.$start$lambda-0$FUNCTION_REFERENCE$35.invoke#internal + 64 (/opt/buildAgent/work/44ec6e850d5c63f0/kotlinx-coroutines-core/native/src/Workers.kt:47:24)
at 14 Shared 0x000000010d6f8f90 kfun:kotlinx.coroutines.WorkerCoroutineDispatcherImpl.$start$lambda-0$FUNCTION_REFERENCE$35.$<bridge-UNN>invoke(){}#internal + 64 (/opt/buildAgent/work/44ec6e850d5c63f0/kotlinx-coroutines-core/native/src/Workers.kt:47:24)
at 15 Shared 0x000000010d545d59 WorkerLaunchpad + 185 (/Users/teamcity/buildAgent/work/f01984a9f5203417/runtime/src/main/kotlin/kotlin/native/concurrent/Internal.kt:69:54)
at 16 Shared 0x000000010d64ba4f _ZN6Worker19processQueueElementEb + 3135
at 17 Shared 0x000000010d64adf6 _ZN12_GLOBAL__N_113workerRoutineEPv + 54
at 18 libsystem_pthread.dylib 0x0000000110a86950 _pthread_start + 224
at 19 libsystem_pthread.dylib 0x0000000110a8247b thread_start + 15
What is strange that the data is written to the db, meaning that dao is called successfully, but data isn't returning from the function, because the exception occurs earlier. At this point I don't understand to what frozen object does the exception relates? What I've tried next is to remove job.await() line and it worked perfectly with no exceptions besides of cause having null in function's output.
So my question is: how to make code run in a background thread still having an ability to wait for its output?
You should include more of the exception info to help figure out what's happening, and you can use ensureNeverFrozen to help identify when something is being inadvertently frozen. However, in this case, I think I can figure it out.
In this case, capturing a reference to dataObject in your background lambda will freeze it. Trying to reassign it is (probably) throwing your exception.
var dataObject: DataObject? = null
val job = scope.async {
//Trying to assign the frozen dataObject will fail
dataObject = dao?.create(dataObjectType = dataObjectType)
}
Since you're already in a suspend function, why not just use something like withContext?
suspend fun create(dataObjectType: TypeOfDataObject): DataObject? {
val dataObject = withContext(Dispatchers.Default) {
dao?.create(dataObjectType = dataObjectType)
}
return dataObject
}
And if you're going that far ...
suspend fun create(dataObjectType: TypeOfDataObject): DataObject? = withContext(Dispatchers.Default) {
dao?.create(dataObjectType = dataObjectType)
}

AudioKit crash: required condition is false: !destNodeMixerConns.empty() && !isDestNodeConnectedToIONode

We are experiencing an exception in our project:
2019-08-08 10:18:28.703708-0600 AppName[99385:5069475] *** Terminating app due to uncaught exception 'com.apple.coreaudio.avfaudio', reason: 'required condition is false: !destNodeMixerConns.empty() && !isDestNodeConnectedToIONode'
*** First throw call stack:
(
0 CoreFoundation 0x000000010ee2e8db __exceptionPreprocess + 331
1 libobjc.A.dylib 0x000000010e21bac5 objc_exception_throw + 48
2 CoreFoundation 0x000000010ee2e662 +[NSException raise:format:arguments:] + 98
3 AVFAudio 0x0000000111b94dbc _Z19AVAE_RaiseExceptionP8NSStringz + 156
4 AVFAudio 0x0000000111bf3937 _Z11_AVAE_CheckPKciS0_S0_b + 295
5 AVFAudio 0x0000000111b8cb8f _ZN18AVAudioEngineGraph8_ConnectEP19AVAudioNodeImplBaseS1_jjP13AVAudioFormat + 1031
6 AVFAudio 0x0000000111bfb598 _ZN17AVAudioEngineImpl7ConnectEP11AVAudioNodeS1_mmP13AVAudioFormat + 194
7 AVFAudio 0x0000000111bfb5ff -[AVAudioEngine connect:to:format:] + 83
8 AppName 0x000000010a424c10 $s8AudioKitAAC6outputAA6AKNodeCSgvWZTf4dd_n + 2576
9 AppName 0x000000010a4230fd $s8AudioKitAAC6outputAA6AKNodeCSgvsZ + 93
10 AppName 0x000000010a2ba3a3 $s6AppName7MaestroC17setUpTrackPlayers7fileURLy10Foundation0H0V_tF + 1235
Examining the common gotchas video I see a similar exception being thrown, required condition is false: !nodeMixerConns.empty() && !hasDirectConnToIONode, which is caused by allowing the variables to go out of scope rather than be retained in the class.
So this occurs when we create an AKPlayer, which is retained in a class, then we create an AKTimePitch with this player which is also retained in that class, and finally assign that to AudioKit.output which triggers the exception. After that we were storing the class that holds onto the player and time pitch in an array, so I tried to move this up after it's created in hopes that was the issue, but I see the same exception.
Interestingly, this code works fine initially when we load up the first song but crashes when we hit the next button to load up the next song.
final class Maestro : NSObject {
static let shared = Maestro()
var audioPlayers = [TrackPlayer]()
func setUpTrackPlayers(fileURL: URL) {
let playerOne = TrackPlayer(url: fileURL)
audioPlayers.append(playerOne)
AudioKit.output = playerOne.handleMixerChain() //boom
do {
try AudioKit.start()
} catch {
print("Maestro AudioKit.start error: \(error)")
}
}
func next() {
for player in audioPlayers {
player.stop()
}
audioPlayers.removeAll()
setUpTrackPlayers(fileURL: newSong.getFileUrl())
}
}
final class TrackPlayer {
let player : AKPlayer
lazy var timePitch = AKTimePitch()
init(url: URL) {
player = AKPlayer(url: url)!
}
func handleMixerChain(pitch: Double = 0.0, tempo: Double = 1.0) -> AKTimePitch {
timePitch = AKTimePitch(player)
timePitch.pitch = pitch
timePitch.rate = tempo
return timePitch
}
}
Any ideas? If you need any more info let me know. May be good to note we are updating from AudioKit 4.5.5 where we didn't experience this crash.
I've opened the project and it seems like you're being a bit too relaxed about your set up / tear down of the signal chain. You're setting up AudioKit's output using local variables, never tearing down this signal chain, and then coming back resetting the AudioKit output and telling AudioKit to start without ever calling AudioKit.stop().

xcode: Thread 1: Signal SIGABART in class AppDelegate: UIResponder, UIApplicationDelegate (game application)

Before marking as duplicate, please consider that I have searched the web and StackOverflow but I didn't find any solution for this specific problem (because all questions about this error are for apps, not games).
I am making a very basic Space Shooter game and I reached a stage where I want to make the hero (code below) shoot bullets; I created a function spawn_bullet to do this. After I wrote this function and called it in the function:
override func update(currentTime: CFTimeInterval),
I get the error: Thread 1: signal SIGABRT. Image is shown below
I believe that the error has something to do with the execution of the spawn_bullet function but I am not sure where it is, why it caused and how to fix it. Anyone has an idea to fix it and if possible to provide enough details for why it causes?
Thank you!
NOTE
English is not my first language (that's why it's bad)
Below I provide my code used in GameScene.swift:
import SpriteKit
class GameScene: SKScene {
var hero = SKSpriteNode(imageNamed: "hero")
var bullet = SKSpriteNode(imageNamed: "bullet")
var enemy = SKSpriteNode(imageNamed: "enemy")
var init_bullet_position = CGFloat(0)
var bullet_velocityY = CGFloat(5)
override func didMoveToView(view: SKView) {
/* Setup your scene here */
self.backgroundColor = UIColor(red: 0.7, green: 0.7, blue: 0.8, alpha: 1)
self.hero.anchorPoint = CGPointMake(0.5, 0)
self.hero.size.height = 50
self.hero.size.width = 30
self.hero.position = CGPointMake(CGRectGetMidX(self.frame), CGRectGetMinX(self.frame) + self.hero.size.height)
self.bullet.anchorPoint = CGPointMake(0.5, 0)
self.bullet.size.height = 30
self.bullet.size.width = 15
self.bullet.position = CGPointMake(CGRectGetMidX(self.frame), CGRectGetMinX(self.frame) + self.hero.size.height + self.hero.size.height / 4)
self.init_bullet_position = CGFloat(CGRectGetMinX(self.frame) + self.hero.size.height + self.hero.size.height / 4)
self.hero.zPosition = 1; //1 = front
self.addChild(bullet)
self.addChild(hero)
}
override func touchesBegan(touches: Set<UITouch>, withEvent event: UIEvent?) {
/* Called when a touch begins */
for touch: AnyObject in touches {
let location = touch.locationInNode!(self)
hero.position.x = location.x
if self.bullet.position.y == init_bullet_position{
self.bullet.position.x = location.x
}
}
}
override func touchesMoved(touches: Set<UITouch>, withEvent event: UIEvent?) {
/* Called when a touch begins */
for touch: AnyObject in touches {
let location = touch.locationInNode!(self)
self.hero.position.x = location.x
if self.bullet.position.y == init_bullet_position{
self.bullet.position.x = location.x
}
}
}
func spawn_bullets(){
self.bullet.anchorPoint = CGPointMake(0.5, 0)
self.bullet.size.height = 30
self.bullet.size.width = 15
self.bullet.position = CGPointMake(CGRectGetMidX(self.frame), CGRectGetMinX(self.frame) + self.hero.size.height + self.hero.size.height / 4)
self.addChild(bullet)
if self.bullet.position.y < self.frame.size.height{
self.bullet.position.y += self.bullet_velocityY
}
}
override func update(currentTime: CFTimeInterval) {
/* Called before each frame is rendered */
spawn_bullets()
}
}
Here is the exception message:
2016-07-14 23:07:54.564 Space shooter[14391:191912] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Attemped to add a SKNode which already has a parent: <SKSpriteNode> name:'(null)' texture:[<SKTexture> 'bullet' (400 x 600)] position:{160, 62.5} scale:{1.00, 1.00} size:{15, 30} anchor:{0.5, 0} rotation:0.00'
*** First throw call stack:
(
0 CoreFoundation 0x000000010ec4fd85 __exceptionPreprocess + 165
1 libobjc.A.dylib 0x0000000111299deb objc_exception_throw + 48
2 CoreFoundation 0x000000010ec4fcbd +[NSException raise:format:] + 205
3 SpriteKit 0x000000010fb74903 -[SKNode insertChild:atIndex:] + 162
4 SpriteKit 0x000000010fb74840 -[SKNode addChild:] + 68
5 Space shooter 0x000000010ea62d23 _TFC13Space_shooter9GameScene13spawn_bulletsfT_T_ + 995
6 Space shooter 0x000000010ea62ef4 _TFC13Space_shooter9GameScene6updatefSdT_ + 36
7 Space shooter 0x000000010ea62f2c _TToFC13Space_shooter9GameScene6updatefSdT_ + 44
8 SpriteKit 0x000000010fb48072 -[SKScene _update:] + 312
9 SpriteKit 0x000000010fb6503a -[SKView _update:] + 932
10 SpriteKit 0x000000010fb6221a __59-[SKView _renderSynchronouslyForTime:preRender:postRender:]_block_invoke + 170
11 SpriteKit 0x000000010fb620e8 -[SKView _renderSynchronouslyForTime:preRender:postRender:] + 235
12 SpriteKit 0x000000010fb64ac2 -[SKView layoutSubviews] + 85
13 UIKit 0x000000010fdd8980 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 703
14 QuartzCore 0x00000001151d7c00 -[CALayer layoutSublayers] + 146
15 QuartzCore 0x00000001151cc08e _ZN2CA5Layer16layout_if_neededEPNS_11TransactionE + 366
16 QuartzCore 0x00000001151cbf0c _ZN2CA5Layer28layout_and_display_if_neededEPNS_11TransactionE + 24
17 QuartzCore 0x00000001151c03c9 _ZN2CA7Context18commit_transactionEPNS_11TransactionE + 277
18 QuartzCore 0x00000001151ee086 _ZN2CA11Transaction6commitEv + 486
19 QuartzCore 0x00000001151ee7f8 _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv + 92
20 CoreFoundation 0x000000010eb74c37 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
21 CoreFoundation 0x000000010eb74ba7 __CFRunLoopDoObservers + 391
22 CoreFoundation 0x000000010eb6a11c CFRunLoopRunSpecific + 524
23 UIKit 0x000000010fd18f21 -[UIApplication _run] + 402
24 UIKit 0x000000010fd1df09 UIApplicationMain + 171
25 Space shooter 0x000000010ea64e82 main + 114
26 libdyld.dylib 0x0000000111dc792d start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
It occurs on this line:
self.addChild(bullet)
This is because bullet already has a parent.
To fix it, add this line before you add the child:
bullet.removeFromParent()
To answer the stated question:
Here's your error:
Attemped to add a SKNode which already has a parent
The problem is in your spawn_bullets() function. You're not actually instantiating new bullets in this function. You're just updating properties on self's instance of bullet, then trying to add it as a child of your scene. The second time this function is called, it crashes, because the bullet is already a child of the scene.
Instead, you should create new instances of your bullet node.
Regarding the underlying problem of creating unique bullets:
This is a whole separate topic in and of itself. I assume you only want to fire bullets at specific times, such as when you tap on something, so rather than spawning bullets from the update() function, which is called before each frame is rendered, I would call spawn_bullets() from a tap method, or other interaction. Secondly, you will want to create new instances of your bullet instead of updating a variable on your scene. These can be added, animated, and subsequently removed. Finally, take a look at the SKAction class for actually animating (and ultimately removing) the bullets. For example:
let newBullet = SKSpriteNode(imageNamed: "bullet")
newBullet.position = CGPoint(x: 10, y: 10)
self.addChild(newBullet)
let moveAction = SKAction.moveTo(CGPoint(x: 50, y: 10), duration: 0.4)
let removeAction = SKAction.removeFromParent()
newBullet.runAction(SKAction.sequence([moveAction, removeAction])) {
// Bullet is done and removed.
}
You can do a lot more with SKAction than is shown here. You can play audio files, follow paths, or even simply run a block.

UIStoryboardScene deallocates its controller unexpectedly without changing retain count

I am running unit tests against my view controllers. There are two view controllers in this suite, one of them has a segue to the other in the storyboard file.
In tests for both controllers, I create my test subject in same way: i get a storyboard with storyboardWithName:factory:bundle: (Typhoon for dependency injection uses the factory thing). Then, I use storyboard.instantiateViewControllerWithIdentifier: to get the VC.
In tests for my first view controller, all tests pass. Importantly, the view controller's deinit method is called ONLY when the vc itself goes out of scope in the test cases, or a new instance becomes the subject and the old one has its retain count reduced to 0.
however, in tests for the second VC, the tests fail in either of these cases (the VC goes out of scope or a new one becomes the subject) because for some reason there is a call being made to [UIStoryboardScene dealloc] which in turn calls deinit on the controller, even though its retain count should still be 1 (retained by the test case). ARC sends another release message to the VC when I set a new instance as the subject, and I get EXC_BAD_ACCESS (CODE=i386, GPFLT).
The [UIStoryboardScene dealloc] happens in a bunch of compiled code in XCTest framework (copied here), but I believe it's happening because the test case is ending, even though it shouldn't.
* thread #1: tid = 0x57cf91, 0x00000001089953a3 sbprod`Mode2ViewController.__deallocating_deinit(self=0x00007fd2bbdde5d0) + 19 at Mode2ViewController.swift:68, queue = 'com.apple.main-thread', stop reason = breakpoint 3.1
* frame #0: 0x00000001089953a3 sbprod`Mode2ViewController.__deallocating_deinit(self=0x00007fd2bbdde5d0) + 19 at Mode2ViewController.swift:68
frame #1: 0x0000000108995492 sbprod`#objc Mode2ViewController.__deallocating_deinit + 34 at Mode2ViewController.swift:0
frame #2: 0x000000010a1ff702 UIKit`-[UIStoryboardScene dealloc] + 36
frame #3: 0x000000010b04dafe libobjc.A.dylib`objc_object::sidetable_release(bool) + 232
frame #4: 0x000000010b04e0b8 libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 488
frame #5: 0x0000000115841f37 XCTest`__24-[XCTestCase invokeTest]_block_invoke_2 + 430
frame #6: 0x0000000115876613 XCTest`-[XCTestContext performInScope:] + 190
frame #7: 0x0000000115841d78 XCTest`-[XCTestCase invokeTest] + 169
frame #8: 0x00000001158423a2 XCTest`-[XCTestCase performTest:] + 459
frame #9: 0x000000011583fcf7 XCTest`-[XCTestSuite performTest:] + 396
frame #10: 0x000000011583fcf7 XCTest`-[XCTestSuite performTest:] + 396
frame #11: 0x000000011583fcf7 XCTest`-[XCTestSuite performTest:] + 396
frame #12: 0x000000011582cb10 XCTest`__25-[XCTestDriver _runSuite]_block_invoke + 51
frame #13: 0x000000011584db4c XCTest`-[XCTestObservationCenter _observeTestExecutionForBlock:] + 640
frame #14: 0x000000011582ca55 XCTest`-[XCTestDriver _runSuite] + 453
frame #15: 0x000000011582d7d1 XCTest`-[XCTestDriver _checkForTestManager] + 259
frame #16: 0x0000000115877a9a XCTest`_XCTestMain + 628
So:
Why is the UIStoryboardScene being created at all? I don't want a scene, just a VC, for my tests. It doesn't appear to happen in the previous test case. I think the only differences as far as the storyboard cares between the two VCs is that one of them has a segue into it, and the other out of it.
If the UIStoryboardScene is in fact existing in both cases, why is it deiniting my VC before it ought to?
My test cases are also not very different from one another in scope, however this test case passes some closures to places and I'm not 100% on how closures affect ARC.
EDIT: relevant code shown here.
In my test case, which is made using Quick:
override func spec() {
var subject: Mode2ViewController!
let presentDisplayString = "DesiredString"
describe("Mode2ViewController") {
describe("loading") {
describe("date and location") {
context("when location is available") {
beforeEach {
let system = MockSystemComponents.CreateWith(location: true, groups: nil)
let assembly = ApplicationAssembly().activateWithCollaboratingAssemblies([
system
])
//crash occurs on next line, before the 2nd test case, because the
//old subject has already been deallocated (by UIStoryboardScene)
//but reassigning this var, which had retains it, triggers a release
subject = assembly.mode2ViewController() as! Mode2ViewController
let _ = subject.view
}
it("records the location") {
expect(subject).notTo(beNil())
}
it("displays the location as a meaningful string") {
expect(subject.locationLabel.text).to(equal(presentDisplayString))
}
}
}
}
}
}
Note: the stack trace given above (first edit) is from a breakpoint I inserted in Mode2ViewController.deinit().
Turns out that the problem was that objective c treats things which begin with the keyword new differently with regards to their retain count. Typhoon can't handle methods that begin with new for this reason (see issue).
Solution: rename my typhoon method and the object being generated has the correct retain count.

Realm object has been deleted or invalidated

When I start my app, I perform an API call to see whether there's new data available. The data is stored in my local Realm database, and some of it is displayed in the initial table view controller.
Once the API call is finished, I check if some conditions are met that require me to delete a bunch of the previous data from the database and then create new objects. However, when I delete the old data, my app crashes with the following exception:
2015-08-06 11:56:32.057 MSUapp[19754:172864] *** Terminating app due to uncaught exception 'RLMException', reason: 'Object has been deleted or invalidated.'
*** First throw call stack:
(
0 CoreFoundation 0x000000010660cc65 __exceptionPreprocess + 165
1 libobjc.A.dylib 0x00000001083bdbb7 objc_exception_throw + 45
2 Realm 0x0000000105b78e95 _ZL17RLMVerifyAttachedP13RLMObjectBase + 85
3 Realm 0x0000000105b7878d _ZL10RLMGetLinkP13RLMObjectBasemP8NSString + 29
4 Realm 0x0000000105b7c23e ___ZL17RLMAccessorGetterP11RLMProperty15RLMAccessorCodeP8NSString_block_invoke_12 + 46
5 MSUapp 0x0000000105764867 _TFFC6MSUapp29FavoriteLeaguesViewController18generateLeagueListFS0_FT_T_U_FTCS_6LeagueS1__Sb + 39
6 MSUapp 0x00000001057648eb _TTRXFo_oC6MSUapp6LeagueoS0__dSb_XFo_iS0_iS0__dSb_ + 27
7 libswiftCore.dylib 0x0000000108674ae2 _TFSs14_insertionSortUSs21MutableCollectionType_USs13GeneratorType__Ss22BidirectionalIndexType_Ss18_SignedIntegerType_Ss33_BuiltinIntegerLiteralConvertible____FTRQ_GVSs5RangeQQ_5Index_RFTQQQ_9Generator7ElementS7__Sb_T_ + 1570
8 libswiftCore.dylib 0x0000000108676682 _TFSs14_introSortImplUSs21MutableCollectionType_USs13GeneratorType__Ss21RandomAccessIndexType_Ss18_SignedIntegerType_Ss33_BuiltinIntegerLiteralConvertible_Ss16SignedNumberType_S3_____FTRQ_GVSs5RangeQQ_5Index_RFTQQQ_9Generator7ElementS8__SbSi_T_ + 1250
9 libswiftCore.dylib 0x0000000108676172 _TFSs10_introSortUSs21MutableCollectionType_USs13GeneratorType__Ss21RandomAccessIndexType_Ss18_SignedIntegerType_Ss33_BuiltinIntegerLiteralConvertible_Ss16SignedNumberType_S3_____FTRQ_GVSs5RangeQQ_5Index_FTQQQ_9Generator7ElementS8__Sb_T_ + 1058
10 libswiftCore.dylib 0x00000001085ec947 _TFSs4sortUSs21MutableCollectionType_USs13GeneratorType__Ss21RandomAccessIndexType_Ss18_SignedIntegerType_Ss33_BuiltinIntegerLiteralConvertible_Ss16SignedNumberType_S3_____FTRQ_FTQQQ_9Generator7ElementS6__Sb_T_ + 471
11 libswiftCore.dylib 0x00000001086a8d9e _TPA__TFFSa4sortU__FRGSaQ__FFTQ_Q__SbT_U_FRGVSs26UnsafeMutableBufferPointerQ__T_ + 222
12 libswiftCore.dylib 0x00000001086a8e18 _TPA__TTRG0_R_XFo_lGVSs26UnsafeMutableBufferPointerq___dT__XFo_lGS_q___iT__42 + 56
13 libswiftCore.dylib 0x00000001085f7fda _TFSa30withUnsafeMutableBufferPointerU__fRGSaQ__U__FFRGVSs26UnsafeMutableBufferPointerQd___Q_Q_ + 522
14 libswiftCore.dylib 0x00000001085f7db4 _TFSa4sortU__fRGSaQ__FFTQ_Q__SbT_ + 132
15 MSUapp 0x0000000105761709 _TFC6MSUapp29FavoriteLeaguesViewController18generateLeagueListfS0_FT_T_ + 1097
16 MSUapp 0x000000010576354b _TFC6MSUapp29FavoriteLeaguesViewController27numberOfSectionsInTableViewfS0_FCSo11UITableViewSi + 59
17 MSUapp 0x00000001057635fa _TToFC6MSUapp29FavoriteLeaguesViewController27numberOfSectionsInTableViewfS0_FCSo11UITableViewSi + 58
18 UIKit 0x000000010737cac3 -[UITableViewRowData _updateNumSections] + 84
19 UIKit 0x000000010737d4b4 -[UITableViewRowData invalidateAllSections] + 69
20 UIKit 0x00000001071c873b -[UITableView _updateRowData] + 217
21 UIKit 0x00000001071de2b7 -[UITableView noteNumberOfRowsChanged] + 112
22 UIKit 0x00000001071dd9f5 -[UITableView reloadData] + 1355
23 MSUapp 0x00000001057647c6 _TFFC6MSUapp29FavoriteLeaguesViewController11viewDidLoadFS0_FT_T_U_FTO10RealmSwift12NotificationCS1_5Realm_T_ + 166
24 RealmSwift 0x0000000105f37210 _TFF10RealmSwift41rlmNotificationBlockFromNotificationBlockFFT12notificationOS_12Notification5realmCS_5Realm_T_bTSSCSo8RLMRealm_T_U_FTSSS2__T_ + 224
25 RealmSwift 0x0000000105f372af _TTRXFo_oSSoCSo8RLMRealm_dT__XFdCb_dCSo8NSStringdS__dT__ + 111
26 Realm 0x0000000105c0645a -[RLMRealm sendNotifications:] + 986
27 Realm 0x0000000105c068e6 -[RLMRealm commitWriteTransaction] + 262
28 Realm 0x0000000105c06a48 -[RLMRealm transactionWithBlock:] + 120
29 RealmSwift 0x0000000105f34250 _TFC10RealmSwift5Realm5writefS0_FFT_T_T_ + 176
30 MSUapp 0x00000001056d46db _TZFC6MSUapp14DatabaseHelper23removeForSportAndSeasonfMS0_FTCS_5Sport6seasonSS_T_ + 603
31 MSUapp 0x0000000105710d22 _TFFFC6MSUapp11AppDelegate14loadRemoteDataFS0_FT_T_U_FGSaCS_5Sport_T_U_FGSaCS_6League_T_ + 866
32 MSUapp 0x0000000105710dc7 _TTRXFo_oGSaC6MSUapp6League__dT__XFo_iGSaS0___iT__ + 23
33 MSUapp 0x00000001057103d1 _TPA__TTRXFo_oGSaC6MSUapp6League__dT__XFo_iGSaS0___iT__ + 81
34 MSUapp 0x000000010575de90 _TTRXFo_iGSaC6MSUapp6League__iT__XFo_oGSaS0___dT__ + 32
35 MSUapp 0x000000010575ddeb _TFZFC6MSUapp9APIHelper11loadLeaguesFMS0_FTSi18shouldWriteToRealmSb10completionGSqFGSaCS_6League_T___T_U_FCSo6NSDataT_ + 2763
36 MSUapp 0x00000001056f4a0e _TTSf2n_n_n_n_n_d_i_n_n_n___TFFC6MSUapp14JSONDataSource18loadRemoteJsonDataFS0_FTSSCS_19GETParameterBuilderFCSo6NSDataT__T_U_FTCSo12NSURLRequestGSqCSo17NSHTTPURLResponse_GSqS2__GSqCSo7NSError__T_ + 2302
37 MSUapp 0x00000001056f2d59 _TPA__TTSf2n_n_n_n_n_d_i_n_n_n___TFFC6MSUapp14JSONDataSource18loadRemoteJsonDataFS0_FTSSCS_19GETParameterBuilderFCSo6NSDataT__T_U_FTCSo12NSURLRequestGSqCSo17NSHTTPURLResponse_GSqS2__GSqCSo7NSError__T_ + 249
38 Alamofire 0x00000001059e7599 _TTRXFo_oCSo12NSURLRequestoGSqCSo17NSHTTPURLResponse_oGSqCSo6NSData_oGSqCSo7NSError__dT__XFo_oS_oGSqS0__iGSqS1__oGSqS2___dT__ + 25
39 Alamofire 0x00000001059e7461 _TFFFC9Alamofire7Request8responseFDS0_US_18ResponseSerializer___FT5queueGSqCSo8NSObject_18responseSerializerQ_17completionHandlerFTCSo12NSURLRequestGSqCSo17NSHTTPURLResponse_GSqQ0__GSqCSo7NSError__T__DS0_U_FT_T_U_FT_T_ + 737
40 Alamofire 0x00000001059e690e _TPA__TFFFC9Alamofire7Request8responseFDS0_US_18ResponseSerializer___FT5queueGSqCSo8NSObject_18responseSerializerQ_17completionHandlerFTCSo12NSURLRequestGSqCSo17NSHTTPURLResponse_GSqQ0__GSqCSo7NSError__T__DS0_U_FT_T_U_FT_T_ + 206
41 Alamofire 0x00000001059a89d7 _TTRXFo__dT__XFdCb__dT__ + 39
42 libdispatch.dylib 0x000000010938b186 _dispatch_call_block_and_release + 12
43 libdispatch.dylib 0x00000001093aa614 _dispatch_client_callout + 8
44 libdispatch.dylib 0x0000000109392a1c _dispatch_main_queue_callback_4CF + 1664
45 CoreFoundation 0x00000001065741f9 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
46 CoreFoundation 0x0000000106535dcb __CFRunLoopRun + 2043
47 CoreFoundation 0x0000000106535366 CFRunLoopRunSpecific + 470
48 GraphicsServices 0x000000010cc17a3e GSEventRunModal + 161
49 UIKit 0x00000001070f08c0 UIApplicationMain + 1282
50 MSUapp 0x000000010570f857 main + 135
51 libdyld.dylib 0x00000001093df145 start + 1
52 ??? 0x0000000000000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
This call stack lets me assume, that it's because of my write access in FavoriteLeaguesViewController's generateLeagueList method. The following is its body:
var favorites = FavoritesHelper.sharedInstance.favoriteLeagues
favorites.sort { $0.sport < $1.sport }
for favorite in favorites {
// Add to array, which we can later use for cellForRowAtIndexPath
}
favorites is of the type [League], where League is a Realm Object. I'd assume the exception occurs because I'm accessing properties of the League objects, which have been deleted from the Realm database in the mean time (because the API call that has been started in the AppDelegate is now finished).
My question then is: How can I prevent this from happening? How can I make sure that there's no more writing/reading-access to any of the League objects prior to deleting them?
You can check if an object has been deleted from the Realm by calling object.invalidated -- if it returns true, then it has been deleted or the Realm has manually invalidated.
I got a really nice way to catch a RLMException within Swift.
Currently Swift doesn't show where a RLMException happened.
In Realm/RLMUtil.mm:266, there is the definition for RLMException.
If you change the code to generate a swift error,
Xcode now can show you where the exception occurred.
Now it is a part of Swift.
// Realm/RLMUtil.mm:266
static NSException *RLMException(NSString *reason, NSDictionary *additionalUserInfo) {
// add some code to generate a swift error. E.g. division-by-zero.
int a = 0;
if (reason == nil) {
a = 1;
}
NSLog(#"calculating 1 / %d = %f", a, 1 / a);
... remainder of the original code...
}
I've just place breakpoint inside method:
// Realm/RLMUtil.mm:193
static NSException *RLMException(NSString *reason, NSDictionary *additionalUserInfo) {
// ...
}
And on left panel you can check stack trace, here you can find where error throws.
The issue was in my FavoritesHelper class. It had both a favoriteLeagueIDs and favoriteLeagues property. I always set both of them and used the IDs for internal usage and the other property for whenever I want some data from these leagues.
This meant, that all favorite leagues were constantly referenced by the favoriteLeagues property (of the type [League]), thus crashing the app when I wanted to fetch them after they're invalidated.
What I've done to fix this, was to change the property favoriteLeagues to a computed property as follows:
var favoriteLeagues: [League] {
get {
var leagues = [League]()
for id in favoriteLeagueIDs {
if let league = realm.objectForPrimaryKey(League.self, key: id) {
leagues.append(league)
}
}
return leagues
}
}
Now the leagues are no longer referenced and just get loaded from the database when I need to read them. Invalidated or deleted objects don't get loaded because of the if let statement (the Realm.objectForPrimaryKey(:key:) method returns nil in such a case).
I was unable to place breakpoints within the Realm framework itself as others suggested, but instead placed an exception breakpoint on my entire project:
This allowed me to catch a proper stack trace when the exception was thrown, and find my bug.
you can calling isInvalidated or invalidated to judge the object is invalid (YES) or not (NO).
you can also write a a custom method to define what is real invalidate
look for the document ,we will see a property:
/**
Indicates if the object can no longer be accessed because it is now invalid.
An object can no longer be accessed if the object has been deleted from the Realm that manages it, or
if `invalidate` is called on that Realm.
*/
#property (nonatomic, readonly, getter = isInvalidated) BOOL invalidated;
the invalidated is readonly but what does isInvalidated mean?
it is equals to - (BOOL)invalidated { return invalidated; }
it means that you can write a a custom method to define what is real invalidate you want.
Try to create the element on realm instead of add
So:
try! realm.write {
realm.add(...)
}
Replace with:
try! realm.write {
realm.create(...)
}
And then after the delete operation realm should work as expected!
In my experience, if you trying to use target object (which you wanna delete) after delete, application will crash.
If you wanna trigger some code blocks after removing realm object, just trying to trigger that block right before the object removing in the memory. Trying to usage that object after removed from memory, will make some problem and will crash the app.
For example:
try! realm.write {
print("deleted word: \(targetObject.word)")
realm.delete(targetObject)
// targetObject was removed, so don't try to access it otherwise you gonna got the 'nil' value instead of object.
}
after spent a day, i figure out with the remove DispatchQueue.main.async in my realm.delete() function and finally it worked.
DispatchQueue.main.async {
realm.delete()
}
to
realm.delete()
In my case I was deleting data from 2 tables at once.. one with a foreign to the other.
let itemToDelete = counters[indexPath.row]
let realm = try! Realm()
try! realm.write {
realm.delete(itemToDelete)
let predicate = NSPredicate(format: "counterid = \(c.id)")
let children = realm.objects(Details.self).filter(predicate)
realm.delete(children)
}
But the problem was that I was trying to delete the children of the item that does not exist anymore. Switching the order, solved it!
let itemToDelete = counters[indexPath.row]
let realm = try! Realm()
try! realm.write {
let predicate = NSPredicate(format: "counterid = \(c.id)")
let children = realm.objects(Details.self).filter(predicate)
realm.delete(children)
realm.delete(itemToDelete) //this should be deleted after
}
Hope this helps someone else!
Here are some of the reasons based on my past experiences.
Overriding NSObject's isEqual(_ object: Any?), then returning identifier which was just deleted by Realm.
How did I fix it?
Check if object is invalidated if so return false otherwise proceed with using your identifier
Example:
extension YourModel {
override func isEqual(_ object: Any?) -> Bool {
guard let object = object as? YourModel,
!self.isInvalidated else {
return false
}
return object.id == self.id
}
}
Using Diffing tools
For those using diffing tools like RxDataSources, IGListKit etc.. you have to perform the same check as mentioned above before trying to access the indentifier.
Here is a work round if you are using RxDataSources that prevent the crash caused by adopting to IdentifiableType protocol.
Check if the Realm object was invalidated. If so, just return a random unique value, like so:
var identity: String {
return isInvalidated ? "deleted-object-\(UUID().uuidString)" : objectId
}
Source: - https://github.com/RxSwiftCommunity/RxDataSources/issues/172#issuecomment-427675816
What you can do is observe the Results<> object returned from your initial Realm query (the one used to populate your list/table view) and update that list in the observer callback method whenever there is a change in the database.
Just make sure that you use the same Realm instance to delete/modify the object as the one used for the initial query.
EDIT:
Some code examples:
let realm = Realm()
let results = realm.objects(Favourite.self)
let notificationToken = results.observe { [weak self] (changes) in
guard let tableView = self?.tableView else { return }
tableView.reloadData()
}
// Somewhere else
try? realm.write {
if let favourite = results.first {
realm.delete(favourite)
}
}
// OR
if let objectRealm = results.first?.realm {
try? objectRealm.write {
objectRealm.delete(results.first!)
}
}
// Don't forget to stop observing in deinit{}
// notificationToken.invalidate()
You can also use the #ObservedRealmObject or #ObservedResults property wrapper, you implicitly open a realm and retrieve the specified objects or results. You can then pass those objects to a view further down the hierarchy.
And use the .onDelete(perform: ) method. In example: .onDelete(perform: $dogs.remove) see below:
(SwiftUI)
struct DogsView: View {
#ObservedResults(Dog.self) var dogs
/// The button to be displayed on the top left.
var leadingBarButton: AnyView?
var body: some View {
NavigationView {
VStack {
// The list shows the dogs in the realm.
// The ``#ObservedResults`` above implicitly opens a realm and retrieves
// all the Dog objects. We can then pass those objects to views further down the
// hierarchy.
List {
ForEach(dogs) { dog in
DogRow(dog: dog)
}.onDelete(perform: $dogs.remove) **//<- Deletion of the Object**
}.listStyle(GroupedListStyle())
.navigationBarTitle("Dogs", displayMode: .large)
.navigationBarBackButtonHidden(true)
.navigationBarItems(
leading: self.leadingBarButton,
// Edit button on the right to enable rearranging items
trailing: EditButton())
}.padding()
}
}
}
Souce: MongoDB - CRUD Swift SDK

Resources