Skip to content

Fuzzer: Respect the noInvokes flag when adding interposing invokes - #9221

Merged
kripken merged 1 commit into
WebAssembly:mainfrom
kripken:fuzz.noinvoke.2
Oct 7, 2026
Merged

kripken merged 1 commit into
WebAssembly:mainfrom
kripken:fuzz.noinvoke.2

Conversation

@kripken

@kripken kripken commented Oct 6, 2026

Copy link
Copy Markdown
Member

noInvokes already stopped us from emitting new invokes. We also emit
calls to invokes, basically adding more invoke executions, by "interposing"
on exports - sticking a call in an export, where the call is to an invoke.
Respect the flag in that case too: if the user doesn't want the code growth
of invokes, they don't want either new invokes or new calls to existing
invokes.

Diff without whitespace is small (almost all comments).

cc @Liedtke

@kripken
kripken requested a review from tlively October 6, 2026 20:22
@kripken
kripken requested a review from a team as a code owner October 6, 2026 20:22

@Liedtke Liedtke left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Yes, this is the interpose call I was referring to in http://crbug.com/561837951#comment18, LGTM, so with this PR, #9214 and #9212 we should have addressed the 3 issues raised in that comment (roman I - III) IIUC. Thanks!

So on Fuzzilli side we'll need to simply add --fuzz-hang-limit=0 --fuzz-no-invokes to "materialize" these changes, is that correct?

@Liedtke

Liedtke commented Oct 7, 2026

Copy link
Copy Markdown
Contributor

As a side note, it might still be interesting to consider my proposal for the case when not calling --fuzz-no-invokes:

I. Interpose on initial exports: On every export the Binaryen fuzzer prepends it with a call that with some chance calls itself or its invoker or a previously added invoker for this function causing a trap for the recursion. My plan is to filter the function itself and its direct invoker(s).

I didn't check the order, so without repeated calls to the fuzzer this might never emit a call to its invoker (if the invoker is added after emitting the interpose call) but it might still emit a call to itself which is placed in the very beginning of the function after the hang limit check, so it will build a recursion that only executes fuzzer instrumentation but no random code when ending up recursively calling itself, so filtering out itself as a potential call target would make sense?

@kripken

kripken commented Oct 7, 2026

Copy link
Copy Markdown
Member Author

@Liedtke

Yes, --fuzz-hang-limit=0 --fuzz-no-invokes are the right flags.

About the ordering, I'm not sure, but I think we have logic to randomize the order. We generate functions and mutate them in random order, that is, to increase the chance for calls from anywhere to anywhere. What I am not sure if the interposition fits in there perfectly, I'll check.

@kripken
kripken merged commit b8e22b4 into WebAssembly:main Oct 7, 2026
16 checks passed
@kripken
kripken deleted the fuzz.noinvoke.2 branch October 7, 2026 16:09
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.

3 participants