-
Notifications
You must be signed in to change notification settings - Fork 466
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
deps: pebble crashes when using zstd #1706
Comments
Looks like I also tried with |
Took another look at this with |
The issue is still there in |
This comment was marked as abuse.
This comment was marked as abuse.
Might be time to address this: #999 (comment) It has a corresponding TODO: pebble/internal/cache/value_normal.go Lines 35 to 38 in 047380b
|
There are a whole host of issues going on in the zstd codepath. First, in this error case we swallow Lines 71 to 73 in 047380b
Second, I think the swallowing of the Lines 48 to 51 in 047380b
Since we're decoding into manually-managed memory, we require zstd to use our buffer. But recent versions of the zstd library will use their own buffer whenever the provided buffer is not big enough to hold the worst case decoded size: We manually allocated memory for the decoded value using the exact value we wrote in a prefix to the block, so there's no chance the zstd library will use our buffer.
pebble/sstable/compression_cgo.go Lines 29 to 33 in 047380b
Edit: I don't think this last one is an issue, although it appears to be relying on undocumented behavior ( |
Opened DataDog/zstd#130 to allow us to decompress directly into a perflectly-sized block-cache buffer. |
Upgrade zstd to v1.5.6. Due to changes in the mechanics of zstd.Decompress function, this required a change to using a new zstd.DecompressInto entrypoint that guarantees it'll deserialize into the provided destination buffer, never allocating a new buffer. Close cockroachdb#1706.
Upgrade zstd to v1.5.6. Due to changes in the mechanics of zstd.Decompress function, this required a change to using a new zstd.DecompressInto entrypoint that guarantees it'll deserialize into the provided destination buffer, never allocating a new buffer. Close #1706.
The commit upgrading was reverted due to issues with Bazel building zstd. Reopening. |
hi all, just wondering if any updates on cockroachdb size to update the dependency? would be nice to have zstd working with pebble as we're also hitting the panic with current version |
cockroachdb/cockroach#105568 is the tracking issue, and there's been no progress yet. |
Upgrade zstd to v1.5.6. Due to changes in the mechanics of zstd.Decompress function, this required a change to using a new zstd.DecompressInto entrypoint that guarantees it'll deserialize into the provided destination buffer, never allocating a new buffer. Close cockroachdb#1706.
Upgrade zstd to v1.5.6. Due to changes in the mechanics of zstd.Decompress function, this required a change to using a new zstd.DecompressInto entrypoint that guarantees it'll deserialize into the provided destination buffer, never allocating a new buffer. Close cockroachdb#1706.
Upgrade zstd to v1.5.6. Due to changes in the mechanics of zstd.Decompress function, this required a change to using a new zstd.DecompressInto entrypoint that guarantees it'll deserialize into the provided destination buffer, never allocating a new buffer. Close cockroachdb#1706.
Upgrade zstd to v1.5.6. Due to changes in the mechanics of zstd.Decompress function, this required a change to using a new zstd.DecompressInto entrypoint that guarantees it'll deserialize into the provided destination buffer, never allocating a new buffer. Close cockroachdb#1706.
Upgrade zstd to v1.5.6. Due to changes in the mechanics of zstd.Decompress function, this required a change to using a new zstd.DecompressInto entrypoint that guarantees it'll deserialize into the provided destination buffer, never allocating a new buffer. Close cockroachdb#1706.
Upgrade zstd to v1.5.6. Due to changes in the mechanics of zstd.Decompress function, this required a change to using a new zstd.DecompressInto entrypoint that guarantees it'll deserialize into the provided destination buffer, never allocating a new buffer. Close cockroachdb#1706.
Upgrade zstd to v1.5.6. Due to changes in the mechanics of zstd.Decompress function, this required a change to using a new zstd.DecompressInto entrypoint that guarantees it'll deserialize into the provided destination buffer, never allocating a new buffer. Close #1706.
When upgrading the version of zstd, Pebble crashes at runtime with the following:
This blocks upgrading the version of zstd that we use.
See #1704 for the diff and reproducer. Note that the issue may have been introduced in a version prior to
v1.5.2
(Pebble at the time of writing is at versionv1.4.5
). I only tested against the latest.The text was updated successfully, but these errors were encountered: