EXC_BAD_ACCESS/SIGABRT in debugCaseOutput

[finestructure]

When adding (or removing) a new action with an associated value, for instance case foo(String), calling .debugActions(actionFormat: .labelsOnly) (not sure if .labelsOnly is relevant) crashes with an EXC_BAD_ACCESS or SIGBART. (I've seen both happen, mostly it's EXC_BAD_ACCESS.)

This is reproducible in my TCA project but I haven't tried it in any of the official examples yet.

What's interesting (and leads me to believe this is a compiler issue): "Clean Build Folder" + "Run" fixes the issue. It's not a big deal to work around this (as it's a debugging tool only anyway) so I'm really just raising the issue to report the workaround in case others are seeing this as well :)

This is on macOS 12.2 with Xcode 13.2.1 and TCA 0.33.1

[stephencelis]

@finestructure Huh! Do you think you could get us more info or ideally a way to repro? E.g., what does the action being fed to debugCaseOutput look like that causes the crash?

[finestructure]

I can literally just add a case foo(String) to actions and handle it by returning a .none effect in the reducer. It doesn’t need to fire at all. I’m guessing other actions would have to. I’ll try it with one of the examples in the TCA repo when I’m at a computer to see if it reproduces there!

[finestructure]

Ok, I've had a look and I've not managed to reproduce it in Tic Tac Toe nor another simple TCA example of mine. So it must be something specific to this project. I can try and make it available to you somehow if you'd like.

[iampatbrown]

@finestructure I'm happy to take a look if you want as well. You could invite me to a private repo or extract part of your existing project that reproduces the issue and post it here.

[finestructure]

Ok, this definitely looks like a memory layout issue. My app fires three events on startup. I've just changed the associated value payload of an action and suddenly three different actions fired. It was very obvious this time, because the normal launch actions load data whereas the replacements had no effect. A clean-build-run fixed it.

So it seems like debugActions exposes the issue in a more dramatic fashion but there can be more subtle effects.

I'll try and reduce the sample to something I can share.

[iampatbrown]

@finestructure thanks for the update. Keen to see what's going on!

[nmccann]

I encountered a very similar bug, however in my case I had just added a new variable (containing an optional enum that had one case with an associated string value) in my State struct, and it occurred with debug() but didn't seem to happen with debugActions(), and didn't happen at all without any debug printing.

A memory layout issue seems likely - if I moved the definition of the new variable around, I could reliably reproduce/fix the issue - with no other changes. Early on the EXC_BAD_ACCESS crashes were all happening in CustomDump, but by the time I thought to take screenshots, it was consistently occurring in Store instead. And as with @finestructure - a clean-build-run seems to have fixed it. Very weird.

[stephencelis]

I'm going to convert this to a discussion for now, since we have no way of reproducing, and because cleaning the build fixes. It's hard to know if it's a Swift bug or a bug with a library of ours. If there are changes we can make to fix the problem, we'd love to make them here and/or in Custom Dump, wherever it makes sense, but for now we'll leave the discussion open for folks to discover a workaround to the problem.

[tgrapperon]

According to the first screenshot, the code executes on a background queue (which is expected). The stack size is thus way smaller than on the main thread (512kB on macOS & iOS instead of 8MB and 1MB), and there is potentially a fair amount of recursion here, or when using Mirrors or interpolating strings with non-Custom(Debug)StringConvertible (which involves other Mirrors) so maybe that's a stack overflow?