1470080 - Devtools use source maps generated by both debugger.html and Debugger API

Status: RESOLVED INVALID

(Core :: JavaScript: WebAssembly, enhancement)

Description

[Benjamin Bouvier [:bbouvier] (inactive)]

Steps to reproduce:

- use a build from https://treeherder.mozilla.org/#/jobs?repo=try&revision=9031df25562f674bddff38d27faa1ebef9bf6445&selectedJob=184004780, which will MOZ_CRASH if one of the Debugger APIs involving the generated source maps is used.
- try to debug a wasm module (webassembly.org/demo) and put a breakpoint somewhere.

It will crash in DebuggerScriptGetLineOffsetsMatcher which is used. As far as I understand, it should be debugger.html's duty to create the text representation as well as the source map (from text to binary offsets and back). So there shouldn't be any usage of this particular Debugger API, and debugger.html only should be used. This suggests it is not the case.

Yury, can you investigate, please? This is blocking bug 1447591 now: we cannot remove the source map generation (and binary->text transform) as long as they're being used by the devtools.

Comment 1

[Benjamin Bouvier [:bbouvier] (inactive)]

Another data point: with a build that only contains the patches from the other bug, in particular stubbing out all the Debugger APIs for wasm without crashing, setting breakpoints doesn't do anything. So it seems to indicate there's definitely something wrong here.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=6563ead4365e7eb3f9bc5efe6d2cbcb68308a100

Comment 2

[Yury Delendik (:yury)]

(In reply to Benjamin Bouvier [:bbouvier] from comment #0)
> Steps to reproduce:
> 

> It will crash in DebuggerScriptGetLineOffsetsMatcher which is used. As far
> as I understand, it should be debugger.html's duty to create the text
> representation as well as the source map (from text to binary offsets and
> back). So there shouldn't be any usage of this particular Debugger API, and
> debugger.html only should be used. 

Yes, debugger.html is responsible for text format and mapping. Currently DebuggerScriptGetLineOffsetsMatcher treats line number as bytecode offset in "binary" mode, and called DebugState::getLineOffsets just ensures breakpoint site exists at this location. See https://searchfox.org/mozilla-central/source/js/src/wasm/WasmDebug.cpp#194 . It is okay to return true and empty offsets array for non-binary mode.

Comment 3

[Yury Delendik (:yury)]

(In reply to Benjamin Bouvier [:bbouvier] from comment #0)
> Steps to reproduce:
> 
> - use a build from
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=9031df25562f674bddff38d27faa1ebef9bf6445&selectedJob=1
> 84004780, which will MOZ_CRASH if one of the Debugger APIs involving the
> generated source maps is used.
> - try to debug a wasm module (webassembly.org/demo) and put a breakpoint
> somewhere.

Was the debugger tab opened before app run or after? This will affect whether binary mode was set.

Comment 4

[Benjamin Bouvier [:bbouvier] (inactive)]

So maybe my patch in the other bug is actually wrong, for binary mode, and that would be the only source of confusion here? I will double check it and try again.

> Was the debugger tab opened before app run or after? This will affect whether binary mode was set.

After. (I had to reload the page to make sure I was in debug mode)

Comment 5

[Benjamin Bouvier [:bbouvier] (inactive)]

This was a red herring, and a confusion from myself between the binary mode (that uses wasm bytecode) and non-binary mode (that doesn't use it). So I think we can close it.