Trap's message "note" is a bit misleading

[srenatus]

Without any env vars set, I get this:

wasm trap: out of bounds memory access
wasm backtrace:
    0: 0x4f3d - <unknown>!opa_value_length
    1: 0x2528 - <unknown>!opa_json_writer_emit_set_literal
    2: 0x22c7 - <unknown>!opa_json_writer_emit_value
    3: 0x27bc - <unknown>!opa_json_writer_write
    4: 0x28f8 - <unknown>!opa_value_dump
    5:  0x791 - <unknown>!opa_eval
note: run with `WASMTIME_BACKTRACE_DETAILS=1` environment variable to display more information

Setting WASMTIME_BACKTRACE_DETAILS=1, I get the same message without the note:

wasm trap: out of bounds memory access
wasm backtrace:
    0: 0x4f3d - <unknown>!opa_value_length
    1: 0x2528 - <unknown>!opa_json_writer_emit_set_literal
    2: 0x22c7 - <unknown>!opa_json_writer_emit_value
    3: 0x27bc - <unknown>!opa_json_writer_write
    4: 0x28f8 - <unknown>!opa_value_dump
    5:  0x791 - <unknown>!opa_eval

Another nitpick is the comment on Message,

wasmtime-go/trap.go

Lines 48 to 49 in ef5be5d

	// Message returns the name in the module this export type is exporting
	func (t *Trap) Message() string {

doesn't seem quite correct 🤔

[alexcrichton]

The message about WASMTIME_BACKTRACE_DETAILS comes from wasmtime itself, and currently it's pretty naive. It basically recognizes that there are unparsed dwarf sections in a wasm module, and prints this message if that is the case. Currently there's no logic along the lines of "we know this backtrace specifically could be improved, so set the env var". Being able to deduce that would require parsing the dwarf sections in the first place which we try to not do by default!

Perhaps a better wording of the message though? Basically say that it "may" improve the backtrace?

Out of curiosity, how are you generating your wasm module? I'm curious why it has some debug information for functions but not for all functions.

[srenatus]

It basically recognizes that there are unparsed dwarf sections in a wasm module, and prints this message if that is the case.

Ah, thanks, I wasn't aware. 💡

Basically say that it "may" improve the backtrace?

Hmm, seems a bit petty of me to request such a change -- but yeah, I suppose this would have kept my eye brows down here 😅 But really, it's not important. I've learnt something discussing this with you, thanks for indulging me.

Out of curiosity, how are you generating your wasm module? I'm curious why it has some debug information for functions but not for all functions.

I'm mostly working with wasm emitted from OPA, compiling policies into wasm modules (docs here). It's built from a portion that doesn't depend on the policy in question, C/C++ compiled to wasm via llvm-12, and a bunch of functions compiled from the policy document through a compiler written in Go. The former may contain dwarf sections (but usually doesn't); the latter will not have them.

I might be able to answer this myself digging through the code, but you probably just know -- which sections should I be on the lookout for here? The modules I've been interacting with recently never had dwarf sections in their C/C++ bits 🤔

[alexcrichton]

Ah ok then it's probably the C/C++ and/or the standard library for C/C++ which has dwarf info for some unrelated functions in your case.

You can use wasm-objdump -h I think to print out section names, and dwarf debug information is in custom sections named .debug_*

[srenatus]

Thanks for elaborating.

dwarf debug information is in custom sections named .debug_*

I thought I didn't have any of those, usually. I'll double-check this. 🔍

[srenatus]

So, I've put together a wasm module that consists of both parts I've described above: custom-built wasm functions, and a C/C++ base.

Its sections are

     Type start=0x0000000b end=0x000000db (size=0x000000d0) count: 27
   Import start=0x000000dd end=0x0000015b (size=0x0000007e) count: 7
 Function start=0x0000015e end=0x00000409 (size=0x000002ab) count: 681
    Table start=0x0000040b end=0x00000410 (size=0x00000005) count: 1
   Global start=0x00000412 end=0x00000424 (size=0x00000012) count: 3
   Export start=0x00000427 end=0x000005b5 (size=0x0000018e) count: 21
    Start start=0x000005b7 end=0x000005b9 (size=0x00000002) start: 686
     Elem start=0x000005bc end=0x00000659 (size=0x0000009d) count: 2
     Code start=0x0000065d end=0x0000df3b (size=0x0000d8de) count: 681
     Data start=0x0000df3f end=0x0001b800 (size=0x0000d8c1) count: 5
   Custom start=0x0001b803 end=0x0001c347 (size=0x00000b44) "name"
   Custom start=0x0001c349 end=0x0001c3ad (size=0x00000064) "producers"

So, there's nothing dwarf-related in it. I've modified our compiler to toss an unreachable in the eval function, so I can trigger this trap:

$ wasmtime run --preload env=env.wat policy.wasm --invoke eval 10
warning: using `--invoke` with a function that takes arguments is experimental and may break in the future
Error: failed to run main module `policy.wasm`

Caused by:
    0: failed to invoke `eval`
    1: wasm trap: unreachable
       wasm backtrace:
           0: 0xde9c - <unknown>!eval
       note: run with `WASMTIME_BACKTRACE_DETAILS=1` environment variable to display more information

☝️ This has the "more information" message although there aren't any dwarf sections. I must be missing something 🤔

When trying to compile a MWE for this, I've noticed that when I convert the policy.wasm to .wat, the "more information" message disappears. Anyways, here's my files: https://github.com/srenatus/scratch-demo-trap

[alexcrichton]

er oops, that's a bug!

[alexcrichton]

Ok and with that most recent PR I think this is good to say it's fixed, thanks again for the report!