Closed nabijaczleweli closed 8 months ago
I ran into this in rye. Since I do not have a mac beta I cannot reproduce this myself but if I were to guess, this might be an initialization order issue. Today curl_global_init
is invoked in a __DATA,__mod_init_func
section:
There is a decent chance that this now runs too early and something that curl's init requires on macOS is not initialized yet.
Interestingly, we recently got a similar crash reported on Windows:
TL;DR. Link CoreServices
to binaries
In Sonoma, some CoreFoundation functions require CoreServices, but dyld of Sonoma cannot load CoreServices when it should do, like cxx_global_init in gettext, MacOS_init in libcurl. So, some programs like aria2(gettext), cargo(libcurl) didn't work.
Linking with CoreServices hasn't helped in my case, but switching to system curl did:
curl-sys = { version = "0.4", features = ["force-system-lib-on-osx"] }
I am facing the same issue in stable sonoma 14.0. Any update? Thanks
Workaround works for me thanks @kornelski
Fix for this issue has been implemented in curl/curl@6ab7e19 and is pending the next release.
Please let us know when the fix is released, thanks!
Hi,
In my comprehension, if someone uses the curl crate to produce a binary, this binary will potentially crash if the linked libcurl is the current system one.
In other words, even if curl is patched, a Rust binary linking to the system libcurl will crash unless:
Given this, shouldn't we always link a Rust binary using curl crate to CoreServices on Sonoma?
In my comprehension, if someone uses the curl crate to produce a binary, this binary will potentially crash if the linked libcurl is the current system one.
For what it's worth, I've seen several similar bug reports and none of them seem to be using the system libcurl. See, for example, the stack trace in this issue description, where Curl_macos_init
is from cargo-install-update
rather than the system libcurl.4.dylib
. It's very likely that curl-sys
built its own libcurl, which was statically linked into the executable.
To further verify this, see the minimal reproducer below.
which seems to be what the brew version of cargo is doing in https://github.com/ZhongRuoyu/homebrew-core/commit/1023367be62069180532aa777b311ba9d24fdcb2
Note that Homebrew's cargo from the rust
formula is using the system libcurl ^1; the patch was on cargo-c
to work around the issue seen here. Due to another unrelated issue (see https://github.com/Homebrew/homebrew-core/pull/146547#discussion_r1339991565), the Homebrew-provided curl
is used instead of the system libcurl.
cargo
Given this, shouldn't we always link a Rust binary using curl crate to CoreServices on Sonoma?
I do think this is a reasonable solution. Upstream (curl) is already doing is (see curl/curl#11894) and it should be in an upcoming release.
Thanks for the clarifications @ZhongRuoyu!
To note, there's no need to wait for the next curl
release, but rather link it as @ZhongRuoyu proposed.
https://github.com/alexcrichton/curl-rust/pull/530 should be enough to fix it.
Does anybody know who's able to review https://github.com/alexcrichton/curl-rust/pull/530 ? Kind of a bummer that the fix is one line (and a minor release) away, and still it is broken for weeks (if not months at this point).
I can confirm that the issue is resolved and my related projects work on Sonoma now.
To fix the issue, one needs to upgrade to https://github.com/alexcrichton/curl-rust/releases/tag/curl-sys-0.4.67
For projects that use this package, run cargo update -p curl-sys
to update to the package that has the issue fixed.
For already installed binaries like cargo-update
, you'll have to reinstall them with cargo install --force cargo-update
Forwarding because I see Curl_macos_init <- _ZN3std4sync4once4Once9callonce28$u7b$$u7b$closure$u7d$$u7d$17hac714a257a9e32a7E <- _ZN4curl9INIT_CTOR9init_ctor17h6cadb2258443a9ccE in backtrace.
Downstream: https://github.com/nabijaczleweli/cargo-update/issues/240
Using cargo 1.71.0 (cfd3bbd8f 2023-06-08)
cargo install-update
immediately crashes.