Crash : Outlined Destroy Of Object

I am getting a weird crash that I have not been able to figure out.


At the top of the crash log in Organizer I see:


#0(null) in 0 ()
#1(null) in outlined destroy of Event ()


where Event is my object.


Does anybody know what this means?


Thanks,


Girish

Accepted Reply

One thing I notiticed is that the crash occurs only on release builds.

That’s not uncommon with things like this. Earlier I wrote:

many of [these retains and releases] are optimised away by the compiler

Such optimisation doesn’t happen in the Debug build, and that can mask a variety of problems.

You wrote:

I was able to fix the issue by removing the intermediate variables (reminders, reminderOverride) and directly assigning to the googleEvent struct.

Shuffling code around like this shouldn’t affect the semantics of your program, so clearly you’re dealing with a bug. There’s two possibilities:

  • It’s a bug in your program.

  • It’s a bug in the compiler.

Ideally you’d want a diagnostic test that helps you tease these apart. There’s two ways you can approach this:

  • You could delve into the crash to see what’s actually triggering it. That means disassembling the

    outlined destroy of Event
    routine to work out what property is causing the problem, and then tracing the memory management of that object.
  • You can try to extract this code into a much simpler project. If you can reproduce the problem with a very simple project — one where you can be absolutely sure that all of your code is safe [1] — that suggests a compiler problem and you can file a bug report about that.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] I’m talking about safe in the Swift sense of the word, meaning:

  • Only Swift code — This means no calling out to Objective-C or any other C-based language.

  • No use of unsafe Swift constructs — These typically have

    unsafe
    or
    Unsafe
    in the name.
  • No threading — As things currently stand, Swift’s safety guarantees are very hard to check in the presence of multiple threads.

Replies

Can you explain the context ?


What actions are you doing on Event ?


Do you use 3rd party framework ?

This seems to be happening in viewDidLoad() for a view controller.

I believe the offending line of code is:


