dev hang at xul.dll!mozilla::image::SourceBuffer::Complete+0x1e




3 years ago
3 years ago


(Reporter: Cees T., Unassigned)


39 Branch
Windows 7

Firefox Tracking Flags

(Not tracked)


(Whiteboard: gfx-noted)


(1 attachment)



3 years ago
Created attachment 8590928 [details]
dev firefox.exe 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

Actual results:

Browser froze.

Expected results:

Browser kept going.

Comment 1

3 years ago
Please try for this issue, as suggested in the other bug.
Flags: needinfo?(tmptgr)

Comment 2

3 years ago
(In reply to Nickolay_Ponomarev from comment #1)
> Please try
> 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.
Flags: needinfo?(tmptgr)

Comment 3

3 years ago
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]

Comment 4

3 years ago
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 with information you should provide when reporting a hang.
Component: Untriaged → ImageLib
Product: Firefox → Core

Comment 5

3 years ago
The abbreviated contents of attachment 8590928 [details]:
> dev firefox.exe
> [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. =\
Whiteboard: gfx-noted
You need to log in before you can comment on or make changes to this bug.