I am guessing this is from SimpleFeature. Other uses have constant pattern that is valid, whereas SimpleFeature seems to be using a variable I can't immediately tell where from.

Is there a stack trace or repro?

the repro steps aren't obvious since I only have runtime logs and trying to work backwards.

I tried running a unittest but couldn't reproduce.
https://chromium-review.googlesource.com/c/chromium/src/+/1119617

Looking closer to the logs, maybe:

chrome_system_log 
[10884:10884:0629/115125.543933:ERROR:child_process_security_policy_impl.cc(1145)] Invalid isolated origin: xxxx
[10884:10884:0629/115125.691746:ERROR:configuration_policy_handler_list.cc(91)] Unknown policy: NTPContentSuggestionsEnabled
[10884:10884:0629/115125.975711:ERROR:url_pattern.cc(165)] NOTREACHED() hit.
[10884:10884:0629/115125.975748:ERROR:url_pattern.cc(165)] NOTREACHED() hit.

many lines of url_pattern in logs, but most of the log is coming from pid 1:1, which probably means it's running inside a pid namespace.

Can you repro on a custom build of CrOS?  If you build with DCHECKs enabled, these NOTREACHEDs will become crashes, which should have a stack trace.

So far I cannot reproduce with a dev image.

(I can definitely see this happening on an enterprise enrolled device, but not on my dev image with test account).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8f4a641ed755cee371869e6314b94bb8eb9897a6

commit 8f4a641ed755cee371869e6314b94bb8eb9897a6
Author: Junichi Uekawa <uekawa@google.com>
Date: Mon Jul 09 01:58:35 2018

Add extra error logging so that something is logged.

NOTREACHED is reached several hundred times but I don't know where
that's coming from.

BUG=chromium:856948

Change-Id: Ia58898bfa1428c03113d99816598f89df3a5e9fb
Reviewed-on: https://chromium-review.googlesource.com/1124201
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#573198}
[modify] https://crrev.com/8f4a641ed755cee371869e6314b94bb8eb9897a6/extensions/common/url_pattern.cc

result 2 == 
  kParseErrorInvalidScheme ?

there's URL:8 and URL:9 in my logs, so there's probably two related logs.

I see them close by PAC config failures; might they be related?

2018-07-18 16:34:29.571 E PacProcessor: Error: Uncaught TypeError: match[1].toUpperCase is not a function
2018-07-18 16:34:29.571 E PacProcessor: Error Running PAC: 
2018-07-18 16:34:29.571 E PacProxy: v8 Proxy request failed.

Just confirming: the pattern we're trying to parse is literally "<URL: 8>"?  If so, that's absolutely invalid, and failing is the right thing to do here.  The invalid scheme error is just the first thing that fails.

Do you know where this "<URL: 8>" is coming from?

#13, no it is actually something else I am going to grab the actual logs real-soon-now.

I've finally got around to obtaining the log:

[1:1:0718/183732.488976:ERROR:url_pattern.cc(167)] Invalid pattern was given http://%2A/* result 2
[1:1:0718/183732.489126:ERROR:url_pattern.cc(169)] NOTREACHED() hit.
[1:1:0718/183732.489193:ERROR:url_pattern.cc(167)] Invalid pattern was given https://%2A/* result 2
[1:1:0718/183732.489245:ERROR:url_pattern.cc(169)] NOTREACHED() hit.


http{,s}://%2A/*

%2A is urlescape of "*" ? Is that valid for domain part too?

I hear that this might be due to v8 having been invoked with wrong character encoding flag and not being able to split scheme part off, that has since been fixed, but can't find reference to the exact fix.

found it.
https://b.corp.google.com/issues/110114134

Is this bug fixed? I hit this DCHECK when trying to build chrome via CRD

No there's still lots of stuff in production builds that I have no idea how to repro, if you have a reliable repro for a debug build that would be a good step forward.

actually, probably that's a different one from what I was trying to chase down because my issue was caused by Google enterprise policy and v8 running in wrong charset.