Crash unloading -turbo mozilla from tray icon

VERIFIED FIXED in mozilla0.9.5

Status

()

Core
Networking: Cache
--
critical
VERIFIED FIXED
17 years ago
6 years ago

People

(Reporter: Martin Poirier, Assigned: Conrad Carlen (not reading bugmail))

Tracking

({crash, topcrash})

Trunk
mozilla0.9.5
x86
Windows 98
crash, topcrash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: want for 0.9.4 Trunk [@ nsDiskCacheBucket::CountRecords][@ nsDiskCacheMap::GetFileForDiskCacheRecord][@ nsDiskCacheBlockFile::DeallocateBlocks][@ nsDiskCacheBlockFile::AllocateBlocks][@ nsDiskCacheDevice::OnDataSizeChange])

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
In today (2001083003) and yesterday's builds mozilla crashes when closind it by
choosing exit from the tray icon.

Reproducible : Always

Steps : 

1.Open mozilla with -turbo switch on

2. Close all mozilla windows (you can browse a little before closing)

3. Choose exit from the tray icon to unload mozilla

4. Mozilla unloads, Crash in nkcache.dll

5. Talkback reports : TB34727011Y, TB34726460Y, TB34726233Z

Comment 1

17 years ago
Confirming based on talkback id.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash

Updated

17 years ago
Summary: Crash unloading mozilla → Crash unloading -turbo mozilla from tray icon [@nkcache.dll]
All three talkback reports are identical:

nsDiskCacheBlockFile::DeallocateBlocks
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsDiskCacheBlockFile.cpp, line 231]
nsDiskCacheMap::DeleteStorage
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsDiskCacheMap.cpp, line 772]
nsDiskCacheMap::WriteDiskCacheEntry
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsDiskCacheMap.cpp, line 662]
nsDiskCacheDevice::DeactivateEntry
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsDiskCacheDevice.cpp, line 435]
nsCacheService::DeactivateEntry
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheService.cpp, line 1279]
nsCacheService::DeactivateAndClearEntry
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheService.cpp, line 1441]
PL_DHashTableEnumerate [d:\builds\seamonkey\mozilla\xpcom\ds\pldhash.c, line 459]
nsCacheService::ClearActiveEntries
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheService.cpp, line 1423]
nsCacheService::Shutdown
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheService.cpp, line 463]
nsCacheProfilePrefObserver::Observe
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheService.cpp, line 220]
nsObserverService::Notify
[d:\builds\seamonkey\mozilla\xpcom\ds\nsObserverService.cpp, line 238]
NS_ShutdownXPCOM [d:\builds\seamonkey\mozilla\xpcom\build\nsXPComInit.cpp, line 465]
main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1682] 

Updated

