- 08 Feb, 2022 1 commit
-
-
Benedikt Meurer authored
Previously the inspector was trying to handle step-out for async functions by annotating the async stacks, but this was merely a hack and didn't work reliably (a) when the async caller that is `await`ing the result of the callee was still in the synchronous part (because then there was no async task yet in the inspector), or (b) not at all when the async stack tracking wasn't enabled or the maximum async stack depth was too small. This CL replaces that hack with a pragmatic solution inside the V8 debugger, where upon `await` we memorize the async function object of the caller on the outer promise of the callee, and when stepping out of the callee we check whether the returned promise has a memorized async function object and if so, we schedule that to resume. This CL thereby effectively reverts https://crrev.com/c/1054618 and replaces it with a V8 debug solution, and thereby further reduces the (memory) overhead of an AsyncStackTrace. Fixed: chromium:1246867 Bug: v8:6161, v8:7753, chromium:1277451, chromium:1280519 Change-Id: I6aa79e90f49d204f66bfd37e7a328c7fb8d635b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3439865Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78990}
-
- 04 Jan, 2022 1 commit
-
-
Benedikt Meurer authored
This change fixes the implementation of the previously introduced API `Runtime.setMaxCallStackSizeToCapture` to work correctly and also apply (consistently) to stack traces captured by V8 when exceptions are thrown. It does so in a fully backwards compatible manner. This change thus makes the previous fix for catapult (which landed in http://crrev.com/c/3347789) effective, and therefore ensures that real world performance benchmarks aren't affected by the use of the `Runtime` domain in the catapult test framework. Note this is basically a reland of crrev.com/c/3361839, but without touching the stack traces for console messages (which led to the regressions in crbug/1283516, crbug/1283523, etc.). Fixed: chromium:1280831 Bug: chromium:1283162, chromium:1278650, chromium:1258599 Bug: chromium:1280803, chromium:1280832, chromium:1280818 Doc: https://bit.ly/v8-cheaper-inspector-stack-traces Change-Id: I3dcec7b75d76ca267fac8bd6fcb2cda60d5e60dd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364086Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78479}
-
- 03 Jan, 2022 1 commit
-
-
Benedikt Meurer authored
This reverts commit 34f73cc7. Reason for revert: Performance regressions throughout a lot of system health and browsing benchmarks. Original change's description: > [inspector] Fix `Runtime.setMaxCallStackSizeToCapture`. > > This change fixes the implementation of the previously introduced API > `Runtime.setMaxCallStackSizeToCapture` to work correctly and also apply > (consistently) to stack traces captured by V8 when exceptions are > thrown. It does so in a fully backwards compatible manner. > > This change thus makes the previous fix for catapult (which landed in > http://crrev.com/c/3347789) effective, and therefore ensures that real > world performance benchmarks aren't affected by the use of the `Runtime` > domain in the catapult test framework. > > Bug: chromium:1283162, chromium:1278650, chromium:1258599 > Bug: chromium:1280803, chromium:1280832, chromium:1280818 > Fixed: chromium:1280831 > Doc: https://bit.ly/v8-cheaper-inspector-stack-traces > Change-Id: I4ec951a858317fa49096cd4023deb0104d92c9c9 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3361839 > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/main@{#78458} Bug: chromium:1283162, chromium:1278650, chromium:1258599 Bug: chromium:1280803, chromium:1280832, chromium:1280818 Bug: chromium:1280831 Change-Id: Id1efaffa2f7f08c47f833f68b8a297494edee21e Fixed: chromium:1283751, chromium:1283749, chromium:1283746 Fixed: chromium:1283729, chromium:1283700, chromium:1283700 Fixed: chromium:1283691, chromium:1283687, chromium:1283678 Fixed: chromium:1283677, chromium:1283676, chromium:1283675 Fixed: chromium:1283674, chromium:1283618, chromium:1283536 Fixed: chromium:1283523, chromium:1283516 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364078 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78462}
-
- 31 Dec, 2021 1 commit
-
-
Benedikt Meurer authored
This change fixes the implementation of the previously introduced API `Runtime.setMaxCallStackSizeToCapture` to work correctly and also apply (consistently) to stack traces captured by V8 when exceptions are thrown. It does so in a fully backwards compatible manner. This change thus makes the previous fix for catapult (which landed in http://crrev.com/c/3347789) effective, and therefore ensures that real world performance benchmarks aren't affected by the use of the `Runtime` domain in the catapult test framework. Bug: chromium:1283162, chromium:1278650, chromium:1258599 Bug: chromium:1280803, chromium:1280832, chromium:1280818 Fixed: chromium:1280831 Doc: https://bit.ly/v8-cheaper-inspector-stack-traces Change-Id: I4ec951a858317fa49096cd4023deb0104d92c9c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3361839 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78458}
-
- 24 Nov, 2021 1 commit
-
-
Benedikt Meurer authored
This is an unused overload, which doesn't add any value to keep around. Bug: none Change-Id: I6e004e28f6ec8d4c8de87a1e86d331a624694659 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3297896 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78052}
-
- 11 Nov, 2021 1 commit
-
-
Benedikt Meurer authored
This introduces a stack frame cache on the V8Debugger level, which de-duplicates StackFrame instances based on their scriptId, line and column number. This greatly reduces the memory pressure when debugging huge Web applications that have a lot of async activity (and potentially have scripts with huge URLs). This is guided by the observation that even in huge applications, there are only a very limited number of call sites that initiate async activity and hence we only have a limited number of distinct StackFrames to worry about (despite having to maintain a large number of async stack traces overall). As a nice side effect, this CL also greatly reduces the negative performance impact of collecting async stack traces in these huge applications. Generally speaking this is mostly duct tape however, and we might want to follow up with changes to make capturing (and storing) stack frames even cheaper. Fixed: chromium:1268436 Change-Id: Ib212b3c97dce2bb7ca47d5875d45cf20b9b97afe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272577 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/main@{#77835}
-
- 30 Sep, 2021 1 commit
-
-
Benedikt Meurer authored
The V8 Inspector was sending an additional frame as part of async stack traces for async functions, which pointed to the first executed `await` in the async function. This is leaking an implementation detail of how (and more precisely when) the inspector decides to collect this stack trace. From the users perspective the async part of the stack trace is supposed to capture what happened _prior to the task_ - meaning in case of async functions: What lead to the execution of the async function. This is reflected by the fact that the DevTools front-end (and the V8 Inspector itself) performs post-processing on these async call stacks, removing the misleading top frame from it. But this post-processing is not applied consistently to all async stack traces (i.e. the Console message stack traces don't get this), and potentially also not applied consistently across consumers of the Chromium debugger backend. Instead the V8 Inspector now removes the top frame itself and thus reports `await` consistently with how other async tasks are reported to debugger front-ends. Note: This preserves backwards compatibility with old versions of devtools-frontend, which do post-processing (for the Call Stack) only on async stack traces marked with "async function", while we now mark these async stack traces with "await" instead (aligned with what the front-end is using as user visibile string anyways in the Call Stack section, and this matching will be updated in a separate follow up CL to look for "await" instead of "async function"). Before: https://imgur.com/kIrWcIc.png After: https://imgur.com/HvZGqiP Fixed: chromium:1254259 Bug: chromium:1229662 Change-Id: I57ce051a28892177b6b96221f083ae957f967e52 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3193535 Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77157}
-
- 24 Aug, 2021 1 commit
-
-
Dan Elphick authored
This is a reland of d1b27019 Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
-
- 23 Aug, 2021 2 commits
-
-
Dan Elphick authored
This reverts commit d1b27019. Reason for revert: Broke vtune build, tsan build and possibly others Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Bug: v8:11965 Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#76428}
-
Dan Elphick authored
This moves every single class/function out of include/v8.h into a separate header in include/, which v8.h then includes so that externally nothing appears to have changed. Every include of v8.h from inside v8 has been changed to a more fine-grained include. Previously inline functions defined at the bottom of v8.h would call private non-inline functions in the V8 class. Since that class is now in v8-initialization.h and is rarely included (as that would create dependency cycles), this is not possible and so those methods have been moved out of the V8 class into the namespace v8::api_internal. None of the previous files in include/ now #include v8.h, which means if embedders were relying on this transitive dependency then it will give compile failures. v8-inspector.h does depend on v8-scripts.h for the time being to ensure that Chrome continue to compile but that change will be reverted once those transitive #includes in chrome are changed to include it directly. Full design: https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing Bug: v8:11965 Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76424}
-
- 23 Jul, 2021 1 commit
-
-
Benedikt Meurer authored
The AsyncStackTrace had some magical self-healing where it'd try to not stitch together async stack traces when the instrumentation seemed to be broken. This silent self-healing however seems to be broken itself, and instead of papering over the problem we should fix instrumentation bugs when they are observed. Fixed: chromium:1231064 Change-Id: I2bcc85679abdbe6f4df4866cb951c5f6cefb4f67 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3048181 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#75885}
-
- 06 May, 2021 1 commit
-
-
Benedikt Meurer authored
Within the inspector we should be consistent about passing the script ID always as integer, and only convert to String16 when actually needed. That (a) saves memory (and some runtime overhead) when stashing away call frames, for example in case of async stack traces, and (b) reduces confusion which representation to chose. Bug: chromium:1162229 Change-Id: I9591931da0a307779372f36aba6e155ec22bbe3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876856 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#74410}
-
- 15 Dec, 2020 1 commit
-
-
Sigurd Schneider authored
Embedders often use integers for representing scriptIds, but the stack trace interface only exposes scriptIds as strings, which introduces the need for parsing the scriptId string to an int in the embedder. This CL also exposes the scriptId as an integer. Bug: chromium:1158782 Change-Id: I7d85ad1497f2eff17f5cd8f9c87f0c72696c1ecf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589973 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#71761}
-
- 18 Nov, 2020 1 commit
-
-
Zhi An Ng authored
Bug: v8:11074 Change-Id: I71fabf7628ec13440585c24381f5ba89e4df03d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543168Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71246}
-
- 09 Jan, 2020 1 commit
-
-
Eric Leese authored
Inspector will no longer report per-function wasm scripts or provide wasm disassembly. Locations in wasm are now consistently reported through the inspector API as lineNumber=0 columnNumber=byte offset in module. Bug: chromium:1013527, chromium:1003022 Change-Id: Ide85bbaa85ad75f29248ff82a3e7f3e40688d377 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991481 Commit-Queue: Eric Leese <leese@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#65660}
-
- 26 Jun, 2019 1 commit
-
-
Johannes Henkel authored
... when building inspector objects. This is useful in Chromium, when recording the initiator information for navigations. See https://chromium-review.googlesource.com/c/chromium/src/+/1674885 Change-Id: Ib9ddcaf05586ca1f48a31921a20ab11a703ec7b0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677381Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Commit-Queue: Johannes Henkel <johannes@chromium.org> Cr-Commit-Position: refs/heads/master@{#62389}
-
- 18 Oct, 2018 1 commit
-
-
Alexey Kozyatinskiy authored
Async tail might be long. On frontend side we use only top frame so we can report tail using id. R=dgozman@chromium.org Bug: chromium:873865 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie9e6b5c4c000cc6bedce2d5fec9f3fa22ea21768 Reviewed-on: https://chromium-review.googlesource.com/c/1286959 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#56784}
-
- 09 Aug, 2018 1 commit
-
-
Alexey Kozyatinskiy authored
Some clients (see Node.js) use platform path as ScriptOrigin. Reporting platform path in protocol makes using protocol much harder. This CL introduced V8InspectorClient::resourceNameToUrl method that is called for any reported using protocol url. V8Inspector uses url internally as well so protocol client may generate pattern for blackboxing with file urls only and does not need to build complicated regexp that covers files urls and platform paths on different platforms. R=lushnikov@chromium.org TBR=yangguo@chromium.org Bug: none Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Iff302e7441df922fa5d689fe510f5a9bfd470b9b Reviewed-on: https://chromium-review.googlesource.com/1164624 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#55029}
-
- 23 Jul, 2018 1 commit
-
-
Ross McIlroy authored
Use the new Isolate version of the methods. BUG=v8:7754 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Id4f10d23927d6ae50cb458b5cac744617fa83e53 Reviewed-on: https://chromium-review.googlesource.com/1145387Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#54613}
-
- 04 Jun, 2018 1 commit
-
-
Hidy Han authored
1) Let firstNonEmptySourceURL traverse async stack trace (if any). 2) Expose Runtime.setMaxCallStackSizeToCapture API to control the number of frames to capture. Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I72f021c6ae9e317af67c3114fd4860ce0f06d977 Reviewed-on: https://chromium-review.googlesource.com/1085643 Commit-Queue: Hidy Han <hidyhan@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Pavel Feldman <pfeldman@chromium.org> Cr-Commit-Position: refs/heads/master@{#53506}
-
- 31 May, 2018 1 commit
-
-
Alexey Kozyatinskiy authored
If async function A awaited async function B, stepOut from function B should go to function A. Bug: v8:7753 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Iedc1d8b85a52aa60519e56b319325436fc2168c9 Reviewed-on: https://chromium-review.googlesource.com/1054618 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#53451}
-
- 07 May, 2018 1 commit
-
-
Hidy Han authored
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I6390806935ada277db965718a804ab090b3be5dd Reviewed-on: https://chromium-review.googlesource.com/1041157Reviewed-by: Pavel Feldman <pfeldman@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Commit-Queue: Hidy Han <hidyhan@chromium.org> Cr-Commit-Position: refs/heads/master@{#53047}
-
- 02 Feb, 2018 1 commit
-
-
jgruber authored
This check verifies that all .h files in the src/ directory have an include guard of the form #ifndef V8_PATH_TO_FILE_H_ #define V8_PATH_TO_FILE_H_ // ... #endif // V8_PATH_TO_FILE_H_ The check can be skipped with a magic comment: // PRESUBMIT_INTENTIONALLY_MISSING_INCLUDE_GUARD Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I0a7b96abec289ad60f64ba8418f1892a6969596d Reviewed-on: https://chromium-review.googlesource.com/897487Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#51079}
-
- 14 Dec, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
Async stack trace can contain empty syncrhonous stack and external stack. R=dgozman@chromium.org Bug: chromium:790567 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I2b04743f7c4f15a038eb1041cc7fc117d438b6b2 Reviewed-on: https://chromium-review.googlesource.com/822971 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#50117}
-
- 23 Nov, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
If async stack is longer then max depth, we add externalParent as id, client can fetch next max depth async stacks by Debugger.getStackTrace. R=dgozman@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I89d461e672251f03fb239f4f16ae3b0374fce766 Reviewed-on: https://chromium-review.googlesource.com/776242 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#49595}
-
- 22 Nov, 2017 3 commits
-
-
Alexey Kozyatinskiy authored
Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. TBR=dgozman@chromium.org,jgruber@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4 Reviewed-on: https://chromium-review.googlesource.com/786274 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49591}
-
Clemens Hammacher authored
This reverts commit 3a41b697. Reason for revert: Break msvc: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/250 Original change's description: > [inspector] introduced stackTraceId and externalAsyncTask API > > Sometimes we need to capture stack trace on one debugger and use it > later as a parent stack on another debugger (e.g. worker.postMessage). > > This CL includes following addition to our protocol and v8-inspector.h: > - added Runtime.StackTraceId, this id represents stack trace captured > on debugger with given id, > - protocol client can fetch Runtime.StackTrace by > Runtime.StacKTraceId using Debugger.getStackTrace method, > - externalParent field is added to Debugger.paused event, it may > contain external parent stack trace, > - V8Inspector::storeCurrentStackTrace captures current stack trace > and returns V8StackTraceId for embedder this id can be used as > argument for V8Inspector::externalAsyncTaskStarted and > V8Inspector::externalAsyncTaskFinished method. Any async stack > trace captured between these calls will get passed external stack > trace as external parent. These methods are designed to be called > on different debuggers. If async task is scheduled and started on > one debugger user should continue to use asyncTask* API, > - Debugger.enable methods returns unique debuggerId. > > Bug: chromium:778796 > Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng > Change-Id: I16aba0d04bfcea90f3e187e635a0588c92354539 > Reviewed-on: https://chromium-review.googlesource.com/754183 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Dmitry Gozman <dgozman@chromium.org> > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49582} TBR=dgozman@chromium.org,pfeldman@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org,jgruber@chromium.org Change-Id: I9b52354fa0841e5148596cf594317f2e5fe508ea No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Reviewed-on: https://chromium-review.googlesource.com/786152Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#49584}
-
Alexey Kozyatinskiy authored
Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I16aba0d04bfcea90f3e187e635a0588c92354539 Reviewed-on: https://chromium-review.googlesource.com/754183Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49582}
-
- 21 Nov, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
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}
-
- 16 May, 2017 1 commit
-
-
kozyatinskiy authored
By default we just break when we first time reach passed location, with current - we'll break at passed location only when it happens within the same stack frame. BUG=v8:6397 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2879923003 Cr-Commit-Position: refs/heads/master@{#45354}
-
- 11 May, 2017 1 commit
-
-
kozyatinskiy authored
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}
-
- 10 May, 2017 1 commit
-
-
kozyatinskiy authored
Revert of [inspector] use creation stack trace as parent for async call chains (patchset #2 id:20001 of https://codereview.chromium.org/2868493002/ ) Reason for revert: CHECK is too strict. Original issue's description: > [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-Commit-Position: refs/heads/master@{#45198} > Committed: https://chromium.googlesource.com/v8/v8/+/e118462f18a862df81a04486e13dd62997cbfc5a TBR=dgozman@chromium.org,alexclarke@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:6189 Review-Url: https://codereview.chromium.org/2868423004 Cr-Commit-Position: refs/heads/master@{#45242}
-
- 09 May, 2017 1 commit
-
-
kozyatinskiy authored
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-Commit-Position: refs/heads/master@{#45198}
-
- 28 Apr, 2017 1 commit
-
-
kozyatinskiy authored
- we should always set creation async stack if it's available regardless existing of current parent async stack, - we should cleanup parent link iff there is no creation and schedule async stack for parent. Let's consider example: Promise.resolve().then(x => x).then(x => x), there is three promises which will call following instrumentation: 1) created #1 (Promise.resolve()) - collected stack #1 2) scheduled #1 - collected stack #2 3) created #2 with #1 as parent (first .then) - collected stack #3 4) created #3 with #2 as parent (first .then) - collected stack #4 5) started #2 - use stack #2 as scheduled 6) scheduled #2 - collected stack #6 7) finished #2 8) started #3 - use stack #6 as scheduled 9) scheduled #3 - collected stack #7 10) finished #3 If we collect stacks between step 4 and 5, it's possible to collect scheduled stack #2 but still have creation stack for #2 - stack #3 - so we always need to add creation event if scheduled is collected. If we collect stacks between created and scheduled we should not remove parent link even if parent was not scheduled yet. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2844753002 Cr-Commit-Position: refs/heads/master@{#44990}
-
- 20 Apr, 2017 1 commit
-
-
kozyatinskiy authored
Since we already have cache on V8 side we can introduce caching on inspector side. It will decrease memory consumption and reduce time which we spend for collecting stacks. See [1] for details. [1] https://docs.google.com/a/google.com/document/d/13H1Pn6dekcwqlaYP26CfyyYGuL-U9LtUPWmt3TIpOag/edit?usp=sharing BUG=v8:6189 R=dgozman@chromium.org,yangguo@chromium.org Review-Url: https://codereview.chromium.org/2825903002 Cr-Commit-Position: refs/heads/master@{#44753}
-
- 18 Apr, 2017 3 commits
-
-
kozyatinskiy authored
- separated V8StackTraceImpl and AsyncStackTrace, - V8Debugger owns all AsyncStackTrace and cleanup half of them when limit is reached (first created - first cleaned), - V8StackTraceImpl, AsyncStackTrace and async-task-related tables in V8Debugger have weak reference to other async stack traces. - async tasks are cleared with related async stacks. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2816043006 Cr-Original-Commit-Position: refs/heads/master@{#44670} Committed: https://chromium.googlesource.com/v8/v8/+/1bca73bc832c645138bd3e0306fcaa8bb44dad04 Review-Url: https://codereview.chromium.org/2816043006 Cr-Commit-Position: refs/heads/master@{#44694}
-
machenbach authored
Revert of [inspector] avoid cloning of async call chains (patchset #7 id:120001 of https://codereview.chromium.org/2816043006/ ) Reason for revert: Speculative revert. Seems to block the roll: https://codereview.chromium.org/2822983004/ Might require changing a browser test first? Original issue's description: > [inspector] avoid cloning of async call chains > > - separated V8StackTraceImpl and AsyncStackTrace, > - V8Debugger owns all AsyncStackTrace and cleanup half of them when limit is reached (first created - first cleaned), > - V8StackTraceImpl, AsyncStackTrace and async-task-related tables in V8Debugger have weak reference to other async stack traces. > - async tasks are cleared with related async stacks. > > BUG=v8:6189 > R=dgozman@chromium.org > > Review-Url: https://codereview.chromium.org/2816043006 > Cr-Commit-Position: refs/heads/master@{#44670} > Committed: https://chromium.googlesource.com/v8/v8/+/1bca73bc832c645138bd3e0306fcaa8bb44dad04 TBR=dgozman@chromium.org,kozyatinskiy@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6189 Review-Url: https://codereview.chromium.org/2825713002 Cr-Commit-Position: refs/heads/master@{#44678}
-
kozyatinskiy authored
- separated V8StackTraceImpl and AsyncStackTrace, - V8Debugger owns all AsyncStackTrace and cleanup half of them when limit is reached (first created - first cleaned), - V8StackTraceImpl, AsyncStackTrace and async-task-related tables in V8Debugger have weak reference to other async stack traces. - async tasks are cleared with related async stacks. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2816043006 Cr-Commit-Position: refs/heads/master@{#44670}
-
- 12 Apr, 2017 1 commit
-
-
kozyatinskiy authored
We currently store it in parent stack trace but stacks with the same parent can have different creations stacks. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2807273002 Cr-Commit-Position: refs/heads/master@{#44624}
-
- 26 Jan, 2017 1 commit
-
-
kozyatinskiy authored
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}
-