Closed Bug 805817 Opened 12 years ago Closed 11 years ago

Gecko profiler can completely kill Firefox

Categories

(Core :: Gecko Profiler, defect)

x86_64
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mayhemer, Unassigned)

Details

Few days ago I first experienced a complete main thread block when using my Nightly build on my old and slow Win-XP laptop with the profiler extension installed. Hang monitor and the profiler sampling thread both suspend the main thread to take a stack walk sample and both these threads eat CPU to do their jobs and never end leaving thus the whole process hanging unresponsive. Settings of the profiler extension are at default, except setting to catch only janks and with disabled Fennec profiling. Example of stacktraces of the two thread (took from visual studio): ntdll.dll!_KiFastSystemCallRet@0() ntdll.dll!_NtReadVirtualMemory@20() + 0xc bytes kernel32.dll!_ReadProcessMemory@20() + 0x1b bytes dbghelp.dll!ReadMemoryRoutineLocal() + 0x3e bytes dbghelp.dll!ReadMemoryInternal() + 0x3e bytes dbghelp.dll!WalkX86_NonFpo_NonFpo() + 0x57 bytes dbghelp.dll!WalkX86Next() + 0x30e bytes dbghelp.dll!_WalkX86@36() + 0x29 bytes dbghelp.dll!_StackWalk64@36() + 0xdb bytes xul.dll!WalkStackMain64(WalkStackData * data) Line 360 C++ xul.dll!NS_StackWalk(void (void *, void *, void *)* aCallback, unsigned int aSkipFrames, void * aClosure, unsigned int aThread) Line 513 C++ xul.dll!TableTicker::doBacktrace(ThreadProfile & aProfile, TickSample * aSample) Line 778 + 0x10 bytes C++ xul.dll!TableTicker::Tick(TickSample * sample) Line 935 C++ > xul.dll!SamplerThread::SampleContext(Sampler * sampler) Line 118 C++ xul.dll!SamplerThread::Run() Line 77 C++ xul.dll!ThreadEntry(void * arg) Line 164 C++ ntdll.dll!_KiFastSystemCallRet@0() ntdll.dll!_NtSetEventBoostPriority@4() + 0xc bytes ntdll.dll!_RtlpUnWaitCriticalSection@4() + 0x22 bytes ntdll.dll!_RtlLeaveCriticalSection@4() + 0x1d bytes xul.dll!WalkStackMain64(WalkStackData * data) Line 362 C++ xul.dll!NS_StackWalk(void (void *, void *, void *)* aCallback, unsigned int aSkipFrames, void * aClosure, unsigned int aThread) Line 513 C++ > xul.dll!mozilla::HangMonitor::GetChromeHangReport(mozilla::Telemetry::ProcessedStack & aStack) Line 137 + 0x13 bytes C++ xul.dll!mozilla::HangMonitor::ThreadMain(void * __formal) Line 184 + 0xa bytes C++ nspr4.dll!_PR_NativeRunThread(void * arg) Line 417 C I can reproduce this by scrolling on google result page, usually image search results. Main thread is usually somewhere at ion interpreter. Cannot get content JS stack in the debugger.
So, I would like to start using the profiler but I can't because of this bug. Is any progress made on fixing or working this around?
By 'kill' do you mean 'hang'? Is the main thread making progress? Can you change 'profiler.interval' to something such as 100 (ms), restart the profiler. Does that help?
(In reply to Benoit Girard (:BenWa) from comment #2) > By 'kill' do you mean 'hang'? Hang. > Is the main thread making progress? Visibly no, it is suspended mostly all the time. I may just kill the app in task manager or process explorer. > Can you > change 'profiler.interval' to something such as 100 (ms), restart the > profiler. Does that help? Will try and refer.
AFAIK we fixed several windows profiler hang. Let me know if this still occurs.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.