зеркало из https://github.com/mozilla/gecko-dev.git
Read-only Git mirror of the Mercurial gecko repositories at https://hg.mozilla.org. How to contribute: https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
896f9b03cb
This also notifies the main process after the minidump has been generated. I refactored the code a bit so the patch is probably larger than it should be but the code should be a bit more readable overall. With this change the minidump generation flow works like this: - When the callback gets invoked in the WER process we read the structure that is stored in every process' to figure out if it's the main process or a child one. This is done by reading said process' memory, the pointer has been passed to the runtime exception module when it was registered. - If the main process crashed everything works like it used to. - If it was a child process then we first capture a minidump of it. - Then we read the structure representing it in the main process: WindowsErrorReportingData. The address of this structure was passed into the child process' command-line so we need to parse that first, then we read it from the main process memory. - We fill the structure and write it back into the main process memory. - At this point if everything went fine we create a new thread in the main process just to execute the WerNotifyProc function that will inform the main process to the presence of the new minidump. There's one important tidbit that's worth keeping in mind: the synchronization between the main process and the WER process is implicit. The WindowsErrorReportingData structure in the main process is kept alive until the child process dies, the main process will destroy it only after that point. As long as we're in the runtime exception module the crashed process is kept alive so this will prevent the main process from touching that structure. We explicitly terminate the crashed process **after** we're done with the structure so nothing bad could happen... unless someone makes a change to Gecko that breaks the previous assumption. Another important thing to keep in mind: we wait for the newly created thread to inform the main process but only for 5 seconds. We don't want to wait indefinitely because the function that we're calling is taking a lock and if it blocks for some reason WER will get stuck waiting for it, so it will never kill the crashed process which in turn will prevent the main process from moving ahead. In principle this should never happen but better be safe than sorry. Depends on D115379 Differential Revision: https://phabricator.services.mozilla.com/D115380 |
||
|---|---|---|
| .cargo | ||
| .vscode | ||
| accessible | ||
| browser | ||
| build | ||
| caps | ||
| chrome | ||
| config | ||
| devtools | ||
| docs | ||
| docshell | ||
| dom | ||
| editor | ||
| extensions | ||
| gfx | ||
| gradle/wrapper | ||
| hal | ||
| image | ||
| intl | ||
| ipc | ||
| js | ||
| layout | ||
| media | ||
| memory | ||
| mfbt | ||
| mobile | ||
| modules | ||
| mozglue | ||
| netwerk | ||
| nsprpub | ||
| other-licenses | ||
| parser | ||
| python | ||
| remote | ||
| security | ||
| services | ||
| servo | ||
| startupcache | ||
| storage | ||
| taskcluster | ||
| testing | ||
| third_party | ||
| toolkit | ||
| tools | ||
| uriloader | ||
| view | ||
| widget | ||
| xpcom | ||
| xpfe/appshell | ||
| .arcconfig | ||
| .babel-eslint.rc.js | ||
| .clang-format | ||
| .clang-format-ignore | ||
| .cron.yml | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .flake8 | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .hg-annotate-ignore-revs | ||
| .hg-format-source | ||
| .hgignore | ||
| .hgtags | ||
| .lando.ini | ||
| .lldbinit | ||
| .mailmap | ||
| .prettierignore | ||
| .prettierrc | ||
| .taskcluster.yml | ||
| .trackerignore | ||
| .yamllint | ||
| .ycm_extra_conf.py | ||
| AUTHORS | ||
| CLOBBER | ||
| Cargo.lock | ||
| Cargo.toml | ||
| GNUmakefile | ||
| LICENSE | ||
| Makefile.in | ||
| README.txt | ||
| aclocal.m4 | ||
| build.gradle | ||
| client.mk | ||
| client.py | ||
| configure.in | ||
| configure.py | ||
| gradle.properties | ||
| gradlew | ||
| gradlew.bat | ||
| mach | ||
| mach.ps1 | ||
| moz.build | ||
| moz.configure | ||
| mozilla-config.h.in | ||
| old-configure.in | ||
| package-lock.json | ||
| package.json | ||
| settings.gradle | ||
| substitute-local-geckoview.gradle | ||
| test.mozbuild | ||
README.txt
An explanation of the Firefox Source Code Directory Structure and links to
project pages with documentation can be found at:
https://firefox-source-docs.mozilla.org/contributing/directory_structure.html
For information on how to build Firefox from the source code and create the patch see:
https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
If you have a question about developing Firefox, and can't find the solution
on https://firefox-source-docs.mozilla.org/, you can try asking your question on Matrix at chat.mozilla.org in `Introduction` (https://chat.mozilla.org/#/room/#introduction:mozilla.org) channel.
Nightly development builds can be downloaded from:
https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
- or -
https://www.mozilla.org/firefox/channel/desktop/#nightly
Keep in mind that nightly builds, which are used by Firefox developers for
testing, may be buggy.