180557 - ASSERTION: CachedChromeStream doesn't receive data: 'Not Reached'

Status: NEW

(Core :: XUL, defect)

Description

[timeless]

###!!! 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.

Comment 1

[timeless]

fwiw, the switch was classic>modern, and the problem happened after i loaded
inspector in modern (first load of the session).

Comment 2

[Boris Zbarsky [:bzbarsky]]

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)...

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

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?

Comment 4

[Benjamin Smedberg]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Er...  If we have a cached prototype, why are we even bothering to look in
fastload?  We should just be using the prototype, no?