Enum with large amount of cases EXC_BAD_ACCESS / stack size overflow?

Dear community,

My domain model includes several larger enums, such as a list of municipalities, of states, languages, etc. Each is logically an enum because they are a limitative list.

However, I'm running into problems using these enums. Take an enum with municipalities for example (circa 300 cases) where the enum itself is a String (:String). I then have a computed variable that returns a simple struct with a translated name (similar to a tuple (english: String, dutch:String), etc.

Using this in a script in macOS as an executable works fine. However, when running a vapor server, it produces an error. (Thread 76: EXC_BAD_ACCESS (code=2, address=0x17267bff8)).

Reducing the amount of cases in the municipalities enum removes this error.

I have researched the issue and learned that enums have a maximum memory size, which differs depending on the environment. It is said that it is 8MB in macOS and much less elsewhere (1MB), which could explain why I don't have the error running an executable.

I have tried to increase the stack size via the -stack_size linkersettings. But haven't gotten this to compile. The modification I tried was one I found via Infinite loops w/ 100% CPU usage caused by stack overflows · Issue #367 · TokamakUI/Tokamak · GitHub, namely: .unsafeFlags(["-Xlinker", "--stack-first", "-Xlinker", "-z", "-Xlinker", "stack-size=16777216"]).

I would be super appreciative of any assistance you could provide. If you have any suggestions, please leave a comment.

Enum doesn't look appropriate choice here but better if you show a representable fragment of your enum as it is not clear what you are doing. The computed variable should not contribute to enum's size, are you talking about associated value here? Then, what's wrong with the standard approach to get strings localised? Also, is this a background thread you are talking about? (secondary threads are known to have smaller stacks compared to the main thread). I'd recommend you to fix the issue by other means and only if everything else failed - change the stack size (e.g. by this) but that's really the last resort way and should not be needed normally.