Closed Bug 54072 Opened 24 years ago Closed 24 years ago

crash in [@ nsReplacementPolicy::AddAllRecordsInCache - MSVCRT.DLL]

Categories

(Core :: Networking: Cache, defect, P3)

Product:
Core
Component:
Networking: Cache
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jay, Assigned: neeti)

References

Details

(Keywords: crash, topcrash, Whiteboard: [rtm++])

Crash Data

Attachments

(2 files)

patch to increase size of array
1.05 KB, patch
Details | Diff | Splinter Review
patch for fixing the crash
3.61 KB, patch
Details | Diff | Splinter Review 
This seems related to bug 52818.  In the latest talkback data, I found a lot of 
crashes in nsReplacementPolicy::AddAllRecordsInCache while looking at the stack 
traces for the MSVCRT.DLL and MSVCRT.dll crashes. here are a few entries and a 
stack trace:

MSVCRT.DLL + 0x1041 (0x78001041) c38454ec
         line 
        Build: 2000091806 CrashDate: 2000-09-19 UptimeMinutes: 564  Total: 598 
        OS: Windows 98  4.10 build 67766222
        URL: 
        Comment: app was "idle"
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17678337
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=17678337

MSVCRT.DLL + 0x10cc8 (0x78010cc8) 13e80406
         line 
        Build: 2000091821 CrashDate: 2000-09-19 UptimeMinutes: 53  Total: 387 
        OS: Windows 98  4.10 build 67766446
        URL: https://int.ids.net/cims/index2.htm
        Comment: 
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17679219
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=17679219

MSVCRT.DLL + 0x1041 (0x78001041) 04dbcfd8
         line 
        Build: 2000091806 CrashDate: 2000-09-19 UptimeMinutes: 99  Total: 212 
        OS: Windows 98  4.10 build 67766446
        URL: www.thinkgeek.org 
        Comment: pressed the 'back' button. 
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17653523
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=17653523

MSVCRT.DLL + 0x10d9 (0x780010d9) 624edb1f
         line 
        Build: 2000091909 CrashDate: 2000-09-20 UptimeMinutes: 54  Total: 54 
        OS: Windows NT  5.0 build 2195
        URL: http://www.bt.com/openworld/
        Comment: I had just clicked the "What do I get?" link to the left of the 
page.
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17713842
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=17713842

MSVCRT.DLL + 0x1041 (0x78001041) fe250a2a
         line 
        Build: 2000091821 CrashDate: 2000-09-19 UptimeMinutes: 317  Total: 323 
        OS: Windows 98  4.10 build 67766446
        URL: https://int.ids.net/cims/index2.htm
        Comment: 
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17675746
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=17675746

MSVCRT.DLL + 0x10d9 (0x780010d9) 47beab79
         line 
        Build: 2000091909 CrashDate: 2000-09-20 UptimeMinutes: 51  Total: 153 
        OS: Windows 98  4.10 build 67766222
        URL: www.ibm.com/developer
        Comment: loading default page
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17746610
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=17746610

MSVCRT.DLL + 0x1041 (0x78001041) 7ba98496
         line 
        Build: 2000091909 CrashDate: 2000-09-21 UptimeMinutes: 125  Total: 125 
        OS: Windows 98  4.10 build 67766222
        URL: 
        Comment: Opening up windows to slashdot.org
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17799154
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=17799154

MSVCRT.DLL + 0x1041 (0x78001041) ccf127f9
         line 
        Build: 2000092213 CrashDate: 2000-09-22 UptimeMinutes: 61  Total: 61 
        OS: Windows 98  4.10 build 67766446
        URL: 
        Comment: I had Manage Bookmarks open.  I was dragging a bookmark to a 
folder
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17888518
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=17888518

MSVCRT.DLL + 0x10cc8 (0x78010cc8) 200cbef9
         line 
        Build: 2000092213 CrashDate: 2000-09-25 UptimeMinutes: 55  Total: 141 
        OS: Windows 98  4.10 build 67766222
        URL: http://www.zdnet.com/gamespot
        Comment: 
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17976052
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=17976052

