I'm trying to integrate Vapor (and with it NIO) in a non-conventional manner using Tuist to be able to cache the dependencies locally as binaries. In a nutshell, the tool uses the dependencies graph and turns it into a compilable Xcode project.
I get a project that compiles linking all the dependencies statically into the app executable. However, when I try to run the app, it blows up with a
EXC_BAD_ACCESS usually coming from Atomic primitives. The project also contains a Hummingbird web app that also blows up in a different point, but also from an Atomic-related primitive.
I've tried to compare side-by-side the compilation of this project with the Swift Package Manager's, but I couldn't find a flag that might be related to this issue so I'm a bit lost. Therefore I decided to share it here in case anyone could shed some light.
Please, feel free to ignore this message since I personally decided to follow a non-conventional path. If you'd like to reproduce and debug the issue yourself, you can follow the setup steps in the repo:
- Install Tuist in your environment.
- Git clone the repository:
git clone https://github.com/tuist/swift-on-server-examples.git.
- Fetch the dependencies with
I'd also appreciate any pointers on how to debug the issue. My initial guess is that it might just be a missing build flag.
Thanks in advance
It would be extremely helpful to get access to the Xcode build log for this. I suspect this is related to an issue around resilience, but there are any number of things that might trigger it.
Can I also ask you to try to shrink the repro? Given that both issues derive from using
ManagedAtomic, is it possible for you to try to use a smaller package that depends on atomics as NIO does, and then try using ManagedAtomic to see if you can repro with less code?
Thanks a lot for your response @lukasa.
I created this repository with an Xcode project where you can reproduce the issue. To reproduce it, you can open the workspace or the project and try to run the
executable executable. As soon as it launches, the execution should blow up in
AtomicBoolean.init(_:). Please let me know if that's not the case.
As for the build logs, I uploaded them to FileTransfer.io because I can't attach them here. Please, let me know if you'd like them to be shared through a different channel.
Once again, thanks for your support
We are also facing this issue and I must say it's the most annoying one. However Tuist suggested a work around override the Product type of Atomic to
Sharing the snippet
"Atomics": .framework // Static Framework casuing the crashing. Tuist suggested to override and declared as dynamic framework https://github.com/tuist/tuist/issues/4769
Is there any update on this? I'm having the same issue just trying to run basic grpc-swift code.
Edit: the solution is here swift-atomics fails runtime · Issue #5794 · tuist/tuist · GitHub