_swift_release_dealloc Crash

For crashes that are this deep in SwiftUI it’s normally hard to come up with any meaningful results. However, in this case your code is closer to the crash than normal. Consider this snippet:

Thread 0 name:   Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libswiftCore.dylib … _swift_release_dealloc + 32
1   libswiftCore.dylib … bool swift::RefCounts>::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 136
2   Dayforce           … objectdestroy.51Tm + 16
3   libswiftCore.dylib … _swift_release_dealloc + 56
4   libswiftCore.dylib … bool swift::RefCounts>::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 136
5   SwiftUI            … 0x18e4f3000 + 14414772

Frames 5 and 3 indicate that SwiftUI has released an object and that’s caused it to be deallocated. The interesting thing is frame 2, which is in your app. That symbol, objectdestroy.51Tm, looks like something compiler generated, with the .51Tm being a disambiguating suffix. Sadly, I wasn’t able to work out how to map this to a type in your program.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Any suggestion of how I can map it to a type, I have tried to play with sanitizer tools like zombies etc to see if I get the exact type/object of what causing the error but its still show a memory address. any suggestion of what we can try on our end. (In general I know the place where it happens but I cant tell what exactly cause the issue). I tried to recreate apple dump method (on view controller) and building a minimal tree of all the elements of course there are some internal iOS elements. After creating the tree its get released. The crash doesnt directly happens in my code but rather when view controller get dismissed by user. Any suggestion of how it can be debugged further?

Any suggestion of how I can map it to a type

No. After posting my reply yesterday I asked that very question internally, but haven’t yet got a reply )-:

Hmmm, thinking about this some more, a link map might help. That would at least tell you which object file this is coming from.

For more on that, see Using a Link Map to Track Down a Symbol’s Origin.

ps It’s hard to believe that a debugging technique that I first used in the very early ’80s is still useful today (-: It’s up with printing stuff and thinking in my top three list of ‘caveman’ debugging techniques that are still incredibly useful.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

not sure how that suppose to help even if create a link map that will be only for the SDK. the SDK is getting the input from the hosting app in that case its some swiftui object. How a link map of the SDK should help me in that case. I manage to catch the crash on Xcode while debugging why Xcode cant just translate that memory to an object? I mean I can understand why it cant do for the hosting app (the code already compiled and no debug info etc) BUT one of the frames has a deallocated swiftui object why we cant inspect that one? ()

How a link map of the SDK should help me in that case.

I suggested that in response to you question of “how I can map it to a type”.

I agree the understanding the type involved is likely to be a good first step in debugging this. I’m hoping that the link map can help you on that front.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"