Just fyi this does not happen at the login window, only once logged in.  

Issue 906314 has been merged into this issue.

Issue 906780 has been merged into this issue.

We have over 70,000 chromebooks holding at 69 until we get approval that the testing app we use is secure on 70.

Can someone gather device logs after reproducing this?

https://support.google.com/chrome/a/answer/3293821?hl=en

Also network logs as described at:

https://support.google.com/chrome/a/answer/6271171?hl=en

would be useful.

If this is fixed in 70 then the solution is to update to 70, we don't backport fixes to older versions. If you are seeing this issue in 70, please gather above logs.

did a quick check on two customer users seeing this issue and no special policy is set for omnibox search provider or search suggest.

I don't have another device producing the issue that I can test with.  Whats odd is that the issue did not seem to appear as part of a new v69 build.  It just started happening later.  I was confused but wrote it off with the first one, but 2 in 2 days was strange.  

We forced everything up to v70 yesterday and that is a valid solution for us.  Still wanted to bring the issue up incase it was something bigger

Closing based on Comment 9.

jonathan.evans@newspring.cc: Please feel free to re-open if you encounter this issue again.

we are still experiencing this issue. we cannot update to v70 yet, hope to soon as our state mandated testing vendor, Pearson, supports v70 for standardized testing. we have sent logs/videos of issue to our open support case with Google, they directed us to this bug forum.

skare@: FYI, looks like some kind of crash down in DocumentSuggestionsService::AccessTokenAvailable().

Reopening because I'm concerned if this bug just goes away, as I don't see anything that would explicitly fix it. +blundell since this is going through the identity service framework so he may know something about an M69 crash in this area.

Hi,

I agree that we should not close this bug without understanding better what is happening.

There is no crash that I know of that would explain this.

I looked at DocumentSuggestionsService::AccessTokenAvailable() and I don't see anything problematic.

+Sylvain

Sylvain, do you see anything subtle in the way that the AccessTokenFetcher/PAATF handle AccessTokenInfo that could result in this crash stack? One difference that I see between this usage site and common usage is the calling of c_str() on the returned access_token_info.token. Could that be exposing some subtle bug with how we're passing through the state? I doublechecked everything and didn't see a problem, but maybe I'm missing something. Thanks!

https://crash.corp.google.com/browse?stbtiq=fcb21d9ce89fd43d

AFAICT from reading the callstack, the crash happens after the value from the AccessTokenInfo has been used (i.e. the call to StringPrintf has completed).

As the crash happens when accessing address 0x000001d8, it looks likely that this correspond to a nullptr network::RessourceRequest (from a quick examination of network::ResourceRequest it is likely for the offset of headers.headers_ to be 0x1d8 bytes).

drive-by:
Document provider is a feature under development / experimentation.  The fact that the bug appeared and disappeared based on version number probably has to do do with how the configs enabling the feature have been set up and changed at various points.  I agree the root cause should be investigated and fixed, certainly before enabling the feature more widely.

Thank you for the insights, Sylvain and Mark!

Sylvain's analysis makes sense to me. That said, the ResourceRequest being null seems extremely odd indeed from looking at the code:

https://cs.chromium.org/chromium/src/components/omnibox/browser/document_suggestions_service.cc?sq=package:chromium&g=0&l=109
https://cs.chromium.org/chromium/src/components/omnibox/browser/document_suggestions_service.cc?sq=package:chromium&g=0&l=125
https://cs.chromium.org/chromium/src/components/omnibox/browser/document_suggestions_service.cc?sq=package:chromium&g=0&l=137

apologies, thought I updated this earlier.

Looking at the history, I believe the following change had a block that fixes the crash, but it wasn't shipped until M70 - a recent study enabled the code for 1% then 2%, including M69.

https://chromiumdash.appspot.com/commits?commit=d52d2fed09a28d0b9e9b2eb200df8c82eb33b247&platform=Android

For anyone following along at home, the problem was that |request| was std::move'd twice in a row :). Sylvain's hunch from c#15 that there was a null ResourceRequest was indeed correct :).

Thanks for the work to resolve this!