AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
7fe2d8854a
v8/test/inspector/debugger/async-stack-created-frame-expected.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

92 lines
1.7 KiB
Plaintext
Raw Normal View History

[inspector] added creation frame for async call chains for promises With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained. At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback: foo2 (test.js:14:2) -- Promise.resolve (test.js:29:14)-- -- Promise.resolve (test.js:28:14)-- promiseThen (test.js:30:2) More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE BUG=v8:5738 R=dgozman@chromium.org,gsathya@chromium.org Review-Url: https://codereview.chromium.org/2648873002 Cr-Commit-Position: refs/heads/master@{#42682}
2017-01-26 09:32:37 +00:00
Checks created frame for async call chain
Running test: testPromise
foo1 (test.js:10:2)
[inspector] reworked async instrumentation for promises Old instrumentation was designed to collect promise creation stack and promise scheduled stack together. In DevTools for last 6 months we show only creation stack for promises. We got strong support from users for new model. Now we can drop support for scheduled stacks and simplify implementation. New promise instrumentation is straightforward: - we send kDebugPromiseThen when promise is created by .then call, - we send kDebugPromiseCatch when promise is created by .catch call, - we send kDebugWillHandle before chained callback and kDebugDidHandle after chained callback, - and we send separate kDebugAsyncFunctionPromiseCreated for internal promise inside async await function. Advantages: - we reduce amount of captured stacks (we do not capture stack for promise that constructed not by .then or .catch), - we can consider async task related to .then and .catch as one shot since chained callback is executed once, - on V8 side we can implement required instrumentation using only promise hooks, Disadvantage: - see await-promise test, sometimes scheduled stack was useful since we add catch handler in native code, Implementation details: - on kInit promise hook we need to figure out why promise was created. We analyze builtin functions until first user defined function on current stack. If there is kAsyncFunctionPromiseCreate function then we send kDebugAsyncFunctionPromiseCreated event. If there is kPromiseThen or kPromiseCatch then only if this function is bottom builtin function we send corresponded event to inspector. We need it because Promise.all internally calls .then and in this case we have Promise.all and Promise.then on stack at the same time and we do not need to report this internally created promise to inspector. Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47 Reviewed-on: https://chromium-review.googlesource.com/765208 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#49553}
2017-11-21 15:42:43 +00:00
-- Promise.then --
[inspector] use creation stack trace as parent for async call chains Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved. For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2868493002 Cr-Original-Commit-Position: refs/heads/master@{#45198} Committed: https://chromium.googlesource.com/v8/v8/+/e118462f18a862df81a04486e13dd62997cbfc5a Review-Url: https://codereview.chromium.org/2868493002 Cr-Commit-Position: refs/heads/master@{#45266}
2017-05-11 19:21:24 +00:00
promise (test.js:20:14)
[inspector] added creation frame for async call chains for promises With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained. At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback: foo2 (test.js:14:2) -- Promise.resolve (test.js:29:14)-- -- Promise.resolve (test.js:28:14)-- promiseThen (test.js:30:2) More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE BUG=v8:5738 R=dgozman@chromium.org,gsathya@chromium.org Review-Url: https://codereview.chromium.org/2648873002 Cr-Commit-Position: refs/heads/master@{#42682}
2017-01-26 09:32:37 +00:00
(anonymous) (expr.js:0:0)
Running test: testPromiseThen
foo1 (test.js:10:2)
[inspector] reworked async instrumentation for promises Old instrumentation was designed to collect promise creation stack and promise scheduled stack together. In DevTools for last 6 months we show only creation stack for promises. We got strong support from users for new model. Now we can drop support for scheduled stacks and simplify implementation. New promise instrumentation is straightforward: - we send kDebugPromiseThen when promise is created by .then call, - we send kDebugPromiseCatch when promise is created by .catch call, - we send kDebugWillHandle before chained callback and kDebugDidHandle after chained callback, - and we send separate kDebugAsyncFunctionPromiseCreated for internal promise inside async await function. Advantages: - we reduce amount of captured stacks (we do not capture stack for promise that constructed not by .then or .catch), - we can consider async task related to .then and .catch as one shot since chained callback is executed once, - on V8 side we can implement required instrumentation using only promise hooks, Disadvantage: - see await-promise test, sometimes scheduled stack was useful since we add catch handler in native code, Implementation details: - on kInit promise hook we need to figure out why promise was created. We analyze builtin functions until first user defined function on current stack. If there is kAsyncFunctionPromiseCreate function then we send kDebugAsyncFunctionPromiseCreated event. If there is kPromiseThen or kPromiseCatch then only if this function is bottom builtin function we send corresponded event to inspector. We need it because Promise.all internally calls .then and in this case we have Promise.all and Promise.then on stack at the same time and we do not need to report this internally created promise to inspector. Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47 Reviewed-on: https://chromium-review.googlesource.com/765208 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#49553}
2017-11-21 15:42:43 +00:00
-- Promise.then --
[inspector] use creation stack trace as parent for async call chains Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved. For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2868493002 Cr-Original-Commit-Position: refs/heads/master@{#45198} Committed: https://chromium.googlesource.com/v8/v8/+/e118462f18a862df81a04486e13dd62997cbfc5a Review-Url: https://codereview.chromium.org/2868493002 Cr-Commit-Position: refs/heads/master@{#45266}
2017-05-11 19:21:24 +00:00
promiseThen (test.js:28:14)
[inspector] added creation frame for async call chains for promises With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained. At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback: foo2 (test.js:14:2) -- Promise.resolve (test.js:29:14)-- -- Promise.resolve (test.js:28:14)-- promiseThen (test.js:30:2) More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE BUG=v8:5738 R=dgozman@chromium.org,gsathya@chromium.org Review-Url: https://codereview.chromium.org/2648873002 Cr-Commit-Position: refs/heads/master@{#42682}
2017-01-26 09:32:37 +00:00
(anonymous) (expr.js:0:0)
foo2 (test.js:14:2)
[inspector] reworked async instrumentation for promises Old instrumentation was designed to collect promise creation stack and promise scheduled stack together. In DevTools for last 6 months we show only creation stack for promises. We got strong support from users for new model. Now we can drop support for scheduled stacks and simplify implementation. New promise instrumentation is straightforward: - we send kDebugPromiseThen when promise is created by .then call, - we send kDebugPromiseCatch when promise is created by .catch call, - we send kDebugWillHandle before chained callback and kDebugDidHandle after chained callback, - and we send separate kDebugAsyncFunctionPromiseCreated for internal promise inside async await function. Advantages: - we reduce amount of captured stacks (we do not capture stack for promise that constructed not by .then or .catch), - we can consider async task related to .then and .catch as one shot since chained callback is executed once, - on V8 side we can implement required instrumentation using only promise hooks, Disadvantage: - see await-promise test, sometimes scheduled stack was useful since we add catch handler in native code, Implementation details: - on kInit promise hook we need to figure out why promise was created. We analyze builtin functions until first user defined function on current stack. If there is kAsyncFunctionPromiseCreate function then we send kDebugAsyncFunctionPromiseCreated event. If there is kPromiseThen or kPromiseCatch then only if this function is bottom builtin function we send corresponded event to inspector. We need it because Promise.all internally calls .then and in this case we have Promise.all and Promise.then on stack at the same time and we do not need to report this internally created promise to inspector. Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47 Reviewed-on: https://chromium-review.googlesource.com/765208 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#49553}
2017-11-21 15:42:43 +00:00
-- Promise.then --
[inspector] use creation stack trace as parent for async call chains Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved. For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2868493002 Cr-Original-Commit-Position: refs/heads/master@{#45198} Committed: https://chromium.googlesource.com/v8/v8/+/e118462f18a862df81a04486e13dd62997cbfc5a Review-Url: https://codereview.chromium.org/2868493002 Cr-Commit-Position: refs/heads/master@{#45266}
2017-05-11 19:21:24 +00:00
promiseThen (test.js:29:14)
[inspector] added creation frame for async call chains for promises With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained. At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback: foo2 (test.js:14:2) -- Promise.resolve (test.js:29:14)-- -- Promise.resolve (test.js:28:14)-- promiseThen (test.js:30:2) More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE BUG=v8:5738 R=dgozman@chromium.org,gsathya@chromium.org Review-Url: https://codereview.chromium.org/2648873002 Cr-Commit-Position: refs/heads/master@{#42682}
2017-01-26 09:32:37 +00:00
(anonymous) (expr.js:0:0)
Running test: testPromiseThenThen
foo1 (test.js:10:2)
[inspector] reworked async instrumentation for promises Old instrumentation was designed to collect promise creation stack and promise scheduled stack together. In DevTools for last 6 months we show only creation stack for promises. We got strong support from users for new model. Now we can drop support for scheduled stacks and simplify implementation. New promise instrumentation is straightforward: - we send kDebugPromiseThen when promise is created by .then call, - we send kDebugPromiseCatch when promise is created by .catch call, - we send kDebugWillHandle before chained callback and kDebugDidHandle after chained callback, - and we send separate kDebugAsyncFunctionPromiseCreated for internal promise inside async await function. Advantages: - we reduce amount of captured stacks (we do not capture stack for promise that constructed not by .then or .catch), - we can consider async task related to .then and .catch as one shot since chained callback is executed once, - on V8 side we can implement required instrumentation using only promise hooks, Disadvantage: - see await-promise test, sometimes scheduled stack was useful since we add catch handler in native code, Implementation details: - on kInit promise hook we need to figure out why promise was created. We analyze builtin functions until first user defined function on current stack. If there is kAsyncFunctionPromiseCreate function then we send kDebugAsyncFunctionPromiseCreated event. If there is kPromiseThen or kPromiseCatch then only if this function is bottom builtin function we send corresponded event to inspector. We need it because Promise.all internally calls .then and in this case we have Promise.all and Promise.then on stack at the same time and we do not need to report this internally created promise to inspector. Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47 Reviewed-on: https://chromium-review.googlesource.com/765208 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#49553}
2017-11-21 15:42:43 +00:00
-- Promise.then --
[inspector] use creation stack trace as parent for async call chains Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved. For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2868493002 Cr-Original-Commit-Position: refs/heads/master@{#45198} Committed: https://chromium.googlesource.com/v8/v8/+/e118462f18a862df81a04486e13dd62997cbfc5a Review-Url: https://codereview.chromium.org/2868493002 Cr-Commit-Position: refs/heads/master@{#45266}
2017-05-11 19:21:24 +00:00
promiseThenThen (test.js:37:14)
[inspector] added creation frame for async call chains for promises With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained. At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback: foo2 (test.js:14:2) -- Promise.resolve (test.js:29:14)-- -- Promise.resolve (test.js:28:14)-- promiseThen (test.js:30:2) More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE BUG=v8:5738 R=dgozman@chromium.org,gsathya@chromium.org Review-Url: https://codereview.chromium.org/2648873002 Cr-Commit-Position: refs/heads/master@{#42682}
2017-01-26 09:32:37 +00:00
(anonymous) (expr.js:0:0)
foo1 (test.js:10:2)
[inspector] reworked async instrumentation for promises Old instrumentation was designed to collect promise creation stack and promise scheduled stack together. In DevTools for last 6 months we show only creation stack for promises. We got strong support from users for new model. Now we can drop support for scheduled stacks and simplify implementation. New promise instrumentation is straightforward: - we send kDebugPromiseThen when promise is created by .then call, - we send kDebugPromiseCatch when promise is created by .catch call, - we send kDebugWillHandle before chained callback and kDebugDidHandle after chained callback, - and we send separate kDebugAsyncFunctionPromiseCreated for internal promise inside async await function. Advantages: - we reduce amount of captured stacks (we do not capture stack for promise that constructed not by .then or .catch), - we can consider async task related to .then and .catch as one shot since chained callback is executed once, - on V8 side we can implement required instrumentation using only promise hooks, Disadvantage: - see await-promise test, sometimes scheduled stack was useful since we add catch handler in native code, Implementation details: - on kInit promise hook we need to figure out why promise was created. We analyze builtin functions until first user defined function on current stack. If there is kAsyncFunctionPromiseCreate function then we send kDebugAsyncFunctionPromiseCreated event. If there is kPromiseThen or kPromiseCatch then only if this function is bottom builtin function we send corresponded event to inspector. We need it because Promise.all internally calls .then and in this case we have Promise.all and Promise.then on stack at the same time and we do not need to report this internally created promise to inspector. Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47 Reviewed-on: https://chromium-review.googlesource.com/765208 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#49553}
2017-11-21 15:42:43 +00:00
-- Promise.then --
[inspector] use creation stack trace as parent for async call chains Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved. For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2868493002 Cr-Original-Commit-Position: refs/heads/master@{#45198} Committed: https://chromium.googlesource.com/v8/v8/+/e118462f18a862df81a04486e13dd62997cbfc5a Review-Url: https://codereview.chromium.org/2868493002 Cr-Commit-Position: refs/heads/master@{#45266}
2017-05-11 19:21:24 +00:00
promiseThenThen (test.js:38:14)
[inspector] added creation frame for async call chains for promises With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained. At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback: foo2 (test.js:14:2) -- Promise.resolve (test.js:29:14)-- -- Promise.resolve (test.js:28:14)-- promiseThen (test.js:30:2) More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE BUG=v8:5738 R=dgozman@chromium.org,gsathya@chromium.org Review-Url: https://codereview.chromium.org/2648873002 Cr-Commit-Position: refs/heads/master@{#42682}
2017-01-26 09:32:37 +00:00
(anonymous) (expr.js:0:0)
foo2 (test.js:14:2)
[inspector] reworked async instrumentation for promises Old instrumentation was designed to collect promise creation stack and promise scheduled stack together. In DevTools for last 6 months we show only creation stack for promises. We got strong support from users for new model. Now we can drop support for scheduled stacks and simplify implementation. New promise instrumentation is straightforward: - we send kDebugPromiseThen when promise is created by .then call, - we send kDebugPromiseCatch when promise is created by .catch call, - we send kDebugWillHandle before chained callback and kDebugDidHandle after chained callback, - and we send separate kDebugAsyncFunctionPromiseCreated for internal promise inside async await function. Advantages: - we reduce amount of captured stacks (we do not capture stack for promise that constructed not by .then or .catch), - we can consider async task related to .then and .catch as one shot since chained callback is executed once, - on V8 side we can implement required instrumentation using only promise hooks, Disadvantage: - see await-promise test, sometimes scheduled stack was useful since we add catch handler in native code, Implementation details: - on kInit promise hook we need to figure out why promise was created. We analyze builtin functions until first user defined function on current stack. If there is kAsyncFunctionPromiseCreate function then we send kDebugAsyncFunctionPromiseCreated event. If there is kPromiseThen or kPromiseCatch then only if this function is bottom builtin function we send corresponded event to inspector. We need it because Promise.all internally calls .then and in this case we have Promise.all and Promise.then on stack at the same time and we do not need to report this internally created promise to inspector. Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47 Reviewed-on: https://chromium-review.googlesource.com/765208 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#49553}
2017-11-21 15:42:43 +00:00
-- Promise.then --
[inspector] use creation stack trace as parent for async call chains Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved. For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2868493002 Cr-Original-Commit-Position: refs/heads/master@{#45198} Committed: https://chromium.googlesource.com/v8/v8/+/e118462f18a862df81a04486e13dd62997cbfc5a Review-Url: https://codereview.chromium.org/2868493002 Cr-Commit-Position: refs/heads/master@{#45266}
2017-05-11 19:21:24 +00:00
promiseThenThen (test.js:37:25)
[inspector] added creation frame for async call chains for promises With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained. At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback: foo2 (test.js:14:2) -- Promise.resolve (test.js:29:14)-- -- Promise.resolve (test.js:28:14)-- promiseThen (test.js:30:2) More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE BUG=v8:5738 R=dgozman@chromium.org,gsathya@chromium.org Review-Url: https://codereview.chromium.org/2648873002 Cr-Commit-Position: refs/heads/master@{#42682}
2017-01-26 09:32:37 +00:00
(anonymous) (expr.js:0:0)
Running test: testPromiseResolve
foo1 (test.js:10:2)
[inspector] reworked async instrumentation for promises Old instrumentation was designed to collect promise creation stack and promise scheduled stack together. In DevTools for last 6 months we show only creation stack for promises. We got strong support from users for new model. Now we can drop support for scheduled stacks and simplify implementation. New promise instrumentation is straightforward: - we send kDebugPromiseThen when promise is created by .then call, - we send kDebugPromiseCatch when promise is created by .catch call, - we send kDebugWillHandle before chained callback and kDebugDidHandle after chained callback, - and we send separate kDebugAsyncFunctionPromiseCreated for internal promise inside async await function. Advantages: - we reduce amount of captured stacks (we do not capture stack for promise that constructed not by .then or .catch), - we can consider async task related to .then and .catch as one shot since chained callback is executed once, - on V8 side we can implement required instrumentation using only promise hooks, Disadvantage: - see await-promise test, sometimes scheduled stack was useful since we add catch handler in native code, Implementation details: - on kInit promise hook we need to figure out why promise was created. We analyze builtin functions until first user defined function on current stack. If there is kAsyncFunctionPromiseCreate function then we send kDebugAsyncFunctionPromiseCreated event. If there is kPromiseThen or kPromiseCatch then only if this function is bottom builtin function we send corresponded event to inspector. We need it because Promise.all internally calls .then and in this case we have Promise.all and Promise.then on stack at the same time and we do not need to report this internally created promise to inspector. Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47 Reviewed-on: https://chromium-review.googlesource.com/765208 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#49553}
2017-11-21 15:42:43 +00:00
-- Promise.then --
[inspector] use creation stack trace as parent for async call chains Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved. For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2868493002 Cr-Original-Commit-Position: refs/heads/master@{#45198} Committed: https://chromium.googlesource.com/v8/v8/+/e118462f18a862df81a04486e13dd62997cbfc5a Review-Url: https://codereview.chromium.org/2868493002 Cr-Commit-Position: refs/heads/master@{#45266}
2017-05-11 19:21:24 +00:00
promiseResolve (test.js:44:27)
[inspector] added creation frame for async call chains for promises With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained. At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback: foo2 (test.js:14:2) -- Promise.resolve (test.js:29:14)-- -- Promise.resolve (test.js:28:14)-- promiseThen (test.js:30:2) More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE BUG=v8:5738 R=dgozman@chromium.org,gsathya@chromium.org Review-Url: https://codereview.chromium.org/2648873002 Cr-Commit-Position: refs/heads/master@{#42682}
2017-01-26 09:32:37 +00:00
(anonymous) (expr.js:0:0)
Running test: testPromiseReject
foo1 (test.js:10:2)
[inspector] reworked async instrumentation for promises Old instrumentation was designed to collect promise creation stack and promise scheduled stack together. In DevTools for last 6 months we show only creation stack for promises. We got strong support from users for new model. Now we can drop support for scheduled stacks and simplify implementation. New promise instrumentation is straightforward: - we send kDebugPromiseThen when promise is created by .then call, - we send kDebugPromiseCatch when promise is created by .catch call, - we send kDebugWillHandle before chained callback and kDebugDidHandle after chained callback, - and we send separate kDebugAsyncFunctionPromiseCreated for internal promise inside async await function. Advantages: - we reduce amount of captured stacks (we do not capture stack for promise that constructed not by .then or .catch), - we can consider async task related to .then and .catch as one shot since chained callback is executed once, - on V8 side we can implement required instrumentation using only promise hooks, Disadvantage: - see await-promise test, sometimes scheduled stack was useful since we add catch handler in native code, Implementation details: - on kInit promise hook we need to figure out why promise was created. We analyze builtin functions until first user defined function on current stack. If there is kAsyncFunctionPromiseCreate function then we send kDebugAsyncFunctionPromiseCreated event. If there is kPromiseThen or kPromiseCatch then only if this function is bottom builtin function we send corresponded event to inspector. We need it because Promise.all internally calls .then and in this case we have Promise.all and Promise.then on stack at the same time and we do not need to report this internally created promise to inspector. Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47 Reviewed-on: https://chromium-review.googlesource.com/765208 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#49553}
2017-11-21 15:42:43 +00:00
-- Promise.catch --
[inspector] use creation stack trace as parent for async call chains Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved. For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2868493002 Cr-Original-Commit-Position: refs/heads/master@{#45198} Committed: https://chromium.googlesource.com/v8/v8/+/e118462f18a862df81a04486e13dd62997cbfc5a Review-Url: https://codereview.chromium.org/2868493002 Cr-Commit-Position: refs/heads/master@{#45266}
2017-05-11 19:21:24 +00:00
promiseReject (test.js:48:31)
[inspector] added creation frame for async call chains for promises With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained. At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback: foo2 (test.js:14:2) -- Promise.resolve (test.js:29:14)-- -- Promise.resolve (test.js:28:14)-- promiseThen (test.js:30:2) More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE BUG=v8:5738 R=dgozman@chromium.org,gsathya@chromium.org Review-Url: https://codereview.chromium.org/2648873002 Cr-Commit-Position: refs/heads/master@{#42682}
2017-01-26 09:32:37 +00:00
(anonymous) (expr.js:0:0)
Running test: testPromiseAll
foo1 (test.js:10:2)
[inspector] reworked async instrumentation for promises Old instrumentation was designed to collect promise creation stack and promise scheduled stack together. In DevTools for last 6 months we show only creation stack for promises. We got strong support from users for new model. Now we can drop support for scheduled stacks and simplify implementation. New promise instrumentation is straightforward: - we send kDebugPromiseThen when promise is created by .then call, - we send kDebugPromiseCatch when promise is created by .catch call, - we send kDebugWillHandle before chained callback and kDebugDidHandle after chained callback, - and we send separate kDebugAsyncFunctionPromiseCreated for internal promise inside async await function. Advantages: - we reduce amount of captured stacks (we do not capture stack for promise that constructed not by .then or .catch), - we can consider async task related to .then and .catch as one shot since chained callback is executed once, - on V8 side we can implement required instrumentation using only promise hooks, Disadvantage: - see await-promise test, sometimes scheduled stack was useful since we add catch handler in native code, Implementation details: - on kInit promise hook we need to figure out why promise was created. We analyze builtin functions until first user defined function on current stack. If there is kAsyncFunctionPromiseCreate function then we send kDebugAsyncFunctionPromiseCreated event. If there is kPromiseThen or kPromiseCatch then only if this function is bottom builtin function we send corresponded event to inspector. We need it because Promise.all internally calls .then and in this case we have Promise.all and Promise.then on stack at the same time and we do not need to report this internally created promise to inspector. Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47 Reviewed-on: https://chromium-review.googlesource.com/765208 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#49553}
2017-11-21 15:42:43 +00:00
-- Promise.then --
[inspector] use creation stack trace as parent for async call chains Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved. For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2868493002 Cr-Original-Commit-Position: refs/heads/master@{#45198} Committed: https://chromium.googlesource.com/v8/v8/+/e118462f18a862df81a04486e13dd62997cbfc5a Review-Url: https://codereview.chromium.org/2868493002 Cr-Commit-Position: refs/heads/master@{#45266}
2017-05-11 19:21:24 +00:00
promiseAll (test.js:52:44)
[inspector] added creation frame for async call chains for promises With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained. At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback: foo2 (test.js:14:2) -- Promise.resolve (test.js:29:14)-- -- Promise.resolve (test.js:28:14)-- promiseThen (test.js:30:2) More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE BUG=v8:5738 R=dgozman@chromium.org,gsathya@chromium.org Review-Url: https://codereview.chromium.org/2648873002 Cr-Commit-Position: refs/heads/master@{#42682}
2017-01-26 09:32:37 +00:00
(anonymous) (expr.js:0:0)
Running test: testPromiseRace
foo1 (test.js:10:2)
[inspector] reworked async instrumentation for promises Old instrumentation was designed to collect promise creation stack and promise scheduled stack together. In DevTools for last 6 months we show only creation stack for promises. We got strong support from users for new model. Now we can drop support for scheduled stacks and simplify implementation. New promise instrumentation is straightforward: - we send kDebugPromiseThen when promise is created by .then call, - we send kDebugPromiseCatch when promise is created by .catch call, - we send kDebugWillHandle before chained callback and kDebugDidHandle after chained callback, - and we send separate kDebugAsyncFunctionPromiseCreated for internal promise inside async await function. Advantages: - we reduce amount of captured stacks (we do not capture stack for promise that constructed not by .then or .catch), - we can consider async task related to .then and .catch as one shot since chained callback is executed once, - on V8 side we can implement required instrumentation using only promise hooks, Disadvantage: - see await-promise test, sometimes scheduled stack was useful since we add catch handler in native code, Implementation details: - on kInit promise hook we need to figure out why promise was created. We analyze builtin functions until first user defined function on current stack. If there is kAsyncFunctionPromiseCreate function then we send kDebugAsyncFunctionPromiseCreated event. If there is kPromiseThen or kPromiseCatch then only if this function is bottom builtin function we send corresponded event to inspector. We need it because Promise.all internally calls .then and in this case we have Promise.all and Promise.then on stack at the same time and we do not need to report this internally created promise to inspector. Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47 Reviewed-on: https://chromium-review.googlesource.com/765208 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#49553}
2017-11-21 15:42:43 +00:00
-- Promise.then --
[inspector] use creation stack trace as parent for async call chains Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved. For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2868493002 Cr-Original-Commit-Position: refs/heads/master@{#45198} Committed: https://chromium.googlesource.com/v8/v8/+/e118462f18a862df81a04486e13dd62997cbfc5a Review-Url: https://codereview.chromium.org/2868493002 Cr-Commit-Position: refs/heads/master@{#45266}
2017-05-11 19:21:24 +00:00
promiseRace (test.js:56:45)
[inspector] added creation frame for async call chains for promises With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained. At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback: foo2 (test.js:14:2) -- Promise.resolve (test.js:29:14)-- -- Promise.resolve (test.js:28:14)-- promiseThen (test.js:30:2) More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE BUG=v8:5738 R=dgozman@chromium.org,gsathya@chromium.org Review-Url: https://codereview.chromium.org/2648873002 Cr-Commit-Position: refs/heads/master@{#42682}
2017-01-26 09:32:37 +00:00
(anonymous) (expr.js:0:0)
Running test: testThenableJob1
foo1 (test.js:10:2)
[inspector] reworked async instrumentation for promises Old instrumentation was designed to collect promise creation stack and promise scheduled stack together. In DevTools for last 6 months we show only creation stack for promises. We got strong support from users for new model. Now we can drop support for scheduled stacks and simplify implementation. New promise instrumentation is straightforward: - we send kDebugPromiseThen when promise is created by .then call, - we send kDebugPromiseCatch when promise is created by .catch call, - we send kDebugWillHandle before chained callback and kDebugDidHandle after chained callback, - and we send separate kDebugAsyncFunctionPromiseCreated for internal promise inside async await function. Advantages: - we reduce amount of captured stacks (we do not capture stack for promise that constructed not by .then or .catch), - we can consider async task related to .then and .catch as one shot since chained callback is executed once, - on V8 side we can implement required instrumentation using only promise hooks, Disadvantage: - see await-promise test, sometimes scheduled stack was useful since we add catch handler in native code, Implementation details: - on kInit promise hook we need to figure out why promise was created. We analyze builtin functions until first user defined function on current stack. If there is kAsyncFunctionPromiseCreate function then we send kDebugAsyncFunctionPromiseCreated event. If there is kPromiseThen or kPromiseCatch then only if this function is bottom builtin function we send corresponded event to inspector. We need it because Promise.all internally calls .then and in this case we have Promise.all and Promise.then on stack at the same time and we do not need to report this internally created promise to inspector. Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47 Reviewed-on: https://chromium-review.googlesource.com/765208 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#49553}
2017-11-21 15:42:43 +00:00
-- Promise.then --
[inspector] use creation stack trace as parent for async call chains Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved. For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2868493002 Cr-Original-Commit-Position: refs/heads/master@{#45198} Committed: https://chromium.googlesource.com/v8/v8/+/e118462f18a862df81a04486e13dd62997cbfc5a Review-Url: https://codereview.chromium.org/2868493002 Cr-Commit-Position: refs/heads/master@{#45266}
2017-05-11 19:21:24 +00:00
thenableJob1 (test.js:60:72)
[inspector] added creation frame for async call chains for promises With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained. At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback: foo2 (test.js:14:2) -- Promise.resolve (test.js:29:14)-- -- Promise.resolve (test.js:28:14)-- promiseThen (test.js:30:2) More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE BUG=v8:5738 R=dgozman@chromium.org,gsathya@chromium.org Review-Url: https://codereview.chromium.org/2648873002 Cr-Commit-Position: refs/heads/master@{#42682}
2017-01-26 09:32:37 +00:00
(anonymous) (expr.js:0:0)
Running test: testThenableJob2
foo1 (test.js:10:2)
[inspector] reworked async instrumentation for promises Old instrumentation was designed to collect promise creation stack and promise scheduled stack together. In DevTools for last 6 months we show only creation stack for promises. We got strong support from users for new model. Now we can drop support for scheduled stacks and simplify implementation. New promise instrumentation is straightforward: - we send kDebugPromiseThen when promise is created by .then call, - we send kDebugPromiseCatch when promise is created by .catch call, - we send kDebugWillHandle before chained callback and kDebugDidHandle after chained callback, - and we send separate kDebugAsyncFunctionPromiseCreated for internal promise inside async await function. Advantages: - we reduce amount of captured stacks (we do not capture stack for promise that constructed not by .then or .catch), - we can consider async task related to .then and .catch as one shot since chained callback is executed once, - on V8 side we can implement required instrumentation using only promise hooks, Disadvantage: - see await-promise test, sometimes scheduled stack was useful since we add catch handler in native code, Implementation details: - on kInit promise hook we need to figure out why promise was created. We analyze builtin functions until first user defined function on current stack. If there is kAsyncFunctionPromiseCreate function then we send kDebugAsyncFunctionPromiseCreated event. If there is kPromiseThen or kPromiseCatch then only if this function is bottom builtin function we send corresponded event to inspector. We need it because Promise.all internally calls .then and in this case we have Promise.all and Promise.then on stack at the same time and we do not need to report this internally created promise to inspector. Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47 Reviewed-on: https://chromium-review.googlesource.com/765208 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#49553}
2017-11-21 15:42:43 +00:00
-- Promise.then --
[inspector] use creation stack trace as parent for async call chains Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved. For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2868493002 Cr-Original-Commit-Position: refs/heads/master@{#45198} Committed: https://chromium.googlesource.com/v8/v8/+/e118462f18a862df81a04486e13dd62997cbfc5a Review-Url: https://codereview.chromium.org/2868493002 Cr-Commit-Position: refs/heads/master@{#45266}
2017-05-11 19:21:24 +00:00
thenableJob2 (test.js:64:57)
[inspector] added creation frame for async call chains for promises With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained. At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback: foo2 (test.js:14:2) -- Promise.resolve (test.js:29:14)-- -- Promise.resolve (test.js:28:14)-- promiseThen (test.js:30:2) More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE BUG=v8:5738 R=dgozman@chromium.org,gsathya@chromium.org Review-Url: https://codereview.chromium.org/2648873002 Cr-Commit-Position: refs/heads/master@{#42682}
2017-01-26 09:32:37 +00:00
(anonymous) (expr.js:0:0)
Running test: testSetTimeouts
foo1 (test.js:10:2)
setTimeout (test.js:72:25)
-- setTimeout --
setTimeout (test.js:72:6)
-- setTimeout --
setTimeout (test.js:71:4)
-- setTimeout --
setTimeouts (test.js:70:2)
(anonymous) (expr.js:0:0)
Reference in New Issue Copy Permalink