Internal UTF / Python error in fuzzer about binaryen HOT 10 CLOSED

I'm working on a fix, btw.

from binaryen.

It's valid WTF-8, but it's not valid UTF-8 because the first code point is a surrogate.

from binaryen.

Should we avoid emitting that in the fuzzer, then? Or if we do want to fuzz it, should we escape it somehow when printing the string?

from binaryen.

It would be good to escape it in the fuzz output, I think. In general it's important to be fuzzing with strings that are not valid unicode.

from binaryen.

I'm not sure how to fix this in the fuzzer specifically, because the fuzzer isn't able to read the output from wasm-opt --fuzz-exec. We could do it in the Literal printing logic for strings, which is what the fuzzer is reading, though I'm not sure if that would affect roundtripping - what do you think?

Btw I see this constantly now when I fuzz - several times a day at least. I'm reverting #6430 locally in order to be able to continue to fuzz for now.

from binaryen.

There's no way to round trip the fuzz exec output anyway, so I think any kind of escaping we can do both in C++ and in the JS fuzz wrapper should be fine, right?

from binaryen.

Fuzz exec output is just showing the output of printing a Literal. We do use the printed output of Literals in the text format as well, which we do need to roundtrip. Are you suggesting that --fuzz-exec mode should have custom printing code instead, something like that?

from binaryen.

For strings, at least, the way we print them in Print.cpp is unrelated to how we print them when they are Literals. We essentially already have that custom printing code.

from binaryen.

Am I misreading the code, then?

That does o << curr->value using a std::ostream and a Literal, so I think it uses the same Literal printing as --fuzz-exec, which is here:

?

from binaryen.

StringConst != Const!

from binaryen.