Joao, any insights?

https://cs.chromium.org/chromium/src/components/policy/core/common/schema_registry.cc?q=schema_registry.cc&sq=package:chromium&dr&l=58

It's uninstalling an extension that wasn't mapped before. Seems like ExtensionService::OnAllExternalProvidersReady is triggering delayed notifications of uninstalls. AFAICS, this can be safely ignored.

OK, we should just switch this to a DLOG(WARNING) then. Putting on my plate for a future noogler.

Thought a bit more about this. Hitting this NOTREACHED() means that we're seeing an extension getting uninstalled that we didn't see getting installed in the first place.

1. maybe an install notification was missed (meaning that we aren't correctly tracking all installed extensions)

2. or this ran on startup before we got a list of all installed extensions (more likely, given that OnAllExternalProvidersReady is called once on startup. We should have a list of installed extensions before getting notified of any uninstalls.)

I think it's (2) and that's not a big problem if confirmed. (1) would be a real bug somewhere else.

Is there anything I can do to help debug when this happens to me? It isn't always reproducible but when it is, it does tend to waste my time rebuilding / etc so I would be happy to help out investigating a fix.

Try logging the ID of the extension that caused the problem, and log the list of all the extensions known to the SchemaRegistry at that time.

This could confirm that the SchemaRegistry is just getting notified of an uninstall before it gets the initial list of installed extensions.

If that's the case, the fix would be to either initialize that list earlier, or to delay the unregistration.

Seems like this is the problem:

https://cs.chromium.org/chromium/src/chrome/browser/extensions/extension_service.cc?sq=package:chromium&dr=C&rcl=1473160695&l=1334

Is the problematic extension being installed via a policy? If so then this is a huge bug: the ExtensionService thinks that the extension isn't being claimed anymore by any extension loader! This means that extensions installed by policy may be flakily uninstalled at startup.

However, OnAllExternalProvidersReady() is blocked until the policy_extension_loader is done, so this should never happen. It may hint at a severe bug in there though.

This just happened again to me this morning. The id of the failing component is:
id: noondiphcddnnabmjcihcjfbhfklnnep
domain: POLICY_DOMAIN_EXTENSIONS

The only other component known in the schema_map_ is the POLICY_DOMAIN_CHROME which has the empty string as an id.

Please let me know if I've left something out. Is there a way to see human readable extension ids?

It's the Google Password Alert extension:

https://chrome.google.com/webstore/detail/password-alert/noondiphcddnnabmjcihcjfbhfklnnep?hl=en

And about:policy shows that it's being force-installed.

So we do have a problem that force-installed extensions are not getting reported to the ExtensionService before OnAllExternalProvidersReady() is fired, which means that the policy loader is becoming ready too early. This is a serious bug!

oh dang :( Let me know if there's more I can do to help out.

So sounds like Extensions system is firing OnAllExternalProvidersReady() prematurely when chromoting. Anyone on chromoting or extensions team able to look at this?

Hi,

The phrase "when chromoting" is ambiguous because it could apply to either the client or the host end of the Chromoting connection.

I will guess that it applies to the Host end in this case, because the platform is marked as Linux, and Chromoting sets up a virtual desktop session that is separate from the main physical session, and causes Chrome to run with a different profile data directory.

The mere fact of running in a separate profile may explain why the problem is seen only in the Chromoting session.

To isolate Chromoting as the actual cause, you would need to run Chrome with the same profile directory ('--user-data-dir=/some/dir') both inside and outside the virtual Chromoting session.

csharrison, if you want to help debug this, can you try Lambros's suggestion?

Yes I can try this. I may not have time to do it right away though. Is there a simple way to see what my profile directory is when running chrome? I'm guessing the best way is to set my profile directory outside of chromoting to the directory used inside chromoting.

If you have Chrome successfully running, you can browse to chrome://version/ and it will appear under Profile Path (I think you go up 1 level for the user-data-dir).

In Chromoting, we set $CHROME_USER_DATA_DIR to ~/.config/chrome-remote-desktop/chrome-profile .

If you want to run Chrome against a particular user-data-dir, you can provide it on the Chrome command-line as --user-data-dir=/path/to/dir (or you can set $CHROME_USER_DATA_DIR)

 Issue 642362  has been merged into this issue.

I've merged  issue 642362  that is also about hitting this NOTREACHED. I think, the root cause is probably the same as in this bug. I put some results of my investigation into the bug description.


Also there's another easily reproducible way to hit this NOTREACHED:

1. Set up a preference file that prescribes to force install an extension, e.g.: create /usr/share/chromium/extensions/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.json (correct the path if you use stable Chrome and change the extension id to any existing one) with the following contents:
{"external_update_url":"https://clients2.google.com/service/update2/crx"}

2. Run Chrome. The extension should be force installed.

3. Close Chrome. Delete the preference file created in step 1.

4. Run Chrome. The NOTREACHED statement will be hit.

I haven't hit this in a long time, and it looks like #17 has a repro, so I'm moving myself to cc.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

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

Dropping into enterprise triage queue.