###!!! ASSERTION: CachedChromeStream doesn't receive data: 'Not Reached', file i:/build/mozilla/content/xul/document/src/nsXULDocument.cpp, line 7069 Break: at file i:/build/mozilla/content/xul/document/src/nsXULDocument.cpp, line 7069 NTDLL! 77f9f9df() nsDebug::Assertion(const char * 0x01adb388, const char * 0x101326bc, const char * 0x01adb34c, int 7069) line 280 + 13 bytes nsDebug::NotReached(const char * 0x01adb388, const char * 0x01adb34c, int 7069) line 457 + 22 bytes nsXULDocument::CachedChromeStreamListener::OnDataAvailable(nsXULDocument::CachedChromeStreamListener * const 0x02d6c140, nsIRequest * 0x051a3ae0, nsISupports * 0x00000000, nsIInputStream * 0x04f89cb8, unsigned int 0, unsigned int 16384) line 7069 + 21 bytes nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x0513aba8, nsIRequest * 0x051a3ae0, nsISupports * 0x00000000, nsIInputStream * 0x04f89cb8, unsigned int 0, unsigned int 16384) line 244 + 46 bytes nsJARChannel::OnDataAvailable(nsJARChannel * const 0x051a3ae4, nsIRequest * 0x015a4854, nsISupports * 0x00000000, nsIInputStream * 0x04f89cb8, unsigned int 0, unsigned int 16384) line 633 nsOnDataAvailableEvent::HandleEvent() line 194 + 70 bytes nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x0350df1c) line 116 PL_HandleEvent(PLEvent * 0x0350df1c) line 644 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x01018f30) line 574 + 9 bytes _md_TimerProc(HWND__ * 0x00040486, unsigned int 275, unsigned int 0, unsigned long 247751407) line 930 + 9 bytes USER32! 77e13eb0() USER32! 77e14092() USER32! 77e13f0f() nsAppShellService::Run(nsAppShellService * const 0x01528e60) line 472 main1(int 1, char * * 0x00284570, nsISupports * 0x00276f08) line 1541 + 32 bytes main(int 1, char * * 0x00284570) line 1902 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e87903() -- i got this while doing a live skin switch with a null profile. i'm pretty sure it's just the skin switch that caused the problem.
fwiw, the switch was classic>modern, and the problem happened after i loaded inspector in modern (first load of the session).
Benjamin, any idea how we're managing to think we have a cached chrome channel while we have a jar channel (that's what seems to be happening here)...
I was playing around with the chrome ph, and I managed to hit this assertion by pretending that nothing was in the chrome cache (i.e., not even checking). Perhaps we get a cache miss, which actually tries to load the document, which asserts?
I don't know, but.. it seems that the fastload cache and the XUL prototype cache are out of sync (the prototype cache thinks the doc is cached, while the chrome registry/fastload cache don't). This means that the (proto) test at http://lxr.mozilla.org/mozilla/source/content/xul/document/src/nsXULDocument.cpp#579 is succeeding, but the chrome registry doesn't find a fastload cache and returns a real channel instead of a cached channel.
Er... If we have a cached prototype, why are we even bothering to look in fastload? We should just be using the prototype, no?
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.