Componentize Debug Builds

[MendyBerger]

First: Thanks for this amazing project! I've been using it a lot lately and it's really a joy!

I'd love to be able to get debug builds out of Jco. I've ran into multiple cases where the wasm was crashing with unhelpful stack traces, and narrowing down the problem was extremely hard.

For example:

    0: error while executing at wasm backtrace:
           0: 0x593501 - <unknown>!<wasm function 10295>
           1: 0x2330ee - <unknown>!<wasm function 5297>
           2: 0x261016 - <unknown>!<wasm function 5562>
           3: 0x261c47 - <unknown>!<wasm function 5565>
           4: 0x262465 - <unknown>!<wasm function 5568>
           5: 0x366d22 - <unknown>!<wasm function 7374>
           6: 0x265bdf - <unknown>!<wasm function 5596>
           7: 0x2588c3 - <unknown>!<wasm function 5561>
           8: 0x252819 - <unknown>!<wasm function 5559>
           9: 0x260edc - <unknown>!<wasm function 5562>
          10: 0x261c47 - <unknown>!<wasm function 5565>
          11: 0x34f3a9 - <unknown>!<wasm function 7280>
          12: 0x261016 - <unknown>!<wasm function 5562>
          13: 0x261c47 - <unknown>!<wasm function 5565>
          14: 0x2e27af - <unknown>!<wasm function 6558>
          15: 0x31f3eb - <unknown>!<wasm function 6955>
          16: 0x2d7cb - <unknown>!<wasm function 398>
          17: 0x231c70 - <unknown>!<wasm function 5289>
          18: 0x7abd4f - <unknown>!wasi:cli/run@0.2.0#run
    1: wasm trap: wasm `unreachable` instruction executed

My understanding from here and here is that a debug build would give better track traces, and hence help with tracking down these kinds of crashes.

[guybedford]

Thanks for the kind words. Slowly getting back to things here - this is currently being tracked in bytecodealliance/ComponentizeJS#137, which in turn is blocked on bytecodealliance/StarlingMonkey#173. The problem is that we need to use a partially optimized build for ComponentizeJS to work properly, which in turn requires wasm-opt to properly maintain the names section.

There may well be something very simple here that could be figured out, and I must admit I haven't looked very deeply into it, but that's where things stand right now.

The alternative if we can't figure that out would be to try and figure out how to get ComponentizeJS working with a full debug build, but that would require some low-level changes to the splicer.

100% agreed this is an important feature.

Note that in general retaining console logging via stdio being enabled as a feature can resolve many issues that are not engine panics.

[cataggar]

A workaround to get a lot of stack traces to show up is to use a local debug build of CompentizeJS. You will need to clone this jco repo and the ComponentizeJS repo. In ComponentizeJS/src/componentize.js, set const DEBUG_BUILD = true;, then build it with npm run build:debug. In your project, you will need to reference the local jco "@bytecodealliance/jco": "file:../../jco",. In the local jco, you will need to have it reference the local CompentiseJS "@bytecodealliance/componentize-js": "file:../ComponentizeJS",. The jco build command is npm run build. This gives me a much bigger wasm backtrace.

[cataggar]

Sorry, I was wrong. Using debug builds is not supported. bytecodealliance/ComponentizeJS#176 (comment)

[MendyBerger]

Was this resolved with #633?

[vados-cosmonic]

It sure was, thanks Mendy!

Happy to re-open if there's still an issue we can solve on this side.