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)
Core Graveyard
File Handling
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.4alpha
People
(Reporter: fredbezies, Assigned: Biesinger)
References
()
Details
(5 keywords)
Crash Data
Attachments
(2 files, 2 obsolete files)
3.54 KB,
text/plain
|
Details | |
986 bytes,
patch
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•21 years ago
|
||
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 ?
Reporter | ||
Comment 2•21 years ago
|
||
I had verified this bug with a yesterday latest trunk build. Here is the talkback ID : TB17568176H
Comment 3•21 years ago
|
||
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030227
Comment 4•21 years ago
|
||
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.
Reporter | ||
Comment 6•21 years ago
|
||
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•21 years ago
|
||
The OS should be ALL.
Comment 8•21 years ago
|
||
*** Bug 195365 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 9•21 years ago
|
||
Following comment #8, moving OS -> ALL, as duplicate was found on OS/2.
OS: Windows XP → All
Comment 10•21 years ago
|
||
Linux 2003022705 OK 2003022708 Crash
Comment 11•21 years ago
|
||
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•21 years ago
|
||
Uhm, that looks like Necko stuff at the bottom, but I really don't know... CC'ing Darin. Did I guess right? =)
Comment 13•21 years ago
|
||
could this be a regression from bug 97324 ?
Comment 14•21 years ago
|
||
Seeing this took talkback ID: TB17594930M Thanks!!
Updated•21 years ago
|
Comment 15•21 years ago
|
||
*** 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
Comment 16•21 years ago
|
||
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•21 years ago
|
||
*** Bug 195404 has been marked as a duplicate of this bug. ***
Comment 18•21 years ago
|
||
*** Bug 195373 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Summary: Download doesn't start and mozilla crashes or freeze. @PL_DHashStringKey → Download doesn't start and mozilla crashes or freeze. [@ PL_DHashStringKey]
Comment 19•21 years ago
|
||
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 21•21 years ago
|
||
Comment 22•21 years ago
|
||
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.
Assignee | ||
Comment 23•21 years ago
|
||
This is my fault, the code mentioned in comment 16 should check the return value of GetCategoryEntry and return if failed.
Assignee | ||
Comment 24•21 years ago
|
||
I prefer this one to bsmedberg's patch
Comment 25•21 years ago
|
||
testing a fix from cbiesinger@web.de right now.
Assignee: sspitzer → cbiesinger
Comment 26•21 years ago
|
||
Attachment #115890 -
Attachment is obsolete: true
Attachment #115892 -
Attachment is obsolete: true
Comment 27•21 years ago
|
||
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+
Comment 28•21 years ago
|
||
er, never mind me. I asked for a different error check....
Comment 29•21 years ago
|
||
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 30•21 years ago
|
||
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
Comment 31•21 years ago
|
||
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•21 years ago
|
||
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.
Updated•21 years ago
|
Comment 33•21 years ago
|
||
*** Bug 195245 has been marked as a duplicate of this bug. ***
Comment 34•21 years ago
|
||
*** Bug 195453 has been marked as a duplicate of this bug. ***
Comment 35•21 years ago
|
||
*** Bug 195416 has been marked as a duplicate of this bug. ***
Comment 36•21 years ago
|
||
*** Bug 195544 has been marked as a duplicate of this bug. ***
Comment 37•21 years ago
|
||
*** Bug 195556 has been marked as a duplicate of this bug. ***
Comment 38•21 years ago
|
||
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•21 years ago
|
||
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
Comment 40•21 years ago
|
||
*** Bug 195497 has been marked as a duplicate of this bug. ***
Comment 41•21 years ago
|
||
*** Bug 196587 has been marked as a duplicate of this bug. ***
Comment 42•21 years ago
|
||
*** Bug 195498 has been marked as a duplicate of this bug. ***
Comment 43•21 years ago
|
||
*** Bug 196654 has been marked as a duplicate of this bug. ***
Updated•13 years ago
|
Crash Signature: [@ PL_DHashStringKey]
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•