Bugzilla

so far, I observe the stderr/stdout are visible in local `./mach test ...` run with Windows opt build, but the issue doesn't reproduce with local run.
Wow checking how it goes on automation.

Then, the debug print covers the following scenario:
  1. promise P1 is created in global G1
  2. promise P2 is created in global G2, directly depending on P1
  3. G1 becomes dying
  4. P1 gets resolved, and reaction job is enqueued
  5. the reaction job for P1 is ignored because G1 is already dying
  6. P2 remains unresolved forever

and the patch detects the situation by the following algorithm:
  * when a reaction job is getting ignored because of the global is dying:
    * if a graph of promises and their reactions contains promise or reaction from other global:
      * print the graph of promises and reactions

If the issue here doesn't match this scenario, it won't print anything.
Possible cases are:
  * (a) P1 isn't get resolved
  * (b) P2 doesn't directly depend on P1, but there's some function or abstraction between them, and all of them belongs to G1

"P2 directly depends on P1" means the following case:
  * `let P2 = P1.then(...)`
  * `let P2 = async function(...) { await P1; }`

and "not-directly" case is, for example, something like the following:
```
// in G2
let P2_resolve = null;
let P2 = new Promise(r => P2_resolve = r);

// in G1
P1.then(function onFulfilled(v) { G2.P2_resolve(v) });
```

in this case, even when P1 gets resolved, the `onFulfilled` isn't executed because G1 is dying.
then, given `onFullfilled` belongs to G1, and the reference to G2 exists only inside the function's code, the graph of promises and reactions doesn't contain anything from G2.

so far, I observe the stderr/stdout are visible in local `./mach test ...` run with Windows opt build, but the issue doesn't reproduce with local run.
Now checking how it goes on automation.

Then, the debug print covers the following scenario:
  1. promise P1 is created in global G1
  2. promise P2 is created in global G2, directly depending on P1
  3. G1 becomes dying
  4. P1 gets resolved, and reaction job is enqueued
  5. the reaction job for P1 is ignored because G1 is already dying
  6. P2 remains unresolved forever

and the patch detects the situation by the following algorithm:
  * when a reaction job is getting ignored because of the global is dying:
    * if a graph of promises and their reactions contains promise or reaction from other global:
      * print the graph of promises and reactions

If the issue here doesn't match this scenario, it won't print anything.
Possible cases are:
  * (a) P1 isn't get resolved
  * (b) P2 doesn't directly depend on P1, but there's some function or abstraction between them, and all of them belongs to G1

"P2 directly depends on P1" means the following case:
  * `let P2 = P1.then(...)`
  * `let P2 = async function(...) { await P1; }`

and "not-directly" case is, for example, something like the following:
```
// in G2
let P2_resolve = null;
let P2 = new Promise(r => P2_resolve = r);

// in G1
P1.then(function onFulfilled(v) { G2.P2_resolve(v) });
```

in this case, even when P1 gets resolved, the `onFulfilled` isn't executed because G1 is dying.
then, given `onFullfilled` belongs to G1, and the reference to G2 exists only inside the function's code, the graph of promises and reactions doesn't contain anything from G2.