FFL-1450 fix memory corruption in flag_metadata#1368
Merged
Conversation
dd-oleksii
changed the title
BenchmarksComparisonBenchmark execution time: 2025-11-24 21:01:13 Comparing candidate commit 067fd56 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 55 metrics, 2 unstable metrics. CandidateCandidate benchmark detailsGroup 1
Group 2
Group 3
Group 4
Group 5
Group 6
Group 7
Group 8
Group 9
Group 10
Group 11
Group 12
Group 13
Group 14
Group 15
Group 16
Group 17
BaselineOmitted due to size. |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #1368 +/- ##
=======================================
Coverage 71.19% 71.20%
=======================================
Files 392 392
Lines 62677 62751 +74
=======================================
+ Hits 44626 44684 +58
- Misses 18051 18067 +16
🚀 New features to boost your workflow:
|
Contributor
Artifact Size Benchmark Reportaarch64-alpine-linux-musl
aarch64-apple-darwin
aarch64-unknown-linux-gnu
libdatadog-x64-windows
libdatadog-x86-windows
x86_64-alpine-linux-musl
x86_64-apple-darwin
x86_64-unknown-linux-gnu
|
sameerank
approved these changes
Nov 25, 2025
| .map(|(k, v)| { | ||
| KeyValue { | ||
| // SAFETY: the borrow is valid as long as string allocation is | ||
| // alive. ResolutionDetails will get moved into heap but this does not |
Contributor
There was a problem hiding this comment.
Ok I think I understand. ResolutionDetails moves, and since Assignment is owned directly by the struct due to inner: Result<Assignment, EvaluationError>, Assignment moves too. So,
let details = ResolutionDetails::new(Ok(value)); // details created
// BorrowedStr pointers in details are valid
let moved_details = details; // move happens
// now BorrowedStr pointers in moved_details are invalid
Thanks for updating the comments! They're helpful
Member
Author
There was a problem hiding this comment.
For a bit more context, this only affects a.allocation_key and does not affect extra_logging. This is because extra_logging strings are already stored in a Vec, which moves them to the heap. So when Vec moves, it does not move its content—it stays in the same place on the heap. This is also true for String, which stores content on the heap.
The issue occurs only with Str which has small string optimization and stores short strings (<= 24 bytes) inline in the structure and only because allocation_key is stored in Assignment directly without any heap-allocation container (e.g. Vec or HashMap)
Member
Author
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
|
dd-devflow
Bot
added
mergequeue-status: queued
mergequeue-status: in_progress
and removed
mergequeue-status: queued
labels
dd-devflow
Bot
added
mergequeue-status: done
and removed
mergequeue-status: in_progress
labels
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Fix a memory corruption bug in flag_metadata.
Additional Notes
Strtype has small string optimization, whereas short strings are stored directly in the structure bytes instead of on heap. This means that taking a reference to anallocation_keystring was pointing to an str structure which was stored on stack at that time and was moved out when result was returned from the structure. When trying to printflag_metadata.allocationKey, it was printing garbage bytes from stack.This PR stores result on heap first (
Box) and pins it for extra measure, to make sure it's not moved. This allows us to create stable pointers toallocation_key.How to test the change?
Example was expanded to print flag metadata, so verified that it was corrupted before / fixed after the change.