459714 - No way to ID troublesome "pseudo-sub-processes"...w/extensions (or w/o)

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[L A Walsh]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

There seems to be no way to identify which web-page or plugin is hanging a FF session -- sometimes, it is important to identify what is going on "right now" -- not to "reboot" FF, in safe mode and bring up a different environment -- or NOT even a "Reboot w/tabs" (assuming that's available).

I had opened several tabs off of one site's index -- one of those pages had an auto-play flash video.  The flash player *slowly* indicated a download of the content (unusually slow due to problem, not link speed) -- with the light-grey bar filling the width (indicating local buffer full) -- but the dark black bar not starting at all.  Instead I just get 100% usage of the CPU -- which even affected my entire desktop, as FF kept locking up the UI (even though I had 3 free CPU's). I tried rebooting with tabs (twice) and got the same problem -- so saved tabs to a bookmark and tried in safemode.  Problem not duplicable.  Then tried non-safemode again -- and it didn't hang, BUT, FF is still using 100%  of a CPU -- even though it is doing *nothing* (other than accepting my typing for this report).

I don't believe it is acceptable to require users to reboot in safemode to duplicate a problem anymore than it would be acceptable to require users to reboot to safemode in Windows and duplicate problems.  Safemode is just _"too far"_ from the problem state and completely reinitializes everything -- destroying the cause of the problem.  But "rebooting" FF is NOT an acceptable way to solve FF problems any more than requiring Windows to be rebooted as "standard usage practice" to get rid of Windows problems.


Reproducible: Sometimes

Steps to Reproduce:
I saved all the bookmarks into a bookmark -- and opening it, with my extensions loaded does reproduce the CPU usage problem -- even though FF isn't doing anything.
The URL's involved:
Test-folder
http://io9.com/5062476/nicole-riche-uses-her-feminine-wiles-++-and-her-fists-++-on-chuck?autoplay=true
http://io9.com/5062369/5-ways-to-make-star-trek-more-like-star-wars
http://io9.com/5062374/lightning-joins-all-the-other-things-striking-in-mortal-kombat-vs-dc
http://io9.com/5062578/roam-the-wastelands-in-your-very-own-interceptor
http://io9.com/5062446/female+dominated-societies-are-violent-say-anthropologists
http://gawker.com/5062683/leave-new-york-alone
http://io9.com/5062470/nerds-vs-jocks-vs-droids-vs-padme-vs-pigeons-vs-serial-killers-on-this-weeks-tv
http://io9.com/5062476/nicole-riche-uses-her-feminine-wiles-++-and-her-fists-++-on-chuck
----
  I do have script block and adblock+ running, though adblock claims to be 
blocking nothing on any of the pages.

I'm 14-minutes into this bug report and the CPU usage has not gone below 100% of 1 of my 4 CPU's.   The UI is behaving *this time*, but I stress, that the first time it hit, the entire desktop was locking up and getting nearly no CPU -- I wasn't even able to click the "X" on the FF window to close it, but had process-explorer running and killed it from there.

The properties of FF show it FF using _19_ threads for the 7 tabs.  Thread "1" is using nearly all of the cpu.  A 2nd thread (shows about 80% as many context switches, but is showing 0% cpu usage (only thread1 shows cpu usage).

Thread 1's stack, which has "firefox+0x15a0" as the start address shows:
ntkrnlpa.exe+0x6dd2b
ntkrnlpa.exe+0x2b592
hal.dll+0x2ef2
hal.dll+0x299a
ntkrnlpa.exe+0x699ac
ntdll.dll!KiFastSystemCallRet+0x4
ntdll.dll!KiFastSystemCallRet
ntdll.dll!ZwQueryVirtualMemory+0xc
kernel32.dll!VirtualQueryEx+0x1d
kernel32.dll!VirtualQuery+0x15
kernel32.dll!SetThreadContext+0x44
kernel32.dll!SetUnhandledExceptionFilter+0x2b
NPSWF32.dll!native_ShockwaveFlash_TCallLabel+0x743d
xul.dll!gfxWindowsFontGroup::GetFontAt+0x178c

the 2nd thread (showing high context switches, but no measurable CPU (to 100's of a percent), says it starts at WINMM.dll.time Thread and has stack:
ntkrnlpa.exe+0x6dd2b
ntkrnlpa.exe+0x2b592
ntkrnlpa.exe+0x2be74
ntkrnlpa.exe+0xe84a9
ntkrnlpa.exe+0x699ac
ntdll.dll!KiFastSystemCallRet+0x4
ntdll.dll!KiFastSystemCallRet
ntdll.dll!ZwWaitForMultipleObjects+0xc
WINMM.dll!timeThread+0x3a
---
The problem is I can't really tell which tab, or which plugin in which tab is causing the problem.
Since FF hides separate tabs all in 1 process or thread (and because there is no mapping from threads->tabs (or vice versa)), I can't tell what's going on.

As long as FF is creating it's own "internal" task scheduler -- it seems imperative to provide some "top" or "ps" functionality to allow users & developers to see what tabs, functions or processes are hogging the CPU -- and,
obviously, IMO, FF shouldn't let one tab or function dominate all threads (ideally, unless by choice -- say for video -- or if not specifically detectable, maybe for plugins in general).

As it is, I have 1 big "blob" of 19-threads with no way to determine which tab is causing the problem or why a flash-video shows it is downloading and buffering (at about 1/3rd normal speed), but not starting to play.
Actual Results:  
Random behavior, including, up to, freezing the desktop for seconds at a time and disallowing desktop control of FF (like closing it by clicking on the frame's "X" box).  I had to kill it with a 3rd party program (task explorer might have worked, but I already had process explorer (sysinterals.com) already up and running, so it was easy to access.


Expected Results:  
Ability to see what extensions on what tabs are causing the problem (
currently accumlated 33:55 (MM:SS) while I typed this report.

I don't see this as an "RFE", since if you are implementing your own multi-task "OS" within FF, I feel that the original design of the "FF" "OS" was deficient in design in not having this functionality.

Related, but not exactly the same -- would it be possible to, at least, put the OS-calls and UI handling into a separate process and make calls to the common UI interface through locking mechanisms?  This could allow multiple invocations of FF to launch in different processes, spreading the load, yet all remaining "coherent" through calls to 1-"resource" handling thread.

Remember -- that Linux's transition to fully SMP wasn't in 1 step, but was through a long series of parallelization efforts.

Comment 1

[Tyler Downer [He/Him]]

This is a mass search for bugs which are in the Firefox General component, are
UNCO, have not been changed for 500 days and have an unspecified version. 

Reporter, can you please update to Firefox 3.6.10 or later, create a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles, and test again. If you still see the issue, please update this bug. If the issue is gone, please set the status to RESOLVED > WORKSFORME.

Comment 2

[Tyler Downer [He/Him]]

No reply from reporter, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.