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

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Frederic Bezies]

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

Comment 1

[Frederic Bezies]

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 ?

Comment 2

[Frederic Bezies]

I had verified this bug with a yesterday latest trunk build.

Here is the talkback ID : TB17568176H

Comment 3

[Hermann Schwab]

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030227

Comment 4

[Hermann Schwab]

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.

Comment 5

[Patrick]

Not sure if this is related, but this started occuring for me after i removed
the helper application for application/octet-stream.

Comment 6

[Frederic Bezies]

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.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

The OS should be ALL.

Comment 8

[Mike Kaply [:mkaply]]

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

Comment 9

[Frederic Bezies]

Following comment #8, moving OS -> ALL, as duplicate was found on OS/2.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Linux 2003022705 OK
      2003022708 Crash

Comment 11

[Matthias Versen [:Matti]]

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

Comment 12

[Owen Marshall (Not reading bugmail)]

Uhm, that looks like Necko stuff at the bottom, but I really don't know... 
CC'ing Darin. Did I guess right? =)

Comment 13

[Matthias Versen [:Matti]]

could this be a regression from bug 97324 ?

Comment 14

[Mel Reyes]

Seeing this took talkback ID:  TB17594930M

Thanks!!

Comment 15

[c.g.workman]

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

Comment 16

[Benjamin Smedberg]

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.

Comment 17

[Bernd]

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

Comment 18

[Chris Petersen]

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

Comment 19

[Mitch]

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.       

Comment 20

[(not reading, please use [e-mail] instead)]

taking, I'll investigate.

Comment 21

[Mitch]

Attachment: Stack from crashing mozilla

Comment 22

[Benjamin Smedberg]

Attachment: Checks rv

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.

Comment 23

[Christian :Biesinger (don't email me, ping me on IRC)]

This is my fault, the code mentioned in comment 16 should check the return value
of GetCategoryEntry and return if failed.

Comment 24

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: better patch, just return on failure

I prefer this one to bsmedberg's patch

Comment 25

[(not reading, please use [e-mail] instead)]

testing a fix from [e-mail] right now.

Comment 26

[(not reading, please use [e-mail] instead)]

Attachment: updated patch

Comment 27

[Boris Zbarsky [:bzbarsky]]

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?

Comment 28

[Boris Zbarsky [:bzbarsky]]

er, never mind me.  I asked for a different error check....

Comment 29

[(not reading, please use [e-mail] instead)]

fixed checked in.  thanks to biesi for the quick patch.

caused by bug #97324

Comment 30

[(not reading, please use [e-mail] instead)]

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.

Comment 31

[Brendan Eich [:brendan]]

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

Comment 32

[(not reading, please use [e-mail] instead)]

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.

Comment 33

[David Tenser [:djst]]

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

Comment 34

[David Tenser [:djst]]

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

Comment 35

[Jure Repinc (JLP)]

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

Comment 36

[David Tenser [:djst]]

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

Comment 37

[Erik]

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

Comment 38

[Chris Petersen]

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.

Comment 39

[Chris Petersen]

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.

Comment 40

[Mrten]

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

Comment 41

[Jason Bassford]

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

Comment 42

[Erik]

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

Comment 43

[Erik]

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