Open
Bug 981514
(async-stacks)
Opened 10 years ago
Updated 1 year ago
[meta] Asynchronous call stacks
Categories
(DevTools :: General, enhancement)
DevTools
General
Tracking
(Not tracked)
NEW
People
(Reporter: jryans, Unassigned)
References
(Depends on 8 open bugs, Blocks 3 open bugs)
Details
(Keywords: meta)
Chrome 33 added support for linking the call stack of something async back up to the original call site that scheduled the async behavior (setTimeout, etc.). Seems like a neat idea for us to consider too. A little more info is available on their post[1]. [1]: http://www.html5rocks.com/en/tutorials/developertools/chrome-33/#toc-asynchronouscallstacks
Comment 1•10 years ago
|
||
Our plan was to add a new console.tagStack() method for the user to opt in to the additional data collection, but it's interesting that they do this automatically. Perhaps the CPU and memory cost isn't that bad after all.
Reporter | ||
Comment 2•10 years ago
|
||
It's not super obvious from Chrome's screenshot, but the "Async" checkbox that appears next to the "Call Stack" panel actually has to be enabled before your code runs. If you hit a breakpoint and then enable "Async" after the fact, no extra information appears (which is slightly confusing UX). I have no idea if this was done for performance reasons, or simply because they can't gather new information once you hit a breakpoint. It does not appear to degrade performance noticeably, but I also haven't tested very much.
Comment 3•10 years ago
|
||
Was talking to Erik Bryn (the Ember dude) about this at DHTMLConf. We should totally do this automatically for users (what Chrome is doing now; this bug) but also expose the console.tagStack() method (bug 882825) for user land tagging. Ember manages its own event loop of sorts and they'd love to be able to link where something came from originally instead of only showing a ton of Ember-internal frames.
Blocks: tagStack
Comment 4•10 years ago
|
||
We will have most of the infrastructure for this completed once bug 961325 lands.
Depends on: 961325
Comment 5•10 years ago
|
||
This is quite awesome! Also just a note: user-land micro-task queues are quite common, in addition to embers run-loop, literally every promise implementation does this as well.
Updated•10 years ago
|
Depends on: dbg-inspect
Updated•10 years ago
|
Blocks: dbg-inspect
No longer depends on: dbg-inspect
Updated•9 years ago
|
Summary: Asynchronous call stacks → [meta] Asynchronous call stacks
Updated•9 years ago
|
Updated•9 years ago
|
Component: Developer Tools: Debugger → Developer Tools
Comment 8•9 years ago
|
||
Paolo, I'm not sure we should enable async stacks by default on 39 for Beta, given that there is still work in progress on bug 1142577 and issues mentioned in bug 1152893. Which other bugs should block enabling this on Beta? Is this ready to ride the trains? We may need to make sure it gets turned off for Desktop as well as mobile?
Flags: needinfo?(paolo.mozmail)
Comment 9•9 years ago
|
||
Please see also bug 981514. It aims for probably the same goal and my experimental work I currently have already gives full walk back (and more.) I'll blog about it soon.
Comment 10•9 years ago
|
||
(In reply to Honza Bambas (:mayhemer) from comment #9) > Please see also bug 981514. It aims for probably the same goal and my > experimental work I currently have already gives full walk back (and more.) > I'll blog about it soon. You linked to this bug :P
Updated•9 years ago
|
Flags: needinfo?(honzab.moz)
Comment 11•9 years ago
|
||
Interesting mistake :) The bug I mean is bug 1148204.
Flags: needinfo?(honzab.moz)
Comment 12•9 years ago
|
||
(In reply to Liz Henry (:lizzard) from comment #8) > Paolo, I'm not sure we should enable async stacks by default on 39 for Beta, > given that there is still work in progress on bug 1142577 and issues > mentioned in bug 1152893. Hi, sorry for the delayed reply. I agree that the before the Async Stacks feature merges to Beta 39 we have to get to a state of consistency as discussed in bug 1152893. The way backwards (and the most likely one for this cycle) would be to back out bug 1140472 (Set an async stack when invoking promise handlers) from late Aurora 39. There might still be other tests written or modified after that bug landed, that depend on it - Nick or Boris will probably be able to help if needed. > Which other bugs should block enabling this on Beta? The way forward is to implement bug 1142577 (Use JS::AutoSetAsyncStackForNewCalls for setTimeout and setInterval) and bug 1158133 (Add a way to disable async stacks, and disable by default on mobile platforms). > Is this ready to ride the trains? We may need to make sure it gets > turned off for Desktop as well as mobile? In fact we may also get bug 1158133 done on its own and turn off the feature on both Desktop and mobile for the 39 cycle. It's unlikely that I'll have time to work on it however, and I'm not familiar with the steps required in the JS engine.
Flags: needinfo?(paolo.mozmail)
Comment 13•9 years ago
|
||
Thanks for the detailed answer! Looks like Nick is out until May 17, Boris is usually quite busy, so can you follow up with this so we can make a decision one way or the other on this and straighten it out by Friday May 8. It sounds like what we need to do is back this out for 39. I would like that to happen before 39 goes to beta, not after.
Flags: needinfo?(paolo.mozmail)
Comment 14•9 years ago
|
||
I'm testing a backout of bug 1140472 on mozilla-central, let's see how it goes. https://treeherder.mozilla.org/#/jobs?repo=try&revision=9fa1cf7d9b5e
Flags: needinfo?(paolo.mozmail)
Comment 15•9 years ago
|
||
Looks like there are a few tests to adjust, but should be quite easy. Filed bug 1163139 which will likely see a patch tomorrow.
Updated•6 years ago
|
Product: Firefox → DevTools
Updated•5 years ago
|
Depends on: dbg-async-stacks
Updated•5 years ago
|
Blocks: dbg-stacks
Updated•5 years ago
|
Depends on: dbg-captured
Updated•1 year ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•