Lots of leftover threads (PacerThread, VoiceProcessThread, ModuleProcessThread)
Categories
(Core :: WebRTC, defect, P3)
Tracking
()
People
(Reporter: florian, Unassigned)
References
Details
In a browser session that I've used for a couple days (6 days old nightly build: 79.0a1 (2020-06-10) (64 bits)), I have a content process that continuously uses 40+% of a CPU core.
about:processes shows that this content process has 183 threads (other content processes have 40 to 50 threads).
In the list of threads for this content process, I see 40+ PacerThread
threads (each taking about 0.5% of a CPU core), 40+ VoiceProcessThread
threads (each taking about 0.4% of a CPU core), and about as many ModuleProcessThread
threads (each taking about 0.1% of a CPU core). There's also an SCTP timer
thread that seems related to webrtc, taking about 0.1% of a core.
I don't have steps to reproduce for this, but I think it's likely related to using https://virtu-allhands.com (28 sessions to this site shown in about:webrtc).
Reporter | ||
Comment 1•4 years ago
|
||
I somehow can't seem to capture a profile of these threads, are they somehow not registered with the Gecko Profiler?
Comment 2•4 years ago
|
||
Thanks for the report! PacerThread, VoiceProcessThread and ModuleProcessThread are created in libwebrtc. PacerThread and ModuleProcessThread are associated with the Call object, VoiceProcessThread with the voice engine. These would be owned by the VideoConduit or AudioConduit which are in turn owned by a Transceiver. So this would suggest you've ended up with 40+ Transceivers that are either staying around or have gone away but not cleaned up properly.
Byron, any thoughts on whether this could be a site issue or if it indicates a bug in our code?
Comment 3•4 years ago
|
||
If the tabs are closed, then this stuff should not be hanging around.
Comment 4•4 years ago
|
||
The SCTP timer stuff probably only goes away when the sctp_stack is shut down, but we only do that at xpcom shutdown time due to bug 1646716.
Comment 5•4 years ago
|
||
The timer threads wakes up periodically and serves timers when needed. That seems OK to me. Of course one could implement them in a different way to sleep until the next timer runs off, but that is not how it is done today.
Updated•4 years ago
|
Description
•