Crash in SymbolTable::EnsureUnique when name is empty

[thisismiller]

This appears to be caused by the &name[0] in SymbolTable::EnsureUnique while running wat2wasm.

#5  0x000055555556d581 in std::basic_string_view<char, std::char_traits<char> >::operator[] (this=<optimized out>, 
    __pos=<optimized out>) at /usr/include/c++/14/string_view:254
#6  std::basic_string_view<char, std::char_traits<char> >::operator[] (this=0x7fffffffc9f0, __pos=0)
    at /usr/include/c++/14/string_view:254
#7  wabt::(anonymous namespace)::SymbolTable::EnsureUnique (this=this@entry=0x7fffffffcec8, name="")
    at /usr/src/debug/wabt-1.0.36-1.fc41.x86_64/src/binary-writer.cc:236
#8  0x000055555557098a in wabt::(anonymous namespace)::SymbolTable::AddSymbol<wabt::(anonymous namespace)::Symbol::Function> (this=<optimized out>, map=<optimized out>, name="", imported=<optimized out>, exported=<optimized out>, sym=...)
    at /usr/src/debug/wabt-1.0.36-1.fc41.x86_64/src/binary-writer.cc:269
#9  wabt::(anonymous namespace)::SymbolTable::Populate (this=this@entry=0x7fffffffcec8, module=<optimized out>)
    at /usr/src/debug/wabt-1.0.36-1.fc41.x86_64/src/binary-writer.cc:324
#10 0x0000555555576a77 in wabt::(anonymous namespace)::BinaryWriter::WriteModule (this=0x7fffffffceb0)
    at /usr/src/debug/wabt-1.0.36-1.fc41.x86_64/src/binary-writer.cc:1317
#11 0x000055555556a2a0 in wabt::WriteBinaryModule (options=..., stream=0x7fffffffce80, module=<optimized out>)
    at /usr/src/debug/wabt-1.0.36-1.fc41.x86_64/src/binary-writer.cc:1812
#12 ProgramMain (argc=<optimized out>, argv=<optimized out>)
    at /usr/src/debug/wabt-1.0.36-1.fc41.x86_64/src/tools/wat2wasm.cc:155
#13 0x00007ffff7a10248 in __libc_start_call_main (main=main@entry=0x555555555fa0 <main(int, char**)>, argc=argc@entry=5, 
    argv=argv@entry=0x7fffffffd4e8) at ../sysdeps/nptl/libc_start_call_main.h:58
#14 0x00007ffff7a1030b in __libc_start_main_impl (main=0x555555555fa0 <main(int, char**)>, argc=5, argv=0x7fffffffd4e8, 
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd4d8)
    at ../csu/libc-start.c:360
#15 0x0000555555562e65 in _start ()

This is reproducible by running wast2json on block.wast from the spec, and then doing wasm2wat block.0.wasm -o block.0.wat && wat2wasm -r block.0.wat -o block.0.wasm

[sbc100]

The -r flag was never very well used to tested. Do you have a good use case for it? If not I'm tempted to instead just remove it since there are very little wabt maintenance going on these days.

[thisismiller]

I'm trying to figure out a way to run the spec tests which doesn't involve building support for assert_result, assert_trap, assert_invalid nor assert_malformed. wast2json to break the module by test, and then emitting a main/_start and linking the two together per test gives an easy way to avoid doing that by pushing most of the work into some python script. That linking means calling wasm-ld, which needs a relocatable wasm file. It turns out that an easier way to reproduce this is just wast2json -r block.wast.

So, working -r support would be an easier workaround than writing a spectest parser myself to essentially re-do wast2json but make executable wasm modules per assertion. But I'll pre-emptively agree that this is roughly just trying to abuse existing tools, and that writing my own parser is probably what I should do.

[sbc100]

I see. I guess that alternatives would be:

(a) Use more than one wasm module and have the runtime link time (i.e. start.wasm / assertions.wasm / <test_name>.wasm)
(b) Somehow inject the support code using use a script of some kind `./inject.sh start.wat assertsion.wat < test_name.wat > test_name_modified.wat

I actually think one of those two options would probably make more sense than trying to involve wasm-ld, which itself adds all kind of things (e.g. __indirect_function_table and memory) that will likely make the test hard to run and debug (and generally more complex than the original wat file).