I got this problem when I play a video using AVPlayer on Simulator since I updated my project to run in Xcode8.
Here are the logs:
sometime like this:
libBacktraceRecording.dylib`__gcd_queue_item_enqueue_hook_block_invoke:
0x10d165ea8 <+0>: pushq %rbp
0x10d165ea9 <+1>: movq %rsp, %rbp
-> 0x10d165eac <+4>: movq 0x20(%rsi), %rax
0x10d165eb0 <+8>: movq 0x20(%rdi), %rcx
0x10d165eb4 <+12>: cmpq 0x8(%rcx), %rax
0x10d165eb8 <+16>: sete %al
0x10d165ebb <+19>: popq %rbp
0x10d165ebc <+20>: retq
Has anyone got this problem? Seems like a block rise it.
Related
So my question is why is let _ = this faster then this != nil?
Example:
This is:
let this : Bool? = true //
let start = DispatchTime.now()
for _ in 0...100000000 {
guard this != nil else { continue }
}
let end = DispatchTime.now()
let nanoTime = end.uptimeNanoseconds - start.uptimeNanoseconds
let timeInterval = Double(nanoTime)
print("Time \(timeInterval)")
// Time 5426559135.0
// Time 5428084767.0
// Time 5327325459.0
Slower than:
let this : Bool? = true //
let start = DispatchTime.now()
for _ in 0...100000000 {
guard let _ = this else { continue }
}
let end = DispatchTime.now()
let nanoTime = end.uptimeNanoseconds - start.uptimeNanoseconds
let timeInterval = Double(nanoTime)
print("Time \(timeInterval)")
// Time 257045414.0
// Time 261933863.0
// Time 263465919.0
Following Jonathan's response I checked the actual disassembled instructions.
Here is the result:
For the code:
let this : Bool? = nil
this != nil
we get:
0x100001290 <+0>: pushq %rbp
0x100001291 <+1>: movq %rsp, %rbp
0x100001294 <+4>: subq $0x30, %rsp
0x100001298 <+8>: leaq 0x2c7259(%rip), %rdx ; type metadata for Swift.Bool
0x10000129f <+15>: leaq 0x2b66ca(%rip), %rcx ; protocol witness table for Swift.Bool : Swift.Equatable in Swift
0x1000012a6 <+22>: leaq -0x18(%rbp), %rax
0x1000012aa <+26>: leaq -0x8(%rbp), %r8
0x1000012ae <+30>: movb $0x2, 0x2f940b(%rip)
0x1000012b5 <+37>: movb 0x2f9404(%rip), %r9b ; test2.this : Swift.Optional<Swift.Bool>
0x1000012bc <+44>: movb %r9b, -0x8(%rbp)
0x1000012c0 <+48>: movb $0x2, -0x10(%rbp)
0x1000012c4 <+52>: movb -0x10(%rbp), %r9b
0x1000012c8 <+56>: movb %r9b, -0x18(%rbp)
0x1000012cc <+60>: movl %edi, -0x1c(%rbp)
0x1000012cf <+63>: movq %r8, %rdi
0x1000012d2 <+66>: movq %rsi, -0x28(%rbp)
0x1000012d6 <+70>: movq %rax, %rsi
0x1000012d9 <+73>: callq 0x10004df10 ; Swift.!= infix <A where A: Swift.Equatable> (Swift.Optional<A>, Swift.Optional<A>) -> Swift.Bool
0x1000012de <+78>: xorl %r10d, %r10d
0x1000012e1 <+81>: movb %al, -0x29(%rbp)
0x1000012e4 <+84>: movl %r10d, %eax
0x1000012e7 <+87>: addq $0x30, %rsp
0x1000012eb <+91>: popq %rbp
0x1000012ec <+92>: retq
and for:
let this : Bool? = nil
let _ = this
there is:
0x1000012d0 <+0>: pushq %rbp
0x1000012d1 <+1>: movq %rsp, %rbp
0x1000012d4 <+4>: xorl %eax, %eax
0x1000012d6 <+6>: movb $0x2, 0x2f93e3(%rip)
0x1000012dd <+13>: movl %edi, -0x4(%rbp)
0x1000012e0 <+16>: movq %rsi, -0x10(%rbp)
0x1000012e4 <+20>: popq %rbp
0x1000012e5 <+21>: retq
Also, thank you Code Different for pointing to the Optimisation level.
Changing the value from [-Onone] to [-O -whole-module-optimisation] will cause a change for the generated asm in the following way:
The
let this : Bool? = nil
let _ = this
has
0x100001490 <+0>: pushq %rbp
0x100001491 <+1>: movq %rsp, %rbp
0x100001494 <+4>: movb $0x2, 0x3d9595(%rip) ; gCRAnnotations + 63
0x10000149b <+11>: xorl %eax, %eax
0x10000149d <+13>: popq %rbp
0x10000149e <+14>: retq
and the
let this : Bool? = nil
this != nil
to
0x100001490 <+0>: pushq %rbp
0x100001491 <+1>: movq %rsp, %rbp
0x100001494 <+4>: movb $0x2, 0x3d9595(%rip) ; gCRAnnotations + 63
0x10000149b <+11>: xorl %eax, %eax
0x10000149d <+13>: popq %rbp
0x10000149e <+14>: retq
So the resulted instructions are actually the same and the time to execute them should be pretty close.
I would check out this post. They both result in the same underlying assembly instructions. My guess is that they both take such a small amount of time to compile that the time difference you're noticing could be due to other miscellaneous outliers affecting performance.
This seems like such a simple piece of code that keeps crashing on me. It's able to find the file and I see it in the logs, but it crashes every time at the webview.loadRequest request line:
let kHelpFile = "DB_Help_Doc"
webView.delegate = self
webView.scalesPageToFit = true
self.view.addSubview(webView)
Scripts.log("WebViewVC >> URL is \(kHelpFile)")
if let url = NSBundle.mainBundle().URLForResource(kHelpFile, withExtension: "pdf") {
Scripts.log("BUNDLE FOUND")
Scripts.log("URL = \(url)")
Scripts.log("PATH = \(url.path)")
req = NSURLRequest(URL: NSURL(fileURLWithPath: url.path!))
self.webView.loadRequest(req)
}
else {
Scripts.log("BUNDLE NOT FOUND")
}
This is the exception
libc++abi.dylib`__cxa_throw:
-> 0x10e077c6b <+0>: pushq %rbp
0x10e077c6c <+1>: movq %rsp, %rbp
0x10e077c6f <+4>: pushq %r15
0x10e077c71 <+6>: pushq %r14
0x10e077c73 <+8>: pushq %r12
0x10e077c75 <+10>: pushq %rbx
0x10e077c76 <+11>: movq %rdx, %r14
0x10e077c79 <+14>: movq %rsi, %r15
0x10e077c7c <+17>: movq %rdi, %rbx
0x10e077c7f <+20>: callq 0x10e07787d ; __cxa_get_globals
0x10e077c84 <+25>: movq %rax, %r12
0x10e077c87 <+28>: callq 0x10e078220 ; std::get_unexpected()
0x10e077c8c <+33>: movq %rax, -0x60(%rbx)
0x10e077c90 <+37>: callq 0x10e078258 ; std::get_terminate()
0x10e077c95 <+42>: movq %rax, -0x58(%rbx)
0x10e077c99 <+46>: movq %r15, -0x70(%rbx)
0x10e077c9d <+50>: movq %r14, -0x68(%rbx)
0x10e077ca1 <+54>: leaq -0x20(%rbx), %r14
0x10e077ca5 <+58>: movabsq $0x434c4e47432b2b00, %rax
0x10e077caf <+68>: movq %rax, -0x20(%rbx)
0x10e077cb3 <+72>: movq $0x1, -0x78(%rbx)
0x10e077cbb <+80>: incl 0x8(%r12)
0x10e077cc0 <+85>: leaq 0x1d(%rip), %rax ; __cxxabiv1::exception_cleanup_func(_Unwind_Reason_Code, _Unwind_Exception*)
0x10e077cc7 <+92>: movq %rax, -0x18(%rbx)
0x10e077ccb <+96>: movq %r14, %rdi
0x10e077cce <+99>: callq 0x10e07ab3c ; symbol stub for: _Unwind_RaiseException
0x10e077cd3 <+104>: movq %r14, %rdi
0x10e077cd6 <+107>: callq 0x10e077d08 ; __cxa_begin_catch
0x10e077cdb <+112>: movq -0x58(%rbx), %rdi
0x10e077cdf <+116>: callq 0x10e078266 ; std::__terminate(void (*)())
I want to create entity from dictionary using MR_ImportFromObject method.
It worked before I update Xcode 6 to 7.
But when I use Xcode7, ImportFromObject method is not working.
Every call that method, willImport Delegate method is not called and application is crashed.
But ImportFromArray method is working very well.
Here is error message. I think the points are "swift_bridgeNonVerbatimFromObjectiveC" and "value type is not bridged to Objective-C".
libswiftCore.dylib`swift_bridgeNonVerbatimFromObjectiveC:
0x1060d4d50 <+0>: pushq %rbp
0x1060d4d51 <+1>: movq %rsp, %rbp
0x1060d4d54 <+4>: pushq %r15
0x1060d4d56 <+6>: pushq %r14
0x1060d4d58 <+8>: pushq %r12
0x1060d4d5a <+10>: pushq %rbx
0x1060d4d5b <+11>: movq %rdx, %r14
0x1060d4d5e <+14>: movq %rsi, %rbx
0x1060d4d61 <+17>: movq %rdi, %r15
0x1060d4d64 <+20>: leaq 0x54a15(%rip), %rsi ; _TMpSs21_ObjectiveCBridgeable
0x1060d4d6b <+27>: movq %rbx, %rdi
0x1060d4d6e <+30>: callq 0x1060d4610 ; swift_conformsToProtocol
0x1060d4d73 <+35>: movq %rax, %r12
0x1060d4d76 <+38>: testq %r12, %r12
0x1060d4d79 <+41>: je 0x1060d4dc9 ; <+121>
0x1060d4d7b <+43>: movq %rbx, %rdi
0x1060d4d7e <+46>: movq %rbx, %rsi
0x1060d4d81 <+49>: callq *0x8(%r12)
0x1060d4d86 <+54>: testb %al, %al
0x1060d4d88 <+56>: je 0x1060d4e49 ; <+249>
0x1060d4d8e <+62>: movq %rbx, %rdi
0x1060d4d91 <+65>: movq %rbx, %rsi
0x1060d4d94 <+68>: callq *0x10(%r12)
0x1060d4d99 <+73>: movq %r15, %rdi
0x1060d4d9c <+76>: movq %rax, %rsi
0x1060d4d9f <+79>: callq 0x1060d2100 ; swift_dynamicCastUnknownClass
0x1060d4da4 <+84>: testq %rax, %rax
0x1060d4da7 <+87>: je 0x1060d4e49 ; <+249>
0x1060d4dad <+93>: movq 0x20(%r12), %r8
0x1060d4db2 <+98>: movq %rax, %rdi
0x1060d4db5 <+101>: movq %r14, %rsi
0x1060d4db8 <+104>: movq %rbx, %rdx
0x1060d4dbb <+107>: movq %rbx, %rcx
0x1060d4dbe <+110>: popq %rbx
0x1060d4dbf <+111>: popq %r12
0x1060d4dc1 <+113>: popq %r14
0x1060d4dc3 <+115>: popq %r15
0x1060d4dc5 <+117>: popq %rbp
0x1060d4dc6 <+118>: jmpq *%r8
0x1060d4dc9 <+121>: movq (%rbx), %rcx
0x1060d4dcc <+124>: xorl %eax, %eax
0x1060d4dce <+126>: cmpq $0x80, %rcx
0x1060d4dd5 <+133>: cmovbeq %rcx, %rax
0x1060d4dd9 <+137>: cmpq $0xf, %rax
0x1060d4ddd <+141>: jne 0x1060d4df1 ; <+161>
0x1060d4ddf <+143>: testl $0x80ffffff, 0x10(%rbx)
0x1060d4de6 <+150>: jne 0x1060d4e49 ; <+249>
0x1060d4de8 <+152>: leaq 0x54959(%rip), %r12 ; protocol witness table for Swift._BridgeableMetatype : Swift._ObjectiveCBridgeable in Swift
0x1060d4def <+159>: jmp 0x1060d4d7b ; <+43>
0x1060d4df1 <+161>: cmpq $0xd, %rax
0x1060d4df5 <+165>: jne 0x1060d4e49 ; <+249>
0x1060d4df7 <+167>: movq 0x8(%rbx), %rax
0x1060d4dfb <+171>: movq (%rax), %rcx
0x1060d4dfe <+174>: xorl %eax, %eax
0x1060d4e00 <+176>: cmpq $0x80, %rcx
0x1060d4e07 <+183>: cmovbeq %rcx, %rax
0x1060d4e0b <+187>: leaq 0x54936(%rip), %r12 ; protocol witness table for Swift._BridgeableMetatype : Swift._ObjectiveCBridgeable in Swift
0x1060d4e12 <+194>: cmpq $0x3f, %rax
0x1060d4e16 <+198>: jg 0x1060d4e33 ; <+227>
0x1060d4e18 <+200>: cmpq $0xf, %rax
0x1060d4e1c <+204>: ja 0x1060d4d7b ; <+43>
0x1060d4e22 <+210>: movl $0xb706, %ecx
0x1060d4e27 <+215>: btq %rax, %rcx
0x1060d4e2b <+219>: jae 0x1060d4d7b ; <+43>
0x1060d4e31 <+225>: jmp 0x1060d4e49 ; <+249>
0x1060d4e33 <+227>: leaq -0x40(%rax), %rcx
0x1060d4e37 <+231>: cmpq $0x2, %rcx
0x1060d4e3b <+235>: jb 0x1060d4e49 ; <+249>
0x1060d4e3d <+237>: cmpq $0x80, %rax
0x1060d4e43 <+243>: jne 0x1060d4d7b ; <+43>
0x1060d4e49 <+249>: leaq 0x4467e(%rip), %rax ; "value type is not bridged to Objective-C"
0x1060d4e50 <+256>: movq %rax, 0x86561(%rip) ; gCRAnnotations + 8
0x1060d4e57 <+263>: int3
-> 0x1060d4e58 <+264>: nopl (%rax,%rax)
I changed the MagicalRecord MR_importFromObject Library for now from
id value = [objectData MR_valueForAttribute:primaryAttribute];
if (primaryAttribute != nil)
{
managedObject = [self MR_findFirstByAttribute:[primaryAttribute name] withValue:value inContext:context];
}
to
if (primaryAttribute != nil)
{
id value = [objectData MR_valueForAttribute:primaryAttribute];
managedObject = [self MR_findFirstByAttribute:[primaryAttribute name] withValue:value inContext:context];
}
You can probably put this in a category or extension (swift) on NSManagedObject and use that until MagicalRecord fixes this. That's what I'll do. This fixed this crash for me.
Try disabling the swift compiler optimizations. We had a similar crash unrelated to magical record that was fixed by changing that setting.
dyld_sim`dyld_fatal_error:
0x103e63000 <+0>: int3
-> 0x103e63001 <+1>: nop
My app is compile & build successfully but it ends with above error.
There're no other messages (error logs).
I set breakpoints in AppDelegate's didFinishLaunghingWithOptions method and in main.m also. But it never stops there.
My app's first view is always visible and error is coming only after it.
I couldn't find anything regarding this error – how can I solve it? Any specific suggestions.
I also tried this,
change frameworks type from Required to Optional.
But nothing works !!
And yes, I'm using CocoaPods.
Update:
My question isn't matched with any other questions, as both having contradict in titles.
Error which I'm getting - dyld_sim`dyld_fatal_error
Error in duplicate (suggestion) question - dyld`dyld_fatal_error:
Update 2:
Update 3:
Crash log
dyld_sim`dyldbootstrap::rebaseDyld:
0x10f95c002 <+0>: pushq %rbp
0x10f95c003 <+1>: movq %rsp, %rbp
0x10f95c006 <+4>: pushq %r15
0x10f95c008 <+6>: pushq %r14
0x10f95c00a <+8>: pushq %r13
0x10f95c00c <+10>: pushq %r12
0x10f95c00e <+12>: pushq %rbx
0x10f95c00f <+13>: subq $0x18, %rsp
0x10f95c013 <+17>: movq %rsi, %rbx
0x10f95c016 <+20>: movq %rdi, %r14
0x10f95c019 <+23>: movl 0x10(%r14), %r13d
0x10f95c01d <+27>: addq $0x20, %r14
0x10f95c021 <+31>: xorl %eax, %eax
0x10f95c023 <+33>: movq %rax, -0x30(%rbp)
0x10f95c027 <+37>: xorl %eax, %eax
0x10f95c029 <+39>: movq %rax, -0x38(%rbp)
0x10f95c02d <+43>: xorl %r12d, %r12d
0x10f95c030 <+46>: xorl %r15d, %r15d
-> 0x10f95c033 <+49>: movl (%r14), %eax
0x10f95c036 <+52>: cmpl $0xb, %eax
0x10f95c039 <+55>: jne 0x10f95c043 ; <+65>
0x10f95c03b <+57>: movq %r14, %r12
0x10f95c03e <+60>: jmp 0x10f95c0cc ; <+202>
0x10f95c043 <+65>: cmpl $0x19, %eax
0x10f95c046 <+68>: jne 0x10f95c0cc ; <+202>
0x10f95c04c <+74>: leaq 0x8(%r14), %rdi
0x10f95c050 <+78>: leaq 0x192c0(%rip), %rsi ; "__LINKEDIT"
0x10f95c057 <+85>: callq 0x10f9751a2 ; strcmp
0x10f95c05c <+90>: testl %eax, %eax
0x10f95c05e <+92>: movq -0x30(%rbp), %rax
0x10f95c062 <+96>: cmoveq %r14, %rax
0x10f95c066 <+100>: movq %rax, -0x30(%rbp)
0x10f95c06a <+104>: leaq 0x48(%r14), %rax
0x10f95c06e <+108>: movl 0x40(%r14), %ecx
0x10f95c072 <+112>: leaq (%rcx,%rcx,4), %rcx
0x10f95c076 <+116>: shlq $0x4, %rcx
0x10f95c07a <+120>: leaq 0x48(%r14,%rcx), %rcx
0x10f95c07f <+125>: jmp 0x10f95c085 ; <+131>
0x10f95c081 <+127>: addq $0x50, %rax
0x10f95c085 <+131>: cmpq %rcx, %rax
0x10f95c088 <+134>: jae 0x10f95c0b3 ; <+177>
0x10f95c08a <+136>: movzbl 0x40(%rax), %edx
0x10f95c08e <+140>: cmpl $0x6, %edx
0x10f95c091 <+143>: jne 0x10f95c081 ; <+127>
0x10f95c093 <+145>: movq 0x28(%rax), %rdx
0x10f95c097 <+149>: shrq $0x3, %rdx
0x10f95c09b <+153>: testl %edx, %edx
0x10f95c09d <+155>: je 0x10f95c081 ; <+127>
0x10f95c09f <+157>: movq 0x20(%rax), %rsi
0x10f95c0a3 <+161>: addq %rbx, %rsi
0x10f95c0a6 <+164>: addq %rbx, (%rsi)
0x10f95c0a9 <+167>: addq $0x8, %rsi
0x10f95c0ad <+171>: decl %edx
0x10f95c0af <+173>: jne 0x10f95c0a6 ; <+164>
0x10f95c0b1 <+175>: jmp 0x10f95c081 ; <+127>
0x10f95c0b3 <+177>: cmpq $0x0, -0x38(%rbp)
0x10f95c0b8 <+182>: jne 0x10f95c0cc ; <+202>
0x10f95c0ba <+184>: testb $0x2, 0x3c(%r14)
0x10f95c0bf <+189>: movl $0x0, %eax
0x10f95c0c4 <+194>: cmovneq %r14, %rax
0x10f95c0c8 <+198>: movq %rax, -0x38(%rbp)
0x10f95c0cc <+202>: movl 0x4(%r14), %eax
0x10f95c0d0 <+206>: addq %rax, %r14
0x10f95c0d3 <+209>: incl %r15d
0x10f95c0d6 <+212>: cmpl %r13d, %r15d
0x10f95c0d9 <+215>: jne 0x10f95c033 ; <+49>
0x10f95c0df <+221>: movl 0x48(%r12), %esi
0x10f95c0e4 <+226>: movl 0x4c(%r12), %edx
0x10f95c0e9 <+231>: testq %rdx, %rdx
0x10f95c0ec <+234>: je 0x10f95c13d ; <+315>
0x10f95c0ee <+236>: movq -0x38(%rbp), %rax
0x10f95c0f2 <+240>: movq 0x18(%rax), %rax
0x10f95c0f6 <+244>: addq %rbx, %rax
0x10f95c0f9 <+247>: movq -0x30(%rbp), %rcx
0x10f95c0fd <+251>: movq %rcx, %rdi
0x10f95c100 <+254>: movq 0x18(%rdi), %rcx
0x10f95c104 <+258>: addq %rbx, %rcx
0x10f95c107 <+261>: addq %rsi, %rcx
0x10f95c10a <+264>: subq 0x28(%rdi), %rcx
0x10f95c10e <+268>: leaq (%rcx,%rdx,8), %rdx
0x10f95c112 <+272>: movl 0x4(%rcx), %esi
0x10f95c115 <+275>: movl %esi, %edi
0x10f95c117 <+277>: andl $0x6000000, %edi
0x10f95c11d <+283>: cmpl $0x6000000, %edi
0x10f95c123 <+289>: jne 0x10f95c14c ; <+330>
0x10f95c125 <+291>: cmpl $0x10000000, %esi
0x10f95c12b <+297>: jae 0x10f95c15f ; <+349>
0x10f95c12d <+299>: movslq (%rcx), %rsi
0x10f95c130 <+302>: addq %rbx, (%rax,%rsi)
0x10f95c134 <+306>: addq $0x8, %rcx
0x10f95c138 <+310>: cmpq %rdx, %rcx
0x10f95c13b <+313>: jb 0x10f95c112 ; <+272>
0x10f95c13d <+315>: addq $0x18, %rsp
0x10f95c141 <+319>: popq %rbx
0x10f95c142 <+320>: popq %r12
0x10f95c144 <+322>: popq %r13
0x10f95c146 <+324>: popq %r14
0x10f95c148 <+326>: popq %r15
0x10f95c14a <+328>: popq %rbp
0x10f95c14b <+329>: retq
0x10f95c14c <+330>: movl $0x8, %edi
0x10f95c151 <+335>: callq 0x10f9710ea ; __cxa_allocate_exception
0x10f95c156 <+340>: leaq 0x191c5(%rip), %rcx ; "relocation in dyld has wrong size"
0x10f95c15d <+347>: jmp 0x10f95c170 ; <+366>
0x10f95c15f <+349>: movl $0x8, %edi
0x10f95c164 <+354>: callq 0x10f9710ea ; __cxa_allocate_exception
0x10f95c169 <+359>: leaq 0x191d4(%rip), %rcx ; "relocation in dyld has wrong type"
0x10f95c170 <+366>: movq %rcx, (%rax)
0x10f95c173 <+369>: leaq 0x24c56(%rip), %rcx ; typeinfo for char const*
0x10f95c17a <+376>: xorl %edx, %edx
0x10f95c17c <+378>: movq %rax, %rdi
0x10f95c17f <+381>: movq %rcx, %rsi
0x10f95c182 <+384>: callq 0x10f971354 ; __cxa_throw
I had this issue after deleting a bunch of things to try and fix another issue. I was able to fix it by reverting the following:
In Project>Build Settings>Runpath Search Paths, add the following (using the + icon, values are comma separated):
$(inherited), #executable_path/Frameworks, #loader_path/Frameworks
Unfortunately, SO text editor made me write it in a code block.
I am developing an app and I'm almost done! However I've run into an issue where when I build my application, iOS simulator immediately crashes and Xcode gives me this:
libswiftCore.dylib`swift_dynamicCastObjCClassUnconditional:
0x1032c0620: pushq %rbp
0x1032c0621: movq %rsp, %rbp
0x1032c0624: pushq %rbx
0x1032c0625: pushq %rax
0x1032c0626: movq %rsi, %rcx
0x1032c0629: movq %rdi, %rbx
0x1032c062c: xorl %eax, %eax
0x1032c062e: testq %rbx, %rbx
0x1032c0631: je 0x1032c064c ; swift_dynamicCastObjCClassUnconditional + 44
0x1032c0633: movq 0x82756(%rip), %rsi ; "isKindOfClass:"
0x1032c063a: movq %rbx, %rdi
0x1032c063d: movq %rcx, %rdx
0x1032c0640: callq 0x1032c31ca ; symbol stub for: objc_msgSend
0x1032c0645: testb %al, %al
0x1032c0647: movq %rbx, %rax
0x1032c064a: je 0x1032c0653 ; swift_dynamicCastObjCClassUnconditional + 51
0x1032c064c: addq $0x8, %rsp
0x1032c0650: popq %rbx
0x1032c0651: popq %rbp
0x1032c0652: retq
0x1032c0653: leaq 0xcdc8(%rip), %rax ; "Swift dynamic cast failed"
0x1032c065a: movq %rax, 0x8ae57(%rip) ; gCRAnnotations + 8
0x1032c0661: int3
0x1032c0662: nopw %cs:(%rax,%rax)
highlighting the last line telling me EXC_BREAKPOINT(code=EXC_i386_BPT, subcode=0x0) error with no description before it gave me the exact same issue but it told me that 'localizable string has failed to load' referring to the storyboard. Although now it doesn't tell me anything only (lldb). I was wondering if this could have something to do with the storyboard as well. Please help
I found out what my issue was! It turns out that I changed one of the classes of one of my view objects inside my scenes (I hope I worded it well enough).