MSVCRT.dll + 0x10cc8 (0x78010cc8) 6647c016
         line 
        Build: 2000092009 CrashDate: 2000-09-22 UptimeMinutes: 257  Total: 257 
        OS: Windows NT  4.0 build 1381
        URL: http://www.cnn.com/2000/TECH/space/09/21/black.hole.ap/
        Comment: Following the link to the above story from http://slashdot.org
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17853254
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=17853254

    MSVCRT.dll + 0x10cc8 (0x78010cc8) da076e21
         line 
        Build: 2000092009 CrashDate: 2000-09-21 UptimeMinutes: 1585  Total: 1594 
        OS: Windows NT  4.0 build 1381
        URL: http://www.ibutton.com/photos.bicycle.html
        Comment: 
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17814789
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=17814789

MSVCRT.DLL + 0x1041 (0x78001041) e0cbad2f
         line 
        Build: 2000092321 CrashDate: 2000-09-25 UptimeMinutes: 13  Total: 251 
        OS: Windows 98  4.10 build 67766222
        URL: 
        Comment: 
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17978294
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=17978294

Incident ID 17978294 
MSVCRT.DLL + 0x1041 (0x78001041) 
nsReplacementPolicy::AddAllRecordsInCache 
[d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsReplacementPolicy.cpp,
line 181] 
nsReplacementPolicy::LoadAllRecordsInAllCacheDatabases
[d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsReplacementPolicy.cpp, line 
673] 
nsReplacementPolicy::DeleteAtleastOneEntry 
[d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsReplacementPolicy.cpp,
line 600] 
nsReplacementPolicy::CheckForTooManyCacheEntries
[d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsReplacementPolicy.cpp, line 
453] 
nsReplacementPolicy::GetCachedNetData 
[d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsReplacementPolicy.cpp, line
560] 
nsCacheManager::GetCachedNetData 
[d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsCacheManager.cpp, line 300] 
nsHTTPChannel::CheckCache 
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPChannel.cpp, line 
971] 
nsHTTPChannel::Open 
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPChannel.cpp, line 
1441] 
nsHTTPChannel::AsyncRead 
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPChannel.cpp, line 
337] 
nsDocumentOpenInfo::Open 
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 201] 
nsURILoader::OpenURIVia 
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 621] 
nsURILoader::OpenURI 
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 507] 
ImageNetContextImpl::GetURL 
[d:\builds\seamonkey\mozilla\gfx\src\nsImageNetContextAsync.cpp, line 822] 
IL_GetImage [d:\builds\seamonkey\mozilla\modules\libimg\src\if.cpp, line 2055] 
ImageRequestImpl::Init [d:\builds\seamonkey\mozilla\gfx\src\nsImageRequest.cpp, 
line 262] 
ImageGroupImpl::GetImage [d:\builds\seamonkey\mozilla\gfx\src\nsImageGroup.cpp, 
line 285] 
nsFrameImageLoader::Init 
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameImageLoader.cpp, line 188] 
nsPresContext::StartLoadImage 
[d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp, line 1007] 
nsHTMLImageLoader::StartLoadImage 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLImageLoader.cpp, line
241] 
nsHTMLImageLoader::GetDesiredSize 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLImageLoader.cpp, line
479] 
nsImageFrame::GetDesiredSize 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsImageFrame.cpp, line 327] 
nsImageFrame::Reflow 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsImageFrame.cpp, line 362] 
nsLineLayout::ReflowFrame 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp, line 922] 
nsInlineFrame::ReflowInlineFrame 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsInlineFrame.cpp, line 604] 
nsInlineFrame::ReflowFrames 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsInlineFrame.cpp, line 413] 
nsInlineFrame::Reflow 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsInlineFrame.cpp, line 329] 
nsLineLayout::ReflowFrame 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp, line 922] 
nsBlockFrame::ReflowInlineFrame 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 4358] 
nsBlockFrame::DoReflowInlineFrames 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 4242] 
nsBlockFrame::DoReflowInlineFramesAuto 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 4176] 
nsBlockFrame::ReflowInlineFrames 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 4122] 
nsBlockFrame::ReflowLine 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3257] 
nsBlockFrame::ReflowDirtyLines 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2946] 
nsBlockFrame::Reflow 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 1747] 
nsContainerFrame::ReflowChild 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 
716] 
nsTableCellFrame::Reflow 
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableCellFrame.cpp, line 
808] 
nsContainerFrame::ReflowChild 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 
716] 
nsTableRowFrame::InitialReflow 
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp, line 
1122] 
nsTableRowFrame::Reflow 
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp, line 
1523] 
nsContainerFrame::ReflowChild 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 
716] 
nsTableRowGroupFrame::ReflowMappedChildren
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp, 
line 425] 
nsTableRowGroupFrame::Reflow 
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp, 
line 1098]

nsContainerFrame::ReflowChild 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 
716] 
nsTableFrame::ResizeReflowPass1 
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 1862] 
nsTableFrame::Reflow 
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 1668] 
nsContainerFrame::ReflowChild 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 
716] 
nsTableOuterFrame::OuterReflowChild 
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 
901] 
nsTableOuterFrame::Reflow 
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 
1441] 
nsBlockReflowContext::DoReflowBlock 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
562] 
nsBlockReflowContext::ReflowBlock 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 
334] 
nsBlockFrame::ReflowBlockFrame 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3874] 
nsBlockFrame::ReflowLine 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3143] 
nsBlockFrame::ReflowDirtyLines 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2946] 
nsBlockFrame::Reflow 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 1747] 
nsContainerFrame::ReflowChild 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 
716] 
nsTableCellFrame::Reflow 
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableCellFrame.cpp, line 
808] 
nsContainerFrame::ReflowChild 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 
716] 
nsTableRowFrame::InitialReflow 
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp, line 
1122] 
nsTableRowFrame::Reflow 
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp, line 
1523] 
nsContainerFrame::ReflowChild 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 
716] 
nsTableRowGroupFrame::ReflowMappedChildren
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp, 
line 425] 
nsTableRowGroupFrame::Reflow 
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp, 
line 1098]

nsContainerFrame::ReflowChild 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 
716]
adding topcrash, crash keywords and [@ 
nsReplacementPolicy::AddAllRecordsInCache] for tracking.  ccing a few people 
from bug 52818.
Keywords: crash, topcrash
this is the second crash I mention in the other bug where it goes off the end of
the cache array because it thinks it's allocated a bigger size but it hasn't.

Here's a patch that stops the crash but probably makes the cache useless since 
nothing after the original entries can be added to the cache.  It will slow us 
down but at least it doesn't crash.  Making the code do the right thing is 
probably better, but stopping this crash reasonably soon would be good too.

Index: mgr/nsReplacementPolicy.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/cache/mgr/nsReplacementPolicy.cpp,v
retrieving revision 1.15
diff -c -r1.15 nsReplacementPolicy.cpp
*** nsReplacementPolicy.cpp	2000/09/14 19:12:03	1.15
--- nsReplacementPolicy.cpp	2000/09/26 06:56:27
***************
*** 497,502 ****
--- 497,505 ----
          if (newCapacity > mMaxEntries)
              newCapacity = mMaxEntries;
  
+ 		if(mNumEntries == newCapacity)
+ 			return NS_ERROR_FAILURE;
+ 
          nsCachedNetData** newRankedEntriesArray; 
          PRUint32 numBytes = sizeof(nsCachedNetData*) * newCapacity;
          newRankedEntriesArray = 

We crash because we are off by one entry. Here's a patch which will stop the 
crash, and still make the cache usable. We should increase the array size by one  
more additional entry. So, when we access mRankedEntries[mNumEntries], we 
are within allocated memory. Could someone apply the patch and test it. I am not 
able to reproduce the crash.

Index: mgr/nsReplacementPolicy.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/cache/mgr/nsReplacementPolicy.cpp,v
retrieving revision 1.15
diff -c -r1.15 nsReplacementPolicy.cpp
*** nsReplacementPolicy.cpp	2000/09/14 19:12:03	1.15
--- nsReplacementPolicy.cpp	2000/09/26 15:30:56
***************
*** 494,501 ****
          PRUint32 newCapacity;
  
          newCapacity = mCapacityRankedEntriesArray + STATS_GROWTH_INCREMENT;
!         if (newCapacity > mMaxEntries)
!             newCapacity = mMaxEntries;
  
          nsCachedNetData** newRankedEntriesArray; 
          PRUint32 numBytes = sizeof(nsCachedNetData*) * newCapacity;
