dead strip! from patching Promise as in @agoric/eventual-send

[dckc]

@phoddie , any clues on how to diagnose dead strip!? What does that mean? Where should I look?

https://gist.github.com/dckc/685b595f5c41f4ec2de47cd2d1ab3a74

for context, previous episode: #255

[phoddie]

The dead strip exception is described in the manifest document where it notes:

If an application attempts to use a class or function that has been stripped, it will throw a dead strip! error

This should not normally happen. However, the linker heuristics for determining what to strip and what to keep are still evolving. Sometimes a function is stripped from the engine that is actually used by a script. That happened here.

The missing function is the native code that implements part of Function.prototype.bind.. As a quick fix, insert these two lines in xslStrip.c at line 328.

if (fxIsLinkerSymbolUsed(linker, mxID(_bind)))
	fxUnstripCallback(linker, fx_Function_prototype_bound);

The stripping capability of the linker is an important optimization for embedded systems where code storage space is limited. For desktop work, it isn't critical. You can disable this linker feature in your manifest as shown below..

	"strip": [],

That will increase the binary executable size but should always eliminate any "dead strip" error. That said, we would like to eliminate those errors completely so we appreciate the reports.

[dckc]

If an application attempts to use a class or function that has been stripped, it will throw a dead strip! error

yes, I saw that, but I didn't know how to make use of it. If there's any way to add file/line numbers to such diagnostics, that sure would help. Or even if it had told me that bind was the thing that got stripped.

... As a quick fix, insert these two lines ...

bingo.

	"strip": [],

yes, I think that's the right setting for my use case.

Thanks again.

I guess I'll leave this open until you commit those two lines...

[phoddie]

Or even if it had told me that bind was the thing that got stripped.

It wasn't bind that got stripped, but the part of its implementation that is executed when the bound function is invoked.

The bug was in the tools that generate the runtime. Adding diagnostic code to the runtime to help debug the tools runs counter to our goal of minimizing the size of the runtime. Perhaps it can be an extra debug option. But, that's of limited value: the knowledge to fix the problem is about the same as the knowledge needed to isolate the "dead strip" exception. That additional tooling wouldn't significantly widen the group of people who could fix the problem.

[dckc]

So I'm curious... how did you figure out what got stripped? I'm not averse to stepping though the tools with gdb from time to time, if that's what it takes.

[phoddie]

In this case, gdb wasn't needed. The async function was being called, but the corresponding await never completed. I checked to see if your resolve was being called by setting a break in your patch to resolve (eventual-send.esm.js). That did get invoked but generated an exception when calling baseResolve.

Though I didn't use it here, a good hack in XS for watching execution (and hence determining when it halts) is to use the debug info to trace the currently executing file and line number (along with a bunch of other information). You can get that by defining mxTrace in xsRun.c.

In the problem this issue reports, the output looks like this:

file [~/test/main.js]
line 1
function [~/test/main.js]
code_archive_2
environment
pop
symbol [funfun]
null
null
integer 3
transfer
symbol [main]
null
null
symbol [default]
integer 4
transfer
integer 3
module
result
end

begin_strict
reserve 2
retrieve 2 [funfun] [main]
file [~/test/main.js]
line 1
async_function [funfun]
code_archive
var_closure_1 0
pop
line 5
async_function [main]
code_archive_2
environment
store_1 0 [funfun]
pop
var_closure_1 1
pop
line 5
end

begin_strict
reserve 3
retrieve 1 [funfun]
start_async
file [~/test/main.js]
line 6
string_archive "in main
"
integer 1
undefined
program_reference [trace]
get_variable [trace]
callin main

pop
line 8
integer 0
undefined
get_closure 0
call
begin_strict
start_async
file [~/test/main.js]
line 2
string_archive "fun fun!
"
integer 1
undefined
program_reference [trace]
get_variable [trace]
callfun fun!

pop
end



await

begin_strict
reserve 5
retrieve 3 [ensureMaps] [presenceToPromise] [baseResolve]
new_local [value] 3
file [~/test/eventual-send.esm.js]
line 105
argument 0
var_local_1 3
pop
new_local [handledPromise] 4
line 106
integer 0
undefined
get_closure 0
call
begin_strict
reserve 3
retrieve 3 [presenceToHandler] [presenceToPromise] [promiseToHandler]
file [~/test/eventual-send.esm.js]
line 27
get_closure 0
not
branch_else_2
line 28
integer 0
program_reference [WeakMap]
get_variable [WeakMap]
new
pull_closure 0
line 29
integer 0
program_reference [WeakMap]
get_variable [WeakMap]
new
pull_closure 1
line 30
integer 0
program_reference [WeakMap]
get_variable [WeakMap]
new
pull_closure 2
end
pop
line 108
get_local 3
integer 1
get_closure 1
dub
get_property [get]
call
const_local 4
pop
line 109
get_local 4
branch_else_2
line 112
get_local 3
integer 1
undefined
get_closure 2
call_tail

[phoddie]

(linker change described above is available in this repository)

[dckc]

Ok... Fixed in fb36ba2