if let event = event {


Event is not from a third party framework, rather a struct defined by the app:


struct Event : Comparable {

.....

}


However, I am using the Google Firebase frameworks in the app.

To be sure it happens here, could you add a print before and just after this line ?


print("event before", event)
if let event = event {
     print("event after", event)

As Claude31 says, it’s hard to offer advice without more context. Can you post an Apple crash report of this failure? To get one you’ll need to run your app outside of Xcode and then trigger the issue.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Please see the crash log below.


I am getting reports of this crash from a user's device (who sees this crash consistently when performing the action to create a new event). I am not able to reproduce it either in simulator or on a device when go through the same steps as him.


What does "outlined destroy" mean?


Thanks

Date/Time: 2019-04-11 21:22:55.0953 -0700

Launch Time: 2019-04-11 21:21:45.1028 -0700

OS Version: iPhone OS 12.2 (16E227)

Baseband Version: 5.55.00

Report Version: 104

 

Exception Type: EXC_BAD_ACCESS (SIGBUS)

Exception Subtype: EXC_ARM_DA_ALIGN at 0x0000000000000001

VM Region Info: 0x1 is not in any region. Bytes before following region: 4338122751

  REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL

  UNUSED SPACE AT START

--->  

  __TEXT 0000000102928000-000000010292c000 [ 16K] r-x/r-x SM=COW ...pp/ReSchedule

 

Termination Signal: Bus error: 10

Termination Reason: Namespace SIGNAL, Code 0xa

Terminating Process: exc handler [514]

Triggered by Thread: 0

 

Thread 0 name:

Thread 0 Crashed:

0 ??? 0x0000000000000001 0 + 1

1 ReSchedule 0x0000000102938784 outlined destroy of Event + 544 (<compiler-generated>:0)

2 ReSchedule 0x00000001029a8e68 MeetingContainerViewController.viewDidLoad() + 2348 (MeetingContainerViewController.swift:127)

3 ReSchedule 0x00000001029a92b4 @objc MeetingContainerViewController.viewDidLoad() + 24 (<compiler-generated>:0)

4 UIKitCore 0x00000001df6678f8 0x1df356000 + 3217656

5 UIKitCore 0x00000001df667cfc 0x1df356000 + 3218684

6 UIKitCore 0x00000001df5e4d90 0x1df356000 + 2682256

7 UIKitCore 0x00000001df59b678 0x1df356000 + 2381432

8 UIKitCore 0x00000001df597ae8 0x1df356000 + 2366184

9 UIKitCore 0x00000001dfc1bfdc 0x1df356000 + 9199580

10 UIKitCore 0x00000001dfc0ab2c 0x1df356000 + 9128748

11 UIKitCore 0x00000001dfc37744 0x1df356000 + 9312068

12 CoreFoundation 0x00000001b3c4c89c 0x1b3ba3000 + 694428

13 CoreFoundation 0x00000001b3c475c4 0x1b3ba3000 + 673220

14 CoreFoundation 0x00000001b3c47b40 0x1b3ba3000 + 674624

15 CoreFoundation 0x00000001b3c47354 0x1b3ba3000 + 672596

16 GraphicsServices 0x00000001b5e4779c 0x1b5e3d000 + 42908

17 UIKitCore 0x00000001dfc10b68 0x1df356000 + 9153384

18 ReSchedule 0x00000001029311fc main + 68 (WeekViewLayout.swift:74)

19 libdyld.dylib 0x00000001b370d8e0 0x1b370c000 + 6368

 

Thread 1 name:

Thread 1:

0 libsystem_kernel.dylib 0x00000001b384e0f4 0x1b3836000 + 98548

1 libsystem_kernel.dylib 0x00000001b384d5a0 0x1b3836000 + 95648

2 CoreFoundation 0x00000001b3c4ccb4 0x1b3ba3000 + 695476

3 CoreFoundation 0x00000001b3c47bc4 0x1b3ba3000 + 674756

4 CoreFoundation 0x00000001b3c47354 0x1b3ba3000 + 672596

5 Foundation 0x00000001b4614fcc 0x1b460d000 + 32716

6 Foundation 0x00000001b4614e5c 0x1b460d000 + 32348

7 UIKitCore 0x00000001dfcf6540 0x1df356000 + 10093888

8 Foundation 0x00000001b47416e4 0x1b460d000 + 1263332

9 libsystem_pthread.dylib 0x00000001b38db2c0 0x1b38d0000 + 45760

10 libsystem_pthread.dylib 0x00000001b38db220 0x1b38d0000 + 45600

11 libsystem_pthread.dylib 0x00000001b38decdc 0x1b38d0000 + 60636

 

Thread 2:

0 libsystem_pthread.dylib 0x00000001b38decd0 0x1b38d0000 + 60624

 

Thread 3 name:

Thread 3:

0 libsystem_kernel.dylib 0x00000001b385afd8 0x1b3836000 + 151512

1 grpc 0x0000000103119564 pollset_work(grpc_pollset*, grpc_pollset_worker**, long long) + 1100 (ev_poll_posix.cc:986)

2 grpc 0x000000010311be0c pollset_work(grpc_pollset*, grpc_pollset_worker**, long long) + 104 (ev_posix.cc:264)

3 grpc 0x0000000103111070 cq_next(grpc_completion_queue*, gpr_timespec, void*) + 632 (completion_queue.cc:927)

4 GRPCClient 0x0000000102e42a08 __27-[GRPCCompletionQueue init]_block_invoke_2 + 156 (GRPCCompletionQueue.m:66)

5 libdispatch.dylib 0x00000001b36fba38 0x1b369c000 + 391736

6 libdispatch.dylib 0x00000001b36fc7d4 0x1b369c000 + 395220

7 libdispatch.dylib 0x00000001b36a0c7c 0x1b369c000 + 19580

8 libdispatch.dylib 0x00000001b36ad02c 0x1b369c000 + 69676

9 libdispatch.dylib 0x00000001b36ad8d0 0x1b369c000 + 71888

10 libsystem_pthread.dylib 0x00000001b38dc1b4 0x1b38d0000 + 49588

11 libsystem_pthread.dylib 0x00000001b38decd4 0x1b38d0000 + 60628

 

Thread 4 name:

Thread 4:

0 libsystem_kernel.dylib 0x00000001b384e0f4 0x1b3836000 + 98548

1 libsystem_kernel.dylib 0x00000001b384d5a0 0x1b3836000 + 95648

2 CoreFoundation 0x00000001b3c4ccb4 0x1b3ba3000 + 695476

3 CoreFoundation 0x00000001b3c47bc4 0x1b3ba3000 + 674756

4 CoreFoundation 0x00000001b3c47354 0x1b3ba3000 + 672596

5 CFNetwork 0x00000001b426074c 0x1b425f000 + 5964

6 Foundation 0x00000001b47416e4 0x1b460d000 + 1263332

7 libsystem_pthread.dylib 0x00000001b38db2c0 0x1b38d0000 + 45760

8 libsystem_pthread.dylib 0x00000001b38db220 0x1b38d0000 + 45600

9 libsystem_pthread.dylib 0x00000001b38decdc 0x1b38d0000 + 60636

 

Thread 5:

0 libsystem_kernel.dylib 0x00000001b3858ee4 0x1b3836000 + 143076

1 libsystem_pthread.dylib 0x00000001b38d3cf8 0x1b38d0000 + 15608

2 grpc 0x000000010316b368 gpr_cv_wait + 124 (sync_posix.cc:79)

3 grpc 0x000000010311ceb4 GrpcExecutor::ThreadMain(void*) + 212 (executor.cc:158)

4 grpc 0x0000000103171dc4 grpc_core::(anonymous namespace)::ThreadInternalsPosix::ThreadInternalsPosix(char const*, void (*... + 108 (thd_posix.cc:100)

5 libsystem_pthread.dylib 0x00000001b38db2c0 0x1b38d0000 + 45760

6 libsystem_pthread.dylib 0x00000001b38db220 0x1b38d0000 + 45600

7 libsystem_pthread.dylib 0x00000001b38decdc 0x1b38d0000 + 60636

 

Thread 6:

0 libsystem_kernel.dylib 0x00000001b3858ee4 0x1b3836000 + 143076

1 libsystem_pthread.dylib 0x00000001b38d3cf8 0x1b38d0000 + 15608

2 grpc 0x000000010316b358 gpr_cv_wait + 108 (sync_posix.cc:89)

3 grpc 0x0000000103174964 timer_thread(void*) + 384 (timer_manager.cc:186)

4 grpc 0x0000000103171dc4 grpc_core::(anonymous namespace)::ThreadInternalsPosix::ThreadInternalsPosix(char const*, void (*... + 108 (thd_posix.cc:100)

5 libsystem_pthread.dylib 0x00000001b38db2c0 0x1b38d0000 + 45760

6 libsystem_pthread.dylib 0x00000001b38db220 0x1b38d0000 + 45600

7 libsystem_pthread.dylib 0x00000001b38decdc 0x1b38d0000 + 60636

 

Thread 7:

0 libsystem_kernel.dylib 0x00000001b3858ee4 0x1b3836000 + 143076

1 libsystem_pthread.dylib 0x00000001b38d3cf8 0x1b38d0000 + 15608

2 grpc 0x000000010316b358 gpr_cv_wait + 108 (sync_posix.cc:89)

3 grpc 0x0000000103174964 timer_thread(void*) + 384 (timer_manager.cc:186)

4 grpc 0x0000000103171dc4 grpc_core::(anonymous namespace)::ThreadInternalsPosix::ThreadInternalsPosix(char const*, void (*... + 108 (thd_posix.cc:100)

5 libsystem_pthread.dylib 0x00000001b38db2c0 0x1b38d0000 + 45760

6 libsystem_pthread.dylib 0x00000001b38db220 0x1b38d0000 + 45600

7 libsystem_pthread.dylib 0x00000001b38decdc 0x1b38d0000 + 60636

 

Thread 8:

0 libsystem_kernel.dylib 0x00000001b3858ee4 0x1b3836000 + 143076

1 libsystem_pthread.dylib 0x00000001b38d3cf8 0x1b38d0000 + 15608

2 leveldb 0x000000010326ecd0 leveldb::(anonymous namespace)::PosixEnv::BGThread() + 92 (env_posix.cc:640)

3 leveldb 0x000000010326ec74 leveldb::(anonymous namespace)::PosixEnv::BGThreadWrapper(void*) + 12 (env_posix.cc:555)

4 libsystem_pthread.dylib 0x00000001b38db2c0 0x1b38d0000 + 45760

5 libsystem_pthread.dylib 0x00000001b38db220 0x1b38d0000 + 45600

6 libsystem_pthread.dylib 0x00000001b38decdc 0x1b38d0000 + 60636

 

Thread 9:

0 libsystem_pthread.dylib 0x00000001b38decd0 0x1b38d0000 + 60624

 

Thread 10:

0 libsystem_pthread.dylib 0x00000001b38decd0 0x1b38d0000 + 60624

 

Thread 0 crashed with ARM Thread State (64-bit):

  x0: 0x000000016d4d5ae8 x1: 0x00000001e0d59ed4 x2: 0x00000001ea112da8 x3: 0x0000000000000030

  x4: 0x000000007ffffffe x5: 0x000000010297dc1c x6: 0x00000002810c7070 x7: 0x00000000652018fe

  x8: 0x0000000000000001 x9: 0xfffffffe00000000 x10: 0x00000001ec711e40 x11: 0x00000001ec711e40

  x12: 0x0000000000000001 x13: 0x00000001ec711e40 x14: 0x0000000000000000 x15: 0x0000000000000010

  x16: 0x00000001e0d9e338 x17: 0x00000001b3bb7c8c x18: 0x0000000000000000 x19: 0x000000016d4d5540

  x20: 0x000000016d4d5ae8 x21: 0x0000000102dd3c88 x22: 0x000000016d4d5640 x23: 0x000000016d4d55d8

  x24: 0x000000016d4d55e8 x25: 0x00000001ea112da8 x26: 0x000000016d4d5550 x27: 0x00000001ea103128

  x28: 0x00000001ea103128 fp: 0x000000016d4d54d0 lr: 0x00000001e0d5ac68

  sp: 0x000000016d4d54c0 pc: 0x0000000000000001 cpsr: 0x60000000

 

Binary Images:

0x102928000 - 0x102d07fff ReSchedule arm64 <d2ef8dd498223346bdc77265cfaf0e78> /var/containers/Bundle/Application/8C0CB628-DD0E-4A55-B1A2-91F7971C378E/ReSchedule.app/ReSchedule

0x102e38000 - 0x102e4bfff GRPCClient arm64 <bbc6788b404f32aeaabeecdb16097b5b> /var/containers/Bundle/Application/8C0CB628-DD0E-4A55-B1A2-91F7971C378E/ReSchedule.app/Frameworks/GRPCClient.framework/GRPCClient

0x102e68000 - 0x102e7bfff GTMOAuth2 arm64 <6c4f34b016bd38bfba79542df5dee588> /var/containers/Bundle/Application/8C0CB628-DD0E-4A55-B1A2-91F7971C378E/ReSchedule.app/Frameworks/GTMOAuth2.framework/GTMOAuth2

0x102e90000 - 0x102ebbfff GTMSessionFetcher arm64 <47f18186ceff35ef8800beb1a7f3c538> /var/containers/Bundle/Application/8C0CB628-DD0E-4A55-B1A2-91F7971C378E/ReSchedule.app/Frameworks/GTMSessionFetcher.framework/GTMSessionFetcher

0x102ed4000 - 0x102efffff GoogleAPIClientForREST arm64 <72f81cd80f083ddd99cba2604286236b> /var/containers/Bundle/Application/8C0CB628-DD0E-4A55-B1A2-91F7971C378E/ReSchedule.app/Frameworks/GoogleAPIClientForREST.framework/GoogleAPIClientForREST

0x102f24000 - 0x102f2bfff GoogleToolboxForMac arm64 <1152e4d73dfd39b19721f27e287da0d8> /var/containers/Bundle/Application/8C0CB628-DD0E-4A55-B1A2-91F7971C378E/ReSchedule.app/Frameworks/GoogleToolboxForMac.framework/GoogleToolboxForMac

0x102f38000 - 0x102f3ffff ProtoRPC arm64 <a0cfa87942d03381aba1acc9a507e085> /var/containers/Bundle/Application/8C0CB628-DD0E-4A55-B1A2-91F7971C378E/ReSchedule.app/Frameworks/ProtoRPC.framework/ProtoRPC

0x102f58000 - 0x102faffff dyld arm64 <8c28034501643b82a228124b23ca0e9f> /usr/lib/dyld

0x103018000 - 0x10302ffff GoogleUtilities arm64 <88bf4061a20f3d6a87768bb6653c56b0> /var/containers/Bundle/Application/8C0CB628-DD0E-4A55-B1A2-91F7971C378E/ReSchedule.app/Frameworks/GoogleUtilities.framework/GoogleUtilities

0x103044000 - 0x10309bfff Protobuf arm64 <9fc1a71e67133c6a86755b2efe745cbf> /var/containers/Bundle/Application/8C0CB628-DD0E-4A55-B1A2-91F7971C378E/ReSchedule.app/Frameworks/Protobuf.framework/Protobuf

0x1030cc000 - 0x1030d7fff RxLibrary arm64 <f812384f17593686b85d4de614e3979b> /var/containers/Bundle/Application/8C0CB628-DD0E-4A55-B1A2-91F7971C378E/ReSchedule.app/Frameworks/RxLibrary.framework/RxLibrary

0x1030e4000 - 0x1031a7fff grpc arm64 <945a4aab20b5341688a0a5b2d58e6ce0> /var/containers/Bundle/Application/8C0CB628-DD0E-4A55-B1A2-91F7971C378E/ReSchedule.app/Frameworks/grpc.framework/grpc

0x103214000 - 0x103237fff grpcpp arm64 <20771fa03ff830dd8c427cf0e6c2403a> /var/containers/Bundle/Application/8C0CB628-DD0E-4A55-B1A2-91F7971C378E/ReSchedule.app/Frameworks/grpcpp.framework/grpcpp

0x103258000 - 0x10328bfff leveldb arm64 <09d3164a1a163838ae9b52878855b686> /var/containers/Bundle/Application/8C0CB628-DD0E-4A55-B1A2-91F7971C378E/ReSchedule.app/Frameworks/leveldb.framework/leveldb

0x1032a8000 - 0x1032b3fff nanopb arm64 <9cd15c2603f23b709c36f53f864473e3> /var/containers/Bundle/Application/8C0CB628-DD0E-4A55-B1A2-91F7971C378E/ReSchedule.app/Frameworks/nanopb.framework/nanopb

0x1032c0000 - 0x103397fff openssl arm64 <73a75147c1b032848129fa06d44252a5> /var/containers/Bundle/Application/8C0CB628-DD0E-4A55-B1A2-91F7971C378E/ReSchedule.app/Frameworks/openssl.framework/openssl

0x104f04000 - 0x104f0ffff libobjc-trampolines.dylib arm64 <cf9cb7f2097e3ea3ae9501c161aaae6c> /usr/lib/libobjc-trampolines.dylib

What does "outlined destroy" mean?

I’m not 100% sure what’s going on here but I can explain some of this. To start, let’s consider frame 1 of your backtrace:

1 ReSchedule … outlined destroy of Event + 544 (<compiler-generated>:0)
<compiler-generated>:0
means pretty much what you’d expect. This code has been generated by the compiler, and hence there’s no meaningful line number, and hence you see a line number of 0.

Next, consider

outlined destroy of Event
.
Event
is obviously the name of your type. In this context, outlined means the opposite of inlined. To understand this, you have to understand a little bit about how Swift structures interact with Swift classes.

Imagine you have a Swift structure like this:

struct Event {
    var obj: Obj
}

where

Obj
is some class type. This structure must hold a reference to
Obj
to guarantee that it doesn’t get deallocated. Now consider what happens when you make a copy of the structure:
var e1: Event = … something …
if true {
    var e2 = e1
    e1.obj = Obj(name: "obj3")
    e2.obj = Obj(name: "obj4")
}

When you do the copy,

e2
must separately retain the object because, after you’ve done the copy, you can modify
e1.obj
and
e2.obj
independently. Consequently, when
e2
goes out of scope (on line 6 in this example), it must release the reference to
e2.obj
.

The Swift runtime knows about all the object references within a structure and takes care of all of these retains and releases for you (in fact, many of them are optimised away by the compiler). In simple cases the code to do these retains and releases is inlined directly into your code. In more complex cases, this code is outlined into a separate routine. That is, the compiler synthesises a routine to do the retains and releases and then calls that routine.

Note What is the definition of complex here? I don’t know for sure, but in my tests, using Xcode 10.2.1 with optimisations turned off, I started seeing outlined routines as soon as

Event
had more than one object reference.

To continue the above example, if the

Event
structure contains lots of object references, inlining all of these retains and releases into every routine that used that structure would result in massive code bloat. Instead, the compiler generates routines like
outlined retain of Event
and
outlined release of Event
to do that work.

In your case you are crashing in one of those routines,

outlined destroy of Event
. The compiler is cleaning up an
Event
structure, that structure is too complex to have the cleanup code inlined, and thus the compiler has generated an outlined routine and has called that. It’s this routine that’s crashed, presumably because one of the object references in the structure is invalid.

For example, consider the test code pasted in at the end of this post, which has a deliberate memory management error. When I put that code into a command-line tool, it crashes on line 24 with a backtrace like this;

0  … __pthread_kill + 10
1  … pthread_kill + 284
2  … abort + 127
3  … malloc_vreport + 545
4  … malloc_report + 151
5  … Obj.__deallocating_deinit + 47
6  … _swift_release_dealloc + 16
7  … outlined destroy of Event + 16
8  … main() + 14 (main.swift:32)
9  … main + 20 (main.swift:34)
10 … start + 1

As you can see frame 7 matches frame 1 of the backtrace in your crash report.

So, where does this leave you? It seems that you have some sort of memory management error associated with the properties of your

Event
structure. It’s hard to say what that is. You could potentially work it out by disassembling the
outlined destroy of Event
routine to work out what property is being deallocated at offset 544. However, that would be tricky.

My recommendation right now is that you run your app under the standard memory debugging tools to see if they give you any hints as to what’s going wrong.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"
class Obj {
    init(name: String) {
        self.name = name
    }
    var name: String
}

struct Event {
    var obj: Obj
    var obj2: Obj
}

struct Test {

    func test() {
        print(">test")
        var e1: Event = Event(obj: Obj(name: "obj1"), obj2: Obj(name: "obj2"))
        if true {
            var e2 = e1
            e1.obj = Obj(name: "obj3")
            e2.obj = Obj(name: "obj4")
            let u = Unmanaged.passUnretained(e2.obj)
            u.release()
        }
        print("<test")
    }
}

func main() {
    let t = Test()
    t.test()
}

main()

Thanks! I think you gave me enough information to get closer to the problem.


One thing I notiticed is that the crash occurs only on release builds. I don't see this on debug builds whether they're running in the

simulator or on device.


By some trail and error I found the cause of the problem to be another function:

func setReminder(_ reminderType : ReminderType) {
        var reminders = GReminder()
        reminders.useDefault = false
        var reminderOverride = GReminderOverride()
        reminderOverride.method = "popup"
        
        switch reminderType {
            case .none:
                reminders.useDefault = true
                googleEvent.reminders = reminders
            case .atTheTimeOfEvent:
                reminderOverride.minutes = 0
            case .fiveMinutesBefore:
                reminderOverride.minutes = 5
            case .fifteenMinutesBefore:
                reminderOverride.minutes = 15
            case .thirtyMinutesBefore:
                reminderOverride.minutes = 30
            case .oneHourBefore:
                reminderOverride.minutes = 60
            case .twoHoursBefore:
                reminderOverride.minutes = 120
            case .oneDayBefore:
                reminderOverride.minutes = 1440
            case .twoDaysBefore:
                reminderOverride.minutes = 2880
            case .oneWeekBefore:
                reminderOverride.minutes = 10080
        }
        
        reminders.overrides = [reminderOverride]
        googleEvent.reminders = reminders
    }


While there are no reference types involved, there are nested structs. I was able to fix the issue by removing the intermediate variables (reminders, reminderOverride) and directly assigning to the googleEvent struct.


Any thoughts on this?

One thing I notiticed is that the crash occurs only on release builds.

That’s not uncommon with things like this. Earlier I wrote:

many of [these retains and releases] are optimised away by the compiler

Such optimisation doesn’t happen in the Debug build, and that can mask a variety of problems.

You wrote:

I was able to fix the issue by removing the intermediate variables (reminders, reminderOverride) and directly assigning to the googleEvent struct.

Shuffling code around like this shouldn’t affect the semantics of your program, so clearly you’re dealing with a bug. There’s two possibilities:

  • It’s a bug in your program.

  • It’s a bug in the compiler.

Ideally you’d want a diagnostic test that helps you tease these apart. There’s two ways you can approach this:

  • You could delve into the crash to see what’s actually triggering it. That means disassembling the

    outlined destroy of Event
    routine to work out what property is causing the problem, and then tracing the memory management of that object.
  • You can try to extract this code into a much simpler project. If you can reproduce the problem with a very simple project — one where you can be absolutely sure that all of your code is safe [1] — that suggests a compiler problem and you can file a bug report about that.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] I’m talking about safe in the Swift sense of the word, meaning:

  • Only Swift code — This means no calling out to Objective-C or any other C-based language.

  • No use of unsafe Swift constructs — These typically have

    unsafe
    or
    Unsafe
    in the name.
  • No threading — As things currently stand, Swift’s safety guarantees are very hard to check in the presence of multiple threads.

I've seen a lot of your great answers of the years, but this is one of the best. Thanks for always taking the time to dive into detail!

Cleaning derived data fixed the issue for me.