Open Bug 1534435 Opened 6 years ago Updated 10 months ago

Add a mechanism for tracking all unresolved `await`s

Categories

(Core :: JavaScript Engine, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: alexical, Unassigned)

References

(Blocks 1 open bug)

Details

Often times it comes up that either a mochitest times out and I'd like to see a printout of all awaits or I'm debugging something that is hung somewhere and I would like to quickly see where I'm awaiting something. I suspect that just being able to see file/line numbers for all of the places that are currently awaiting a promise would get me a long way toward not having these problems anymore. It's not a complete solution but it's still likely to be tremendously useful.

Filing this here instead of under Mochitest or the Debugger because we'd need a change here (or at least I can't find a better place) for either to have this feature.

Flags: needinfo?(jorendorff)

I don't know how important this is. Currently I get the impression it would be valuable, but it's not worth spending a month on.

Unfortunately there's nothing like the Unix process table for async function activations. Async processes are just objects in memory. The awaited promise (which after all is just an object) keeps the async function call alive via callbacks. If the promise gets GC'd, the async function call will be GC'd.

Suppose we create an "async process table", a list of all the existing async function calls in a realm. There's another problem: when one async function awaits another, which is super typical, there'd be two entries in the table. There's currently no way to puzzle out from the state of the heap that one is awaiting the other, and therefore they are really two stack frames on the same "thread".

These two problems can be overcome, but it's a chunk of work.

Flags: needinfo?(jorendorff)

I wonder, though, if we couldn't use Debugger.prototype.findObjects to find all Promises, and then filter them by Debugger.Object.prototype.promiseState, to find unresolved promises? If there we too many false positives that way, we could add a method to Debugger.Object to distinguish promises being awaited by async functions, since those have a particular kind of callback on them.

For bug 1523865, I'm going to have to add the methods we need to take a Debugger.Object referring to a Promise and return Debugger.Frames for all async functions awaiting that Promise. That could help with this, too.

Better than findObjects (because that's a terrible API that we should delete) would be to run the mochitest in a mode where we attach a Debugger from the beginning, and then use onNewPromise and onPromiseSettled to maintain a Set of unresolved promises. Then it'd be a matter of looking through that and reporting.

Priority: -- → P3
Severity: normal → S3
Blocks: sm-runtime
Severity: S3 → N/A
You need to log in before you can comment on or make changes to this bug.