--- 494,501 ----
          PRUint32 newCapacity;
  
          newCapacity = mCapacityRankedEntriesArray + STATS_GROWTH_INCREMENT;
!         if (newCapacity >= mMaxEntries)
!             newCapacity = mMaxEntries + 1;
  
          nsCachedNetData** newRankedEntriesArray; 
          PRUint32 numBytes = sizeof(nsCachedNetData*) * newCapacity;




    
    

    
  
Hey Neeti,

Your patch doesn't fix the crash.  It just crashes the next time around.  The
problem is that mMaxEntries is stuck at 512. So, the first time you increase the
capacity to 513 it works but then the next time you increase the capicity to 513
and when it tries accessing the 513th element it crashes.  So, we either have to
make mMaxEntries growable in which case this array could grow forever, we need
to bail out like my original patch, or we need to find what's causing this
problem.  I have not tried applying the patch from 42606 yet.  I don't know if
that will make a difference.  I will try that next.


    
    

    
  
I have a theory about what's causing this.

The disk cache has items already in it when starting up.  Let's say the initial
size is 20.

The replacement policy keeps around 512 cache entries before it decided it has
to rank them in order to find one to delete.

When the replacement policy has to delete one, it loads all of the records from
the disk cache because it needs to include them in the ranking since one of
those might get deleted. As it loads each one it sees if we already have a cache
entry and if it doesn't it tries to create a new one and this is where it tries
to allocate space for a larger rankingArray.

So, in a best case scenario, the 20 items in the disk cache before starting are
already known to the replacement policy in which case 512 is still big enough.
But in the worst case, all 20 url's have not been visited in this session in
which case the array needs to be able to hold 532 entries.  So, it seems that
the max size we need to allow is maxSize + number of original items in the
cache.  This is just a theory. There are a few solutions I can think of.  One is
to know what the original size of all of the caches are and make this + 512 be
the maximum size the rankingArray can be.  Another is to let rankingArray be
unbounded since I think that might be ok, the other is to not use the items in
the disk cache when determining which one to create.


    
    

    
  
I think I know a reason why I'm seeing strange behavior with the cache.  I don't
always hit nsNetDiskCache::~nsNetDiskCache() on exit. This means that we never
save the correct current disk cache size.  My guess is that my cache is totally
messed up regarding the number of entries in it and the number of entries it
thinks it has in it.  I think this might be a problem because we have failure
cases sprinkled throughout replacement policy based on the cache size being less
than the numbers of entries the replacement policy knows about.  I've found
cases where I get failure becaue it thinks my cache is reporting too few
entries.  Sometimes I hit the destructor and it saves what it thinks are the
correct number of entries, but my guess is that over time the difference between
the two numbers is getting pretty high.


    
    

    
  
Yes, I am noticing the same behaviour too i.e. we don't always hit 
nsNetDiskCache::~nsNetDiskCache() on exit. 

    
  
Keywords: rtm

    
    

    
  
*** Bug 54724 has been marked as a duplicate of this bug. ***

    
    

    
  
I'd assume we can't count on hitting it either - i.e. when we crash, machine
gets turned off or loses power, we hang and get killed, etc.


    
    

    
  
How about adding some defensive code in 
nsReplacementPolicy::AddAllRecordsInCache() to prevent the hard crash.

Index: nsReplacementPolicy.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/cache/mgr/nsReplacementPolicy.cpp,v
retrieving revision 1.15
diff -c -r1.15 nsReplacementPolicy.cpp
*** nsReplacementPolicy.cpp     2000/09/14 19:12:03     1.15
--- nsReplacementPolicy.cpp     2000/10/04 23:07:37
***************
*** 162,168 ****
--- 162,172 ----
      nsCOMPtr<nsISimpleEnumerator> iterator;
      nsCOMPtr<nsISupports> iSupports;
      nsCOMPtr<nsINetDataCacheRecord> record;
+     NS_ASSERTION(aCache, "null aCache\n");
+     if (!aCache) return NS_ERROR_FAILURE;
      rv = aCache->NewCacheEntryIterator(getter_AddRefs(iterator));
