fix(arm32): widen MinidumpContextARM::fpscr to uint64_t#150
Closed
jpnurmi wants to merge 2 commits into
Closed
Conversation
MinidumpContextARM::fpscr was declared as uint32_t, making the struct 364 bytes on disk. Every other downstream reader of the ARM32 minidump context stream — breakpad's MDRawContextARM, rust-minidump's CONTEXT_ARM, the Sentry ingest path that uses rust-minidump — treats fpscr as uint64_t and expects a 368-byte struct, so crashpad's output was 4 bytes short and couldn't be fully deserialized. The comment above the struct already noted that extra[8] is "included for compatibility with breakpad"; fpscr's width was the remaining divergence. Switch it to uint64_t so sizeof(MinidumpContextARM) == 368, matching breakpad / rust-minidump. rust-minidump's struct at a pinned SHA, for reference: https://github.com/rust-minidump/rust-minidump/blob/d4fefc765aad35b3bef569d53c1680eadab5a268/minidump-common/src/format.rs#L1034-L1055 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After widening MinidumpContextARM::fpscr to uint64_t to match breakpad's on-disk layout, the in-memory CPUContextARM::vfp_regs.fpscr is still uint32_t (the ARM FPSCR register is genuinely 32 bits; the u64 in the minidump stream is padding for alignment, not extra data). Add an explicit static_cast to silence MSVC's /WX narrowing warning. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
jpnurmi
commented
Apr 21, 2026
| context_.arm->pc = src->pc; | ||
| context_.arm->cpsr = src->cpsr; | ||
| context_.arm->vfp_regs.fpscr = src->fpscr; | ||
| context_.arm->vfp_regs.fpscr = static_cast<uint32_t>(src->fpscr); |
Collaborator
Author
There was a problem hiding this comment.
This makes me feel that Crashpad is actually right and we should fix Breakpad and rust-minidump instead...
Collaborator
Author
|
I assumed Verified with a quick sizeof/offsetof check: CrashpadOrig: size=368 fpscr@72 vfp@80 extra@336 No change needed. |
jpnurmi
added a commit
to getsentry/sentry-native
that referenced
this pull request
Apr 21, 2026
See also: getsentry/crashpad#150 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
1 participant
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.
MinidumpContextARM::fpscrwas declared asuint32_t, making the struct 364 bytes on disk. Other downstream readers of the ARM32 minidump context stream — breakpad'sMDRawContextARM, rust-minidump'sCONTEXT_ARM, the Sentry ingest path that uses rust-minidump — treatfpscrasuint64_tand expect a 368-byte struct, so crashpad's output was 4 bytes short and couldn't be fully deserialized.The comment above the struct already noted that extra[8] is "included for compatibility with breakpad"; fpscr's width was the remaining divergence. Switch it to
uint64_tsosizeof(MinidumpContextARM) == 368, matching breakpad / rust-minidump.See also: