Closed Bug 142310 Opened 22 years ago Closed 22 years ago

Crash if quitting while downloading; trunk [@ nsHashtable::Exists]


(Core :: DOM: Navigation, defect, P1)






(Reporter: nahor.j+bugmoz, Assigned: alecf)



(4 keywords, Whiteboard: [adt2 RTM] [vrfy'd on linux/win2k trunk])

Crash Data


(2 files, 2 obsolete files)

Reproducible: always

1. Start to download a file
2. Select "File | Exit"

Actual result: crash

Expedted result: Well, crashing does what I want (mozilla is dead) but I'm
expecting something more... gracefull :)
Build ID ?
Do you have a talkback ID from that crash ?
I even have several. 

The first ID is for build "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.0.0+) Gecko/20020504"
The four others are from a slightly older build (couple days ago or so)
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0+) Gecko/20020506

If it's of any help, here is the talkback from today's build:
Keywords: crash
has anyone experienced this using branch bits? i haven't (using
2002.05.07.08-1.0.0 comm on win2k).

and, just tried to repro this using 2002.05.07.08-trunk bits (win2k, comm), and
wasn't able to.

Nahor, is this still happening for you with *today's* build?

Incident ID 5943950
Stack Signature nsHashtable::Exists c8fb8acc
Product ID MozillaTrunk
Build ID 2002050408
Trigger Time 2002-05-04 19:58:05
Platform Win32
Operating System Windows NT 5.0 build 2195
Module xpcom.dll
Trigger Reason Access violation
Source File Name nsHashtable.cpp
Trigger Line No. 260

nsHashtable::Exists [nsHashtable.cpp, line 260]
nsDownloadManager::DownloadEnded [nsDownloadManager.cpp, line 165]
nsDownload::OnStateChange [nsDownloadManager.cpp, line 1070]
nsDownloadProxy::OnStateChange [./../download-manager/src\nsDownloadProxy.h,
line 157]
nsExternalAppHandler::OnStopRequest [nsExternalHelperAppService.cpp, line 1370]
nsDocumentOpenInfo::OnStopRequest [nsURILoader.cpp, line 255]
nsStreamListenerTee::OnStopRequest [nsStreamListenerTee.cpp, line 25]
nsHttpChannel::OnStopRequest [nsHttpChannel.cpp, line 2909]
nsOnStopRequestEvent::HandleEvent [nsRequestObserverProxy.cpp, line 213]
PL_HandleEvent [plevent.c, line 597]
PL_ProcessPendingEvents [plevent.c, line 530]
nsEventQueueImpl::ProcessPendingEvents [nsEventQueue.cpp, line 392]
Ever confirmed: true
Yes, it still happens (build 2002050708), talkback id: TB6038752Z
anyone else able to repro this crasher?

