Closed Bug 687709 Opened 13 years ago Closed 7 years ago

Hi CPU load + shutdown hang in nsBuiltinDecoderStateMachine::StopDecodeThread()

Categories

(Core :: Audio/Video: Playback, defect)

Product:
Core
Component:
Audio/Video: Playback
Version:
8 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INACTIVE

People

(Reporter: mayhemer, Unassigned)

Details

Reproduced with current Aurora on Win7 with integrated HD audio on Intel DX58SO while browsing http://apod.nasa.gov/apod/archivepix.html (probably the problem started here). Some links open a page with a video that use HTML5 for rendering Youtube content. I don't have installed Flash on the machine. I tried few of the videos but none of them started to play (just buffer). Thanks sudden noise of my CPU fan I have noticed that one background thread has been loading 100% of one of my cores. I used AMD CodeAnalyst to check on the process. It identified a huge number of calls to nsThread::ProcessNextEvent and nsXPConnect::Push. I didn't know how accurate this was but I had up to date revision of aurora sources (03b0d42603f8) and symbols from the server. During shutdown Firefox process hanged and now 2 threads loaded 100% of its cores. Here are stacks from both of them: First: > nspr4.dll!PR_GetThreadPrivate(unsigned int index=2) Line 234 + 0xa bytes C xul.dll!XPCPerThreadData::GetDataImpl(JSContext * cx=0x00000000) Line 457 + 0x7 bytes C++ xul.dll!nsThread::ProcessNextEvent(int mayWait=659278192, int * result=0x6b4cc5db) Line 647 + 0x7 bytes C++ xul.dll!nsThread::GetObserver(nsIThreadObserver * * obs=0x00000001) Line 705 + 0x9 bytes C++ xul.dll!nsThread::Shutdown() Line 494 + 0xa bytes C++ xul.dll!nsBuiltinDecoderStateMachine::StopDecodeThread() Line 1039 C++ xul.dll!nsBuiltinDecoderStateMachine::RunStateMachine() Line 1586 + 0x1e bytes C++ xul.dll!nsBuiltinDecoderStateMachine::CallRunStateMachine() Line 1914 C++ xul.dll!nsBuiltinDecoderStateMachine::Run() Line 1893 + 0x6 bytes C++ xul.dll!nsThread::ProcessNextEvent(int mayWait=663526144, int * result=0x6b4cc5db) Line 637 C++ xul.dll!nsThread::GetObserver(nsIThreadObserver * * obs=0x00000001) Line 705 + 0x9 bytes C++ xul.dll!nsThread::Shutdown() Line 494 + 0xa bytes C++ xul.dll!nsBuiltinDecoderStateMachine::StopAudioThread() Line 1055 C++ xul.dll!nsBuiltinDecoderStateMachine::RunStateMachine() Line 1586 + 0x18 bytes C++ xul.dll!nsBuiltinDecoderStateMachine::CallRunStateMachine() Line 1914 C++ xul.dll!nsBuiltinDecoderStateMachine::Run() Line 1893 + 0x6 bytes C++ xul.dll!nsThread::ProcessNextEvent(int mayWait=544974944, int * result=0x6b4cc5db) Line 637 C++ xul.dll!nsThread::GetObserver(nsIThreadObserver * * obs=0x00000001) Line 705 + 0x9 bytes C++ xul.dll!nsThread::Shutdown() Line 494 + 0xa bytes C++ xul.dll!nsBuiltinDecoderStateMachine::StopAudioThread() Line 1055 C++ xul.dll!nsBuiltinDecoderStateMachine::RunStateMachine() Line 1586 + 0x18 bytes C++ xul.dll!nsBuiltinDecoderStateMachine::CallRunStateMachine() Line 1914 C++ xul.dll!nsBuiltinDecoderStateMachine::Run() Line 1893 + 0x6 bytes C++ xul.dll!nsThread::ProcessNextEvent(int mayWait=648757312, int * result=0x6b4cc5db) Line 637 C++ xul.dll!nsThread::GetObserver(nsIThreadObserver * * obs=0x00000001) Line 705 + 0x9 bytes C++ xul.dll!nsThread::Shutdown() Line 494 + 0xa bytes C++ xul.dll!nsBuiltinDecoderStateMachine::StopAudioThread() Line 1055 C++ xul.dll!nsBuiltinDecoderStateMachine::RunStateMachine() Line 1586 + 0x18 bytes C++ xul.dll!nsBuiltinDecoderStateMachine::CallRunStateMachine() Line 1914 C++ xul.dll!nsBuiltinDecoderStateMachine::Run() Line 1893 + 0x6 bytes C++ xul.dll!nsThread::ProcessNextEvent(int mayWait=1801358952, int * result=0x2d37eba0) Line 637 C++ xul.dll!nsThreadStartupEvent::Run() Line 201 + 0x8 bytes C++ nspr4.dll!_PR_NativeRunThread(void * arg=) Line 448 C mozcrt19.dll!arena_dalloc(void * ptr=0x00000000, unsigned int offset=0) Line 4284 + 0xa bytes C nspr4.dll!pr_root(void * arg=0x0fa84940) Line 122 + 0xd bytes C mozcrt19.dll!_callthreadstartex() Line 348 + 0x9 bytes C mozcrt19.dll!_threadstartex(void * ptd=0x0c4cf400) Line 326 + 0x5 bytes C kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes Second: > nspr4.dll!PR_EnterMonitor(PRMonitor * mon=0x2d3bbf60) Line 99 C xul.dll!nsThread::ProcessNextEvent(int mayWait=669147024, int * result=0x6b4cc5db) Line 614 + 0x2d bytes C++ xul.dll!nsThread::GetObserver(nsIThreadObserver * * obs=0x00000001) Line 705 + 0x9 bytes C++ xul.dll!nsThread::Shutdown() Line 494 + 0xa bytes C++ xul.dll!nsBuiltinDecoderStateMachine::StopAudioThread() Line 1055 C++ xul.dll!nsBuiltinDecoderStateMachine::DecodeSeek() Line 1304 C++ xul.dll!nsBuiltinDecoderStateMachine::DecodeThreadRun() Line 306 + 0x6 bytes C++ xul.dll!nsRunnableMethodImpl<void (__thiscall nsFileUploadContentStream::*)(void),1>::Run() Line 346 C++ xul.dll!nsThread::ProcessNextEvent(int mayWait=1801358952, int * result=0x12b1c8c0) Line 637 C++ xul.dll!nsThreadStartupEvent::Run() Line 201 + 0x8 bytes C++ nspr4.dll!_PR_NativeRunThread(void * arg=) Line 448 C nspr4.dll!pr_root(void * arg=0x2eea5d80) Line 122 + 0xd bytes C mozcrt19.dll!_callthreadstartex() Line 348 + 0x9 bytes C mozcrt19.dll!_threadstartex(void * ptd=0x1f71dc00) Line 326 + 0x5 bytes C kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes Then I have found another thread that could be of interest: > user32.dll!_NtUserMessageCall@28() + 0x15 bytes user32.dll!_NtUserMessageCall@28() + 0x15 bytes user32.dll!_SendMessageTimeoutW@28() + 0x21 bytes user32.dll!_SendMessageTimeoutW@28() + 0x21 bytes MMDevAPI.dll!CDeviceEnumerator::RegisterEndpointNotificationCallback() + 0x45 bytes msacm32.drv!_RegisterNotificationClient@4() + 0x57 bytes msacm32.drv!_mapDriverOpenWave@8() + 0x21d bytes msacm32.drv!_mapWaveOpen@20() + 0x19a bytes msacm32.drv!_wodMessage@20() + 0x79 bytes winmm.dll!_waveOutOpen@24() + 0x140 bytes xul.dll!openAudio(sa_stream * s=0x00000000) Line 457 C xul.dll!sa_stream_open(sa_stream * s=0x13483ec0) Line 188 + 0x6 bytes C xul.dll!nsAudioStreamLocal::Init(int aNumChannels=2, int aRate=44100, nsAudioStream::SampleFormat aFormat=FORMAT_FLOAT32) Line 433 + 0x7 bytes C++ xul.dll!nsBuiltinDecoderStateMachine::AudioLoop() Line 527 C++ xul.dll!nsRunnableMethodImpl<void (__thiscall nsFileUploadContentStream::*)(void),1>::Run() Line 346 C++ xul.dll!nsThread::ProcessNextEvent(int mayWait=1801358952, int * result=0x14109aa0) Line 637 C++ xul.dll!nsThreadStartupEvent::Run() Line 201 + 0x8 bytes C++ nspr4.dll!_PR_NativeRunThread(void * arg=) Line 448 C mozcrt19.dll!arena_dalloc(void * ptr=0x00000000, unsigned int offset=0) Line 4284 + 0xa bytes C nspr4.dll!pr_root(void * arg=0x2eea4480) Line 122 + 0xd bytes C mozcrt19.dll!_callthreadstartex() Line 348 + 0x9 bytes C mozcrt19.dll!_threadstartex(void * ptd=0x243d0c00) Line 326 + 0x5 bytes C kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes I have found 4 like this in total (including this one)... It is possible i have opened exactly that number of videos.
I could not reproduce after restart with simply opening the "Hurricane Irene Forms" link and pressing play on the video..
Summary: Hi CPU load in nsBuiltinDecoderStateMachine::StopDecodeThread() → Hi CPU load + shutdown hang in nsBuiltinDecoderStateMachine::StopDecodeThread()
I hit something like this as well. My browser hung at shutdown with a full core pegged. I killed it and got the following crash dump: https://crash-stats.mozilla.com/report/index/bp-82bb730e-00de-4b99-8a8b-3764a2111010 Thread 17 scares me a bit.
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #2) > I hit something like this as well. My browser hung at shutdown with a full > core pegged. I killed it and got the following crash dump: > > https://crash-stats.mozilla.com/report/index/bp-82bb730e-00de-4b99-8a8b- > 3764a2111010 > > Thread 17 scares me a bit. It is pretty similar to my "First" thread from the description. I have seen this in the debugger, so it shouldn't be a bogus report.
Want to chime in here and say that this sounds *exactly* the same as issues I have been facing for several months on 2 separate machines (Laptop and Desktop - both have similar software setups). Re-producable: ALWAYS At first I thought this was a 'Flash' bug, but it is video in general as it also occurs whilst watching HTML5 videos (for me, it is mainly on YouTube). If I avoid videos then my FF will be fine. It also depends on how long FF has been opened; If I have a fresh start of FF then go to YouTube, I will likely be able to see the video with no issues, but if FF has been opened for a few hours, maybe only 15 mins (possibly having seen some videos in the mean time), then I expect it to hang. When hanging occurs, the video stops, all of FF appears to be responsive (regarding mouse overs), but as soon as you click on something (links, tabs, close tabs, close/minimise FF, anything...) the whole of FF locks up and goes into Windows "(not repsonding)". For me it normally comes back to life in about 30 seconds, all flash content has the grey "whoops, flash crashed" box with the "Send crash report" - sometimes, I can reload the page and watch some videos in peace before it happens again, but more often, I will load a video, which will completely buffer, but it won't play - this requires me to close FF (using normal methods such as the 'X'), but I check to see that FF has actually exited (sometimes it starts using considerable CPU on exit after this issue and doesn't actually exit - Window goes, but process stays with, as far as I can tell, all of its RAM still allocated). I also check that all plugin-containers also exit - if they remain, it causes issues. If you are unlucky, sometmes (and quite rarely) it won't come back at all from a hang...requiring me to end the process, and also on even rarer occasions I have to end the plugin-containers, of which there could be in the region of 2-4. I am fairly new to bug reporting for FF, but I am no novice of computers or development. If you require any additional help/information, please ask - but you may need to direct me to somewhere with step-by-step instructions :P System: OS: Windows 7 Enterprise x64 CPU: Intel Core i7 920 MB: ASUS P6TD DELUXE RAM: Corsair Dominator, 6GB (3x2GB), DDR3 PC3-12800 (1600MhZ), (Triple-Channel) GPU: MSI NVIDIA GeForce® GTX580 1536MB Twin FrozR II/OC HDD: Samsung Spinpoint F3 HD103SJ, 1TB, 32MB Cache, NCQ
Saw this bug in Chromium, which although it is a different browser, appears to be a similar issue: http://code.google.com/p/chromium/issues/detail?id=111514 It states at one point that it is a "4 way deadlock between the browser->plugin->renderer->gpu" Just in case.
Christoper, you may be suffering from a different bug. This bug has a specific stack trace pointing to the problem area, and it's not clear if what you're seeing is related to that issue. It'd be best to file a new bug and work from there. One thing that would be very useful to check is if hardware acceleration is enabled (check "GPU accelerated windows" in about:support), and let us know if you're able to reproduce the problem with hardware acceleration disabled, if it was enabled. You can toggle hardware acceleration in Options->Advanced->General->Browsing; you'll need to restart the browser after changing that setting.
Assignee: cpearce → nobody
Component: Audio/Video → Audio/Video: Playback
Mass closing do to inactivity. Feel free to re-open if still needed.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.