Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fuzzer: When nested under makeTrivial(), avoid normal make() #5657

Merged
merged 5 commits into from
Apr 12, 2023

Conversation

kripken
Copy link
Member

@kripken kripken commented Apr 12, 2023

Without this, in certain complex operations we could end up calling a nested
make() operation that included nontrivial things, which could cause problems.
The specific problem I encountered was in fixAfterChanges() we tried to fix up
a duplicate label, but calling makeTrivial() emitted something very large that
happened to include a new block with a new label nested under a struct.get,
and that block's label conflicted with a label we'd already processed.

@kripken kripken requested a review from tlively April 12, 2023 17:09
@@ -1212,6 +1216,14 @@ Expression* TranslateToFuzzReader::_makeunreachable() {
}

Expression* TranslateToFuzzReader::makeTrivial(Type type) {
struct TrivialNester {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an unfortunate amount of boilerplate just to run trivialNesting-- to run at scope exit, but I couldn't find a better way to do it outside of boost.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah... other languages can do better, e.g. defer in Go and Zig.

@kripken kripken enabled auto-merge (squash) April 12, 2023 20:05
@kripken kripken merged commit 958daad into main Apr 12, 2023
@kripken kripken deleted the fuzz.nest.trivial branch April 12, 2023 20:30
radekdoulik pushed a commit to dotnet/binaryen that referenced this pull request Jul 12, 2024
…mbly#5657)

Without this, in certain complex operations we could end up calling a nested
make() operation that included nontrivial things, which could cause problems.
The specific problem I encountered was in fixAfterChanges() we tried to fix up
a duplicate label, but calling makeTrivial() emitted something very large that
happened to include a new block with a new label nested under a struct.get,
and that block's label conflicted with a label we'd already processed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants