gecko-dev/toolkit/crashreporter/nsDummyExceptionHandler.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

275 lines
7.6 KiB
C++
Raw Normal View History

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#include <functional>
#include "nsExceptionHandler.h"
#include "nsExceptionHandlerUtils.h"
#include "prio.h"
namespace CrashReporter {
void AnnotateOOMAllocationSize(size_t size) {}
void AnnotateTexturesSize(size_t size) {}
void AnnotatePendingIPC(size_t aNumOfPendingIPC, uint32_t aTopPendingIPCCount,
const char* aTopPendingIPCName,
uint32_t aTopPendingIPCType) {}
nsresult SetExceptionHandler(nsIFile* aXREDirectory, bool force /*=false*/) {
return NS_ERROR_NOT_IMPLEMENTED;
}
bool GetEnabled() { return false; }
bool GetMinidumpPath(nsAString& aPath) { return false; }
nsresult SetMinidumpPath(const nsAString& aPath) {
return NS_ERROR_NOT_IMPLEMENTED;
}
nsresult SetupExtraData(nsIFile* aAppDataDirectory,
const nsACString& aBuildID) {
return NS_ERROR_NOT_IMPLEMENTED;
}
nsresult UnsetExceptionHandler() { return NS_ERROR_NOT_IMPLEMENTED; }
nsresult AnnotateCrashReport(Annotation key, bool data) {
return NS_ERROR_NOT_IMPLEMENTED;
}
nsresult AnnotateCrashReport(Annotation key, int data) {
return NS_ERROR_NOT_IMPLEMENTED;
}
nsresult AnnotateCrashReport(Annotation key, unsigned int data) {
return NS_ERROR_NOT_IMPLEMENTED;
}
nsresult AnnotateCrashReport(Annotation key, const nsACString& data) {
return NS_ERROR_NOT_IMPLEMENTED;
}
nsresult RemoveCrashReportAnnotation(Annotation key) {
return NS_ERROR_NOT_IMPLEMENTED;
}
AutoAnnotateCrashReport::AutoAnnotateCrashReport(Annotation key, bool data) {}
AutoAnnotateCrashReport::AutoAnnotateCrashReport(Annotation key, int data) {}
AutoAnnotateCrashReport::AutoAnnotateCrashReport(Annotation key,
unsigned data) {}
AutoAnnotateCrashReport::AutoAnnotateCrashReport(Annotation key,
const nsACString& data) {}
AutoAnnotateCrashReport::~AutoAnnotateCrashReport() {}
Bug 1547698 - Refactor the code that writes the .extra file for a content process crash or hang r=froydnj Upon a content process crash or hang crash annotations were incrementally written into the .extra file starting with the exception handler callback and then in a number of different places before the file was ready for submission. This had a number of downsides: since the annotations were directly added to the file it was impossible to tell which ones were already written at a certain point in time, additionally some were written twice or even thrice. The code doing the writing would also behave differently depending on the contents of the file, the parameters passed to it and the contents of global variables. This change overhauls the whole process by keeping the annotations into a temporary per-crash annotation table which is filled with all the required annotations before being written out in a single pass when they are ready. The annotations are gathered from the main process annotation table, the per-process one (held by the CrashReporterHost) and exception-time specific ones. The resulting annotations are slightly different than before the patch: first of all there are no more duplicate entries in the .extra file and secondly all content/plugin process hangs annotations are properly filtered, before annotations that were main process-only would leak into them. Differential Revision: https://phabricator.services.mozilla.com/D31069 --HG-- extra : moz-landing-system : lando
2019-05-18 16:19:55 +00:00
void MergeCrashAnnotations(AnnotationTable& aDst, const AnnotationTable& aSrc) {
}
nsresult SetGarbageCollecting(bool collecting) {
return NS_ERROR_NOT_IMPLEMENTED;
}
void SetEventloopNestingLevel(uint32_t level) {}
void SetMinidumpAnalysisAllThreads() {}
nsresult AppendAppNotesToCrashReport(const nsACString& data) {
return NS_ERROR_NOT_IMPLEMENTED;
}
bool GetAnnotation(const nsACString& key, nsACString& data) { return false; }
void GetAnnotation(uint32_t childPid, Annotation annotation,
nsACString& outStr) {
return;
}
nsresult RegisterAppMemory(void* ptr, size_t length) {
return NS_ERROR_NOT_IMPLEMENTED;
}
nsresult UnregisterAppMemory(void* ptr) { return NS_ERROR_NOT_IMPLEMENTED; }
void SetIncludeContextHeap(bool aValue) {}
bool GetServerURL(nsACString& aServerURL) { return false; }
nsresult SetServerURL(const nsACString& aServerURL) {
return NS_ERROR_NOT_IMPLEMENTED;
}
nsresult SetRestartArgs(int argc, char** argv) {
return NS_ERROR_NOT_IMPLEMENTED;
}
#if !defined(XP_WIN)
int GetAnnotationTimeCrashFd() { return 7; }
#endif
void RegisterChildCrashAnnotationFileDescriptor(ProcessId aProcess,
PRFileDesc* aFd) {
// The real implementation of this function takes ownership of aFd
// and closes it when the process exits; if we don't close it, it
// causes a leak. With no crash reporter we'll never write to the
// pipe, so it's safe to close the read end immediately.
PR_Close(aFd);
}
void DeregisterChildCrashAnnotationFileDescriptor(ProcessId aProcess) {}
#ifdef XP_WIN
nsresult WriteMinidumpForException(EXCEPTION_POINTERS* aExceptionInfo) {
return NS_ERROR_NOT_IMPLEMENTED;
}
#endif
#ifdef XP_LINUX
bool WriteMinidumpForSigInfo(int signo, siginfo_t* info, void* uc) {
return false;
}
#endif
#ifdef XP_MACOSX
nsresult AppendObjCExceptionInfoToAppNotes(void* inException) {
return NS_ERROR_NOT_IMPLEMENTED;
}
#endif
nsresult GetSubmitReports(bool* aSubmitReports) {
return NS_ERROR_NOT_IMPLEMENTED;
}
nsresult SetSubmitReports(bool aSubmitReports) {
return NS_ERROR_NOT_IMPLEMENTED;
}
void SetProfileDirectory(nsIFile* aDir) {}
void SetUserAppDataDirectory(nsIFile* aDir) {}
void UpdateCrashEventsDir() {}
bool GetCrashEventsDir(nsAString& aPath) { return false; }
void SetMemoryReportFile(nsIFile* aFile) {}
nsresult GetDefaultMemoryReportFile(nsIFile** aFile) {
return NS_ERROR_NOT_IMPLEMENTED;
}
void DeleteMinidumpFilesForID(const nsAString& id) {}
bool GetMinidumpForID(const nsAString& id, nsIFile** minidump) { return false; }
bool GetIDFromMinidump(nsIFile* minidump, nsAString& id) { return false; }
bool GetExtraFileForID(const nsAString& id, nsIFile** extraFile) {
return false;
}
bool GetExtraFileForMinidump(nsIFile* minidump, nsIFile** extraFile) {
return false;
}
Bug 1547698 - Refactor the code that writes the .extra file for a content process crash or hang r=froydnj Upon a content process crash or hang crash annotations were incrementally written into the .extra file starting with the exception handler callback and then in a number of different places before the file was ready for submission. This had a number of downsides: since the annotations were directly added to the file it was impossible to tell which ones were already written at a certain point in time, additionally some were written twice or even thrice. The code doing the writing would also behave differently depending on the contents of the file, the parameters passed to it and the contents of global variables. This change overhauls the whole process by keeping the annotations into a temporary per-crash annotation table which is filled with all the required annotations before being written out in a single pass when they are ready. The annotations are gathered from the main process annotation table, the per-process one (held by the CrashReporterHost) and exception-time specific ones. The resulting annotations are slightly different than before the patch: first of all there are no more duplicate entries in the .extra file and secondly all content/plugin process hangs annotations are properly filtered, before annotations that were main process-only would leak into them. Differential Revision: https://phabricator.services.mozilla.com/D31069 --HG-- extra : moz-landing-system : lando
2019-05-18 16:19:55 +00:00
bool WriteExtraFile(const nsAString& id, const AnnotationTable& annotations) {
return false;
}
void OOPInit() {}
#if defined(XP_WIN) || defined(XP_MACOSX)
const char* GetChildNotificationPipe() { return nullptr; }
#endif
#ifdef MOZ_CRASHREPORTER_INJECTOR
void InjectCrashReporterIntoProcess(DWORD processID,
InjectorCrashCallback* cb) {}
void UnregisterInjectorCallback(DWORD processID) {}
#endif // MOZ_CRASHREPORTER_INJECTOR
bool GetLastRunCrashID(nsAString& id) { return false; }
#if !defined(XP_WIN) && !defined(XP_MACOSX)
bool CreateNotificationPipeForChild(int* childCrashFd, int* childCrashRemapFd) {
return false;
}
#endif // !defined(XP_WIN) && !defined(XP_MACOSX)
bool SetRemoteExceptionHandler(const char* aCrashPipe,
Bug 1697895 - Register the WER runtime exception module in child processes r=KrisWright This patch sets up a few different things that will be used by the WER runtime exception module when it needs to notify the main process of a child process crash. For every child process we allocate a structure in the main process called WindowsErrorReportingData that contains three things: - The address of the function used to notify the main process that there's a pending minidump for a given child process - The PID of said child process - The name of the minidump that has been generated The first field is filled up by the main process and will be read by the WER process when running the runtime exception module, the second and third fields on the other hand start empty and will be written into by the runtime exception module after it has generated a minidump. I know this sounds scary. It is. But bear with me please. When we register the runtime exception module we can pass it a single pointer-sized parameter but we need to pass it at least another pointer that includes data coming from the child process itself (this one is called InProcessWindowsErrorReportingData). This data currently includes only the process type but will also include certain annotations in the future (e.g. bug 1711418). So here's what we do: we store a pointer to the parent data structure in the child process command-line (cringe) and we read it from the runtime exception module by reading the crashed process command-line arguments and parsing them (double-cringe). Armed with this information the WER runtime exception module can populate the info for the generated minidump and then push it into the main process by calling CreateRemoteThread() (which creates a new thread in the main process, triple-cringe at this point). Differential Revision: https://phabricator.services.mozilla.com/D115379
2021-06-11 09:59:49 +00:00
FileHandle aCrashTimeAnnotationFile) {
return false;
}
bool TakeMinidumpForChild(uint32_t childPid, nsIFile** dump,
Bug 1547698 - Refactor the code that writes the .extra file for a content process crash or hang r=froydnj Upon a content process crash or hang crash annotations were incrementally written into the .extra file starting with the exception handler callback and then in a number of different places before the file was ready for submission. This had a number of downsides: since the annotations were directly added to the file it was impossible to tell which ones were already written at a certain point in time, additionally some were written twice or even thrice. The code doing the writing would also behave differently depending on the contents of the file, the parameters passed to it and the contents of global variables. This change overhauls the whole process by keeping the annotations into a temporary per-crash annotation table which is filled with all the required annotations before being written out in a single pass when they are ready. The annotations are gathered from the main process annotation table, the per-process one (held by the CrashReporterHost) and exception-time specific ones. The resulting annotations are slightly different than before the patch: first of all there are no more duplicate entries in the .extra file and secondly all content/plugin process hangs annotations are properly filtered, before annotations that were main process-only would leak into them. Differential Revision: https://phabricator.services.mozilla.com/D31069 --HG-- extra : moz-landing-system : lando
2019-05-18 16:19:55 +00:00
AnnotationTable& aAnnotations, uint32_t* aSequence) {
return false;
}
bool FinalizeOrphanedMinidump(uint32_t aChildPid, GeckoProcessType aType,
nsString* aDumpId) {
return false;
}
Bug 1697895 - Register the WER runtime exception module in child processes r=KrisWright This patch sets up a few different things that will be used by the WER runtime exception module when it needs to notify the main process of a child process crash. For every child process we allocate a structure in the main process called WindowsErrorReportingData that contains three things: - The address of the function used to notify the main process that there's a pending minidump for a given child process - The PID of said child process - The name of the minidump that has been generated The first field is filled up by the main process and will be read by the WER process when running the runtime exception module, the second and third fields on the other hand start empty and will be written into by the runtime exception module after it has generated a minidump. I know this sounds scary. It is. But bear with me please. When we register the runtime exception module we can pass it a single pointer-sized parameter but we need to pass it at least another pointer that includes data coming from the child process itself (this one is called InProcessWindowsErrorReportingData). This data currently includes only the process type but will also include certain annotations in the future (e.g. bug 1711418). So here's what we do: we store a pointer to the parent data structure in the child process command-line (cringe) and we read it from the runtime exception module by reading the crashed process command-line arguments and parsing them (double-cringe). Armed with this information the WER runtime exception module can populate the info for the generated minidump and then push it into the main process by calling CreateRemoteThread() (which creates a new thread in the main process, triple-cringe at this point). Differential Revision: https://phabricator.services.mozilla.com/D115379
2021-06-11 09:59:49 +00:00
#if defined(XP_WIN)
DWORD WINAPI WerNotifyProc(LPVOID aParameter) { return 0; }
#endif // defined(XP_WIN)
ThreadId CurrentThreadId() { return -1; }
bool TakeMinidump(nsIFile** aResult, bool aMoveToPending) { return false; }
bool CreateMinidumpsAndPair(ProcessHandle aTargetPid,
ThreadId aTargetBlamedThread,
const nsACString& aIncomingPairName,
nsIFile* aIncomingDumpToPair,
Bug 1547698 - Refactor the code that writes the .extra file for a content process crash or hang r=froydnj Upon a content process crash or hang crash annotations were incrementally written into the .extra file starting with the exception handler callback and then in a number of different places before the file was ready for submission. This had a number of downsides: since the annotations were directly added to the file it was impossible to tell which ones were already written at a certain point in time, additionally some were written twice or even thrice. The code doing the writing would also behave differently depending on the contents of the file, the parameters passed to it and the contents of global variables. This change overhauls the whole process by keeping the annotations into a temporary per-crash annotation table which is filled with all the required annotations before being written out in a single pass when they are ready. The annotations are gathered from the main process annotation table, the per-process one (held by the CrashReporterHost) and exception-time specific ones. The resulting annotations are slightly different than before the patch: first of all there are no more duplicate entries in the .extra file and secondly all content/plugin process hangs annotations are properly filtered, before annotations that were main process-only would leak into them. Differential Revision: https://phabricator.services.mozilla.com/D31069 --HG-- extra : moz-landing-system : lando
2019-05-18 16:19:55 +00:00
AnnotationTable& aTargetAnnotations,
nsIFile** aTargetDumpOut) {
return false;
}
bool CreateAdditionalChildMinidump(ProcessHandle childPid,
ThreadId childBlamedThread,
nsIFile* parentMinidump,
const nsACString& name) {
return false;
}
bool UnsetRemoteExceptionHandler() { return false; }
#if defined(MOZ_WIDGET_ANDROID)
Bug 1697895 - Register the WER runtime exception module in child processes r=KrisWright This patch sets up a few different things that will be used by the WER runtime exception module when it needs to notify the main process of a child process crash. For every child process we allocate a structure in the main process called WindowsErrorReportingData that contains three things: - The address of the function used to notify the main process that there's a pending minidump for a given child process - The PID of said child process - The name of the minidump that has been generated The first field is filled up by the main process and will be read by the WER process when running the runtime exception module, the second and third fields on the other hand start empty and will be written into by the runtime exception module after it has generated a minidump. I know this sounds scary. It is. But bear with me please. When we register the runtime exception module we can pass it a single pointer-sized parameter but we need to pass it at least another pointer that includes data coming from the child process itself (this one is called InProcessWindowsErrorReportingData). This data currently includes only the process type but will also include certain annotations in the future (e.g. bug 1711418). So here's what we do: we store a pointer to the parent data structure in the child process command-line (cringe) and we read it from the runtime exception module by reading the crashed process command-line arguments and parsing them (double-cringe). Armed with this information the WER runtime exception module can populate the info for the generated minidump and then push it into the main process by calling CreateRemoteThread() (which creates a new thread in the main process, triple-cringe at this point). Differential Revision: https://phabricator.services.mozilla.com/D115379
2021-06-11 09:59:49 +00:00
void SetNotificationPipeForChild(FileHandle childCrashFd) {}
Bug 1697895 - Register the WER runtime exception module in child processes r=KrisWright This patch sets up a few different things that will be used by the WER runtime exception module when it needs to notify the main process of a child process crash. For every child process we allocate a structure in the main process called WindowsErrorReportingData that contains three things: - The address of the function used to notify the main process that there's a pending minidump for a given child process - The PID of said child process - The name of the minidump that has been generated The first field is filled up by the main process and will be read by the WER process when running the runtime exception module, the second and third fields on the other hand start empty and will be written into by the runtime exception module after it has generated a minidump. I know this sounds scary. It is. But bear with me please. When we register the runtime exception module we can pass it a single pointer-sized parameter but we need to pass it at least another pointer that includes data coming from the child process itself (this one is called InProcessWindowsErrorReportingData). This data currently includes only the process type but will also include certain annotations in the future (e.g. bug 1711418). So here's what we do: we store a pointer to the parent data structure in the child process command-line (cringe) and we read it from the runtime exception module by reading the crashed process command-line arguments and parsing them (double-cringe). Armed with this information the WER runtime exception module can populate the info for the generated minidump and then push it into the main process by calling CreateRemoteThread() (which creates a new thread in the main process, triple-cringe at this point). Differential Revision: https://phabricator.services.mozilla.com/D115379
2021-06-11 09:59:49 +00:00
void SetCrashAnnotationPipeForChild(FileHandle childCrashAnnotationFd) {}
void AddLibraryMapping(const char* library_name, uintptr_t start_address,
size_t mapping_length, size_t file_offset) {}
#endif
// From ThreadAnnotation.cpp
void InitThreadAnnotation() {}
void SetCurrentThreadName(const char* aName) {}
void GetFlatThreadAnnotation(
const std::function<void(const char*)>& aCallback) {}
void ShutdownThreadAnnotation() {}
} // namespace CrashReporter