DumpWithoutCrashing() causes complete crash rather than just dumping (on Mac) |
|||||
Issue description
I experienced 5 browser crashes consistently yesterday (while trying to open a particular Google Doc in a meeting).
Only a single report was uploaded (37cfb06d00000000), however this report indicates the crash cause as being:
void DumpWithoutCrashing() {
CRASHPAD_SIMULATE_CRASH();
}
This is unexpected -- DumpWithoutCrashing() should not be killing the browser process.
Another possibility is that CRASHPAD_SIMULATE_CRASH() was innocent in this, and then the real browser crash happened immediately later but that report was throttled and not uploaded. (I have the other .dmp files if someone wants to take a look.)
I was running Stable Chrome (53.0.2785.116) at the time
,
Sep 30 2016
(sorry if already known) For the following crash on Mac, we are getting crashdumps for hangs (or jank) in Stable, Beta and Dev. M53 - https://crash.corp.google.com/browse?stbtiq=bb546a6d00000000 M54 - https://crash.corp.google.com/browse?stbtiq=d1fd3a6d00000000#3 M55 - https://crash.corp.google.com/browse?stbtiq=edee05ad00000000 In stable, the following are the crash dumps we got because shutdown was taking too long on Mac. https://crash.corp.google.com/browse?q=product.name%3D%27Chrome_Mac%27%20AND%20product.version%3D%2753.0.2785.116%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BShutdown%20hang%5D%20PasswordStoreProxyMac%3A%3AShutdownOnUIThread%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BShutdown%20hang%5D%20PasswordStoreProxyMac%3A%3AShutdownOnUIThread%27%20AND%20ReportID%3D%27bb546a6d00000000%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D&stbtiq=&reportid=&index=0#3
,
Sep 30 2016
+ creis for https://crash.corp.google.com/browse?stbtiq=37cfb06d00000000#4 crash report
,
Sep 30 2016
Crash 37cfb06d00000000 is not a browser crash on its own. (It's diagnostics for solving issue 575245 .) It's just classified that way because the dump is sent from the browser process. It seems likely that in your case, the browser crashed shortly afterwards for a different reason. If you have the dump files, that would be worth checking. (rtenneti: How is comment 2 related to this report? I don't understand the connection.)
,
Sep 30 2016
creis: Thanks for looking into this. I wanted to verify DumpWithoutCrashing() is working on Mac and we are getting reports (I just looked for that crash signature in various channels to convince myself that it does work and that there was no regression recently).
,
Sep 30 2016
@creis: Confirmed, that does seem to be what happened. I manually uploaded the next minidump with curl (reportID: 4447bb8300000000). The .dmp files are 3 seconds apart. So DumpWithoutCrashing() may be working as advertised (wrote the original report), and then a few seconds later the browser crashed due to issue 627400. Sorry false alarm regarding DumpWithoutCrashing()
,
Sep 30 2016
,
Sep 30 2016
Great! Of course, if there's anything more you can share on the repro steps on issue 627400, we'd love to track that one down as well. :)
,
Sep 30 2016
xref https://bugs.chromium.org/p/crashpad/issues/detail?id=23 on improving rate-limiting logic.
,
Sep 30 2016
Good job, everybody! |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by eroman@chromium.org
, Sep 30 2016