Frequent EXC_BAD_ACCESS crashes, temporarily fixed by clean & rebuild

[Xythus]

Description

Lately I've been getting frequent crashes in TCA source code when a related view/reducer becomes active.
The breakpoint usually points to one of a few lines in the scope and pullback methods.

When this happens, a full clean & rebuild always seems to resolve the issue until it inevitably occurs again.
Unfortunately I cannot seem to reliably reproduce the issue, so it's tough to give any useful information.
It does seem to only happen to views/reducers that have been changed since the last build, although I don't want to definitively rule out other situations.

I was wondering if anyone else has encountered this behavior.
I'm using the prerelease branch and navigation beta.

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

The app doesn't crash when a related view/reducer becomes active.

Actual behavior

The app crashes when a related view/reducer becomes active.

Steps to reproduce

No response

The Composable Architecture version information

prerelease/1.0

Destination operating system

iOS 16.3.1, iOS 16.4

Xcode version information

Xcode 14.3 14E222b

Swift Compiler version information

swift-driver version: 1.75.2 Apple Swift version 5.8 (swiftlang-5.8.0.124.2 clang-1403.0.22.11.100)
Target: x86_64-apple-macosx13.0

[stephencelis]

@Xythus I think this is unfortunately an incremental compile bug in Swift, especially if you say it's always resolved by a clean. Swift just seems to have more trouble with incrementally compiling these days, especially when it's around generic code like reducers. I'm going to convert this to a discussion since there's not much I think we can do, and because the issue seems to be in the Swift compiler and not in our library.

I'd suggest seeing if you can find a repro in your project (after a clean build that works, figure out what change causes the build to crash) and share that with Apple. Here's hoping this stuff gets better in the next version of Swift!

[Xythus]

I was afraid this would be the case. I guess I'll keep on cleaning then! Thanks :)

[WedgeSparda]

Hi, I'm facing a similar issue and, until now, the only solution was to delete the derived data and build again.

It is really confusing, since the only change I'm making is adding or removing properties to a Reducer State.

[acosmicflamingo]

Whoaaaaaaa, deleting derived data? Command + Shift + K does not help you out with the issues?

[acosmicflamingo]

[WedgeSparda]

Didn't try, honestly 🤣

[notcome]

For any future readers, I want to remind you that EXC_BAD_ACCESS is a best case scenario. You could run into silent code corruption with this bug! I have a simple code that looks like this

enum Action {
    case updateEmptyArray([Int])
    case updateNonemptyArray([Int])
}

The actual code does not concern emptiness of an array, of course. But the thing is, due to the incremental compilation bug, the wrong case will be used, but at the same time, since both cases have the exact same payload, no EXC_BAD_ACCESS is triggered! You end up getting a logical error from nowhere, and this could cost you significant time to figure it out.

[stephencelis]

For what it's worth this will likely only affect your development cycle, as release builds you ship to the App Store won't be incrementally compiled. Still can be annoying! And we hope the Swift team addresses it.

[notcome]

Yes yes for sure! Just try to let people know that Clean Build Folder may solve mysterious issues! Hope people won't spend too much time doubting themselves for too long: I have done that and that didn't feel good😂

[JackYoustra]

I frequently encounter this whenever I change the object layout of any of my non-root feature modules. It usually occurs for me when building the iOS app target. The way I usually fix it is by building the app-level feature library (AppFeature). I can't tell if this fixes or screws up the incremental compiler state to the point where it has to rebuild everything, but it gets the job done and is less heavy than clearing derived data.