933684 - High CPU load from webrtc::VoiceEngine::Create even when not browsing

Status: RESOLVED INVALID

(Core :: WebRTC, defect)

Description

[Mason]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22 (Beta/Release)
Build ID: 20131028182244

Steps to reproduce:

I have around 10-15 tabs open. Everything that "steals" CPU cycles is blocked (NoScript to block rogue javascripts, ABP to block flash and ads, animated GIFs disabled). Before version 2.22, when I didn't use Seamonkey, the CPU load would be 0-2%. Now even idling, Seamonkey consumes 15-30% of the CPU.


Actual results:

When I examine the call stack of the main thread, I always see the same bt, meaning this must be hammering the CPU:

ntoskrnl.exe!ExReleaseResourceLite+0x1a3
ntoskrnl.exe!PsGetContextThread+0x329
ntoskrnl.exe!FsRtlInitializeFileLock+0x83f
ntoskrnl.exe!FsRtlInitializeFileLock+0x87e
ntoskrnl.exe!ProbeForWrite+0x4eb
ntoskrnl.exe!ZwYieldExecution+0xb78
ntdll.dll!KiFastSystemCallRet
USER32.dll!GetLastInputInfo+0x105
xul.dll!JSD_GetValueForObject+0x57794
xul.dll!JSD_GetValueForObject+0x5982f
xul.dll!JSD_GetValueForObject+0x84d36
xul.dll!XRE_AddJarManifestLocation+0x3698
xul.dll!JSD_JSContextInUse+0x339b1b
xul.dll!JSD_JSContextInUse+0x131fcd
xul.dll!NS_InvokeByIndex+0xe809
xul.dll!NS_InvokeByIndex+0xe8bd
xul.dll!JSD_GetValueForObject+0x848ab
xul.dll!webrtc::VoiceEngine::Create+0xa9b5f



Expected results:

When not used, Seamonkey should not use any CPU.

I tried disabling everything about webrtc in about:config

Every media.*.enabled entry was set to "false" => still high CPU load

Comment 1

[Mason]

Hmmm, at the moment, I have 50 tabs open in 12 windows.
Seamonkey is not using any CPU according to Process Explorer.
No idea what kept SM busy yesterday.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Note: linkers will often merge identical routines, and VoiceEngine::Create() is basically "return GetVoiceEngine();" (though I'd have to look at the built code in a debugger).  More to the point, though, is that it's not even close to exposed to the JS layer, so it would not be calling GetValueForObject, so the stack is spurious in some way.

If this recurs and you can get more info on the cause, please open a new bug or reopen this one.