zig libc panics on macOS
#10478
Comments
Jarred-Sumner
added
the
bug
|
Were you running a beta release on macOS by chance? |
I was when this was happening to me (but it turned out zig just didn’t support Ventura) |
|
Yep, this is because Zig doesn't include a copy of In order to use Zig on Ventura, #12080 is required as well as the following diff: diff --git a/src/Compilation.zig b/src/Compilation.zig
index b00f13581..4e21245f4 100644
--- a/src/Compilation.zig
+++ b/src/Compilation.zig
@@ -4474,7 +4474,7 @@ fn detectLibCIncludeDirs(
// If linking system libraries and targeting the native abi, default to
// using the system libc installation.
- if (link_system_libs and is_native_abi and !target.isMinGW()) {
+ if ((link_system_libs or target.isDarwin()) and is_native_abi and !target.isMinGW()) {
if (target.isDarwin()) {
return if (has_macos_sdk)
// For Darwin/macOS, we are all set with getDarwinSDK found earlier. |
|
I started seeing this issue after upgrading my computer to MacOSX 13.0 (Ventura) |
|
Can you try the macos-13 branch? |
|
@jedisct1 I tried to build |
|
Can you git pull and try again? |
|
Also, Jakub has a PR for it: #13299 |
|
Now |
|
Ventura support landed in d42a719 |
|
Is there any chance to have this fix in a |
|
Sorry, 0.9.2 is not planned. |
|
Instead of patching Zig I suggest to start passing Alternately you can upgrade to Zig 0.10.0 which is to be released 4 days from now. |
|
Yes, waiting for the release of 0.10.0 sounds like a much better idea. Thanks! |
|
|
|
That's because you've installed Homebrew into |
|
Ah yes I remember dealing with this earlier. I was recently messing around with my |
|
FYI I'm seeing this panic on Zig 0.10.0, downloaded with homebrew: (on macOS Ventura 13.0.1, Macbook Air M1 2020) |
|
@akgvn What does |
|
|
@akgvn, what's the output of ? |
|
@carlocab Ran all those in order: |
|
Yea, this seems to be a problem with Zig. I can reproduce this using the latest build from master at https://ziglang.org/builds/zig-macos-aarch64-0.11.0-dev.937+c9e3524d0.tar.xz. I suggest opening a new issue (if there isn't already a related one open). |
bors bot
added a commit
to tigerbeetle/tigerbeetle
that referenced
this issue
Jan 12, 2023
364: VSR/Correctness: Preserve Canonical Headers r=sentientwaffle a=sentientwaffle (Includes #359, to ensure `repair()` commits enough ops that the pipeline can't run out of space when the new primary has to play catch-up.) Fixes 2 correctness bugs: 1. Don't Truncate Canonical DVC 2. Bump Primary view_normal Early ## Don't Truncate Canonical DVC ### Summary Truncating a canonical DVC's headers can fork the log. ### VOPR Example Consider a cluster with: - Replica 2 is leading a view change (view=17). - Replica 1 is participating in the view=17 view change. - Replica 0 is partitioned. - `pipeline_prepare_queue_max = 6` The DVC quorum: 2: on_do_view_change: replica=1 view_normal=15 op=38 commit_min=31 2: on_do_view_change: replica=2 view_normal=14 op=33 commit_min=28 primary_set_log_from_do_view_change_messages(): 1. Replica 2's `op_canonical` is 28 (computed by `primary_op_canonical_max()`). 3. Replica 1's DVC included headers 33,34,35,36,37,38. These were loaded into Replica 2's headers since Replica 1 has the canonical view. 4. Near the end of `primary_set_log_from_do_view_change_messages()`, `do_view_change_op_max()` finds a hash break between op 32/33, and discards 33…38, forking the log. It discarded the entire (canonical!) hash chain from replica 1! (In this case those ops were uncommitted, but that doesn't necessarily need to be true.) In any case, by discarding those ops we revert to our old (incorrect) op 29, which otherwise would have been repaired. We go on to commit the wrong op 29. According to `do_view_change_op_max()`, the rationale for discarding those breaks (i.e. breaks which follow the primary's `op_canonical`) is: /// If there is a hash chain break, none of the headers from the canonical DVCs replaced /// the broken (leftover uncanonical) op. /// Removing these is necessary for correctness and liveness, to ensure that /// disconnected headers do not remain in place in lieu of gaps. As the first sentence hints, passing more headers in the DVC would decrease the probability of this error, but that isn't an actual fix. (Aside: This bug was likely hidden until recently because it is becomes less probably for larger pipelines, and I have recently been heavily testing small pipelines.) ### Simplified Example With `pipeline_prepare_queue_max=3`: ``` replica headers commit_min view_normal 0 (1a 2a 3a 4a 5a 6a 7a 8a) 8a 4 (partitioned) 1 1a 2a 3a 4a 5a{6a 7a 8a} 5a 4 2 1a 2a 3a 4b 3a 2 ``` Prior to the do_view_change_op_max() truncation, replica's 2 headers are: ``` 2 1a 2a 3a 4b 5a 6a 7a 8a ↑ hash break ``` Per CTRL, we can only discard headers that are *definitely uncommitted*. A gap/break in replica 1's 6a,7a,8a would be definitively uncommitted and this safe to discard. A break before _any_ of the view_normal_canonical's DVC headers though _must_ be repaired. ## Bump Primary view_normal Early ### Background The new primary picks (in `primary_set_log_from_do_view_change_messages()`) at least one "canonical view". This is the highest `view_normal` from any DVC in its quorum. The canonical DVC(s) headers are called the view's "canonical headers". These headers help select the new log head. If multiple replicas have the same `view_normal`, there may be multiple canonical DVCs. However, canonical headers _must_ be unambiguous. More specifically: - Any particular DVC may have gaps (1a, 2a, 4a), but no hash breaks (1a, 2a, 4b). - DVCs with the same `view_normal` _must_ not conflict. ### Bug *DVCs with the same `view_normal` _must_ not conflict.* Currently they can conflict, though. The heart of this bug is that the `view_normal` updates at a different time than the headers, so there is an interval when do not correspond. Consider the new primary during a view change: 1. Primary (`R₀`) receives DVC quorum for view `V₀`. `R₀` replaces its log. `R₀` begins repair. 2. (... primary repairs) 3. `R₀` completes repair. `R₀` transitions to `status=normal`. `R₀` bumps `view_normal`. `R₀` sends out `start_view` messages. If another view change occurs during step 2 (with new primary `R₁`), `R₀` will send a DVC with a `view_normal` from _before_ `V₀`, but with the headers from `V₀`. But another replica in the view change may _also_ send a DVC, with the same `view_normal`, but the actual (different) headers! ### Not So Normal Possibly `view_normal` should be renamed. - For backups, "view normal" is accurate. - But for primaries that completed completed their DVC quorum but did _not_ complete repair, it is inaccurate. They never reach normal status, but still need to advertise as if they did, to match their headers. Maybe `view_active`? `view_write`? `view_member`? This issue isn't present in VRR because VRR's DVCs include the entire log, and assume that it can be replace atomically. 372: Node Client: Optional build target for postinstall script. r=sentientwaffle a=A-Mozeak Hi there 👋🏾 I made this change after trying to run the steps in https://github.com/interledger/rafiki/blob/main/README.md#environment-setup. (I'm on a 2019 Intel MacBook Pro, running MacOS 13.0.1 Ventura). I was getting the following error when trying to `pnpm install` that package, and the same when `npm install`-ing in the node client in this package (on the `npm run build_lib` step of `"postinstall"`). ``` thread 7274527 panic: Darwin is handled separately via std.zig.system.darwin module ``` I found [this solution](ziglang/zig#10478 (comment)) in Zig's repo, and then made the following changes (let me know if there is a better way to do this): 1) Extract the commands from the `build_lib` script in `src/clients/node/package.json` into their own shell script. 2) Conditionally set the `-target` flag for the `zig/zig build-lib` command in that script based on a passed-in `$ZIG_BUILD_TARGET` environment variable. Now the install commands work for me by running, e.g.: ``` ZIG_BUILD_TARGET=native-macos.11 npm i ``` I ran into a different error when trying to set the version of Zig to 0.10.0 in `src/tigerbeetle/scripts/install_zig.sh`, so I didn't go too deep into that approach. Hope this is useful! Co-authored-by: sentientwaffle <[email protected]> Co-authored-by: Alexander Mozeak <[email protected]>
bors bot
added a commit
to tigerbeetle/tigerbeetle
that referenced
this issue
Jan 18, 2023
372: Node Client: Optional build target for postinstall script. r=eatonphil a=A-Mozeak Hi there 👋🏾 I made this change after trying to run the steps in https://github.com/interledger/rafiki/blob/main/README.md#environment-setup. (I'm on a 2019 Intel MacBook Pro, running MacOS 13.0.1 Ventura). I was getting the following error when trying to `pnpm install` that package, and the same when `npm install`-ing in the node client in this package (on the `npm run build_lib` step of `"postinstall"`). ``` thread 7274527 panic: Darwin is handled separately via std.zig.system.darwin module ``` I found [this solution](ziglang/zig#10478 (comment)) in Zig's repo, and then made the following changes (let me know if there is a better way to do this): 1) Extract the commands from the `build_lib` script in `src/clients/node/package.json` into their own shell script. 2) Conditionally set the `-target` flag for the `zig/zig build-lib` command in that script based on a passed-in `$ZIG_BUILD_TARGET` environment variable. Now the install commands work for me by running, e.g.: ``` ZIG_BUILD_TARGET=native-macos.11 npm i ``` I ran into a different error when trying to set the version of Zig to 0.10.0 in `src/tigerbeetle/scripts/install_zig.sh`, so I didn't go too deep into that approach. Hope this is useful! Co-authored-by: Alexander Mozeak <[email protected]>
bors bot
added a commit
to tigerbeetle/tigerbeetle
that referenced
this issue
Jan 27, 2023
372: Node Client: Optional build target for postinstall script. r=sentientwaffle a=A-Mozeak Hi there 👋🏾 I made this change after trying to run the steps in https://github.com/interledger/rafiki/blob/main/README.md#environment-setup. (I'm on a 2019 Intel MacBook Pro, running MacOS 13.0.1 Ventura). I was getting the following error when trying to `pnpm install` that package, and the same when `npm install`-ing in the node client in this package (on the `npm run build_lib` step of `"postinstall"`). ``` thread 7274527 panic: Darwin is handled separately via std.zig.system.darwin module ``` I found [this solution](ziglang/zig#10478 (comment)) in Zig's repo, and then made the following changes (let me know if there is a better way to do this): 1) Extract the commands from the `build_lib` script in `src/clients/node/package.json` into their own shell script. 2) Conditionally set the `-target` flag for the `zig/zig build-lib` command in that script based on a passed-in `$ZIG_BUILD_TARGET` environment variable. Now the install commands work for me by running, e.g.: ``` ZIG_BUILD_TARGET=native-macos.11 npm i ``` I ran into a different error when trying to set the version of Zig to 0.10.0 in `src/tigerbeetle/scripts/install_zig.sh`, so I didn't go too deep into that approach. Hope this is useful! Co-authored-by: Alexander Mozeak <[email protected]> Co-authored-by: Phil Eaton <[email protected]>
|
I'm seeing similar error on Is there something obvious I'm missing? |
It's been fixed in Zig 0.11. |
|
Okay nice. I thought it was fixed in |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Zig Version
0.10.0-dev.4870+be5130ec5
Steps to Reproduce
Run
zig libcExpected Behavior
Don't panic, maybe print a non-zero exit code
Actual Behavior
The text was updated successfully, but these errors were encountered: