ASSERTION FAILED at wasm-micro-runtime/core/iwasm/interpreter/wasm_runtime.c, line 3020

[Q1IQ]

Current State

Run the following command:

iwasm --interp -f test test.wasm

Observed output:

[00:30:43:039 - 7FAC87DBCEC0]: 
ASSERTION FAILED: offset_flag == INIT_EXPR_TYPE_GET_GLOBAL || offset_flag == INIT_EXPR_TYPE_FUNCREF_CONST || offset_flag == INIT_EXPR_TYPE_REFNULL_CONST || is_valid_i32_offset(offset_flag), at file /work/harnesses/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_runtime.c, line 3020

Original Command (For Reference)

The full command that triggered this issue:

/work/harnesses/binaries/iwasm --interp -f test test.wasm

GDB Backtrace

warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[00:30:43:499 - 7F73C1A2AEC0]: 
ASSERTION FAILED: offset_flag == INIT_EXPR_TYPE_GET_GLOBAL || offset_flag == INIT_EXPR_TYPE_FUNCREF_CONST || offset_flag == INIT_EXPR_TYPE_REFNULL_CONST || is_valid_i32_offset(offset_flag), at file /work/harnesses/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_runtime.c, line 3020


Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140135146630848) at ./nptl/pthread_kill.c:44
44	./nptl/pthread_kill.c: No such file or directory.
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140135146630848) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140135146630848) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140135146630848, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007f73c1a92476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007f73c1a787f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x000055fc1a55e7bc in bh_assert_internal (v=<optimized out>, file_name=<optimized out>, file_name@entry=0x55fc1a66ed40 "/work/harnesses/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_runtime.c", line_number=line_number@entry=3020, expr_string=<optimized out>, expr_string@entry=0x55fc1a670340 "offset_flag == INIT_EXPR_TYPE_GET_GLOBAL || offset_flag == INIT_EXPR_TYPE_FUNCREF_CONST || offset_flag == INIT_EXPR_TYPE_REFNULL_CONST || is_valid_i32_offset(offset_flag)") at /work/harnesses/sources/wasm-micro-runtime/core/shared/utils/bh_assert.c:24
#6  0x000055fc1a5771a0 in wasm_instantiate (module=module@entry=0x515000000080, parent=parent@entry=0x0, exec_env_main=exec_env_main@entry=0x0, args=args@entry=0x5020000001d0, error_buf=error_buf@entry=0x7ffc74d50c90 "unknown import or incompatible import type", error_buf_size=error_buf_size@entry=128) at /work/harnesses/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_runtime.c:3020
#7  0x000055fc1a5646d5 in wasm_runtime_instantiate_internal (module=module@entry=0x515000000080, parent=parent@entry=0x0, exec_env_main=exec_env_main@entry=0x0, args=0x5020000001d0, error_buf=error_buf@entry=0x7ffc74d50c90 "unknown import or incompatible import type", error_buf_size=error_buf_size@entry=128) at /work/harnesses/sources/wasm-micro-runtime/core/iwasm/common/wasm_runtime_common.c:1632
#8  0x000055fc1a564824 in wasm_runtime_instantiate_ex2 (module=module@entry=0x515000000080, args=<optimized out>, error_buf=error_buf@entry=0x7ffc74d50c90 "unknown import or incompatible import type", error_buf_size=error_buf_size@entry=128) at /work/harnesses/sources/wasm-micro-runtime/core/iwasm/common/wasm_runtime_common.c:1722
#9  0x000055fc1a55d8d8 in main (argc=<optimized out>, argv=<optimized out>) at /work/harnesses/sources/wasm-micro-runtime/product-mini/platforms/linux/../posix/main.c:979
A debugging session is active.

	Inferior 1 [process 3872202] will be killed.

Quit anyway? (y or n) [answered Y; input not from terminal]

Reproduction steps

1. Save the attached WASM file: test.wasm
2. Run the command:

iwasm --interp -f test test.wasm

test1.wasm.txt

IWASM Version or Commit you used

Commit: 4b42cfd
Version: iwasm 2.4.3

Operating system information

Ubuntu 20.04

Hardware Architecture

amd64 (x86_64)

[lum1n0us]

IIUC, it is only reproducible with a debug build. With a release build, an exception will be raised, such as: Exception: out of bounds table access. Therefore, this is an invalid wasm. May I ask about your expectations for this scenario?

[Q1IQ]

Thanks for the explanation. I understand that the WASM is invalid, but the difference between debug and release behaviors still seems unintended. Ideally, both builds should surface the same failure mode for the same input.

[Q1IQ]

The CMake options I used for the build, FYI:

cmake -DCMAKE_BUILD_TYPE=Debug \
          -DCMAKE_C_COMPILER=gcc \
          -DCMAKE_CXX_COMPILER=g++ \
          -DCMAKE_C_FLAGS="-g -O1 -fno-omit-frame-pointer" \
          -DCMAKE_CXX_FLAGS="-g -O1 -fno-omit-frame-pointer" \
          -DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address -fno-sanitize=leak" \
          -DWAMR_BUILD_INTERP=1 \
          -DWAMR_BUILD_FAST_INTERP=1 \
          -DWAMR_BUILD_FAST_JIT=0 \
          -DWAMR_BUILD_JIT=0 \
          -DWAMR_BUILD_AOT=0 \
          -DWAMR_BUILD_SIMD=1 \
          -DWAMR_BUILD_REF_TYPES=1 \
          -DWAMR_BUILD_BULK_MEMORY=1 \
          -DWAMR_BUILD_SHARED_MEMORY=1 \
          -DWAMR_BUILD_TAIL_CALL=1 \
          -DWAMR_BUILD_MULTI_MODULE=1 \
          -DWAMR_BUILD_MEMORY64=1 \
          -DWAMR_BUILD_GC=1 

[Q1IQ]

IIUC, it is only reproducible with a debug build. With a release build, an exception will be raised, such as: Exception: out of bounds table access. Therefore, this is an invalid wasm. May I ask about your expectations for this scenario?

May I check whether this type of issue is something the team is interested in? Previously, similar assertion-related problems such as #3839, #4115 and
#3883 were fixed. I am wondering if this case falls into the same category and whether further investigation would be helpful.

[lum1n0us]

Those are all incorrect assertions. Taking #3883 as an example, the SGX-specific implementation will ignore the MMAP_MAP_32BIT flags and break the low region assumption.