17 years ago
Keywords: mozilla0.9.4
Summary: Crash unloading -turbo mozilla from tray icon [@nkcache.dll] → Crash unloading -turbo mozilla from tray icon [nsDiskCacheBlockFile::DeallocateBlocks
I'm going to give this to ccarlen based on the checkins that went in between
8-28 and 8-29 (I suspect it's fallout from bug 86021), since the comments in
this bug mention -turbo, and since all the talkback reports of this crash are on
Windows.

Three new topcrash signatures appeared in the builds on 8-29:
nsDiskCacheBucket::CountRecords
nsDiskCacheMap::GetFileForDiskCacheRecord
nsDiskCacheBlockFile::DeallocateBlocks

They were the #1, #2, and #3 topcrashes for the builds of 8-29 and 8-30.  I
think it would be very good to get this sorted out for 0.9.4.

Since I could certainly be wrong about which checkin caused this crash, here's
the checkins link for the relevant time period:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2001-08-28+08%3A00&maxdate=2001-08-29+12%3A00&cvsroot=%2Fcvsroot
Assignee: gordon → ccarlen
Keywords: topcrash
Summary: Crash unloading -turbo mozilla from tray icon [nsDiskCacheBlockFile::DeallocateBlocks → Crash unloading -turbo mozilla from tray icon [@ nsDiskCacheBlockFile::DeallocateBlocks][@ nsDiskCacheBucket::CountRecords][@ nsDiskCacheMap::GetFileForDiskCacheRecord]
Whiteboard: want for 0.9.4
User comments for nsDiskCacheMap::GetFileForDiskCacheRecord:

     (34746286) Comments: closing Mozilla and Outlook Express at essentially the
                same time
     (34736337) URL: usopen.org
     (34718347) URL: equitymaster.com
     (34718347) Comments: while closing the browser

User commenst for nsDiskCacheBucket::CountRecords:

     (34749638) URL: http://jon.livejournal.com/friends/
     (34749638) Comments: Doing a Shift-Reload
     (34746067) Comments: closing out of netscape
User comments for nsDiskCacheBlockFile::DeallocateBlocks:

     (34728183) Comments: BUG 97620
     (34690038) Comments: crash closing mozilla


FWIW, I put these all on the same bug because I think it's too much of a
coincidence for three cache-related crashes to start on the same day with the
limited number of checkins that were going in during the closure.  However, I
admit they could be different, since, looking at the stacks, only one of the
three happens on cache service shutdown.  Maybe I'm wrong that it's related to
ccarlen's checkin, but there's really not much else I can think of.

Sample stacks for the other two crashes (that aren't above):

         nsDiskCacheMap::GetFileForDiskCacheRecord     
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsDiskCacheMap.cpp  line 793]
         nsDiskCacheMap::DeleteStorage 
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsDiskCacheMap.cpp  line 761]
         nsDiskCacheMap::DeleteStorage 
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsDiskCacheMap.cpp  line 743]
         nsDiskCacheDevice::DeactivateEntry    
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsDiskCacheDevice.cpp  line 432]
         nsCacheService::DeactivateEntry       
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheService.cpp  line 1279]
         nsCacheService::CloseDescriptor       
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheService.cpp  line 1240]
         nsCacheEntryDescriptor::Close 
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheEntryDescriptor.cpp  line 338]
         nsCacheEntryDescriptor::~nsCacheEntryDescriptor       
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheEntryDescriptor.cpp  line 49]
         nsCacheEntryDescriptor::`scalar deleting destructor'
         nsCacheEntryDescriptor::Release       
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheEntryDescriptor.cpp  line 32]
         nsCOMPtr_base::assign_with_AddRef     
[d:\builds\seamonkey\mozilla\xpcom\base\nsCOMPtr.cpp  line 59]
         nsHttpChannel::OnStopRequest  
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp  line 2204]
         nsHttpChannel::OnStopRequest  
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp  line 2204]
         nsOnStopRequestEvent::HandleEvent     
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp  line 162]
         PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c 
line 591]


And:

         nsDiskCacheBucket::CountRecords       
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsDiskCacheMap.cpp  line 65]
         GetCacheEntryBinding  
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsDiskCacheBinding.cpp  line 102]
         nsDiskCacheMap::DoomRecord    
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsDiskCacheMap.cpp  line 736]
         nsDiskCacheDevice::DoomEntry  
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsDiskCacheDevice.cpp  line 518]
         nsCacheService::DoomEntry_Locked      
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheService.cpp  line 993]
         nsCacheEntryDescriptor::Doom  
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheEntryDescriptor.cpp  line 308]
         nsHttpChannel::CloseCacheEntry
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp  line 886]
         nsHttpChannel::OnStopRequest  
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp  line 2204]
         nsOnStopRequestEvent::HandleEvent     
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp  line 162]
         PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c 
line 591]
I went through 5 of the nsDiskCacheMap::GetFileForDiskCacheRecord talkback
reports on http://climate.mcom.com/reports/incidenttemplate.cfm?bbid=NNNNNNNNN ,
and three of them were using -turbo on the command line and two were not.  (Is
there a way for turbo to be invoked without the command line option?)

Anybody else have any suggestions for what might have caused this?
(Assignee)

Comment 6

17 years ago
  This problem (whatever it is) was exposed (not caused) by bug 86021. That code
causes the cache's profile change observer to be used. This cache's profile
change observer has been around for a while.
  What it may have to with is this: In -turbo mode, closing the last window
causes the cache to partially shut down in response to the profile being shut
down. When the user than exits from the tray icon, the cache will fully shut
down in response to the "xpcom-shutdown" notification. Looking at the code, that
shouldn't be a problem, though I could be missing something. I have not been
able to reproduce this. Still looking.

Comment 7

17 years ago
adding "trunk" to summary for tracking
Summary: Crash unloading -turbo mozilla from tray icon [@ nsDiskCacheBlockFile::DeallocateBlocks][@ nsDiskCacheBucket::CountRecords][@ nsDiskCacheMap::GetFileForDiskCacheRecord] → Crash unloading -turbo mozilla from tray icon trunk [@ nsDiskCacheBlockFile::DeallocateBlocks ][@ nsDiskCacheBucket::CountRecords][@ nsDiskCacheMap::GetFileForDiskCacheRecord ]

Updated

17 years ago
Summary: Crash unloading -turbo mozilla from tray icon trunk [@ nsDiskCacheBlockFile::DeallocateBlocks ][@ nsDiskCacheBucket::CountRecords][@ nsDiskCacheMap::GetFileForDiskCacheRecord ] → Crash unloading -turbo mozilla from tray icon - Trunk [@ nsDiskCacheBucket::CountRecords][@ nsDiskCacheMap::GetFileForDiskCacheRecord ][@ nsDiskCacheBlockFile::DeallocateBlocks ]
Any status on this bug?  Should it go to someone who works on the cache?
(Assignee)

Comment 9

17 years ago
I haven't been able to reproduce this and have been working on another bug. I'll
be back on this tommorrow.

Gordon, can you take a look at the situation of:
the disk cache device being shut down in response to a profile shutdown
followed immediately by the cache service shutting down in response to
xpcom-shutdown?

It's a but easier to read on the Talkback report itself. Here's one:
http://climate/reports/singleincidentinfo.cfm?dynamicBBID=TB34727011Y

The thing which seems odd to me is that, at this point, if the disk cache device
is shut down, why is nsDiskCacheDevice::DeactivateEntry on the stack?
 

Comment 10

17 years ago
shouldn't this be targetted for 0.9.4?

Comment 11

17 years ago
Conrad, what is the sequence of events for turbo mode?  Profile shutdown
followed by xpcom shutdown?

I'll look at this more this afternoon.  Setting target milestone to 0.9.4,
presuming turbo mode will be on by default.  ...but on what platforms?
Target Milestone: --- → mozilla0.9.4
(Assignee)

Comment 12

17 years ago
Right - profile shutdown, followed by xpcom shutdown.
It's Windows only.

Comment 13

17 years ago
I was able to reproduce this on the first try and can do it consistantly.

Windows 98 build 2001-09-07-09-trunk 

1. I installed build (with the Quicklaunch option checked) 
2. Surfed a couple of sights 
3. Closed the window (using the x in the upper right corner)
4. Right clicked the try icon and selected exit
5. Crash

Talkback Incident ID 35093143 (I will try on other Windows OS's)
(Assignee)

Comment 14

17 years ago
Terri, looking at the stack trace, that was a different crash and was very
reproducible. That was a regression from fix to bug 97514 which was in for a
short time yesterday and backed out. See comments on that bug about how it
crashed turbo.
(Reporter)

Comment 15

17 years ago
Update : I'm the reporter of this bug and here is a little update.

I still get the crash on exit from the tray icon (still always reproducible).
However, the problem seems to have changed a little. While I had a crash in
nkcache.dll, mozilla now crashes in appshell.dll. Here is the win98 error report.


MOZILLA a causé une défaillance de page dans
 le module APPSHELL.DLL à 017f:600b6e7e.
Registres :
EAX=00000000 CS=017f EIP=600b6e7e EFLGS=00010206
EBX=00000000 SS=0187 ESP=0068f9a0 EBP=0068f9bc
ECX=02b5de70 DS=0187 ESI=00875340 FS=12bf
EDX=00000002 ES=0187 EDI=00000000 GS=0000
Octets à CS : EIP :
8b 03 8d 4d 0c 51 53 89 7d 0c ff 50 0c 39 7d 0c 
État de la pile :
60f0cc2d 80000000 00000000 0068fa78 004058b2 007b0ed0 00000000 0068fa78 00404a2b
02b5de70 00000000 0068fa9c 00000000 0068fae6 03cf000a 276c0182 


This happened to me with the latest nightlies, while the crash was in nkcache
before. Here are some new Talkback reports with the appshell.dll crash

TB35104261Z
TB35105423M
TB35117132X
TB35118252H
TB35119353x
TB35120618E
TB35127357X
Created attachment 48739 [details]
TB35104261
(Assignee)

Comment 17

17 years ago
Martin, Stephen - read my comment from 2001-09-08 06:15. 
(Assignee)

Comment 18

17 years ago
Again, (read the comments) the crash in appshell is not this bug, was a
regression from bug 97514, and has been fixed. Let's keep this bug where it
started - crashes in the cache when unloading -turbo from tray icon.

Comment 19

17 years ago
For sept 7, 8 and 9, this is the number 3 topcrash bug with 22 crashes. all
on win32. Could someone please please please figure out how to reproduce it.
endico was only counting one of the stack signatures.  If you combine all of
them, it's #2 with 50 crashes, and I think #1 was already fixed (smoketest
blocker from Friday).  #3 is bug 99052 with 27, and I don't think there's a
clear #4.  (See my tables at
http://www.people.fas.harvard.edu/~dbaron/mozilla/#talkback .)

Comment 21

17 years ago
I think I can reproduce this. Do the following: Start mozilla using "mozilla
-turbo". Double click the tray icon to open the browser. Enter the URL of a page
that needs a while to load and has many images, e.g. "www.spiegel.de". While the
page is still loading, quickly click the upper right corner icon to close the
browser. It crashes for me all the time with a stack of nkcache, necko, xpcom.

Comment 22

17 years ago
I can reproduce the crash using Kai's steps with a recent cvs build on win2k.

Comment 23

17 years ago
Created attachment 48972 [details] [diff] [review]
v1.0 patch

Comment 24

17 years ago
gordon and i came up with a fix for this bug... ccarlen: seems to work for us,
can you give it a try?

briefly, on a profile shutdown we enumerate the active cache entries and doom
them.  we then clear the doom list, which detaches any open descriptors from the
cache entries.  this solves the problem without any negative side-effects.
(Assignee)

Comment 25

17 years ago
Before the patch, using Kai's test, it crashed 3 of 3 times.
After applying the patch, it succeeded 3 of 3 times :-)
(Assignee)

Comment 26

17 years ago
Gagan, can you r=? Rick, can you sr=?

Comment 27

17 years ago
Comment on attachment 48972 [details] [diff] [review]
v1.0 patch

in addition to the assertions I'd suggest you also check to see if the entry or the array are valid. So--

if (array && entry) {
   array->AppendElement(entry);
   entry->Mark...
}
This will prevent any random crashes becuz of invalid entry or array.

Comment 28

17 years ago
Comment on attachment 48972 [details] [diff] [review]
v1.0 patch

since my stuff is mostly nitpicky, I'll go ahead and add the r=. whoever checks this in can decide to take my review changes.
Attachment #48972 - Flags: review+
Comment on attachment 48972 [details] [diff] [review]
v1.0 patch

sr=ben@netscape.com
Attachment #48972 - Flags: superreview+

Comment 30

17 years ago
Comment on attachment 48972 [details] [diff] [review]
v1.0 patch

a=asa for checkin to 0.9.4 branch.
Attachment #48972 - Flags: approval+

Comment 31

17 years ago
r=rpotts@netscape.com

My only comments relate to the code snippet below:

+    nsCacheEntry * entry;
+    for (PRInt32 i=0; i<array.Count(); ++i)
+        DoomEntry_Locked((nsCacheEntry *) array[i]);

it looks like 'entry' is an unused variable.  Could we hoist the array.Count()
out of the for loop... So it is not continually (and needlessly) re-evaluated?

-- rick

Comment 32

17 years ago
I'll incorporate Rick's feedback and submit a new patch.
Created attachment 49112 [details] [diff] [review]
patch with rick's comments
Comment on attachment 49112 [details] [diff] [review]
patch with rick's comments

All good.

/be
Attachment #49112 - Flags: superreview+
Attachment #49112 - Flags: review+
Attachment #49112 - Flags: approval+
Checked into 0.9.4 branch.  I leave it up to gordon to get it into the tip.

Updated

17 years ago
Blocks: 99488

Comment 36

17 years ago
Looking at Talkback data, there seem to be a few more "nsDiskCache*" stack
signatures showing up in topcrash reports.  dbaron already mentioned the top 3:

nsDiskCacheBucket::CountRecords
nsDiskCacheMap::GetFileForDiskCacheRecord
nsDiskCacheBlockFile::DeallocateBlocks

And further down the topcrash list there are these:

nsDiskCacheBlockFile::AllocateBlocks
nsDiskCacheDevice::OnDataSizeChange

Just wanted to mention them here in case they show up later on.  
Summary: Crash unloading -turbo mozilla from tray icon - Trunk [@ nsDiskCacheBucket::CountRecords][@ nsDiskCacheMap::GetFileForDiskCacheRecord ][@ nsDiskCacheBlockFile::DeallocateBlocks ] → Crash unloading -turbo mozilla from tray icon - Trunk [@ nsDiskCacheBucket::CountRecords][@ nsDiskCacheMap::GetFileForDiskCacheRecord][@ nsDiskCacheBlockFile::DeallocateBlocks][@ nsDiskCacheBlockFile::AllocateBlocks][@ nsDiskCacheDevice::OnDataSizeChange]

Comment 37

17 years ago
0.9.4 is out the door.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Any chance this could get landed on the trunk soon?  It's still among the top
trunk topcrashes.

Comment 39

17 years ago
Fix checked into trunk.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 40

16 years ago
*** Bug 100279 has been marked as a duplicate of this bug. ***

Comment 41

16 years ago
verified:  win98 build 2001111303
Status: RESOLVED → VERIFIED

Comment 42

15 years ago
shortening summary per justdave's orders, summaries will have limit in near future
Summary: Crash unloading -turbo mozilla from tray icon - Trunk [@ nsDiskCacheBucket::CountRecords][@ nsDiskCacheMap::GetFileForDiskCacheRecord][@ nsDiskCacheBlockFile::DeallocateBlocks][@ nsDiskCacheBlockFile::AllocateBlocks][@ nsDiskCacheDevice::OnDataSizeChange] → Crash unloading -turbo mozilla from tray icon
Whiteboard: want for 0.9.4 → want for 0.9.4 Trunk [@ nsDiskCacheBucket::CountRecords][@ nsDiskCacheMap::GetFileForDiskCacheRecord][@ nsDiskCacheBlockFile::DeallocateBlocks][@ nsDiskCacheBlockFile::AllocateBlocks][@ nsDiskCacheDevice::OnDataSizeChange]
Blocks: 75599
No longer blocks: 99488
You need to log in before you can comment on or make changes to this bug.