Assertion failure in InlineCache.cpp

[fatcerberus]

I discovered this while trying to produce a repro for #6160. The following code when run in ch hits an assertion in InlineCache.cpp:

WScript.Attach(() => {
    let iter = g();
    iter.next();
    iter.next();
});
(async () => {
    await 777;
    await 1206;
    WScript.Detach(() => {});
})();

function* g() { yield 0; }

The assertion that was hit is:
https://github.com/microsoft/ChakraCore/blob/master/lib/Runtime/Language/InlineCache.cpp#L570

        Assert(!needsProtoInvalidation || isProtoRegistered);

[zenparsing]

I believe we have a bad interaction between generator functions (which keep an interpreter stack frame on the heap) and the debugger.

In this case, we are unregistering all inline proto cache entries from the thread context when the debugger is attached. But if a generator function has created an interpreter stack frame, it may be storing inline cache entries. This results in a mismatch between the inline caches stored with the interpreter stack frame and the inline caches registered with the thread context.

This example (using no async functions) also fails:

WScript.Attach(() => {
  iter.next();
  iter.next();
  iter.next();
});

function* g() {
  while (true) {
    yield 0;
    WScript;
  }
}

let iter = g();

[fatcerberus]

@zenparsing FWIW this still repros with #6312

When is that WScript.Attach callback called, exactly? I’d expect that to error because iter hasn’t been assigned yet...

Could this also be the cause of #6160 ? I can’t manage to repro that one outside of miniSphere, but it also looks generator-related.

[zenparsing]

@fatcerberus Yep, I already tried to repro this on my branch 🤞 but it's there as well. It's more about generators than anything else.

It sounds like #6160 might be the same thing (or at least closely related). I haven't tried to dig into solutions yet but I hope to take a look sometime this week.

[zenparsing]

@fatcerberus For your debugging use case, do you need to be able to attach and detach a debugger at arbitrary times during the lifetime of a script context? Or do you just create a script context, immediately put it into debug mode, and then leave it that way (until shutdown)?

[fatcerberus]

Assuming debugging is enabled for a given session, JsDiagStartDebugging is called almost immediately after context creation, and runs continuously until the runtime is freed. This lets me run a debug server over loopback to allow attaching an ssj instance on-demand at any time.

I already made this commit in my own repo as a workaround - spheredev/neosphere@71ccfc8

The only thing that concerned me with that workaround is that in my case, without it, CC hits a failfast (https://github.com/microsoft/ChakraCore/blob/master/lib/Runtime/Debug/DebugContext.cpp#L359) which struck me as a potential security issue I might just be sweeping under the carpet.