Runtime Error about wabt

[jcbeyler]

I have a few colleagues who have seen the same thing. The solution is not entirely clear to me but @mbodart found that if you forced the definition of YY_INITIAL_VALUE to actually initialize things instead of maybe not doing it; then it seemed to work.

I have not confirmed this since I don't have an issue.

Maybe another solution is to regenerate the wasm-parser.c file that seems to be a problem but I tried to do that and my bison is not recent enough it seems (it fails).

[wanderer]

Maybe another solution is to regenerate the wasm-parser.c file

I tried with bison 3.0.4. And it does not work.

[wanderer]

I compiled and ran successfully on an ubuntu VM. The error still occurs on the host OS (Arch). I'm betting it has to do with the bison version

[binji]

I tried it on a file and just got a bunch of (expected) errors. How did you generate test.wasm?

Same problem here. Bison 3.0.2, gcc 4.9.2. Workaround noted by @jcbeyler above works.

[mbodart]

How did you generate test.wasm?

I started with the small example in README.md (which is perhaps out of date).
But here's another example:

(module
(func $test (result i32) (i32.add (i32.const 1) (i32.const 2)))
(export "test" $test))

The failure seems to be reproducible in a "known good" environment, if I simply
change the definition of YY_INITIAL_VALUE in wasm-parser.c to be empty.
(Note that I don't regenerate wasm-parser.c from wasm-parser.y.)

A quick run with valgrind points to problems in the vector append operations, e.g.

==21318== Conditional jump or move depends on uninitialised value(s)
==21318== at 0x41F2A7: ensure_capacity (wasm-vector.c:11)
==21318== by 0x41F369: append_element (wasm-vector.c:28)
==21318== by 0x4016F5: wasm_append_func_ptr (wasm.c:17)
==21318== by 0x401718: wasm_append_func_ptr_value (wasm.c:17)
==21318== by 0x40C9CC: wasm_parse (wasm-parser.y:1263)
==21318== by 0x403959: main (sexpr-wasm.c:180)

which suggests these module-level vectors are not initialized with null values
before being appended to.

Perhaps wasm-parser.y needs another surgically placed ZEROMEM?

[mbodart]

Indeed, it seems the wasm-parser.y rule for module:

module :
LPAR MODULE module_fields RPAR {
$$.loc = @2;

needs a ZEROMEM($$);

That fixed this issue for me.

[binji]

Ah, interesting. I've been running with clang's memory sanitizer, so I assume it would have caught a bug like this, but it seems not to have. Thanks for the fix!