Runtime Error

[wanderer]

This happens when given any *.wasm file

Starting program: /home/null/code/WASM/sexpr-wasm-prototype/out/sexpr-wasm ../test.wasm
*** Error in `/home/null/code/WASM/sexpr-wasm-prototype/out/sexpr-wasm': realloc(): invalid pointer: 0x00007ffff7fc1548 ***
======= Backtrace: =========
/usr/lib/libc.so.6(+0x72055)[0x7ffff7aa9055]
/usr/lib/libc.so.6(+0x779a6)[0x7ffff7aae9a6]
/usr/lib/libc.so.6(realloc+0x1db)[0x7ffff7ab2d0b]
/home/null/code/WASM/sexpr-wasm-prototype/out/sexpr-wasm[0x41ccd5]
/home/null/code/WASM/sexpr-wasm-prototype/out/sexpr-wasm[0x41cd41]
/home/null/code/WASM/sexpr-wasm-prototype/out/sexpr-wasm[0x401990]
/home/null/code/WASM/sexpr-wasm-prototype/out/sexpr-wasm[0x4019ae]
/home/null/code/WASM/sexpr-wasm-prototype/out/sexpr-wasm[0x40c30f]
/home/null/code/WASM/sexpr-wasm-prototype/out/sexpr-wasm[0x40385d]
/usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7ffff7a57610]
/home/null/code/WASM/sexpr-wasm-prototype/out/sexpr-wasm[0x400ff9]
======= Memory map: ========
00400000-00431000 r-xp 00000000 08:03 9838228                            /home/null/code/WASM/sexpr-wasm-prototype/out/sexpr-wasm
00631000-00632000 rw-p 00031000 08:03 9838228                            /home/null/code/WASM/sexpr-wasm-prototype/out/sexpr-wasm
00632000-00653000 rw-p 00000000 00:00 0                                  [heap]
7ffff0000000-7ffff0021000 rw-p 00000000 00:00 0
7ffff0021000-7ffff4000000 ---p 00000000 00:00 0
7ffff7821000-7ffff7837000 r-xp 00000000 08:03 19140025                   /usr/lib/libgcc_s.so.1
7ffff7837000-7ffff7a36000 ---p 00016000 08:03 19140025                   /usr/lib/libgcc_s.so.1
7ffff7a36000-7ffff7a37000 rw-p 00015000 08:03 19140025                   /usr/lib/libgcc_s.so.1
7ffff7a37000-7ffff7bd2000 r-xp 00000000 08:03 19139726                   /usr/lib/libc-2.22.so
7ffff7bd2000-7ffff7dd1000 ---p 0019b000 08:03 19139726                   /usr/lib/libc-2.22.so
7ffff7dd1000-7ffff7dd5000 r--p 0019a000 08:03 19139726                   /usr/lib/libc-2.22.so
7ffff7dd5000-7ffff7dd7000 rw-p 0019e000 08:03 19139726                   /usr/lib/libc-2.22.so
7ffff7dd7000-7ffff7ddb000 rw-p 00000000 00:00 0
7ffff7ddb000-7ffff7dfd000 r-xp 00000000 08:03 19139725                   /usr/lib/ld-2.22.so
7ffff7fbf000-7ffff7fc2000 rw-p 00000000 00:00 0
7ffff7ff6000-7ffff7ff8000 rw-p 00000000 00:00 0
7ffff7ff8000-7ffff7ffa000 r--p 00000000 00:00 0                          [vvar]
7ffff7ffa000-7ffff7ffc000 r-xp 00000000 00:00 0                          [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 00021000 08:03 19139725                   /usr/lib/ld-2.22.so
7ffff7ffd000-7ffff7ffe000 rw-p 00022000 08:03 19139725                   /usr/lib/ld-2.22.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

Program received signal SIGABRT, Aborted.
0x00007ffff7a6a5f8 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff7a6a5f8 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff7a6ba7a in abort () from /usr/lib/libc.so.6
#2  0x00007ffff7aa905a in __libc_message () from /usr/lib/libc.so.6
#3  0x00007ffff7aae9a6 in malloc_printerr () from /usr/lib/libc.so.6
#4  0x00007ffff7ab2d0b in realloc () from /usr/lib/libc.so.6
#5  0x000000000041ccd5 in ensure_capacity (data=0x7ffffffeca98, capacity=0x7ffffffecaa8,
    desired_size=2, elt_byte_size=8) at src/wasm-vector.c:16
#6  0x000000000041cd41 in append_element (data=0x7ffffffeca98, size=0x7ffffffecaa0,
        capacity=0x7ffffffecaa8, elt_byte_size=8) at src/wasm-vector.c:28
#7  0x0000000000401990 in wasm_append_import_ptr (vec=0x7ffffffeca98) at src/wasm.c:20
#8  0x00000000004019ae in wasm_append_import_ptr_value (vec=0x7ffffffeca98, value=0x7ffffffec058)
            at src/wasm.c:20
#9  0x000000000040c30f in wasm_parse (scanner=0x632260, parser=0x7fffffffe380) at src/wasm-parser.y:1275
#10 0x000000000040385d in main (argc=2, argv=0x7fffffffe4b8) at src/sexpr-wasm.c:180

[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?

[ghost]

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!