Nahor, another question: is QuickLaunch on for you? (fwiw, i don't have QL on.)
Keywords: qawanted
no, I don't have quicklaunch
I did a fresh install on a completely reinstalled system (win2k SP2 with all
patchs) (different machine the usual).
1. I downloaded current nightly build (2002050708) and installed it. At the end
Mozilla starts with a completely new profile (since no previous mozilla nor
2. went to
3. clicked on the "etc." link for the nightly build
4. clicked on the source tar.gz (any big file will do).
5. the download manager showed up.
6. clicked "File | Exit" in the browser window .
7. crashed (talkback ID TB6042512G)

I tried again but this time I closed the Download manager window before
quitting, and it still crashed (TB6042678E).
*** Bug 142922 has been marked as a duplicate of this bug. ***
adding keywords etc from the dupe
Keywords: testcase, topcrash+
Summary: Crash if quitting while downloading → Crash if quitting while downloading [@ nsHashtable::Exists]
Changed to all from bug 142922
OS: Windows 2000 → All
Blake, any comments?
Keywords: nsbeta1
nsbeta1+/adt1-rtm per Nav triage team
Keywords: nsbeta1nsbeta1+
Priority: -- → P1
Whiteboard: [ADT1 RTM]
Target Milestone: --- → mozilla1.0
aha, i was finally able to do repro this. it took a fresh profile, too, at least
for me.

tested using 2002.05.07 *trunk* commercial bits on win2k and linux rh7.2.

1. create a new profile (i've multiple ones, so made one via the profile mgr).
2. launch profile.
3. like Nahor in comment 8, i went to and clicked on a large file
4. helper app dlg appeared, i chose "save this file to disk" and clicked OK.
5. chose location in resulting file picker dlg, clicked Save.
6. after dl mgr window appears, then quickly go to File > Exit in browser window.

results: crash. talkback came up, but the internal server doesn't seem to be
behaving at the moment (cannot do my usual email search). i believe a report was

i wonder if what needed here is a profile that has been created with a recent
build? the profiles which didn't crash for me had been created a week or more ago...

side note: i couldn't repro this on mac 10.1.4 --but one thing to note here is
that the Download Mgr doesn't appear automatically (expected). i opened up the
dl mgr window before step (3), but no crash. perhaps related to the dl mgr
automatically opening...? (that was bug 137440, fixed 4/28, trunk only.)

let me check this out with an older build.
Keywords: qawanted
i cannot repro this using a profile i had created and launched with
2002.04.27.08-trunk bits on win2k.

could this have been caused by the fix for bug 137440? has anyone been able to
repro with a build from *before* 4/28?
Depends on: 137440
Keywords: regression
My profle isn't new. It's an imported profile from Netscape. The profile goes
back at least to April 16, more likely April 8 if the file dates are of any
interesting... do you recall with what build you did the import, ie, was it with
a recent build or one from 16 or 8 april? just wondering...

side note: i couldn't repro this using today's branch (2002.05.08.08-1.0.0 comm)
build, again using a profile created with that build.
From your question I guess you didn't understand. My _Mozilla_ profile has been
created on April 16 or 8 from a Netscape profile (which is more than 3 years
old, likely 6).
What I don't remember is if I imported it with RC1 then reused it when I
returned to a Trunk build or if I trashed my old Mozilla profile after RC1 and
reimported it from Netscape when I went back to Trunk.

side note: I'm going to try today's build then.
Still crashing with my current profile (build 2002050807, Talkback: TB6085102Z)
I also tried with a fresh import of my netscape profile (crash TB6085224G) and
with a completely new profile (crash TB6085433Y)
So trunk isn't fixed. I'm going to try with last-1.0.0 now.
Well, it's working with the branch but it's not the download manager that is
used but the progress dialog and this was working before. 
How do you make the download manager the default? I have read about
"browser.downloadmanager.behavior" in prefs.js but it doesn't seems to work
(tried 0, 1 and 2). Is it trunk specific?
This is #6 on todays trunk topcrash report with 122 crashes reported over the
last 10 days.  Here is todays info from the top 40:

 	Source File : nsHashtable.cpp line : 260

     Count   Offset    Real Signature
[ 83   nsHashtable::Exists c8fb8acc - nsHashtable::Exists ]
     Crash date range: 2002-04-29 to 2002-05-08
     Min/Max Seconds since last crash: 23 - 332295
     Min/Max Runtime: 23 - 754901
     Keyword List : download(12), load(12), crash(6),  
     Count   Platform List 
     50   Windows NT 5.0 build 2195
     26   Windows NT 5.1 build 2600
     4   Windows 98 4.10 build 67766446
     2   Windows NT 4.0 build 1381
     1   Windows 98 4.90 build 73010104
     Count   Build Id List 
     11   2002042908
     9   2002050708
     9   2002050108
     8   2002050408
     7   2002050508
     6   2002050807
     6   2002050208
     4   2002050604
     4   2002050308
     4   2002043010
     3   2002050608
     3   2002043003
     2   2002050705
     2   2002050104
     2   2002043008
     1   2002050304
     1   2002050204
     1   2002042903
     No of Unique Users        66
 Stack trace(Frame) 

[nsHashtable.cpp  line 260] 
[nsDownloadManager.cpp  line 166] 
[nsDownloadManager.cpp  line 1086] 
[./../download-manager/src\nsDownloadProxy.h  line 157] 
[nsExternalHelperAppService.cpp  line 1369] 
[nsURILoader.cpp  line 255] 
[nsStreamListenerTee.cpp  line 25] 
[nsHttpChannel.cpp  line 2909] 
[nsRequestObserverProxy.cpp  line 213] 
[plevent.c  line 597] 
[plevent.c  line 530] 
[nsEventQueue.cpp  line 392]  
     (6076483)	Comments: downloading openoffice 1.0.0
     (6058927)	Comments: I closed Mozilla by Ctrl+Q
     (6058847)	Comments: I closed Mozilla by Ctrl+Q
     (6058314)	Comments: trying to erase entries in download manager
     (6055255)	URL:
     (6055255)	Comments: I closed the browser  thanks for ruining my 100 meg download
     (6054872)	URL:
     (6054872)	Comments: Closing the browser
     (6038940)	URL:
     (6038940)	Comments: Was opening in a new
tab  closed the page  browser crashed.
     (6034882)	URL:
     (6034882)	Comments: downloading latest nightly manager opened  and
moz. froze up like a deer in headlights.
     (6014170)	URL:
     (6014170)	Comments: Crash on exit via quicklaunch icon. Java Plug-In was running.
     (5995556)	URL:
     (5986245)	URL:
     (5986245)	Comments: i wanted to download a trial of copernic. this site (mentioned)
appeared  the download manager opened but it didn't respond. when i tried to use
it/to activate the download it didn't react. when i closed the window if the
download manager it crashed
     (5985185)	Comments: i was surfing around the sites of (i don't know anymore the adresses of the sites i visited
before ;-( )when i wanted to download a software the downloadmanager didn't
react...when i closed it and mozilla --> the
     (5985185)	Comments:  crashedby the way: the download manager's great!but you should
improve  how it shows how many time's left for the download
     (5956971)	Comments: closed the quick launch in the tray
     (5922980)	URL:
     (5920332)	Comments: I closed all windows  then the download manager while it was
downloading a file :(
     (5919382)	Comments: Closing netscape after downloading soemthing
     (5904296)	URL:
     (5863856)	URL:
     (5863856)	Comments: closing after a download had started in the download manager  but
i closed that window first
     (5844246)	URL:
     (5844246)	Comments: crash on exit
     (5806497)	Comments: closing latest window while hidden download manager was active
(getting some file from net).
     (5782302)	Comments: I shut down mozilla. Download manager was still running. I closed
the d/l manager and it crashed. Apps running: MSN mesg  Pocomail  tomcat on WinXP
     (5770645)	Comments: Quitting a download of a milestone build.  Had downloaded
Moz1.0.0+ but mail hangs. (WinXPH  on starting mail  processor time goes to 100%
and stays there for 30+sec on P3 1GHz 513M)  Started download  realized logged
in as user & need to go to root so
     (5770645)	Comments:  cancelled it.
[ 18   nsHashtable::Exists 6eace8d9 - nsHashtable::Exists ]
     8   Windows NT 5.0 build 2195
     7   Windows NT 5.1 build 2600
     2   Windows NT 4.0 build 1381
     1   Windows 98 4.10 build 67766222
     3   2002050208
     2   2002050708
     2   2002050608
     2   2002050508
     2   2002050408
     2   2002050108
     2   2002042908
     1   2002050308
     1   2002050104
     1   2002043008
     (6046928)	URL:
     (6046928)	Comments: Same crash. at nsHashtable::Exists
     (6046679)	URL:
     (6046679)	Comments: Copied link into browesr  selected "Save to disk"  closed all
browser windows during download (including download mgr.) -> Crash.
     (6011509)	Comments: I was shutting down Mozilla RC1 and it just crashed on me.
     (6011420)	URL:
     (6011420)	Comments: Shutting down browser. Mail client was also killed at the same
time and the aget apeared.
     (5952757)	Comments: closing moz
     (5834842)	URL:
     (5834842)	Comments: I was downloading the lastest build of Mozilla 1.0RC1 and closed
down Mozilla before the download was complete. Then Mozilla crashed.
[ 6   nsHashtable::Exists e16be92f - nsHashtable::Exists ]
     Count   Platform List 
     2   Windows NT 5.1 build 2600
     2   Windows NT 5.0 build 2195
     2   Windows 98 4.10 build 67766446
     Count   Build Id List 
     2   2002050408
     2   2002050108
     1   2002050308
     1   2002050304
     (6076652)	URL:
     (6041356)	URL:
     (6041356)	Comments: Cancelling a sownload of a very large file from a very slow ftp
connection  after about an hour of waiting.
     (5947946)	URL:
     (5947946)	Comments: Download Manager was downloading the file  and I closed the
associated Mozilla Browser window. The Download Manager then crashed.

[ 2   nsHashtable::Exists() e6c17603 - nsHashtable::Exists() ]
     2   Linux 2.4.18-0.13   
     Count   Build Id List 
     2   2002050210
[ 2   nsHashtable::Exists() 3898052d - nsHashtable::Exists() ]
[ 1   nsHashtable::Exists() b879754b - nsHashtable::Exists() ]
[ 1   nsHashtable::Exists() 99ba2447 - nsHashtable::Exists() ]
[ 1   nsHashtable::Exists() 87a5a8dc - nsHashtable::Exists() ]
[ 1   nsHashtable::Exists() 8292293f - nsHashtable::Exists() ]
[ 1   nsHashtable::Exists() 6697a0e8 - nsHashtable::Exists() ]

     5   Linux 2.4.18-6mdk   
     1   Linux 2.4.8-26mdk   
     1   Linux 2.4.7-10smp   
     Count   Build Id List 
     2   2002050307
     1   2002050710
     1   2002050610
     1   2002050310
     1   2002050210
     1   2002050110
yeah, this looks trunk-only.

Nahor, info on the pref that controls this dl mgr behavior is:


its values are:

0 - open the download mgr window
1 - open a progress dlg
2 - do nothing
Whiteboard: [ADT1 RTM] → [ADT1 RTM][trunk only]
That pref won't work on the branch.  However, whether or not download manager is
on by default should not impact this.  The download manager tracks the download
either way, so we go through the same codepath.  I suspect that something
unrelated to download manager is causing this crash, but I'll have to look into
it further.  In the mean time, I'm not sure I understand why this is
nsbeta1+/adt1-rtm if it's trunk-only.
Sarah, can you help me narrow down exactly when this regressed?
narrowed it down to this period, using linux commercial trunk bits:

2002.04.28.07-trunk - works fine, no crash when quitting during download
2002.04.28.21-trunk - broken, crashes when quitting during download

in the 7am build, the download manager didn't automatically appear; instead the
regular progress dlg came up. in the 9pm build, the download manager
automatically appeared for the download. (side note: for both builds i created
new profiles.)
Even on yesterday's build (2002050908 Win2k), if you change the default to
progress dialog (browser.downloadmanager.behavior=1) which doesn't involve the
download manager, it doesn't crash. For the behaviors 0 and 2 which use the
manager, it crashes.
Blake & Sairuh: Is this really only a problem on the trunk?  If so, we need to
get it off the MachV radar.
This will occur on the branch once the pref goes on the branch.

Cc'ing cvs blamers -- any idea how nsHashtable::Exists() could be crashing?  I
need to get a debug build to investigate further.
Hm, judging from the (slightly off) stack line numbers, I guess it's crashing on

PLHashNumber hash = aKey->HashCode();

so the key I'm passing in must be null or garbage when we're shutting down. Need
to figure out why.
It could also be crashing if |this| is null or garbage, since it's non-virtual.

The disassembly and registers would help to show what the cause is.  (Go to a
talkback report, with a URL like
http://cyclone/reports/incidenttemplate.cfm?bbid=16077289 , click on the "Code
around the PC" tab, and get the register info and the disassembly (where the
first line of the disassembly should be red -- if it's a different line, need to
note that).
x86 Registers:
EAX: 0905ed4e EBX: 0905ed4e ECX: 0012fd34 EDX: 0012fd34
ESI: 00000000 EDI: 0012fd2c ESP: 0012fd14 EBP: 0012fd3c
EIP: 60e38619 cf pf af zf sf of IF df nt RF vm   IOPL: 0
CS: 001b DS: 0023 SS: 0023 ES: 0023 FS: 0038 GS: 0000

Code Around the PC: 60e38619 8b4604           mov     eax,[esi+0x4]
60e3861c 85c0             test    eax,eax
60e3861e 7408             jz      60e38628
60e38620 50               push    eax
60e38621 ff15d8b1e760     call    dword ptr [60e7b1d8]
60e38627 59               pop     ecx
60e38628 837e2800         cmp     dword ptr [esi+0x28],0x0
60e3862c 8d4608           lea     eax,[esi+0x8]
60e3862f 57               push    edi
60e38630 53               push    ebx
60e38631 50               push    eax
60e38632 7407             jz      60e3863b
60e38634 e849210400       call    60e7a782

I have discovered a bit more about this crash, I'll post it soon.
Comment 32 shows that the crash occurs because |this| is null in
nsHashtable::Exists, so we crash when trying to look at |mLock|.
That pref must not go onto the branch until this is fixed.
dbaron is correct, |this| is null.  Actually, the whole download manager service
has already been shut down by the time the nsIDownload receives notification
that the transfer has stopped and calls various nsIDownloadManager functions. 
The only reason this doesn't occur when using the progress dialogs instead of
download manager is because the progress dlg holds a ref to the download manager
as its observer... 
You mean we dont really abort the download, kill all datastructures/callbacks
before going into shutdown. That sounds bad (with and without download manager).
Right, listeners are still getting progress notifications after services have
been shut down:

nsDownload::OnStateChange(nsDownload * const 0x0334bd8c, nsIWebProgress *
0x00000000, nsIRequest * 0x032b5298, unsigned int 16, unsigned int 0) line 1062
+ 35 bytes
nsDownloadProxy::OnStateChange(nsDownloadProxy * const 0x034821bc,
nsIWebProgress * 0x00000000, nsIRequest * 0x032b5298, unsigned int 16, unsigned
int 0) line 142 + 39 bytes
nsExternalAppHandler::OnStopRequest(nsExternalAppHandler * const 0x032880b0,
nsIRequest * 0x032b5298, nsISupports * 0x00000000, unsigned int 2152398850) line
nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x0351c978,
nsIRequest * 0x032b5298, nsISupports * 0x00000000, unsigned int 2152398850) line 256
nsStreamListenerTee::OnStopRequest(nsStreamListenerTee * const 0x03675dd0,
nsIRequest * 0x032b5298, nsISupports * 0x00000000, unsigned int 2152398850) line 66
nsHttpChannel::OnStopRequest(nsHttpChannel * const 0x032b529c, nsIRequest *
0x035b9924, nsISupports * 0x00000000, unsigned int 2152398850) line 2897
nsOnStopRequestEvent::HandleEvent() line 213
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x02a84bf4) line 116
PL_HandleEvent(PLEvent * 0x02a84bf4) line 596 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00c5dd28) line 526 + 9 bytes
nsEventQueueImpl::ProcessPendingEvents(nsEventQueueImpl * const 0x00c4a778) line
388 + 12 bytes
NS_ShutdownXPCOM(nsIServiceManager * 0x00000000) line 563
main(int 1, char * * 0x004448a0) line 1814 + 8 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e7eb69()

In light of that, this probably belongs to someone in networking. But I will
keep digging.
Passing to networking for a look.
Assignee: blaker → new-network-bugs
Component: Download Manager → Networking
QA Contact: sairuh → benc
necko must fire OnStopRequest... that's required.

-> docshell
Assignee: new-network-bugs → adamlock
Component: Networking → Embedding: Docshell
QA Contact: benc → adamlock
I think the download manager or download progress should cancel the download
before letting shutdown happen. Rather I wonder if shutdown should issue
something equivalent of cancel all network activity. Anyway it all seems like it
should happen from the client.
The download manager cannot stop the download, it doesn't have that kind of
control: the downloader could be anyone (AIM, etc.).  It just listens to
Whiteboard: [ADT1 RTM][trunk only] → [ADT1 RTM][trunk only],custrtm-
Hmm, the status whiteboard in this bug says this is trunk only, if that's true,
then why is this marked nsbeta1+?
Because this can occur on the branch if you set the pref to have download
manager appear automatically (which will be possible once nsbeta1+ bug 137440 is
fixed on the branch). is marked adt1.0.0-, so it's
never going to get fixed on the branch.  In order to change that, you'll need to
raise this to the ADT's attention again by adding an adt1.0.1 keyword.  I'm not
sure why they would change stance on that bug at this point though...
true, but now that the Downloads pref panel is back on the branch, if the user
turns on the "open the dl mgr" option, s/he would encounter this.
I was just looking into fixing this by cancelling all transferring downloads in
nsDownloadManager's dtor, but that's not possible right now because the download
manager would need to use rdf to get a list of the ongoing downloads, and by
then the rdf service has been shut down.  This demonstrates why networking
either needs to cancel the download itself, or, as Suresh said in comment 40,
networking should notify us that network activity is ending, and then dl mgr
could cancel.
adam, what's the ETA on this bug.  Blake, should this be reassigned to you?
No, this is not something I can fix from my end.  Any object that listens to
notifications and then does something using a service, and receives the
notification upon quitting, can potentially run into this.  I will see if I can
somehow work around it.  Alternatively, we can remove the option to open the
download manager for downloads if we don't think this can get fixed by MachV.
A trunk build from yesterday doesn't crash for me but the 1.0.1 branch does. 

Would it be possible to add code to the download manager listen to the
"quit-application" notification sent out by the goQuitApplication() routine and
have the download manager cancel all downloads at that point?

Download manager may even be able to pose a "You are downloading files, are you
sure you want to quit?" message and throw an exception to abort the quit.

Attached patch Rouch patch (obsolete) — Splinter Review
This illustrates my previous suggestion - add a "quit-application" observer to
the download manager and cancel downloads in progress when it arrives. It works
*most* of the time but I have observed a crash that I was unable to debug,
which might have been network events arriving after xpcom shutdown.

Personally I wonder if the download manager is ready for 1.0.1, since it
appears to suffer from some odd behaviour such as opening one download manager
window per download plus plenty of assertions in debug mode. Perhaps the pref
panel should be removed.
Adam, the opening one window per download thing is fixed on the trunk...are you
saying it's not on the branch? That would be bad.

The assertions have to do with trees that have embedded progressmeters, and
isn't specific to download manager.
Good catch!  The fix for bug 131762 hasn't been checked in on the branch.  I've
nominated it.

Any bug on the assertions should be filed to Jan Varga.
Comment on attachment 87522 [details] [diff] [review]
Rouch patch

This is a good suggestion.  Not done quite correctly, since we can just use the
dom to enumerate the downloads (no need to select them all, etc.).  Also, the
bug to add a warning about canceled downloads being was minused long ago. I'll
produce an updated patch.
Attachment #87522 - Flags: needs-work+
Reassign to Blake
Assignee: adamlock → blaker
QA Contact: adamlock → sairuh
sairuh - shiould this still say [trunk only] in the status whiteboard?
Whiteboard: [ADT1 RTM][trunk only],custrtm- → [ADT1 RTM],custrtm-
Whiteboard: [ADT1 RTM],custrtm- → [ADT1 RTM],custrtm- [ETA 6/20/02]
Attached patch new patch (obsolete) — Splinter Review
Attachment #87522 - Attachment is obsolete: true
Attached patch better patchSplinter Review
Attachment #88526 - Attachment is obsolete: true
Comment on attachment 88528 [details] [diff] [review]
better patch

Attachment #88528 - Flags: review+
Fixed on trunk.
Closed: 22 years ago
Keywords: adt1.0.1
Resolution: --- → FIXED
Whiteboard: [ADT1 RTM],custrtm- [ETA 6/20/02] → [ADT1 RTM],custrtm-
adt1.0.1+ (on adt's behalf) approval for checkin to the 1.0 branch, pending
drivers' approval. pls checkin this in asap, the add the "fixed1.0.1" keyword.
Blocks: 143047
Whiteboard: [ADT1 RTM],custrtm- → [ADT1 RTM],custrtm- [ETA 06/21]
Keywords: adt1.0.1adt1.0.1+
Whiteboard: [ADT1 RTM],custrtm- [ETA 06/21] → [ADT1 RTM],custrtm- [ETA 06/24]
Still plan on checking this in today, just waiting for branch opening...
Whiteboard: [ADT1 RTM],custrtm- [ETA 06/24] → [ADT1 RTM],custrtm- [ETA 06/21]
this looks good on the trunk, using 2002.06.21.10 comm trunk bits on linux rh7.2.

Nahor, is this working for you now with the latest trunk build?
Whiteboard: [ADT1 RTM],custrtm- [ETA 06/21] → [ADT1 RTM],custrtm- [ETA 06/21] [vrfy'd on trunk, linux]
Yes, it seems to work fine. I just tried a couple times on two different machine
and it didn't crash.
thanks for checking, Nahor!

marking verified [on the TRUNK].
Whiteboard: [ADT1 RTM],custrtm- [ETA 06/21] [vrfy'd on trunk, linux] → [ADT1 RTM],custrtm- [ETA 06/21] [vrfy'd on trunk]
Comment on attachment 88528 [details] [diff] [review]
better patch

a=asa (on behalf of drivers) for checkin to the branch.
Attachment #88528 - Flags: approval+
approved for checkin to the branch. when you've landed this please change the
mozilla1.0.1+ keyword to fixed1.0.1. 
Fixed on branch.
verified on the branch using 2002.06.27.08 comm bits on win2k.
Reopening as a topcrash on the trunk.

Rank    StackSignature    Count  
15   nsHashtable::Exists   15
Source File : c:/builds/seamonkey/mozilla/xpcom/ds/nsHashtable.cpp line : 261

  Count   Offset    Real Signature
[ 12   nsHashtable::Exists f338067b - nsHashtable::Exists ]
     Crash date range: 2002-07-07 to 2002-07-15
     Min/Max Seconds since last crash: 427 - 177884
     Min/Max Runtime: 427 - 177884
     Keyword List :  
     Count   Platform List 
     5   Windows NT 5.0 build 2195
     3   Windows NT 5.1 build 2600
     2   Windows 98 4.10 build 67766446
     1   Windows NT 4.0 build 1381
     1   Windows 95 4.0 build 67109975
     Count   Build Id List 
     3   2002071008
     3   2002070908
     1   2002071204
     1   2002071004
     1   2002070808
     1   2002070708
     1   2002070608
     1   2002070508
     No of Unique Users        12
 Stack trace(Frame) 

	 nsHashtable::Exists	[c:/builds/seamonkey/mozilla/xpcom/ds/nsHashtable.cpp 
line 261] 
 line 174] 
 line 1188] 
 line 676] 
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsStreamListenerTee.cpp  line 66] 
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp  line
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsRequestObserverProxy.cpp  line 213] 
	 PL_HandleEvent	[c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c  line 597] 
	 PL_ProcessPendingEvents	[c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c 
line 530] 
[c:/builds/seamonkey/mozilla/xpcom/threads/nsEventQueue.cpp  line 392]  
     (8344847)	Comments: There were 3 Downloads running in the backgroud
(downloadmanager-window closed) when I shut down mozilla. It crashed
     (8326572)	URL:
     (8258875)	Comments: crash after installling type ahead search XPI
     (8230340)	Comments: eating tofu
     (8222151)	Comments: Crashed on automatic restart by Quick Launch
     (8298242)	Comments: Closing the browser
Resolution: FIXED → ---
Summary: Crash if quitting while downloading [@ nsHashtable::Exists] → Crash if quitting while downloading; trunk [@ nsHashtable::Exists]
Something must have changed on the trunk.  I haven't touched download manager on
awhile.  Removing adt markings since it's trunk-only.
Keywords: adt1.0.1+, nsbeta1+nsbeta1
Whiteboard: [ADT1 RTM],custrtm- [ETA 06/21] [vrfy'd on trunk] → [vrfy'd on trunk]
Nav triage team: nsbeta1+/adt1
Keywords: nsbeta1nsbeta1+
Whiteboard: [vrfy'd on trunk] → [vrfy'd on trunk][adt1]
Ok, so my theory is that some screwy download path is never creating the
hashtable. Instead of putting a whole bunch of if (!mCurrDownloads)
mCurrDownloads = new nsHashtable() all over the place, I decided to make it
just a normal member variable, so the hashtable will always exist - this will
save is one extra allocation anyway, and avoid future codepaths where
mCurrDownloads doesn't exist.
this could be our 600th topcrash fix!  let's get this on the Trunk so we can
moniter Talkback data to see if the crashes go away.

