Hi, Claude31, thanks for the help.
This is the error message (or do you mean a complete crash log as described in this page?)
Thread 7: EXC_BAD_ACCESS (code=2, address=0x70000be7cfb0)
And this is the stack trace of a test I written to reproduce the crash. The test contains no UI code (I ran into the issue in my app at first). The test calls API of a library in my app, so the stack trace is perhaps meanlingless to you. More on this below.
I have been thinking about the issue today and now I suspect it might be a stack overflow issue, mainly because I can't think of any other reason why it crashed (more on this below). It may also explains why the issue doesn't occur on my phone (for example, could it be that the cooperative thread on phone has larger stack size than that on macOS? BTW, my laptop has Intel CPU, not sure it makes a difference)
Below are some details which may help to understand the background of the issue:
-
The code that crashed are quite simple. My app has a demo mode. When user activates the demo mode, the app runs an async func to generate demo data, and pass the generated data back to the main thread. The crash occurred in the async func to generate the demo data.
While the internal of the code to generate the data are complex, it's quite simple from architecture perspective because a) it doesn't interact with any other part of the code in the app, and b) it uses only structs internally and return value of a struct. So there isn't a obvious reason why it could crash due to memeory error.
-
I was able to reproduce the issue in a non-ui test (see stack trace above). Unfortunately I wasn't able to reproduce the issue without using my library. For example, creating a large (e.g, size of 8M) array or dictionary in an async func doens't crash. I think it's because array and dictionary have very small footprint in stack (they are mainly in heap to support COW behavior). That said, I use only value types (structs, array, dictonary, enum) in my app, so I have no idea why I could have stack overflow issue.
-
If I change the async func to a plain old sync func and call it in main thread, the code worked fine. That's why I think it's might be a stack size issue, because main thread has larger size than worker thread. That said, I have developed the app for more than one year and did a lot of testing, including provisioning a large set of data in main thread. I never saw the crash issue in main thread (as I explained above, I suppose it's because arrays and dictonary has small footprint in stacks). So, while worker thread has smaller stack size, I didn't expect this issue.
-
Also, as I decribed in previous posts, I run into the issue after I upgraded my OS and Xcode. It worked fine on macOS 13.0 + Xcode 14.0. Could it be some thing changed on macOS that caused the crash (I don't mean it's a bug)?
Now I'm trying to figure out how to verify this is really a stack overflow issue and identify which function the overflow occurs. The internals of the demo data generation file is complex: it generates raw data, then parse the data to generate derived data and repeat (there are recursion invoved, thought I don't think recusion is the reason caused the stack overflow, I suspect it's the size of the data instead). The crash log seems helpless. The size(ofValue:) doesn't help either, because as I said above most of the storage in array and dictionary are in heap. Do you have any suggestions? I'm also thinking to ask in Swift forum what's the general approach to identify stackoverflow issue. Thanks.
