Skip to content
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

Spurious failures when unzipping #74

Open
criemen opened this issue Jul 30, 2024 · 2 comments
Open

Spurious failures when unzipping #74

criemen opened this issue Jul 30, 2024 · 2 comments

Comments

@criemen
Copy link

criemen commented Jul 30, 2024

Hi,

we're seeing spurious failures during unzip-file on CI which imo hint at a concurrency problem. Unfortunately, I don't have a good reproducer, but we do see this on CI every once in a while.

Errors we're seeing:

Error: invalid Zip archive: Invalid local file header
Error: Failed to extract legal/java.desktop/mesa3d.md

Caused by:
    0: Failed to write directory
    1: corrupt deflate stream
Error: Failed to extract bin/java

Caused by:
    0: Failed to write directory
    1: corrupt deflate stream

We're seeing this across multiple platforms (at least macos and windows, maybe also linux), and with multiple zip files.
I'd guess the error rate is at or below 1%.

@adetaylor
Copy link
Collaborator

Thanks for the report - I agree that sounds bad. It's quite surprising though: there's a lot of concurrency complexity in the HTTP reads, but hardly any within the file reads.

Is it remotely possible that the length of the file is changing underneath our feet? This can confuse ripunzip. Perhaps I'll put in place checks for this (as best I can).

adetaylor added a commit that referenced this issue Sep 28, 2024
This will result in errors being emitted in a few cases where seek requests are
too big or too weird.

This is a first step to diagnosing #74, though it seems unlikely to be related.
This was referenced Sep 28, 2024
@criemen
Copy link
Author

criemen commented Sep 28, 2024

Is it remotely possible that the length of the file is changing underneath our feet?

That would be very surprising (or a pretty bad OS or bazel bug, but as we've seen this cross-platform it hardly can be a OS bug), as we're unzipping zip files provided from our build system - once that declares that the file has been written, it better be fully written to disk. Thanks for taking a look at this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants