Segfault in ctor-eval when an imported global isn't used

[stevenfontanella]

I ran /usr/local/google/home/stevenfont/code/binaryen/bin/wasm-ctor-eval /usr/local/google/home/stevenfont/code/binaryen/test/ctor-eval/basics.wast -all -o a.wat -S --ctors test1 from main with the following basics.wast:

(module
  (import "env" "asdf" (global $g i32))
  (export "test1" (func $test1))
  (func $test1
    (drop (i32.const 0))
  )
)

which segfaults with the following stack trace:

Process 2492289 stopped
* thread #1, name = 'wasm-ctor-eval', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x8)
    frame #0: 0x000055555566b453 wasm-ctor-eval`wasm::Type::operator==(this=0x0000555555752c38, other=0x0000000000000008) const at wasm-type.h:488:65
   485    // (In)equality must be defined for both Type and BasicType because it is
   486    // otherwise ambiguous whether to convert both this and other to int or
   487    // convert other to Type.
-> 488    bool operator==(const Type& other) const { return id == other.id; }
   489    bool operator==(const BasicType& other) const { return id == other; }
   490    bool operator!=(const Type& other) const { return id != other.id; }
   491    bool operator!=(const BasicType& other) const { return id != other; }
(lldb) bt
* thread #1, name = 'wasm-ctor-eval', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x8)
  * frame #0: 0x000055555566b453 wasm-ctor-eval`wasm::Type::operator==(this=0x0000555555752c38, other=0x0000000000000008) const at wasm-type.h:488:65
    frame #1: 0x000055555561a95d wasm-ctor-eval`(anonymous namespace)::CtorEvalExternalInterface::applyGlobalsToModule(this=0x00007fffffffb6e0) const at wasm-ctor-eval.cpp:583:51
    frame #2: 0x000055555561775f wasm-ctor-eval`(anonymous namespace)::CtorEvalExternalInterface::applyToModule(this=0x00007fffffffb6e0) const at wasm-ctor-eval.cpp:216:25
    frame #3: 0x000055555561c90e wasm-ctor-eval`(anonymous namespace)::evalCtor(instance=0x00007fffffffb400, interface=0x00007fffffffb6e0, funcName=Name @ 0x00007fffffffad60, exportName=Name @ 0x00007fffffffb390) at wasm-ctor-eval.cpp:1219:30
    frame #4: 0x000055555561db1c wasm-ctor-eval`(anonymous namespace)::evalCtors(wasm=0x00007fffffffbdd0, ctors=size=1, keptExports=size=0) at wasm-ctor-eval.cpp:1414:68
    frame #5: 0x000055555561f27a wasm-ctor-eval`main(argc=8, argv=0x00007fffffffd428) at wasm-ctor-eval.cpp:1572:14
    frame #6: 0x00007ffff4033ca8 libc.so.6`__libc_start_call_main(main=(wasm-ctor-eval`main at wasm-ctor-eval.cpp:1476:40), argc=8, argv=0x00007fffffffd428) at libc_start_call_main.h:58:16
    frame #7: 0x00007ffff4033d65 libc.so.6`__libc_start_main_impl(main=(wasm-ctor-eval`main at wasm-ctor-eval.cpp:1476:40), argc=8, argv=0x00007fffffffd428, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffd418) at libc-start.c:360:3
    frame #8: 0x0000555555616111 wasm-ctor-eval`_start + 33

imported-global.wast is similar but succeeds. As far as I can tell the difference is that it actually tries to read the imported global which results in a FailToEvalException. Maybe this exception is thrown before it can hit the segfaulting code?

This only happens when the import comes from the "env" module which is handled specially.

[stevenfontanella]

This is incidentally fixed by #8166, but I'm not sure why yet. I'll look some more to make sure that any underlying issue is addressed too.

[stevenfontanella]

I compiled with ASAN enabled and found that the issue is that we dereference a nullptr since init isn't set for the imported global.

It's not clear to me yet how #8166 fixes this (the direct lines affecting the function wouldn't seem to impact this at first glance). Will investigate more.