Closed
Bug 1159285
Opened 9 years ago
Closed 6 years ago
Assertion failure: proxy->NotificationsDeferred() (Proxies waiting on cache validation should be deferring notifications!), at c:/Users/mozilla/debug-builds/mozilla-central/image/src/imgLoader.cpp:282
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1416774
People
(Reporter: cbook, Assigned: tnikkel)
References
()
Details
(Keywords: assertion, Whiteboard: gfx-noted)
Attachments
(2 files)
Found via Bughunter and reproduced on a Windows 7 Trunk Debug Build: Steps to reproduce: -> Load http://www.dpr.go.id ->> Assertion failure on load Assertion failure: proxy->NotificationsDeferred() (Proxies waiting on cache validation should be def erring notifications!), at c:/Users/mozilla/debug-builds/mozilla-central/image/src/imgLoader.cpp:282 #01: mozilla::net::nsHttpChannel::CallOnStartRequest (c:\users\mozilla\debug-builds\mozilla-central\ netwerk\protocol\http\nshttpchannel.cpp:956) #02: mozilla::net::nsHttpChannel::ContinueOnStartRequest3 (c:\users\mozilla\debug-builds\mozilla-cen tral\netwerk\protocol\http\nshttpchannel.cpp:5447) #03: mozilla::net::nsHttpChannel::OnStartRequest (c:\users\mozilla\debug-builds\mozilla-central\netw erk\protocol\http\nshttpchannel.cpp:5410) #04: nsInputStreamPump::OnStateStart (c:\users\mozilla\debug-builds\mozilla-central\netwerk\base\nsi nputstreampump.cpp:532) #05: nsInputStreamPump::OnInputStreamReady (c:\users\mozilla\debug-builds\mozilla-central\netwerk\ba se\nsinputstreampump.cpp:449) #06: nsInputStreamReadyEvent::Run (c:\users\mozilla\debug-builds\mozilla-central\xpcom\io\nsstreamut ils.cpp:93) #07: nsThread::ProcessNextEvent (c:\users\mozilla\debug-builds\mozilla-central\xpcom\threads\nsthrea d.cpp:868) #08: NS_ProcessNextEvent (c:\users\mozilla\debug-builds\mozilla-central\xpcom\glue\nsthreadutils.cpp :265) #09: mozilla::ipc::MessagePump::Run (c:\users\mozilla\debug-builds\mozilla-central\ipc\glue\messagep ump.cpp:99) #10: MessageLoop::RunInternal (c:\users\mozilla\debug-builds\mozilla-central\ipc\chromium\src\base\m essage_loop.cc:233) #11: MessageLoop::RunHandler (c:\users\mozilla\debug-builds\mozilla-central\ipc\chromium\src\base\me ssage_loop.cc:227) [4736] WARNING: Previous vsync timestamp is ahead of the calculated vsync timestamp.: file c:/Users/ mozilla/debug-builds/mozilla-central/gfx/thebes/gfxWindowsPlatform.cpp, line 2185 #12: MessageLoop::Run (c:\users\mozilla\debug-builds\mozilla-central\ipc\chromium\src\base\message_l oop.cc:201) #13: nsBaseAppShell::Run (c:\users\mozilla\debug-builds\mozilla-central\widget\nsbaseappshell.cpp:16 7) #14: nsAppShell::Run (c:\users\mozilla\debug-builds\mozilla-central\widget\windows\nsappshell.cpp:18 0) #15: nsAppStartup::Run (c:\users\mozilla\debug-builds\mozilla-central\toolkit\components\startup\nsa ppstartup.cpp:281) #16: XREMain::XRE_mainRun (c:\users\mozilla\debug-builds\mozilla-central\toolkit\xre\nsapprunner.cpp :4071) #17: XREMain::XRE_main (c:\users\mozilla\debug-builds\mozilla-central\toolkit\xre\nsapprunner.cpp:41 51) #18: XRE_main (c:\users\mozilla\debug-builds\mozilla-central\toolkit\xre\nsapprunner.cpp:4240) #19: do_main (c:\users\mozilla\debug-builds\mozilla-central\browser\app\nsbrowserapp.cpp:214) #20: NS_internal_main (c:\users\mozilla\debug-builds\mozilla-central\browser\app\nsbrowserapp.cpp:47 8) #21: wmain (c:\users\mozilla\debug-builds\mozilla-central\toolkit\xre\nswindowswmain.cpp:124) [4736] WARNING: Previous vsync timestamp is ahead of the calculated vsync timestamp.: file c:/Users/ mozilla/debug-builds/mozilla-central/gfx/thebes/gfxWindowsPlatform.cpp, line 2185 #22: __tmainCRTStartup (f:\dd\vctools\crt\crtw32\startup\crt0.c:255) #23: BaseThreadInitThunk[kernel32 +0x4ee1c] #24: RtlInitializeExceptionChain[ntdll +0x637eb] #25: RtlInitializeExceptionChain[ntdll +0x637be] 1
Reporter | ||
Comment 1•9 years ago
|
||
seth: bz told me you might be interested in this, could you take a look ?
Flags: needinfo?(seth)
Updated•9 years ago
|
Component: General → ImageLib
Comment 2•9 years ago
|
||
Yes, thanks. Looks like a race in the image loading code.
Assignee | ||
Comment 3•9 years ago
|
||
This might be a regression from bug 1063369. I got the assert when testing once with bug 1063369 in. But both times I tried with bug 1063369 backed out I got no assert.
Whiteboard: gfx-noted
Reporter | ||
Comment 4•8 years ago
|
||
still able to reproduce this on http://wueste.pl/kontakt/ milan, could you help find an owner for this since this is a regression according to comment #3 and waiting for a fix since +6 months or so :) ?
Flags: needinfo?(milan)
Reporter | ||
Comment 5•8 years ago
|
||
fwiw, here is a current stack from a m-c build based on m-c tip Assertion failure: proxy->NotificationsDeferred() (Proxies waiting on cache validation should be deferring notifications!), at c:/Users/ l/image/imgLoader.cpp:2751 #01: mozilla::net::nsHttpChannel::CallOnStartRequest[xul +0x98651f] #02: mozilla::net::nsHttpChannel::ContinueOnStartRequest3[xul +0x98f1a4] #03: mozilla::net::nsHttpChannel::ContinueOnStartRequest2[xul +0x98f137] #04: mozilla::net::nsHttpChannel::OnStartRequest[xul +0x9b76ee] #05: nsInputStreamPump::OnStateStart[xul +0x714b50] #06: nsInputStreamPump::OnInputStreamReady[xul +0x71280b] #07: nsInputStreamReadyEvent::Run[xul +0x579d0a] #08: nsThread::ProcessNextEvent[xul +0x5b242f] #09: NS_ProcessNextEvent[xul +0x6179c2] #10: mozilla::ipc::MessagePump::Run[xul +0xbd60b1] #11: MessageLoop::RunInternal[xul +0xb5dd4d] #12: MessageLoop::RunHandler[xul +0xb5dcc2] #13: MessageLoop::Run[xul +0xb5d8cd] #14: nsBaseAppShell::Run[xul +0x40639c0] #15: nsAppShell::Run[xul +0x41080e7] #16: nsAppStartup::Run[xul +0x50ebf7f] #17: XREMain::XRE_mainRun[xul +0x519dbaa] #18: XREMain::XRE_main[xul +0x519a976] #19: XRE_main[xul +0x51a049a] #20: do_main (c:\users\mozilla\debug-build\mozilla-central\browser\app\nsbrowserapp.cpp:212) #21: NS_internal_main (c:\users\mozilla\debug-build\mozilla-central\browser\app\nsbrowserapp.cpp:352) #22: wmain (c:\users\mozilla\debug-build\mozilla-central\toolkit\xre\nswindowswmain.cpp:131) #23: __tmainCRTStartup (f:\dd\vctools\crt\crtw32\startup\crt0.c:255) #24: BaseThreadInitThunk[kernel32 +0x4ee6c] #25: RtlInitializeExceptionChain[ntdll +0x63ab3] #26: RtlInitializeExceptionChain[ntdll +0x63a86]
Does it crash in release, or is it "just" the assert?
Comment 7•8 years ago
|
||
From Automation, it appears to be a debug fatal assert only.
Reporter | ||
Comment 8•8 years ago
|
||
this is prettty reproducible in the wild. Timothy can you take a look ? Thanks!
Flags: needinfo?(tnikkel)
Assignee | ||
Comment 9•7 years ago
|
||
Sorry for taking so long to get to this. I tried to two urls in this bug, neither one reproduced. Can we get a new url (or set of urls) that reproduce this problem? I'm not sure if this is super important (ie not sure it can lead to much bigger problems). Looking at the history when NotificationsDeferred was added it looks like it was to avoid sending duplicate notifications. Our image observers have been changed a lot since then and have less expectations (out of necessity), so they might not even be confused by these things anymore.
Flags: needinfo?(cbook)
Comment 10•7 years ago
|
||
http://www.gdltax.gov.cn/ reproduced on load with nightly from today on fedora 25 64bit.
Flags: needinfo?(cbook)
Assignee | ||
Comment 11•7 years ago
|
||
Hmm, I tried my local build on OS X, e10s and non-e10s, a debug build with optimizations enabled and a debug build with optimization disabled. Couldn't reproduce.
Comment 12•7 years ago
|
||
This is the mozconfig I am using. I have rust installed and llvm/clang 3.9.1 as well. I have a macbook and will try to get a build and check there.
Assignee | ||
Comment 13•7 years ago
|
||
Hmm, I don't see anything in your mozconfig that should change anything. My two linux machines are currently not working so I can't try linux atm. Maybe you can provide a list of urls that reproduce and hopefully one of them will work for me?
Comment 14•7 years ago
|
||
I tested 174 urls where we have reproduced this on Linux/Windows on a fresh build on OSX 10.12.3 and reproduced the assertion on these 12 urls.
Assignee | ||
Comment 15•7 years ago
|
||
Thanks! I can reproduce!
Assignee | ||
Comment 16•7 years ago
|
||
The "notifications deferred" is used for two different things. 1) deferring notifications while we have a runnable pending to send them 2) when we are validating that the image we have in the cache is still valid to use The assert comes from the code handling 2. But while 2) is happening the src of the <img> element in question gets changed, which causes the imgRequestProxy to stop observing the progress tracker (nsImageLoadingContent calls CancelAndForgetObserver). ProgressTracker::RemoveObserver calls SetNotificationsDeferred(false), in case ProgressTracker had deferred notifications before (it hadn't in this case).
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 22•6 years ago
|
||
I had forgotten about this bug. I hit this locally, figured out the root cause and posted a patch in bug 1416774.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(tnikkel)
Resolution: --- → DUPLICATE
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
You need to log in
before you can comment on or make changes to this bug.
Description
•