-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
assertion failure in liveness #15814
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
If you want a workaround, you can have a local http server (such as python server) serve up the local version of the package file pointed by the url and once it hits the cache, you can just turn off the server (you won't need it again on the same machine). Your build.zig.zon file can even go back to the regular url. At least it will allow you to proceed while they fix this. |
Downloading and hashing this package worked correctly for me (zig version = 0.11.0-dev.2969+855493bb8). Do note that zig do not create the hash in build.zig.zon when downloading a package, it has to be supplied beforehand. What happens is that zig compares the hash given in the .zon file with the content of the downloaded package to ensure that the correct/expected files+content are present. .{
.name = "test",
.version = "0.0.0",
.dependencies = .{
.stuff = .{
.url = "https://github.com/ziglibs/s2s/archive/6484f786b1830115601cd9ffb51bccec551ac6be.tar.gz",
.hash = "1220f6c17bde3f75ac79f29b5572f75fc35275b552b5b398d42df133fa038a29b396",
},
},
} |
Not related, the package is downloaded just fine, it's in the path one would expect and everything The problem is 100% when it starts making the hash to check if the provided hash is correct, once you use strace, you see that it tries to open the file (After a few successful matches) and breaks, in the case of using a package like antiphony, which has images and assets for decoration, on those images for such decoration. |
@Deecellar on which OS/Platform and File-system are you experiencing the hashing issue? |
Still having the following error at
|
zig build segfaults at least 33% of the time if it needs to fetch packages. it has done so for a while. this issue was shadowed by more frequent TLS bugs before. I can't poinpoint to where exactly it is crashing until we get zig debug releases. I run nightly CI builds and the chance of waking up to a segfaulted build is > 33% |
Here's what it looks like if you use a debug build of zig:
This particular crash is not in the package manager but in a liveness analysis pass, after successfully downloading the package. cc @mlugg liveness bug for you right here |
Zig Version
0.11.0-dev.3258+7621e5693
Steps to Reproduce and Observed Behavior
Once you execute zig build, the compiler will segfault
Expected Behavior
To download the package without issues
The text was updated successfully, but these errors were encountered: