fix: Crash (Load access fault) when indexing chapters containing characters unsupported by bold/italic font variants#997
Merged
daveallie merged 1 commit intocrosspoint-reader:masterfrom Feb 19, 2026
Conversation
…cters unsupported by bold/italic font variants
Contributor
Author
|
If anyone wants to take a look at the serial log: |
daveallie
approved these changes
Feb 19, 2026
Member
daveallie
left a comment
daveallie
left a comment
There was a problem hiding this comment.
Good find, thanks for this!
daveallie
pushed a commit
that referenced
this pull request
Feb 19, 2026
…acters unsupported by bold/italic font variants (#997) ## Summary * **What is the goal of this PR?** I flashed the last revision before commit f1740db, and chapter indexing worked without any crashes. After applying f1740db, the same chapter consistently triggered a device reboot during indexing. The affected chapter contains inline equation images surrounded by styled (bold/italic) text that includes special math/symbol characters. ## Additional Context Prior to f1740db, both `getTextAdvanceX()` and `getSpaceWidth()` always measured text using `EpdFontFamily::REGULAR`, regardless of the actual style. Commit f1740db improved correctness by passing the active style so spacing is calculated using the actual bold/italic font variant. However, bold and italic variants have narrower Unicode coverage than the regular font. When a character exists in the regular font but not in the selected styled variant, `pdFont::getGlyph()` returns `nullptr`. The updated measurement functions did not check for this and immediately dereferenced the pointer: `width += font.getGlyph(cp, style)->advanceX; // nullptr->advanceX` Because `advanceX` is located at byte offset 2 within `EpdGlyph`, dereferencing a null pointer caused the CPU to attempt a load from address `0x00000002`, resulting in a RISC-V: Load access fault MCAUSE = 5 MTVAL = 2 ## Fix Added null-safety checks to both `getTextAdvanceX()` and `getSpaceWidth()`, following the same pattern used in the rendering path: If the glyph is missing in the selected style → fall back to the replacement glyph. If the replacement glyph is also unavailable → treat the character as zero-width. This preserves the improved style-correct spacing while preventing crashes. No behavioral changes occur for characters that are supported by the selected font variant. --- ### AI Usage Did you use AI tools to help write this code? _**< YES >**_ I encounter this bug while testing 1.1.0 RC. I pasted the serial log to Claude, which identify the bug and fixed it. I can confirm now the chapter in question is indexed and loaded correctly.
saslv
pushed a commit
to saslv/crosspoint-reader
that referenced
this pull request
Feb 19, 2026
…acters unsupported by bold/italic font variants (crosspoint-reader#997) ## Summary * **What is the goal of this PR?** I flashed the last revision before commit f1740db, and chapter indexing worked without any crashes. After applying f1740db, the same chapter consistently triggered a device reboot during indexing. The affected chapter contains inline equation images surrounded by styled (bold/italic) text that includes special math/symbol characters. ## Additional Context Prior to f1740db, both `getTextAdvanceX()` and `getSpaceWidth()` always measured text using `EpdFontFamily::REGULAR`, regardless of the actual style. Commit f1740db improved correctness by passing the active style so spacing is calculated using the actual bold/italic font variant. However, bold and italic variants have narrower Unicode coverage than the regular font. When a character exists in the regular font but not in the selected styled variant, `pdFont::getGlyph()` returns `nullptr`. The updated measurement functions did not check for this and immediately dereferenced the pointer: `width += font.getGlyph(cp, style)->advanceX; // nullptr->advanceX` Because `advanceX` is located at byte offset 2 within `EpdGlyph`, dereferencing a null pointer caused the CPU to attempt a load from address `0x00000002`, resulting in a RISC-V: Load access fault MCAUSE = 5 MTVAL = 2 ## Fix Added null-safety checks to both `getTextAdvanceX()` and `getSpaceWidth()`, following the same pattern used in the rendering path: If the glyph is missing in the selected style → fall back to the replacement glyph. If the replacement glyph is also unavailable → treat the character as zero-width. This preserves the improved style-correct spacing while preventing crashes. No behavioral changes occur for characters that are supported by the selected font variant. --- ### AI Usage Did you use AI tools to help write this code? _**< YES >**_ I encounter this bug while testing 1.1.0 RC. I pasted the serial log to Claude, which identify the bug and fixed it. I can confirm now the chapter in question is indexed and loaded correctly.
el
pushed a commit
to el/crosspoint-reader
that referenced
this pull request
Feb 19, 2026
…acters unsupported by bold/italic font variants (crosspoint-reader#997) ## Summary * **What is the goal of this PR?** I flashed the last revision before commit f1740db, and chapter indexing worked without any crashes. After applying f1740db, the same chapter consistently triggered a device reboot during indexing. The affected chapter contains inline equation images surrounded by styled (bold/italic) text that includes special math/symbol characters. ## Additional Context Prior to f1740db, both `getTextAdvanceX()` and `getSpaceWidth()` always measured text using `EpdFontFamily::REGULAR`, regardless of the actual style. Commit f1740db improved correctness by passing the active style so spacing is calculated using the actual bold/italic font variant. However, bold and italic variants have narrower Unicode coverage than the regular font. When a character exists in the regular font but not in the selected styled variant, `pdFont::getGlyph()` returns `nullptr`. The updated measurement functions did not check for this and immediately dereferenced the pointer: `width += font.getGlyph(cp, style)->advanceX; // nullptr->advanceX` Because `advanceX` is located at byte offset 2 within `EpdGlyph`, dereferencing a null pointer caused the CPU to attempt a load from address `0x00000002`, resulting in a RISC-V: Load access fault MCAUSE = 5 MTVAL = 2 ## Fix Added null-safety checks to both `getTextAdvanceX()` and `getSpaceWidth()`, following the same pattern used in the rendering path: If the glyph is missing in the selected style → fall back to the replacement glyph. If the replacement glyph is also unavailable → treat the character as zero-width. This preserves the improved style-correct spacing while preventing crashes. No behavioral changes occur for characters that are supported by the selected font variant. --- ### AI Usage Did you use AI tools to help write this code? _**< YES >**_ I encounter this bug while testing 1.1.0 RC. I pasted the serial log to Claude, which identify the bug and fixed it. I can confirm now the chapter in question is indexed and loaded correctly.
lukestein
pushed a commit
to lukestein/crosspoint-reader
that referenced
this pull request
Feb 20, 2026
…acters unsupported by bold/italic font variants (crosspoint-reader#997) ## Summary * **What is the goal of this PR?** I flashed the last revision before commit f1740db, and chapter indexing worked without any crashes. After applying f1740db, the same chapter consistently triggered a device reboot during indexing. The affected chapter contains inline equation images surrounded by styled (bold/italic) text that includes special math/symbol characters. ## Additional Context Prior to f1740db, both `getTextAdvanceX()` and `getSpaceWidth()` always measured text using `EpdFontFamily::REGULAR`, regardless of the actual style. Commit f1740db improved correctness by passing the active style so spacing is calculated using the actual bold/italic font variant. However, bold and italic variants have narrower Unicode coverage than the regular font. When a character exists in the regular font but not in the selected styled variant, `pdFont::getGlyph()` returns `nullptr`. The updated measurement functions did not check for this and immediately dereferenced the pointer: `width += font.getGlyph(cp, style)->advanceX; // nullptr->advanceX` Because `advanceX` is located at byte offset 2 within `EpdGlyph`, dereferencing a null pointer caused the CPU to attempt a load from address `0x00000002`, resulting in a RISC-V: Load access fault MCAUSE = 5 MTVAL = 2 ## Fix Added null-safety checks to both `getTextAdvanceX()` and `getSpaceWidth()`, following the same pattern used in the rendering path: If the glyph is missing in the selected style → fall back to the replacement glyph. If the replacement glyph is also unavailable → treat the character as zero-width. This preserves the improved style-correct spacing while preventing crashes. No behavioral changes occur for characters that are supported by the selected font variant. --- ### AI Usage Did you use AI tools to help write this code? _**< YES >**_ I encounter this bug while testing 1.1.0 RC. I pasted the serial log to Claude, which identify the bug and fixed it. I can confirm now the chapter in question is indexed and loaded correctly.
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
2 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.
Summary
I flashed the last revision before commit f1740db, and chapter indexing worked without any crashes.
After applying f1740db, the same chapter consistently triggered a device reboot during indexing.
The affected chapter contains inline equation images surrounded by styled (bold/italic) text that includes special math/symbol characters.
Additional Context
Prior to f1740db, both
getTextAdvanceX()andgetSpaceWidth()always measured text usingEpdFontFamily::REGULAR, regardless of the actual style.Commit f1740db improved correctness by passing the active style so spacing is calculated using the actual bold/italic font variant.
However, bold and italic variants have narrower Unicode coverage than the regular font. When a character exists in the regular font but not in the selected styled variant,
pdFont::getGlyph()returnsnullptr.The updated measurement functions did not check for this and immediately dereferenced the pointer:
width += font.getGlyph(cp, style)->advanceX; // nullptr->advanceXBecause
advanceXis located at byte offset 2 withinEpdGlyph, dereferencing a null pointer caused the CPU to attempt a load from address0x00000002, resulting in a RISC-V:Load access fault
MCAUSE = 5
MTVAL = 2
Fix
Added null-safety checks to both
getTextAdvanceX()andgetSpaceWidth(), following the same pattern used in the rendering path:If the glyph is missing in the selected style → fall back to the replacement glyph.
If the replacement glyph is also unavailable → treat the character as zero-width.
This preserves the improved style-correct spacing while preventing crashes.
No behavioral changes occur for characters that are supported by the selected font variant.
AI Usage
Did you use AI tools to help write this code? < YES >
I encounter this bug while testing 1.1.0 RC.
I pasted the serial log to Claude, which identify the bug and fixed it. I can confirm now the chapter in question is indexed and loaded correctly.