The high bit is set there, too, so I'm not sure that conclusion is correct. I wonder if it's related to some of the enums-with-one-payload issues that we've seen (cc aschwaighofer@apple.com (JIRA User)).

Oh huh you're right the high bit is indeed set, it's 0x8000000000000010. Interestingly, the Crashlytics crash shows the invalid address as 0x0000000000000000. While we did notice the Apple crash ended in 10 instead of 00 we didn't notice the high bit had flipped too. I'm going to just chalk this up to yet another Crashlytics bug and assume the Apple log is correct.

@belkadan or aschwaighofer@apple.com (JIRA User) do you have another Jira for that enums issue you referenced?

As an update, users of our app hit this about 1000 times per day.

https://bugs.swift.org/browse/SR-10445

Great, thank you!

Looking at the source code and that other Jira, I don't see how it can be related, but maybe I'm missing something. It seems like that issue was related to single-case enums, but there are no enums in this code?

We're not sure if it's related. There's not really enough information in this bug to be actionable.

How can we gather more information? All we have right now is the crash log, the line it occurs on, and the fact that it didn't happen with the Swift 4.2 compiler.

By "bound protocol function", do you mean something like the case in https://bugs.swift.org/browse/SR-75 ? It could be that you're somehow "lucky" enough that your case miscompiles rather than crashing somewhere inside the compiler.

Not quite. The code is accessing a bound function like that, except on a protocol existential, not on a protocol type. It's something like

protocol NormalizedCache {
    func loadRecords(forKeys keys: [CacheKey]) -> Promise<[Record?]>
    …
}

class ReadTransaction {
    let cache: NormalizedCache

    lazy var loader: DataLoader<CacheKey, Record?> = DataLoader(cache.loadRecords)
    …
}

class DataLoader<Key, Value> {
    let loader: ([Key]) -> Promise<[Value]>

    init(_ loader: @escaping ([Key]) -> Promise<[Value]>) {
        self.loader = loader
    }
    …
}

So cache is a protocol existential of type NormalizedCache and the bound function cache.loadRecords is retrieved and passed to another type, which stores it and then later invokes it (with self.loader(keys)).

The concrete NormalizedCache type involved here is something called InMemoryNormalizedCache, and the crash occurs inside its implementation of loadRecords at the first spot where the self value is accessed. So AFAICT the bound function cache.loadRecords is acting pretty similarly to something like

If you've got it narrowed down to that, you've got a potential workaround: use an explicit closure. If that makes it go away, it might be a problem with bound functions on existentials; if it doesn't, it could be a problem with lazy.

The crash isn't in our code, it's in a third-party library that we depend on. And unfortunately the authors of that library are rather nonresponsive to issues so I have very little hope that we'd be able to convince them to change that to a closure.

If we knew how to reproduce this crash locally I'd test that as a temporary patch, but I don't think any of us have ever seen this crash ourselves, we've only gotten crash logs from users.

Got it. :-(

We manually patched the dependency code to try out that work-around in our latest release, but that did not fix the crash.

We changed from:

fileprivate lazy var loader: DataLoader<CacheKey, Record?> = DataLoader(self.cache.loadRecords)

to:

fileprivate lazy var loader: DataLoader<CacheKey, Record?> = DataLoader({ [cache] keys in return cache.loadRecords(forKeys: keys) })

This has now skyrocketed to being our number 1 crasher.