Interesting, thanks. Here's the corresponding trace:

                    {
                        "functionName": "UtilEscape",
                        "isBlockCoverage": true,
                        "ranges": [
                            {
                                "count": 1,
                                "endOffset": 120,
                                "startOffset": 28
                            },
                            {
                                "count": 0,
                                "endOffset": 88,
                                "startOffset": 67
                            },
                            {
                                "count": 0,
                                "endOffset": 119,
                                "startOffset": 88
                            }
                        ]
                    }

The problem is that when we attempt to merge nested ranges [0], we incorrectly remove the 'else' range with an execution count of one.

[0] https://cs.chromium.org/chromium/src/v8/src/debug/debug-coverage.cc?l=285&rcl=81094bec9a28e792d5e681fb34599638fbdcfe5a

Fix in flight: https://crrev.com/c/992114

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

commit e42ce2005d535bcbab8c71d683987b68a31fc66f
Author: jgruber <jgruber@chromium.org>
Date: Wed Apr 04 12:46:24 2018

[coverage] Fix invalid coverage block transformation

Before reporting coverage data, we attempt to reduce clutter by
merging nested and consecutive ranges. Nested ranges are merged, if
the child range has the same execution count as the parent range.
Sibling ranges are merged, if one sibling begins where the other ends
and execution counts are identical.

This allowed an invalid transformation in which a range with an
execution count of 1 would be merged into the parent change, but the
sibling range with identical start and end points and a count of 0
would remain, effectively deleting the covered range.

For example:

{start: 0, end: 10, count: 1},
{start: 5, end:  8, count: 1},  // It's invalid to remove this.
{start: 5, end:  8, count: 0}

The fix is to separate the parent and sibling merge passes, and
removing duplicate ranges in-between.

Bug:  chromium:827530 
Change-Id: Ic35eae1d4a106746570ce9cb412ed6710ef6da53
Reviewed-on: https://chromium-review.googlesource.com/992114
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52352}
[modify] https://crrev.com/e42ce2005d535bcbab8c71d683987b68a31fc66f/src/debug/debug-coverage.cc
[modify] https://crrev.com/e42ce2005d535bcbab8c71d683987b68a31fc66f/test/mjsunit/code-coverage-block.js

This bug requires manual review: We are only 12 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Why is this fix needed for m66 vs waiting until 67? 

It's a correctness bug, so ideally we can merge the fix to 66.

how safe is this merge overall? Since this doesn't appear to be release blocking and it's also present in current M65 Stable, my recommendation is to target M67 instead of 66. We're only a week away from Stable, so we're only taking critical changes now. 

In that case let's just wait and not merge at all. The bug is an annoyance, but not critical.

When will it be merged? Do you forget about this bug?)

As per #12 the merge request has been rejected. The fix will be in 67.