-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
cranelift-fuzzgen fuzzbug: "interpreter failed: Error(StepError(UnknownFunction(fn0)))" #4758
Comments
Formatted:
I think this was introduced in #4155, and at the time I didn't think it would cause issues. I think the optimal fix for this is #4667 and subsequently adding support for generating multiple functions in fuzzgen (and ensuring that we only produce valid references). That way we don't have to disable important features for the |
Oh! I was just looking at that part of the function generator last week, and wondering how that ever worked. I didn't realize it was introduced in the icache PR. |
@bnjbvr and @cfallin: The incremental cache PR added support to cranelift_fuzzgen for generating random function calls. This is fine for the icache fuzz target which only compiles functions, so it doesn't care if the target of the call exists. But the fuzzgen target tries to run the generated functions so it needs the callee to exist. How important is testing function calls to our confidence that the incremental cache is working? If we just turn off that part of the function generator, would that significantly reduce our confidence that we can detect bugs in the incremental cache? Maybe we can parameterize the function generator over a list of other functions and libcalls that it can use. In the fuzzgen target we'd currently pass an empty list, and as work like #4667 develops we can add support there later. Then we'd move the current implementation of |
One of my main worries with a previous version of the incremental cache PR was that it would misbehave around function calls, so I did say pretty important. |
I think we should be able to disable function calls by altering the |
Yes, one of two (IIRC?) ways that we are "resilient" in the incremental cache is when specific function references change but the shape of the CLIF remains the same; so we definitely want to test this. Luckily it sounds from above like it's pretty easy to parameterize this differently in different fuzz targets! |
This has the same issue as the other PR's that it changes the input format, so we won't be able to merge it, but its a pretty easy solution for now. |
This fixes bytecodealliance#4757, fixes bytecodealliance#4758, and fixes new fuzzbugs that are probably coming after we merged bytecodealliance#4667.
OSS-Fuzz: https://oss-fuzz.com/testcase-detail/4625103710715904
input:
cc @afonso360
The text was updated successfully, but these errors were encountered: