Segfault with `valgrind(1)` and default configuration

[midokura-xavi92]

Subject of the issue

The following minimal reproducible example builds wasm-micro-runtime with the default configuration and segfaults when calling wasm_runtime_init with valgrind(1).

Test case

• Minimal reproducible example: https://github.com/midokura-xavi92/wamr-valgrind-sigsegv

Your environment

• Host OS

Linux xavier-midokura 6.8.0-52-generic #53~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jan 15 19:18:46 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

• WAMR version, platform, cpu architecture, running mode, etc.
  • c6f9344
  • Default configuration (X86_64)

Steps to reproduce

• Configure with:

cmake -B build

• Build with:

cmake --build build

• Execute with:

valgrind --leak-check=full ./build/wamr-valgrind-sigsegv

Expected behavior

No segmentation fault should occur.

Actual behavior

A segmentation fault is notified by valgrind(1):

==176051== Memcheck, a memory error detector
==176051== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==176051== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==176051== Command: ./build/wamr-valgrind-sigsegv
==176051== 
==176051== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==176051== 
==176051== Process terminating with default action of signal 11 (SIGSEGV)
==176051==  Access not within mapped region at address 0x1FFE801FFF
==176051== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==176051==    at 0x128F50: touch_pages (in /home/xavier/wamr-valgrind-sigsegv/build/wamr-valgrind-sigsegv)
==176051==  If you believe this happened as a result of a stack
==176051==  overflow in your program's main thread (unlikely but
==176051==  possible), you can try to increase the size of the
==176051==  main thread stack using the --main-stacksize= flag.
==176051==  The main thread stack size used in this run was 8388608.
==176051== 
==176051== HEAP SUMMARY:
==176051==     in use at exit: 96 bytes in 3 blocks
==176051==   total heap usage: 14 allocs, 11 frees, 11,384 bytes allocated
==176051== 
==176051== LEAK SUMMARY:
==176051==    definitely lost: 0 bytes in 0 blocks
==176051==    indirectly lost: 0 bytes in 0 blocks
==176051==      possibly lost: 0 bytes in 0 blocks
==176051==    still reachable: 96 bytes in 3 blocks
==176051==         suppressed: 0 bytes in 0 blocks
==176051== Reachable blocks (those to which a pointer was found) are not shown.
==176051== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==176051== 
==176051== For lists of detected and suppressed errors, rerun with: -s
==176051== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

Extra Info

N/A.

[lum1n0us]

==176051== Stack overflow in thread #1: can't grow stack to 0x1ffe801000

From my experience, it's necessary to

• disable hardware-boundary-check, by set(WAMR_DISABLE_HW_BOUND_CHECK 1)
• disable using GS register, by set(WAMR_DISABLE_WRITE_GS_BASE 1)

when operating with Valgrind.

[midokura-xavi92]

Thanks for your feedback. Then, I think this should be reflected by the documentation accordingly - the use of valgrind(1) is common among Linux users and finding out that WAMR_DISABLE_HW_BOUND_CHECK and WAMR_DISABLE_WRITE_GS_BASE must be disabled in such circumstances is far from trivial.