Crashes

[stevenou]

The Patch library somehow appears to crash ruby. I did some research and found this: https://bugs.ruby-lang.org/issues/14009. I can avoid the issue with DISABLE_SPRING=true. However, there is probably some code in the SDK or its dependencies that could be replaced in order to make this play nice without workarounds. My guess is it has to do with how ethon/libcurl works which conflicts with Objective-C's forking rules...

Calling API: ProjectsApi.retrieve_projects ...
ETHON: Libcurl initialized
objc[9892]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[9892]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.

[pcothenet]

Very interesting. We'll look into that.

@stevenou while we do, is the workaround you found and acceptable solution on your side, or is this blocking you from using further?

[junr03]

@stevenou thanks for the report. Do you mind adding more details so we can debug further?

1. What version of the SDK are you using?
2. Do you have any repro steps we could use?
3. What environment are you running your code in?

[stevenou]

It is currently non-blocking in development due to the workaround. And since this appears to be an issue related to Objective-C, it should be a non-issue in production (which is running Linux servers).

patch_ruby (1.23.0)
Mac OS X 12.4 on MacBook Air M1

I don't have exact reproduction steps unfortunately. But I'm on ruby 3.1.2, rails 7.0.3, running puma 5.6.4, which is probably relevant because of the forking.

[junr03]

Hi @stevenou - @maximevaillancourt did an excellent deep dive into this issue. I am posting below his summary:

I briefly looked into this: all is this is caused by fork safety meaures that Apple introduced in macOS High Sierra (10.13) (see explainer blog post). This particular bug may stem from the typhoeus gem that we use (see bug report in typhoeus/typhoeus).
Going deeper, it may be coming directly from Ethon—which the typhoeus gem relies on (view source)—specifically when the first use of Ethon is from within a fork (see bug report in typhoeus/ethon). Since Spring relies on the fork system call to speed things up, it would explain why setting the DISABLE_SPRING=true environment variable "fixed" the problem for the bug reporter.
There's another "fix" floating around to specifically disable macOS's fork safety railguards (OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES), which obviously isn't ideal.
To circumvent this issue until it's fixed within Ruby and/or Ethon, we may need to somehow force a first request through Typhoeus outside of a forked process... or disable Spring altogether. 😞

So, for now disabling spring in development like you are doing is our best course of action. Feel free to reopen this issue if you have additional comments!