+mark, for crashpad plans (or perhaps is already a solved problem there?).

We just realized that after chrome is updated (but before restarting it), renderer crashes that happen fails to be symbolized by crash/.
This seems to be because the module GUID for chrome is reported as 0000000000000000.

It's not fully clear to me why. I can see how this happens if we try to open() the chrome executable in the minidump_writer after it has been unliked by the updated.
However that shouldn't be the case. The code in FindElfBuildIDNote seems to just use the existing memory-mapped area, so right now I can't tell where the bug is.

I don’t want to put too much effort into tracing through Breakpad spaghetti and integration spaghetti, but I see that MinidumpWriter::WriteMappings does some stuff “mappings from the dumper” and some other stuff with “mappings provided by the caller”. The former will try to grab the module ID from memory, but the latter will use whatever the caller provided. Could the caller be doing something dumb like trying to get the build ID from open()ing the executable?

 Issue 716579  has been merged into this issue.

I fully agree that fixing this right now in breakpad is like doing a fancy tattoo to a dying horse. Whatever this is we have been in this situation for a while now.
Just a use-case to keep in mind for crashpad.

Crashpad’s going to grab the module ID from the loaded image. I hope we can avoid stuff like “let the caller pass in its own boneheaded garbage” that perverted Breakpad. I’ll just block this bug on the Crashpad Android client, then.

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.

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

Should be fixed in the next few quarters.