-
Notifications
You must be signed in to change notification settings - Fork 183
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
EOFError: end of buffer reached #474
Comments
I managed to grab a copy of a bad
Hope this helps |
I work with @kuahyeow and reproduced the same issue on my end. In our environment something appears to fail while loading ---
table_name: ci_builds
classes:
- Ci::Bridge
- Ci::Build
- Ci::Processable
- CommitStatus
- GenericCommitStatus
feature_categories:
- continuous_integration
description: TODO
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/046b28312704f3131e72dcd2dbdacc5264d4aa62
milestone: '8.0'
gitlab_schema: gitlab_ci
For some reason Bootsnap is just trying to load a single byte: [201, 210] in /Users/stanhu/.asdf/installs/ruby/3.2.3/lib/ruby/gems/3.2.0/gems/bootsnap-1.18.1/lib/bootsnap/compile_cache/yaml.rb
201: def storage_to_output(data, kwargs)
202: if kwargs&.key?(:symbolize_names)
203: kwargs[:symbolize_keys] = kwargs.delete(:symbolize_names)
204: end
205:
=> 206: unpacker = CompileCache::YAML.msgpack_factory.unpacker(kwargs)
207: unpacker.feed(data)
208: safe_loaded = unpacker.unpack
209: if safe_loaded
210: unpacker.unpack
(byebug) data
"\xC3" I added some debug log messages, and I see that the right file is being loaded. However,
|
I'm also running into #471. It does seem like the header is getting corrupted somehow because you can see in the hexdump the length is indeed set to 1:
It appears the first time the YAML cache is compiled it is correct:
However, for some reason the next time I ran |
Thanks. Yes very likely the same root cause than #471. The revalidation must corrupt the cache entry somehow. If more people are running into it, I think I'll cut another patch release to disable revalidation (or put it behind a flag). |
I see that bootsnap/ext/bootsnap/bootsnap.c Line 663 in 4b6d40e
However, when |
Interesting catch. If that's indeed it, it shouldn't be too hard to produce a test case. 👀 BTW: I just pushed a |
Thanks. This diff fixes the issue for me: diff --git a/ext/bootsnap/bootsnap.c b/ext/bootsnap/bootsnap.c
index 326aade..5a7ddb0 100644
--- a/ext/bootsnap/bootsnap.c
+++ b/ext/bootsnap/bootsnap.c
@@ -115,7 +115,7 @@ static void bs_cache_path(const char * cachedir, const VALUE path, char (* cache
static int bs_read_key(int fd, struct bs_cache_key * key);
static enum cache_status cache_key_equal_fast_path(struct bs_cache_key * k1, struct bs_cache_key * k2);
static int cache_key_equal_slow_path(struct bs_cache_key * current_key, struct bs_cache_key * cached_key, const VALUE input_data);
-static int update_cache_key(struct bs_cache_key *current_key, int cache_fd, const char ** errno_provenance);
+static int update_cache_key(struct bs_cache_key *current_key, uint64_t data_size, int cache_fd, const char ** errno_provenance);
static void bs_cache_key_digest(struct bs_cache_key * key, const VALUE input_data);
static VALUE bs_fetch(char * path, VALUE path_v, char * cache_path, VALUE handler, VALUE args);
@@ -331,9 +331,10 @@ static int cache_key_equal_slow_path(struct bs_cache_key *current_key,
return current_key->digest == cached_key->digest;
}
-static int update_cache_key(struct bs_cache_key *current_key, int cache_fd, const char ** errno_provenance)
+static int update_cache_key(struct bs_cache_key *current_key, uint64_t data_size, int cache_fd, const char ** errno_provenance)
{
lseek(cache_fd, 0, SEEK_SET);
+ current_key->data_size = data_size;
ssize_t nwrite = write(cache_fd, current_key, KEY_SIZE);
if (nwrite < 0) {
*errno_provenance = "update_cache_key:write";
@@ -803,7 +804,7 @@ bs_fetch(char * path, VALUE path_v, char * cache_path, VALUE handler, VALUE args
valid_cache = cache_key_equal_slow_path(¤t_key, &cached_key, input_data);
if (valid_cache) {
if (!readonly) {
- if (update_cache_key(¤t_key, cache_fd, &errno_provenance)) {
+ if (update_cache_key(¤t_key, RSTRING_LEN(input_data), cache_fd, &errno_provenance)) {
exception_message = path_v;
goto fail_errno;
}
@@ -965,7 +966,7 @@ bs_precompile(char * path, VALUE path_v, char * cache_path, VALUE handler)
}
valid_cache = cache_key_equal_slow_path(¤t_key, &cached_key, input_data);
if (valid_cache) {
- if (update_cache_key(¤t_key, cache_fd, &errno_provenance)) {
+ if (update_cache_key(¤t_key, RSTRING_LEN(input_data), cache_fd, &errno_provenance)) {
goto fail;
}
} I wonder if it's simpler to do: current_key->data_size = current_key->size; UPDATE: Probably not, since |
Hmm, maybe this is not exactly right. The |
Yup, I have what I think is a cleaner patch, but you were right on the money, I'm just writing a proper test case and will open a PR in a few minutes. Thanks a lot, that was a great catch. |
I made sure the issue is in bootsnap
After disabling bootsnap, the issue now longer appears
Steps to reproduce
Unfortunately, this only happens reliably with
gdk update
(GitLab tooling). I am working to find a simpler reproduction in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/143230#note_1750589800Expected behavior
Actual behavior
The previous version of bootsnap we used as 1.17.0. After the upgrade to 1.18.1,
bundle exec rails db:migrate
started failing with:If I run it with
--backtrace
, I notice this lines at the top:I suspect something in 1.18.1 has changed relating to
YAML.load_file
. Looking at how Bootsnap monkey patches YAML, it's possible that changes to the bs_fetch function in 1.18.0 might be relate to this bug. df6267fSystem configuration
Bootsnap version: 1.18.1
Ruby version:
ruby 3.2.3 (2024-01-18 revision 52bb2ac0a6) [arm64-darwin22]
Rails version: 7.0.8
The text was updated successfully, but these errors were encountered: