toolkit/components/backgroundhangmonitor

firefox-main/toolkit/components/backgroundhangmonitor

	Name	Description	Size	Coverage
	aggregation			-
	BackgroundHangMonitor.cpp	BackgroundHangManager is the global object that manages all instances of BackgroundHangThread.	25561	83 %
	BackgroundHangMonitor.h	The background hang monitor is responsible for detecting and reporting hangs in main and background threads. A thread registers itself using the BackgroundHangMonitor object and periodically calls its methods to inform the hang monitor of the thread's activity. Each thread is given a thread name, a timeout, and a maximum timeout. If one of the thread's tasks runs for longer than the timeout duration but shorter than the maximum timeout, a (transient) hang is reported. On the other hand, if a task runs for longer than the maximum timeout duration or never finishes (e.g. in a deadlock), a permahang is reported. Tasks are defined arbitrarily, but are typically represented by events in an event loop -- processing one event is equivalent to running one task. To ensure responsiveness, tasks in a thread often have a target running time. This is a good starting point for determining the timeout and maximum timeout values. For example, the Compositor thread has a responsiveness goal of 60Hz or 17ms, so a starting timeout could be 100ms. Considering some platforms (e.g. Android) can terminate the app when a critical thread hangs for longer than a few seconds, a good starting maximum timeout is 4 or 5 seconds. A thread registers itself through the BackgroundHangMonitor constructor. Multiple BackgroundHangMonitor objects can be used in one thread. The constructor without arguments can be used when it is known that the thread already has a BackgroundHangMonitor registered. When all instances of BackgroundHangMonitor are destroyed, the thread is unregistered. The thread then uses two methods to inform BackgroundHangMonitor of the thread's activity: > BackgroundHangMonitor::NotifyActivity should be called before starting a task. The task run time is determined by the interval between this call and the next NotifyActivity call. > BackgroundHangMonitor::NotifyWait should be called before the thread enters a wait state (e.g. to wait for a new event). This prevents a waiting thread from being detected as hanging. The wait state is automatically cleared at the next NotifyActivity call. The following example shows hang monitoring in a simple event loop: void thread_main() { mozilla::BackgroundHangMonitor hangMonitor("example1", 100, 1000); while (!exiting) { hangMonitor.NotifyActivity(); process_next_event(); hangMonitor.NotifyWait(); wait_for_next_event(); } } The following example shows reentrancy in nested event loops: void thread_main() { mozilla::BackgroundHangMonitor hangMonitor("example2", 100, 1000); while (!exiting) { hangMonitor.NotifyActivity(); process_next_event(); hangMonitor.NotifyWait(); wait_for_next_event(); } } void process_next_event() { mozilla::BackgroundHangMonitor hangMonitor(); if (is_sync_event) { while (!finished_event) { hangMonitor.NotifyActivity(); process_next_event(); hangMonitor.NotifyWait(); wait_for_next_event(); } } else { process_nonsync_event(); } }	6772	-
	BHRTelemetryService.sys.mjs		4924	93 %
	components.conf		597	-
	HangAnnotations.cpp		2683	82 %
	HangAnnotations.h	This class extends nsTArray<HangAnnotation> with some methods for adding annotations being reported by a registered hang Annotator.	1906	-
	HangDetails.cpp		23493	85 %
	HangDetails.h	HangDetails is the concrete implementaion of nsIHangDetails, and contains the infromation which we want to expose to observers of the bhr-thread-hang observer notification.	3063	100 %
	HangTypes.ipdlh		2240	-
	mach_commands.py	mach command for running the BHR aggregation job locally. This is a thin wrapper around aggregation/bhr_collection.py:aggregate(). It exists so a developer can run the daily BHR aggregation on their machine without remembering the PYTHONPATH incantation. The virtualenv_name below points mach at python/sites/bhr-aggregate.txt, so the google-cloud-bigquery dependency gets installed automatically the first time the command runs. BigQuery needs GCP Application Default Credentials. If they're missing or expired the command prints how to set them up and exits; pass --login to have it run `gcloud auth application-default login` for you instead. Note on --date: this is the build date to process directly. The legacy python_mozetl CLI subtracted 4 days internally, so its `--date 2026-05-29` processed build date 2026-05-25. Here `--date 2026-05-25` processes 2026-05-25.	8045	-
	metrics.yaml		3630	-
	moz.build		1723	-
	nsIHangDetails.idl	A scriptable interface for getting information about a BHR detected hang. This is the type of the subject of the "bhr-thread-hang" observer topic.	2100	-
	pings.yaml		1831	-
3%	tests			-
	ThreadStackHelper.cpp		13224	96 %
	ThreadStackHelper.h	ThreadStackHelper is used to retrieve the profiler's "profiling stack" of a thread, as an alternative of using the profiler to take a profile. The target thread first declares an ThreadStackHelper instance; then another thread can call ThreadStackHelper::GetStack to retrieve the profiling stack of the target thread at that instant. Only non-copying labels are included in the stack, which means labels with custom text and markers are not included.	3459	100 %

Revision control

Other Tools