Closed Bug 195386 Opened 21 years ago Closed 21 years ago

Download doesn't start and mozilla crashes or freeze. [@ PL_DHashStringKey]

Categories

(Core Graveyard :: File Handling, defect)

defect
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.4alpha

People

(Reporter: fredbezies, Assigned: Biesinger)

References

()

Details

(5 keywords)

Crash Data

Attachments

(2 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030228
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030228

I only see it since yesterday. When I click on a link for downloading a file,
mozilla either crashes (saying there is an access violation in XPCOM.DLL) or it
freeze !

URL provided is just an example of the problem.

Reproducible: Always

Steps to Reproduce:
1.Go to a site with file downloading URL
2.Click on link to download.


Actual Results:  
Crash (in XPCOM.DLL) or mozilla is freezing, no more throbber.

Expected Results:  
Opening dialog box for saving file or asking what to do with it.

Using a current CVS based trunk build. Installed it cleanly, removing xul.mfl,
downloads.rdf or mimetypes.rdf does nothing.

Here is my about:buildconfig

about:buildconfig

Build platform
target
i686-pc-cygwin

Build tools
Compiler 	Version 	Compiler flags
cl 		-TC -W3 -nologo -Gy -Fd$(PDBFILE)
cl 		-TP -W3 -nologo -Gy -Fd$(PDBFILE)

Configure arguments
--enable-calendar --enable-crypto --disable-installer --disable-tests
--disable-debug --enable-optimize --enable-strip
Just to add some infos : using "Save link target as" is working. Only left click
is buggy.

Is this a smoketest blocker ? Should it be considered as a 1.4a blocker ?
I had verified this bug with a yesterday latest trunk build.

Here is the talkback ID : TB17568176H
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030227
TB17588651M Build ID 2003022709 Win98SE
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030227

Instant crash at start download example with leftclick.

re comment #3: Build ID 2003022704 
crashed too, but after download I had a windows crash, with automatic rebooting.
Had downloaded or started successfully installer.exe (218Kb) and started 2 big
downloads, just for testing.
After about the time DSL would have finished downloading I had this crash,
and only installer.exe was found on disk.
I´m not sure if I didn´t download it with rightclick, I´m used to right-clicking.
Not sure if this is related, but this started occuring for me after i removed
the helper application for application/octet-stream.
Crash also happened when I try to save a custom .mozconfig created with
UnixBuild Configurator from mozilla.org site. I just clicked on "save" :-/

So, it seems that mozilla is crashing at each try for saving datas.
The OS should be ALL.
*** Bug 195365 has been marked as a duplicate of this bug. ***
Following comment #8, moving OS -> ALL, as duplicate was found on OS/2.
OS: Windows XP → All
Linux 2003022705 OK
      2003022708 Crash
PL_DHashStringKey(PLDHashTable * 0x0024e2f0, const void * 0x00000000) line 79 +
6 bytes
nsComponentManagerImpl::GetServiceByContractID(nsComponentManagerImpl * const
0x0024e2f0, const char * 0x00000000, const nsID & {...}, void * * 0x80004005)
line 2264 + 18 bytes
nsComponentManagerImpl::GetServiceByContractID(nsComponentManagerImpl * const
0x0024e2ac, const char * 0x00000000, const nsID & {...}, void * * 0x0012f8bc)
line 2264 + 18 bytes
nsGetServiceByContractID::operator()(const nsGetServiceByContractID * const
0x0024e6b0, const nsID & {...}, void * * 0x0012f8bc) line 121 + 15 bytes
nsCOMPtr_base::assign_from_helper(nsCOMPtr_base * const 0x0024e6b0, const
nsCOMPtr_helper & {...}, const nsID & {...}) line 81 + 14 bytes
nsDocShell::NewContentViewerObj(nsDocShell * const 0x03d1b230, const char *
0x0012f9b4, nsIRequest * 0x0024e398, nsILoadGroup * 0x058a74d0,
nsIStreamListener * * 0x0012fb28, nsIContentViewer * * 0x0012f93c) line 4541 +
40 bytes
nsDocShell::CreateContentViewer(nsDocShell * const 0x03d1b230, const char *
0x0012f9b4, nsIRequest * 0x05dad1a0, nsIStreamListener * * 0x0012fb28) line 4446
nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x00090000,
const char * 0x0012f9b4, int 0, nsIRequest * 0x05dad1a0, nsIStreamListener * *
0x0012fb28, int * 0x05dad1a0) line 110
nsDocumentOpenInfo::DispatchContent(nsDocumentOpenInfo * const 0x0024e6b0,
nsIRequest * 0x05dad1a0, nsISupports * 0x00000000) line 436
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x06dab3f0,
nsIRequest * 0x05dad1a0, nsISupports * 0x00000000) line 228 + 14 bytes
nsHttpChannel::CallOnStartRequest(nsHttpChannel * const 0x0024e6b0) line 598 +
14 bytes
nsHttpChannel::ProcessNormal(nsHttpChannel * const 0x0024e6b0) line 726
nsHttpChannel::ProcessResponse(nsHttpChannel * const 0x0024e6b0) line 663 + 7 bytes
nsHttpChannel::OnStartRequest(nsHttpChannel * const 0x05dad1a8, nsIRequest *
0x05e5a580, nsISupports * 0x00000000) line 2874 + 8 bytes
nsInputStreamPump::OnStateStart(nsInputStreamPump * const 0x0024e6b0) line 354
nsInputStreamPump::OnInputStreamReady(nsInputStreamPump * const 0x06dab060,
nsIAsyncInputStream * 0x10051778 const  nsCString::`vftable') line 328
Uhm, that looks like Necko stuff at the bottom, but I really don't know... 
CC'ing Darin. Did I guess right? =)
could this be a regression from bug 97324 ?
Seeing this took talkback ID:  TB17594930M

Thanks!!
Keywords: crash, hang
*** Bug 195419 has been marked as a duplicate of this bug. ***
Keywords: topcrash
Summary: Download doesn't start and mozilla crashes or freeze. → Download doesn't start and mozilla crashes or freeze. @PL_DHashStringKey
http://lxr.mozilla.org/mozilla/source/docshell/base/nsDocShell.cpp#4537

catMan->GetCategoryEntry("Gecko-Content-Viewers", aContentType,
 getter_Copies(contractId));

this is returning a null string into contractID, which is passed up the chain.
*** Bug 195404 has been marked as a duplicate of this bug. ***
*** Bug 195373 has been marked as a duplicate of this bug. ***
Keywords: smoketest
Summary: Download doesn't start and mozilla crashes or freeze. @PL_DHashStringKey → Download doesn't start and mozilla crashes or freeze. [@ PL_DHashStringKey]
I'm seeing this on Solaris too. Can someone change the Hardware to "All"
please too. My stack is attached with a clearer culprit. Since we do daily
builds from CVS i can confirm this behavior only happened on todays build.

For me it happens if i don't have a plugin for a specified mime type and
the default helper is to download to disk, but i never see the popup
and it crashes as per the stack attached.

In line 79 of pldhash.c, we should really be doing

for (s = key; s && (*s != '\0'); s++)

since key was passed in as NULL.       

taking, I'll investigate.
Assignee: law → sspitzer
Hardware: PC → All
Attached patch Checks rv (obsolete) — Splinter Review
OK, uploading this. It builds, and I think it's correct. However, I have to go,
so someone else test it and check it in.
This is my fault, the code mentioned in comment 16 should check the return value
of GetCategoryEntry and return if failed.
I prefer this one to bsmedberg's patch
testing a fix from cbiesinger@web.de right now.
Assignee: sspitzer → cbiesinger
Attached patch updated patchSplinter Review
Attachment #115890 - Attachment is obsolete: true
Attachment #115892 - Attachment is obsolete: true
Comment on attachment 115892 [details] [diff] [review]
better patch, just return on failure

Hmm.. didn't I comment on the patch that added this code asking for these
checks to be added?
Attachment #115892 - Attachment is obsolete: false
Attachment #115892 - Flags: superreview+
er, never mind me.  I asked for a different error check....
fixed checked in.  thanks to biesi for the quick patch.

caused by bug #97324
Status: NEW → RESOLVED
Closed: 21 years ago
Keywords: regression
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.4alpha
Comment on attachment 115892 [details] [diff] [review]
better patch, just return on failure

there was one more place to check rv, see the final patch.
Attachment #115892 - Attachment is obsolete: true
Re: comment 19, we certainly should not be null testing s in PL_DHashStringKey,
absolutely not in the loop control.  But we shouldn't null test key before the
loop either.  Null is not a legal string (char *) value.

/be
I've added a small test case to the browser smoketest to cover this type of 
thing.

check http://www.mozilla.org/quality/smoketests/index.html#browser in a few 
hours, and see the B.28 that I added.
Keywords: topcrashtopcrash+
*** Bug 195245 has been marked as a duplicate of this bug. ***
*** Bug 195453 has been marked as a duplicate of this bug. ***
*** Bug 195416 has been marked as a duplicate of this bug. ***
*** Bug 195544 has been marked as a duplicate of this bug. ***
*** Bug 195556 has been marked as a duplicate of this bug. ***
This is fixed on the 2003-03-03-08 Win32 trunk build. However, still need try on
Mach-o 0S x build when http://bugzilla.mozilla.org/show_bug.cgi?id=195654 is fixed.
Ok, I didn't realized this bug got fixed on the 2003-02-28-11 Mach-O. I just
verified on that build so I'm marking verified.
Status: RESOLVED → VERIFIED
*** Bug 195497 has been marked as a duplicate of this bug. ***
*** Bug 196587 has been marked as a duplicate of this bug. ***
*** Bug 195498 has been marked as a duplicate of this bug. ***
*** Bug 196654 has been marked as a duplicate of this bug. ***
Crash Signature: [@ PL_DHashStringKey]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: