Closed Bug 149158 Opened 22 years ago Closed 8 years ago

synchronous url loads result in "entry already used" assert in nsCacheEntry

Categories

(Core :: Networking: Cache, defect)

x86
Windows NT
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: depman1, Unassigned)

References

()

Details

Attachments

(2 files)

Mozilla 1.0.0 Gecko 20020603 debug build. Also see bug 146907, a url crash
appearing to be caused by obtaining a zero-valued hashtable entry for the url
image. The bug described here occurs with successive url loads, doesn't appear
to be crashing, and asserts when attempting to add a hashtable entry. But if fix
for 146907 fixes this one as well, you can dupe it.
1. Turn off mfc alert posting for url loads in embedding app. I'll post a
'patch' for turning it off, but you can also just use a '1' for log posting only
in RVTestResult() (see above url, CNsIWebNav::LoadUriTest()).
2. compile TestEmbed and run from /dist/../bin
3. From Interfaces menu, select nsIWebNav. Select 'Run All Tests'.
4. confirm dlogs through LoadURI tests.
Result: Url load gets cancelled, but cache doesn't get cleared out. Get
Assertion: ### nsCacheEntryHashTable::AddEntry - entry already used:
((nsCacheEntryHashTableEntry *)hashEntry)->cacheEntry == 0)', file
/mozilla/netwerk/cache/src/nsCacheEntry.cpp line 525.

Call stack from assertion:
nsDebug::Assertion(const char * 0x029ef180, const char * 0x029ef144, const char
* 0x029ef108, int 525) line 278 + 13 bytes
nsCacheEntryHashTable::AddEntry(nsCacheEntry * 0x031f9840) line 525 + 35 bytes
nsCacheService::ActivateEntry(nsCacheRequest * 0x031a79f0, nsCacheEntry * *
0x0012f0f8) line 901 + 15 bytes
nsCacheService::ProcessRequest(nsCacheRequest * 0x031a79f0, int 1,
nsICacheEntryDescriptor * * 0x031c3fa0) line 750 + 16 bytes
nsCacheService::OpenCacheEntry(nsCacheSession * 0x00f3eb00, const char *
0x0012f1f8, int 2, int 0, nsICacheListener * 0x00000000, nsICacheEntryDescriptor
* * 0x031c3fa0) line 826 + 18 bytes
nsCacheSession::OpenCacheEntry(nsCacheSession * const 0x00f3eb00, const char *
0x0012f1f8, int 2, int 0, nsICacheEntryDescriptor * * 0x031c3fa0) line 82 + 34 bytes
nsHttpChannel::OpenCacheEntry(int * 0x0012f254) line 903 + 84 bytes
nsHttpChannel::Connect(int 1) line 213 + 12 bytes
nsHttpChannel::AsyncOpen(nsHttpChannel * const 0x031c3ed0, nsIStreamListener *
0x03198550, nsISupports * 0x00000000) line 2387 + 10 bytes
nsDocumentOpenInfo::Open(nsIChannel * 0x031c3ed0, int 0, nsISupports *
0x00ec8a40) line 170 + 18 bytes
nsURILoader::OpenURIVia(nsURILoader * const 0x00ec8940, nsIChannel * 0x031c3ed0,
int 0, nsISupports * 0x00ec8a40, unsigned int 0) line 538 + 20 bytes
nsURILoader::OpenURI(nsURILoader * const 0x00ec8940, nsIChannel * 0x031c3ed0,
int 0, nsISupports * 0x00ec8a40) line 500
nsDocShell::DoChannelLoad(nsIChannel * 0x031c3ed0, nsIURILoader * 0x00ec8940)
line 5169 + 39 bytes
nsDocShell::DoURILoad(nsIURI * 0x00f39c90, nsIURI * 0x00000000, nsISupports *
0x00000000, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000, int 1,
nsIDocShell * * 0x00000000, nsIRequest * * 0x00000000) line 4944 + 38 bytes
nsDocShell::InternalLoad(nsDocShell * const 0x00ec8a40, nsIURI * 0x00f39c90,
nsIURI * 0x00000000, nsISupports * 0x00000000, int 0, const unsigned short *
0x00000000, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000, unsigned
int 50331650, nsISHEntry * 0x031745d4, int 1, nsIDocShell * * 0x00000000,
nsIRequest * * 0x00000000) line 4737 + 51 bytes
nsDocShell::LoadHistoryEntry(nsDocShell * const 0x00ec8a40, nsISHEntry *
0x031745d4, unsigned int 50331650) line 5752 + 61 bytes
nsDocShell::Reload(nsDocShell * const 0x00ec8a50, unsigned int 768) line 2438 +
38 bytes
nsWebBrowser::Reload(nsWebBrowser * const 0x00ec9b84, unsigned int 768) line 622
CNsIWebNav::ReloadTest(const unsigned long 768) line 351 + 42 bytes
CNsIWebNav::LoadUriandReload(int 11) line 215
CNsIWebNav::RunAllTests() line 174
CNsIWebNav::OnStartTests(unsigned int 32907) line 99
CTests::OnInterfacesNsiwebnav() line 781
_AfxDispatchCmdMsg(CCmdTarget * 0x00f38280 {CTests hWnd=0x00000000}, unsigned
int 32907, int 0, void (void)* 0x004010aa CTests::OnInterfacesNsiwebnav(void),
void * 0x00000000, unsigned int 12, AFX_CMDHANDLERINFO * 0x00000000) line 88
CCmdTarget::OnCmdMsg(unsigned int 32907, int 0, void * 0x00000000,
AFX_CMDHANDLERINFO * 0x00000000) line 302 + 39 bytes
CTests::OnCmdMsg(unsigned int 32907, int 0, void * 0x00000000,
AFX_CMDHANDLERINFO * 0x00000000) line 724
CBrowserView::OnCmdMsg(unsigned int 32907, int 0, void * 0x00000000,
AFX_CMDHANDLERINFO * 0x00000000) line 1062 + 42 bytes
CBrowserFrame::OnCmdMsg(unsigned int 32907, int 0, void * 0x00000000,
AFX_CMDHANDLERINFO * 0x00000000) line 280 + 37 bytes
CWnd::OnCommand(unsigned int 32907, long 0) line 2088
CFrameWnd::OnCommand(unsigned int 32907, long 0) line 321
CWnd::OnWndMsg(unsigned int 273, unsigned int 32907, long 0, long * 0x0012fd98)
line 1597 + 28 bytes
CWnd::WindowProc(unsigned int 273, unsigned int 32907, long 0) line 1585 + 30 bytes
AfxCallWndProc(CWnd * 0x01144340 {CBrowserFrame hWnd=0x00050642}, HWND__ *
0x00050642, unsigned int 273, unsigned int 32907, long 0) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x00050642, unsigned int 273, unsigned int 32907, long 0)
line 368
AfxWndProcBase(HWND__ * 0x00050642, unsigned int 273, unsigned int 32907, long
0) line 220 + 21 bytes
US

Note: if you press Ignore at this point, you get another assert: ### Attempting
to remove unknown cache entry!!! 'check == cacheEntry', file
/mozilla/netwerk/cache/src/nsCacheEntry.cpp line 544.

call stack:
nsDebug::Assertion(const char * 0x029ef31c, const char * 0x029ef308, const char
* 0x029ef2cc, int 544) line 278 + 13 bytes
nsCacheEntryHashTable::RemoveEntry(nsCacheEntry * 0x02d69e90) line 544 + 34 bytes
nsCacheService::DoomEntry_Locked(nsCacheEntry * 0x02d69e90) line 1027
nsCacheService::DoomEntry(nsCacheEntry * 0x02d69e90) line 1007 + 12 bytes
nsCacheEntryDescriptor::Doom(nsCacheEntryDescriptor * const 0x02d69e30) line 318
nsHttpChannel::CloseCacheEntry(unsigned int 2152398850) line 1258 + 29 bytes
nsHttpChannel::OnCacheEntryAvailable(nsHttpChannel * const 0x02d690a8,
nsICacheEntryDescriptor * 0x02d69e30, int 2, unsigned int 0) line 3182
XPTC_InvokeByIndex(nsISupports * 0x02d690a8, unsigned int 3, unsigned int 3,
nsXPTCVariant * 0x02dba2c0) line 106
EventHandler(PLEvent * 0x02dba270) line 567 + 41 bytes
PL_HandleEvent(PLEvent * 0x02dba270) line 596 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00e7e6a0) line 526 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x14dc0390, unsigned int 49621, unsigned int 0,
long 15197856) line 1077 + 9 bytes
USER32! 77e71820()
00
only will post to logfile C:/temp/TestOutput.txt for LoadURI() tests.
How would a user see this type of crash in using the product with Necko?
The problem here isn't a crash, but an assert occurring when attempting to add a
hashtable entry. The previous url request is being cancelled, but the cache
isn't being cleared out. I don't think this is a typical user scenario because
embeddors will likely use web progress listener states for asynchronous url
loading, i.e. STATE_STOP before the next load; but this test might be unmasking
some problem which the user doesn't directly see.
-> gordon
Assignee: darin → gordon
Component: Networking: HTTP → Networking: Cache
QA Contact: tever → benc
this bug needs to be reassigned
Assignee: gordon → nobody
QA Contact: benc → networking.cache
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: