This magic signature has only been hit 93 times, spread out over the last month and a half, so I'm not sure why I have hit the crash three times this afternoon, but I have.

If you restrict the query to crash.Address=0x00000000 then there are only five crashes and I'm three of them. Let me know if there is some extra investigating I should do.

The callstacks don't make sense to me, my initial reaction is that there is some kind of memory corruption and that the crash has nothing to do with token fetches.

Renderer creation is really not a place where someone would fetch a OAuth token, and even if they did, then the callstack would look very different (at the very least it means that this callstack is heavily truncated).

I'm not sure what to do with this bug, I'd be happy to dig into it more if you think that there is really something there, but without more information I assume that the problem is not in the token fetcher.

I'll dig in to the crash dumps a bit more deeply and report back once I understand how the call stack ended up looking that way.

Because source indexing was broken on these builds the debugging process involves some extra steps. After manually downloading the PDBs I needed to do this:

git checkout 95065abbd18c9be7661f8f6492 && gclient sync
Add my local repo to windbg's source path

Looking again at the crash dumps with a slightly more critical eye I can see (in the assembly language) that there is clearly a call from task_manager::RenderProcessHostTaskProvider::CreateTask to OAuth2AccessTokenFetcher::FireOnGetTokenSuccess. But, as was pointed out, that makes no sense. The source code shows a call to NotifyObserverTaskAdded.

It turns out that NotifyObserverTaskAdded and OAuth2AccessTokenFetcher::FireOnGetTokenSuccess are code-gen identical and were therefore /opt:ICF folded. That is, both of them grab an object pointer from this+8, load its vtable, and then tail-call jump/call the function whose address is at offset 8:

chrome!OAuth2AccessTokenFetcher::FireOnGetTokenSuccess:
00007ff8`da1d2d30 488b4908        mov     rcx,qword ptr [rcx+8]
00007ff8`da1d2d34 488b01          mov     rax,qword ptr [rcx]
00007ff8`da1d2d37 488b4008        mov     rax,qword ptr [rax+8]
00007ff8`da1d2d3b 48ffe0          jmp     rax

So the linker folded them together and assigned them the FireOnGetTokenSuccess name. Awesome!

Querying for a magic signature of task_manager::TaskProvider::NotifyObserverTaskAdded finds one additional crash. Still not many.

Title updated. Owner removed. Priority lowered. I'm still not sure what the bug is, or whether it is important enough to matter. Monitoring.