Closed Bug 1159285 Opened 6 years ago Closed 3 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 :: ImageLib, defect)

Unspecified
Windows 7
defect
Not set
normal

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
seth: bz told me you might be interested in this, could you take a look ?
Flags: needinfo?(seth)
Component: General → ImageLib
Yes, thanks. Looks like a race in the image loading code.
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.
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)
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?
Assignee: nobody → tnikkel
Blocks: 1063369
Flags: needinfo?(seth)
Flags: needinfo?(milan)
From Automation, it appears to be a debug fatal assert only.
this is prettty reproducible in the wild. Timothy can you take a look ? Thanks!
Flags: needinfo?(tnikkel)
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)
http://www.gdltax.gov.cn/ reproduced on load with nightly from today on fedora 25 64bit.
Flags: needinfo?(cbook)
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.
Attached file mozconfig
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.
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?
Attached file prox.txt
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.
Thanks! I can reproduce!
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).
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: 3 years ago
Flags: needinfo?(tnikkel)
Resolution: --- → DUPLICATE
Duplicate of bug: 1416774
You need to log in before you can comment on or make changes to this bug.