+     NS_ASSERTION(iterator, "null iterator\n");
+     if (!iterator) return NS_ERROR_FAILURE;
      if (!NS_SUCCEEDED(rv)) return rv;

      while (1) {

    
    

    
  
I think that's reasonable to do in general, but based on where I crashed, that's
not causing the crash.


    
    

    
  
Is there any action occuring on this one?  It is a top crash.  I just hit it
again looking at http://soros.ath.cx.

    
    

    
  
I have a fix in hand. Will be attaching it shortly for review.

    
    

    
  
*** Bug 53498 has been marked as a duplicate of this bug. ***

    
    

    
  
The cache gets corrupted, if we crash before shutdown, or if there is a leak. 
See bug 55405.
Depends on: 55405

    
    

    
  


  

    
    

    
  
I have attached a patch for this bug.  This patch should be applied along with 
the patch to bug 55405

1. I have made the number of entries in the memory (replacement policy) to be 
one  more than the number, because the code in AssociateCacheEntryWithRecord(..) 
requires that there be room for atleast one more entry in the array.

2. In CheckForTooManyEntries(..), we delete entries, if the undeleted entries >=  
(mMaxEntries-1)

3.In GetCachedNetData(..) for the replacement policy, we first check for too 
many entries, and then create the record, rather than creating the record 
before.

4. In AssociateCacheEntryWithRecord(..), there is a check to return a failure, 
if number of entries >= maxEntries to prevent an ABR. We should never hit this 
condition with the above fixes.

5. When we initialize the cache, if the number of records is greater than the 
maximum, we do a DBRecovery(..) 

    
    

    
  
I am rtm plussing this. Patch is being reviewed.
Whiteboard: [rtm+]

    
    

    
  
*** Bug 55411 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 55548 has been marked as a duplicate of this bug. ***

    
    

    
  
PDT really really wants this fixed, but no reviewers are listed. Please check in
ASAP after getting peer review and super review.

Whiteboard: [rtm+] → [rtm need info]

    
    

    
  
Rick,

Could you review this patch? It's been already by r=dp.

Thanks,
Neeti
No longer depends on: 55405

    
    

    
  
The 10/06/00 patch looks okay to me but I'm hoping we can get rpotts to give it
a thumbs up. He knows this part of the cache much better than I....


    
    

    
  
hey neeti,

I think that this looks ok...  Have you tried running under purify and forced 
mNumEntries == mMaxEntries?

(r=rpotts)


    
    

    
  
I haven't tried running it under purify, but I have forced mNumEntries == 
mMaxEntries in the debugger.

Neeti



    
    

    
  
rtm++

Whiteboard: [rtm need info] → [rtm++]

    
    

    
  
I tried out these patches and it definitely stops the crash I was seeing.
However, unless I'm not seeing something correctly, it still makes the cache
unuseable after you get into this state.

Once I hit this state where this becomes true:

    if (mNumEntries >= mMaxEntries)
        return NS_ERROR_FAILURE;

then another entry never gets added to my cache.

But it stops the crash so we should get this in.


    
    

    
  
We should hit the condition, only if the cache is corrupt.
 if (mNumEntries >= mMaxEntries)
        return NS_ERROR_FAILURE;

The fix to bug 55405, detects corruption and clears the cache if corrupted on 
startup. This should fix some of the corruption cases.


    
    

    
  
I applied the patch for 55405 and I still found myself in this state.


    
    

    
  
Scott,

Can you reproduce this with a new cache directory. When the the patch to bug 
55405 is checked in, we should updated the cache version, so we start with a 
fresh cache . The patch to bug 55405 cannot detect if the cache is corrupted, if 
the cache was already corrupted before the patch was applied.

    
    

    
  
probably not. I've never been able to reproduce any of these problems with a new
cache directory, just the corrupted one I've been using to work on these bugs.
If we update the cache version then I'm sure everything will work out and I
agree that your fix works great.


    
    

    
  
Phil,

Can I check in the fix first, without running purify?

Thanks,
Neeti

    
    

    
  
yes, see my reply in email


    
    

    
  
Checked in a fix on branch and trunk
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED

    
  
Summary: crash in [@ nsReplacementPolicy::AddAllRecordsInCache] → crash in [@ nsReplacementPolicy::AddAllRecordsInCache - MSVCRT.DLL]

    
    

    
  
not seeing this in talkback reports for 10/24 - crash appears to have been fixed

verif.
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsReplacementPolicy::AddAllRecordsInCache - MSVCRT.DLL]

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: