caseq/kozy could you assist in assigning to the proper party?

Scripts can be kept alive by precise coverage, and AFAIK we don't have a mechanism to clear old scripts on navigation.

I'm also not sure what the expectation should be. Do we really want to clear existing coverage data on navigation?

Yang, wdyt?

This is working as intended from V8, we need to keep functions alive to not accidentally lose them to GC.

FWIW, V8 does not have any concept of page navigation. Maybe DevTools should stop and restart precise coverage on page navigation?

If I'm reading your comments right, the issue isn't that coverage has been enabled the entire time and I see coverage for a previous page (I would expect that to be the case). The issue is that I'm starting coverage while on about:blank before navigating to page B and yet I'm receiving coverage information for page A that was never touched while coverage was enabled.

Or are you saying that simply calling startPreciseCoverage, stopPreciseCoverage while on about:blank will flush out the previous page and then I can startPreciseCoverage normally as I would expect?

Let me see if I understand this correctly.

- You navigate to page A
- Then you navigate to new tab page
- You enable precise coverage
- Then you navigate to page B
- You now take coverage
- The coverage info includes scripts from A
- These coverage info from A includes coverage data from before enabling precise coverage.

Is that correct?

I think I know what the issue is... while executing, V8 always collects call counts, for other reasons than code coverage. These call counts are not always accurate. To use this data, you can use getBestEffortCoverage without enabling precise coverage upfront.

When you enable precise coverage, the existing call count data is not cleared, and "leak" into the precise coverage.

You can try one of the following to confirm this theory:

- Immediately after enabling precise coverage, call takePreciseCoverage to clear coverage info.
- Add the following code after this line:
https://cs.chromium.org/chromium/src/v8/src/debug/debug-coverage.cc?q=debug-coverage.cc&sq=package:chromium&dr&l=544

vector->clear_invocation_count();

That description of the issue is correct I'll give that a try thanks!

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/6cd99b38b95abd62f85c6c7ff954a797a8a95e14

commit 6cd99b38b95abd62f85c6c7ff954a797a8a95e14
Author: Yang Guo <yangguo@chromium.org>
Date: Mon Aug 28 03:49:59 2017

[coverage] clear call counts for precise coverage.

This is so that precise coverage starts with a clean slate.
The old behavior can be emulated by calling getBestEffortCoverage
before starting precise coverage.

R=jgruber@chromium.org

Bug: chromium:757998
Change-Id: Ib3ee2316966f676456198159bdcf8ba8b9d3896f
Reviewed-on: https://chromium-review.googlesource.com/635084
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47629}
[modify] https://crrev.com/6cd99b38b95abd62f85c6c7ff954a797a8a95e14/src/debug/debug-coverage.cc
[modify] https://crrev.com/6cd99b38b95abd62f85c6c7ff954a797a8a95e14/test/inspector/cpu-profiler/coverage-block-expected.txt
[modify] https://crrev.com/6cd99b38b95abd62f85c6c7ff954a797a8a95e14/test/inspector/cpu-profiler/coverage-expected.txt