5.70 KB, text/plain
Created attachment 8590928 [details] dev firefox.exe 126.96.36.19976 hang at image_SourceBuffer_Complete.txt User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0 Build ID: 20150409004007 Steps to reproduce: Play multiple animated GIFs on https://nl.pinterest.com/NaughtyGirl4Eva/sexy-gifs/ Actual results: Browser froze. Expected results: Browser kept going.
Please try https://support.mozilla.org/en-US/kb/troubleshoot-extensions-themes-to-fix-problems for this issue, as suggested in the other bug.
(In reply to Nickolay_Ponomarev from comment #1) > Please try > https://support.mozilla.org/en-US/kb/troubleshoot-extensions-themes-to-fix- > problems for this issue, as suggested in the other bug. As you said, add-ons should've cause the browser to freeze. I can't even repro with the add-on active.
Shouldn't, rather, but it appears this one's using deep legacy magic (as noted in the other bug 1148837); when i use the debugger button of the Pinterest add-on in the add-on screen, i get a window saying this: [Exception... "Component returned failure code: 0x804b000d (NS_ERROR_CONNECTION_REFUSED) [nsIInputStream.available]" nsresult: "0x804b000d (NS_ERROR_CONNECTION_REFUSED)" location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/security/socket.js :: onInputStreamReady :: line 300" data: no]
I don't think this stack trace is useful without more information. The stack shows that: * either the process is stuck waiting on the lock (in this case it would help seeing what other threads were doing at that moment) * or that you just took the stack trace at the moment it was acquiring the lock. I updated https://developer.mozilla.org/en-US/docs/How_to_Report_a_Hung_Firefox with information you should provide when reporting a hang.
Component: Untriaged → ImageLib
Product: Firefox → Core
The abbreviated contents of attachment 8590928 [details]: > dev firefox.exe 188.8.131.5276 > [snip] > nss3.dll!PR_Lock+0x17 > xul.dll!mozilla::image::SourceBuffer::Complete+0x1e > xul.dll!mozilla::image::RasterImage::OnImageDataComplete+0x2e > xul.dll!imgRequest::OnStopRequest+0xb1 > xul.dll!ProxyListener::OnStopRequest+0x1d > xul.dll!nsStreamListenerTee::OnStopRequest+0x4d > xul.dll!mozilla::net::nsHttpChannel::OnStopRequest+0x209 > xul.dll!nsInputStreamPump::OnStateStop+0xb5 > xul.dll!nsInputStreamPump::OnInputStreamReady+0x83 > xul.dll!nsInputStreamReadyEvent::Run+0x1b > xul.dll!nsThread::ProcessNextEvent+0x768 > xul.dll!mozilla::ipc::MessagePump::Run+0x5f > xul.dll!MessageLoop::RunHandler+0x20 > xul.dll!MessageLoop::Run+0x19 > xul.dll!nsBaseAppShell::Run+0x32 > [snip] > [the stack is repeated 4 times]
If what's happening is a deadlock in SourceBuffer::Complete(), then we really need a stack for all threads to figure out how the deadlock is happening. =\
3 years ago
You need to log in before you can comment on or make changes to this bug.