Closed Bug 81799 Opened 24 years ago Closed 24 years ago

Infinite loop in disk cache

Categories

(Core :: Networking: Cache, defect)

Product:
Core
Component:
Networking: Cache
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: jwbaker, Assigned: gordon)

Details

(Keywords: hang, smoketest)

I'm am hitting an infinite loop in the new disk cache with Linux build pulled 2001-05-19-11, and with nightly 2001-05-19-<mumble>. Here's what I see when I interrupt it: 1 Thread 1024 (LWP 23241) 0x41c10739 in nsDiskCacheMap::EvictRecords ( this=0x4217d008, visitor=0xbfffee4c) at nsDiskCacheMap.cpp:476 (gdb) thread 1 [Switching to thread 1 (Thread 1024 (LWP 23241))]#0 0x41c10739 in nsDiskCacheMap::EvictRecords (this=0x4217d008, visitor=0xbfffee4c) at nsDiskCacheMap.cpp:476 476 for (int i = 0; i < kBucketsPerTable; ++i) { Current language: auto; currently c++ (gdb) where #0 0x41c10739 in nsDiskCacheMap::EvictRecords (this=0x4217d008, visitor=0xbfffee4c) at nsDiskCacheMap.cpp:476 #1 0x41c0e4ee in nsDiskCacheDevice::EvictDiskCacheEntries (this=0x85f9090) at nsDiskCacheDevice.cpp:1032 #2 0x41c0dcaf in nsDiskCacheDevice::OnDataSizeChange (this=0x85f9090, entry=0x83fed98, deltaSize=4096) at nsDiskCacheDevice.cpp:870 #3 0x41c07f01 in nsCacheService::OnDataSizeChange (this=0x823fc40, entry=0x83fed98, deltaSize=4096) at nsCacheService.cpp:906 #4 0x41c031b3 in nsCacheEntryDescriptor::RequestDataSizeChange ( this=0x8601788, deltaSize=4096) at nsCacheEntryDescriptor.cpp:182 #5 0x41c0473b in nsCacheEntryDescriptor::nsOutputStreamWrapper::OnWrite ( this=0x84f1198, count=4096) at nsCacheEntryDescriptor.cpp:644 #6 0x41c045a5 in nsCacheEntryDescriptor::nsOutputStreamWrapper::Write ( this=0x84f1198, buf=0x865aef0 "r>\nrootdsks/pcmcia.dsk: Upgraded to pcmcia-cs-3.1.25.<br>\na1/elflibs.tgz: Upgraded libvga, libvgagl. Added libgmp.<br>\na1/hdsetup.tgz: Enhancements to installpkg/removepkg suggested<br>\n&nbsp; &nb"..., count=4096, result=0xbfffefd0) at nsCacheEntryDescriptor.cpp:611 #7 0x4010c338 in nsInputStreamTee::TeeSegment (this=0x8475378, buf=0x865aef0 "r>\nrootdsks/pcmcia.dsk: Upgraded to pcmcia-cs-3.1.25.<br>\na1/elflibs.tgz: Upgraded libvga, libvgagl. Added libgmp.<br>\na1/hdsetup.tgz: Enhancements to installpkg/removepkg suggested<br>\n&nbsp; &nb"..., count=4096) at nsInputStreamTee.cpp:67 #8 0x4010c456 in nsInputStreamTee::WriteSegmentFun (in=0x83eb268, closure=0x8475378, fromSegment=0x865aef0 "r>\nrootdsks/pcmcia.dsk: Upgraded to pcmcia-cs-3.1.2 5.<br>\na1/elflibs.tgz: Upgraded libvga, libvgagl. Added libgmp.<br>\na1/hdsetup.tgz: Enhancements to installpkg/removepkg suggested<br>\n&nbsp; &nb"..., offset=0, count=4096, writeCount=0xbffff080) at nsInputStreamTee.cpp:88 #9 0x40104b3e in nsPipe::nsPipeInputStream::ReadSegments (this=0x83eb268, writer=0x4010c398 <nsInputStreamTee::WriteSegmentFun(nsIInputStream *, void *, char const *, unsigned int, unsigned int, unsigned int *)>, closure=0x8475378, count=16384, readCount=0xbffff138) at nsPipe2.cpp:411 #10 0x4010ca9c in nsInputStreamTee::ReadSegments (this=0x8475378, writer=0x40d4d434 <ParserWriteFunc(nsIInputStream *, void *, char const *, unsigned int, unsigned int, unsigned int *)>, closure=0xbffff13c, count=16384, bytesRead=0xbffff138) at nsInputStreamTee.cpp:137 #11 0x40d4d708 in nsParser::OnDataAvailable (this=0x86572d0, request=0x8600a90, aContext=0x0, pIStream=0x8475378, sourceOffset=28672, aLength=16384) at nsParser.cpp:2320 #12 0x40dbf043 in nsDocumentOpenInfo::OnDataAvailable (this=0x8600d70, request=0x8600a90, aCtxt=0x0, inStr=0x8475378, sourceOffset=28672, count=16384) at nsURILoader.cpp:237 #13 0x40b6808e in nsStreamListenerTee::OnDataAvailable (this=0x851ffd8, request=0x8600a90, context=0x0, input=0x83eb268, offset=28672, count=16384) at nsStreamListenerTee.cpp:56 #14 0x40b9c534 in nsHttpChannel::OnDataAvailable (this=0x8600a90, request=0x8600d98, ctxt=0x0, input=0x83eb268, offset=28672, count=16384) at nsHttpChannel.cpp:2071 #15 0x40b4ef90 in nsOnDataAvailableEvent::HandleEvent (this=0x83f3fe8) at nsStreamListenerProxy.cpp:173 #16 0x40b4e2b9 in nsARequestObserverEvent::HandlePLEvent (plev=0x83f3fe8) at nsRequestObserverProxy.cpp:63 #17 0x40125ce4 in PL_HandleEvent (self=0x83f3fe8) at plevent.c:590 #18 0x40125ad0 in PL_ProcessPendingEvents (self=0x80a88d0) at plevent.c:520 #19 0x40127f7c in nsEventQueueImpl::ProcessPendingEvents (this=0x80a88a8) ---Type <return> to continue, or q <return> to quit--- at nsEventQueue.cpp:374 #20 0x40982a63 in event_processor_callback (data=0x80a88a8, source=7, condition=GDK_INPUT_READ) at nsAppShell.cpp:168 #21 0x40982615 in our_gdk_io_invoke (source=0x81c8740, condition=G_IO_IN, data=0x81d78b8) at nsAppShell.cpp:61 #22 0x4045720e in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0 #23 0x40458717 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #24 0x40458cdb in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #25 0x40458e59 in g_main_run () from /usr/lib/libglib-1.2.so.0 #26 0x40387069 in gtk_main () from /usr/lib/libgtk-1.2.so.0 #27 0x409831d5 in nsAppShell::Run (this=0x80f4690) at nsAppShell.cpp:360 #28 0x40918efe in nsAppShellService::Run (this=0x80e8158) at nsAppShellService.cpp:417 #29 0x0805abd9 in main1 (argc=1, argv=0xbffff7f4, nativeApp=0x0) at nsAppRunner.cpp:1093 #30 0x0805b9e1 in main (argc=1, argv=0xbffff7f4) at nsAppRunner.cpp:1391 #31 0x4058bf5c in __libc_start_main (main=0x805b7c8 <main>, argc=1, ubp_av=0xbffff7f4, init=0x80549d4 <_init>, fini=0x806895c <_fini>, rtld_fini=0x4000ce30 <_dl_fini>, stack_end=0xbffff7ec) at ../sysdeps/generic/libc-start.c:129
Marking smoketest/blocker because I cannot complete the smoketests without hitting this. CCing those mentioned on the cache checkin.
Severity: critical → blocker
Keywords: crash, smoketest
Replacing "crash" keyword by "hang".
Keywords: crash → hang
Is there any particular series of smoketests that this occurs on? I have not been able to reproduce it yet.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Maybe your cache isn't filling up, or it is turned off. My caches are set to 5KB memory and 30KB disk for testing. I find that this roots out cache bugs pretty frequently :) Anyway there isn't a particular test it hangs on, it just usually starts spinning after the first or second page loaded. Maybe this shouldn't be blocker though since turning the cache off is probably a workaround. It does block testing of the cache.
may be related: A hang on reload is reported in bug 81837 and bug 81885.
Bug 81907 may be related, too.
I see the same hang on OpenVMS if I have my disk cache size set to 0. This is with 5/19 code. If I try to stop it I'm also in EvictRecords.
I reported this in another bug, which is probably a dupe, but I can reporduce the other problem everytime. Basically, it will occur whent he disk cache is full. If anyone can confirm I will mark the other as a dupe. Here`s the description I posted: Downloading a file larger than what the disk cache is set to will halt the browser and eventually require the task to be killed. I tested by setting the disk cache to 4096 and then tried downloading mozilla nightly. The browser freeze after obtaining 4096KB of the zip file.
...which explains why if I set the disk cache size to zero I can't do anything.
Thanks for the investigation. I think I know what's going on now. If the most evictable entry in a cache map bucket is active (perhaps because we're currently fetching it from the net), we will end up in an infinite loop. One way to make this happen is to fetch a single document that is larger than the cache itself. I need to add some additional logic to move on to the next bucket after we've decided not to evict an active entry. I should have a patch for this later this afternoon. I'll have to investigate the disk cache set to 0 problem. That may be a separate bug.
Oh, since this is a smoketest blocker, I'll have a patch ready as soon as possible.
i'm not seeing this in the smoketest results... i'm not sure this *should* be a smoketest blocker, especially if you are on the right track. gordon, can you page me when you've checked in your fix; i think we can open the tree before respins are done.
A fix has been checked in. Downgrading severity to major, until I've investigated any problems with a zero-size disk cache, after which I'll close the bug.
Severity: blocker → major
Found another infinite loop case when setting disk cache size to 0. Here's the patch to fix it: Index: mozilla/netwerk/cache/src/nsDiskCacheMap.cpp =================================================================== RCS file: /cvsroot/mozilla/netwerk/cache/src/nsDiskCacheMap.cpp,v retrieving revision 1.6 diff -u -2 -r1.6 nsDiskCacheMap.cpp --- nsDiskCacheMap.cpp 2001/05/21 22:05:07 1.6 +++ nsDiskCacheMap.cpp 2001/05/21 22:43:25 @@ -496,4 +496,5 @@ } + if (rank == 0) break; // we've examined all the records NS_ASSERTION(mHeader.mEvictionRank[index] == mBuckets[index].EvictionRank(0), "header eviction rank out of sync");
sr=hyatt
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Verifying with linux 2001052308 build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.