Repository navigation
Keep the expression decoder's frames small when optimized (Covered by… - #653
Merged
brianegge merged 1 commit intoOct 4, 2026
Merged
Conversation
… dco/Brian_Egge.md) OSS-Fuzz issue 569129860: stack-overflow in hobbes::decode, reached from fuzz-type-decode through a TExpr. The expression decoder splits each node kind into its own function so that the frame that recurs per nesting level only holds that kind's locals, but each of those functions has a single caller, and an optimizing build inlined them all back into decode(). Under the OSS-Fuzz build (-O1 with ASan) that frame was 3.6KB, so the 2000 levels maxDecodeNesting allows needed about 7MB of stack, and ClusterFuzz ran out before the bound was reached. Mark the per-kind decoders noinline. decode() is now 224 bytes of ASan frame and the recurring path well under 1KB a level, so a description at the bound decodes in under 1MB of stack in that build. Adds the ClusterFuzz testcase to the type-decode corpus, and a test that decodes a description at the nesting bound on a thread with a small stack (2MB, or 4MB under ASan); it overflows on the unfixed code in the OSS-Fuzz build configuration. Also documents in AGENTS.md how to set up a build on Ubuntu 24.04 (including cloud agent containers) and macOS, and how to reproduce an OSS-Fuzz crash. Old bug, present since the first OSS-Fuzz build; not a regression. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018Y1u5Q3rXMvtPYL8eGktgn
bingenito
approved these changes
Oct 4, 2026
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.
OSS-Fuzz issue 569129860: stack-overflow in hobbes::decode, reached from fuzz-type-decode through a TExpr. The expression decoder splits each node kind into its own function so that the frame that recurs per nesting level only holds that kind's locals, but each of those functions has a single caller, and an optimizing build inlined them all back into decode(). Under the OSS-Fuzz build (-O1 with ASan) that frame was 3.6KB, so the 2000 levels maxDecodeNesting allows needed about 7MB of stack, and ClusterFuzz ran out before the bound was reached.
Mark the per-kind decoders noinline. decode() is now 224 bytes of ASan frame and the recurring path well under 1KB a level, so a description at the bound decodes in under 1MB of stack in that build.
Adds the ClusterFuzz testcase to the type-decode corpus, and a test that decodes a description at the nesting bound on a thread with a small stack (2MB, or 4MB under ASan); it overflows on the unfixed code in the OSS-Fuzz build configuration.
Also documents in AGENTS.md how to set up a build on Ubuntu 24.04 (including cloud agent containers) and macOS, and how to reproduce an OSS-Fuzz crash.
Old bug, present since the first OSS-Fuzz build; not a regression.
Claude-Session: https://claude.ai/code/session_018Y1u5Q3rXMvtPYL8eGktgn