just to clarify, this crash appears to be Trunk only (there haven't been any
incidents with the Gecko1.0 Branch).  were the nsbeta1+ and adt1 markings put in
on 7/19 for Buffy?
yup, that's why I attached the patch.. (to get the 600th!) 
I just need reviews.. we don't even need approvals anymore..

I'll just take this and go bug blake for reviews...
Assignee: blaker → alecf
Comment on attachment 94027 [details] [diff] [review]
make mCurrDownloads a non-pointer member

Attachment #94027 - Flags: superreview+
Comment on attachment 94027 [details] [diff] [review]
make mCurrDownloads a non-pointer member

Attachment #94027 - Flags: review+
QA Contact: sairuh → mdunn
hey chofmann, I haven't checked this in just yet - I'm waiting desperately for
an open tree :)
it looks like bug 90571 was the one that took us to 600 earlier today...but that
wasn't even really a fix (a new version of the jre fixed that crash).  so as
soon as the tree opens you can officially take us to 601 alec!
ok, NOW this is fixed :)
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
Keywords: verified1.0.1
Whiteboard: [vrfy'd on trunk][adt1] → [adt1][fixed on trunk]
note: chris petersen and i cannot verify this using trunk builds on Mac OS X,
either with pre- or post-fix trunk builds. perhaps this is related to bug
155426. i guess we'll know for OS X if/when this get checked in on the branch.

anyhow, gonna get trunk bits for the other platforms to test this...
vrfy'd fixed on linux [2002.08.07.08] and win2k [2002.08.07.11] comm trunk builds.

unable to verify on mac os 9.x [2002.08.07.08 comm trunk], prolly due to bug

do ppl want this for the 1.0.1 branch?
Keywords: adt1.0.1
Whiteboard: [adt1][fixed on trunk] → [adt1][vrfy'd on linux/win2k trunk]
Whiteboard: [adt1][vrfy'd on linux/win2k trunk] → [adt2 RTM] [vrfy'd on linux/win2k trunk]
Target Milestone: mozilla1.0 → mozilla1.0.1
removing adt1.0.1 based on comments that say this is trunk only.
Keywords: adt1.0.1
Over to depstein for verification
QA Contact: mdunn → depstein
Verified with commercial trunk Netscape 1.3b Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.3b) Gecko/20030109 Netscape/7.01+ . No crashing. Download
manager remains even after quitting app, document successfully downloads.
Crash Signature: [@ nsHashtable::Exists]
You need to log in before you can comment on or make changes to this bug.