Fix alignment error - #126
Merged
Merged
Conversation
This is a quick&dirty fix for an alignment error in the buddy system. Fixes #105. Per the C standard, malloc() returns memory aligned to max_align_t, typically 8 bytes on some LP64 platforms (e.g., many Linux/ARM64 configurations) and 16 bytes on x86-64. The C standard does not guarantee malloc() satisfies over-aligned types (with alignment greater than max_align_t). Possible problems in the previous implementation: - Undefined behavior: Accessing a misaligned alignas(16) member is UB per C11 §6.2.8. - SIMD crashes: If the compiler auto-vectorizes operations on longest[] or base_mem[] and emits SSE aligned loads/stores (movaps, ld1), a misaligned buffer will cause a hardware fault. - Checkpoint corruption: The static_assert in buddy.h enforces contiguity between longest and base_mem. Misalignment of the struct could interact poorly with memcpy-based checkpoint/restore paths (checkpoint.c) if the compiler assumes alignment it doesn't actually have. I wasn't actually able to trigger this latter condition in any environment, but it should be nevertheless possible from my understanding. On x86-64, malloc() typically returns 16-byte-aligned memory, so this bug is latent on the most common targets. It becomes active on platforms where max_align_t alignment is less than 16. Since we pretend to be architecture-independent, I classify this as a severe bug. Signed-off-by: Alessandro Pellegrini <a.pellegrini@ing.uniroma2.it>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #126 +/- ##
===========================================
- Coverage 85.81% 85.32% -0.49%
===========================================
Files 46 46
Lines 1600 1554 -46
Branches 39 39
===========================================
- Hits 1373 1326 -47
- Misses 211 212 +1
Partials 16 16 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Piccions
approved these changes
Jun 11, 2026
Piccions
left a comment
Contributor
There was a problem hiding this comment.
Quick and dirty does the job here!
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
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.
This is a quick&dirty fix for an alignment error in the buddy system. Fixes #105.
Per the C standard, malloc() returns memory aligned to max_align_t, typically 8 bytes on some LP64 platforms (e.g., many Linux/ARM64 configurations) and 16 bytes on x86-64. The C standard does not guarantee
malloc() satisfies over-aligned types (with
alignment greater than max_align_t).
Possible problems in the previous implementation:
On x86-64, malloc() typically returns 16-byte-aligned memory, so this bug is latent on the most common targets. It becomes active on platforms where max_align_t alignment is less than 16.
Since we pretend to be architecture-independent, I classify this as a severe bug.