Wamr Loader/GC giving a type mismatch failure

[nickbetteridge]

I'm too sure whether the issue I'm having is with the ocaml wasm compiler or with the bytecodealliance's runtime (wamr).

I've wrote a simple ocaml program:

let _ = Printf.printf "Hello")

compiled it with:

ocamlfind ocamlc -package js_of_ocaml -linkpkg -o hello.byte hello.ml

generated the wasm:

wasm_of_ocaml hello.byte

After building the wamr runtime with the following flags ...

-DWAMR_BUILD_TAIL_CALL=1
-DWAMR_BUILD_EXCE_HANDLING=1
-DWAMR_BUILD_GC=1

... I was able to run a simple wasm file generated from C.

When attempting to run the ocaml wasm file I got the following error:

WASM module load failed: type mismatch: expect (ref ht) but got other

So, could anyone suggest possible ways for me to narrow down the cause of the error?

[vouillon]

I think I fixed this issue in bytecodealliance/wasm-micro-runtime#4075.

But the implementation of the GC proposal in WAMR is partial and not sufficient to run programs produced by wasm_of_ocaml. I have just reopened an issue: bytecodealliance/wasm-micro-runtime#4190

[nickbetteridge]

Ah, sorry - you're right, I was using an older commit.

However, I rebuilt and this time got a unhandled SIGSEGV, si_addr: 0x575800000002 - it does seem to be fragile

What's the best way of debugging this? Perhaps I should just raise a new issue on bytecodealliance/wasm-micro-runtime?

[vouillon]

You can get a backtrace by running it with gdb:

gdb --args ~/sources/wasm-micro-runtime/product-mini/platforms/linux/build/iwasm hello.assets/code*.wasm

It seems it fails because the Wasm module is not a WASI module, and then crashes while trying to unload the module. You can raise an issue on bytecodealliance/wasm-micro-runtime, indeed. By the way, if you want to produce WASI modules (which do not depend on some JavaScript helper code), you should use #1831 and compile using the --enable wasi option.

0x000055555567bb68 in destroy_init_expr_data_recursive (module=0x55555574d340, 
    data=0x555500000005)
    at /home/jerome/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_loader.c:509
509	    wasm_type = module->types[struct_init_values->type_idx];
(gdb) bt
#0  0x000055555567bb68 in destroy_init_expr_data_recursive (
    module=0x55555574d340, data=0x555500000005)
    at /home/jerome/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_loader.c:509
#1  0x000055555567bd7a in destroy_init_expr_data_recursive (
    module=0x55555574d340, data=0x55555577f790)
    at /home/jerome/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_loader.c:552
#2  0x000055555567bc72 in destroy_init_expr_data_recursive (
    module=0x55555574d340, data=0x55555577f970)
    at /home/jerome/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_loader.c:535
#3  0x00005555556a5f7d in destroy_init_expr (module=<optimized out>, 
    expr=<optimized out>)
    at /home/jerome/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_loader.c:647
#4  destroy_init_expr (module=<optimized out>, expr=<optimized out>)
    at /home/jerome/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_loader.c:642
#5  wasm_loader_unload (module=0x55555574d340)
    at /home/jerome/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_loader.c:6889
#6  0x00005555556a69ac in wasm_loader_load (buf=buf@entry=0x7ffff7e56010 "", 
    size=size@entry=167172, args=args@entry=0x7fffffffd580, 
    error_buf=error_buf@entry=0x7fffffffd8f0 "WASM module load failed: a module with WASI apis must export memory by default", 
    error_buf_size=error_buf_size@entry=128)
    at /home/jerome/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_loader.c:6794

[nickbetteridge]

Thanks for the above! Yes, after building the wasi branch, array as a field in struct object is definitely a show stopper - I'll add frustration to 4190. Thanks again for your help