Crash clicking on .exe file from web page I'm testing this on a Mac OS X 2001-07-17 branch build. I searched bugzilla for platform Mac builds with crash keyword and didn't see this filed. I haven't had a chance to check to see if this problem occurs outside of OS X. 1. Start the product 2. Go to any page which has an .exe. I used: http://home.netscape.com/browsers/6/index61pr.html?cp=dowwin#Preview Release 3. Go to the bottom of the page and click on the link for "English" under Windows. 4. Crash occurs. I don't have Talkback enabled on this OS X build of the product. I don't have MacsBug set up (sorry). I know that I'm clicking on an .exe file for Windows, but a crash shouldn't happen.
I'm able to reproduce the same problem when clicking on a link to a BMP file. I should get a helper app dialog instead of a crash. 1) Go to http://www.boeing.com/defense-space/military/jsf/jsftheme.htm 2) Scroll down to "WallPaper" section of document. 3) Click on any of the airplane photos 4) A crash occurs.
who should own this? paul?
Do you want to mark this with OSX status whiteboard? petersen - can you see if this happens outside of OS X? I don't have a machine to try. Thanks.
I couldn't reproduce the BMP problem under Mac OS 9.1. I believe both problems are related to Mac OSX. I will double-check tommorrow with the specified .exe crash.
Just checked in "Classic" OS 9 mode in OS X. Download dialog opens and application doesn't crash after clicking .exe link. See attachment.
Under Mac OS 9.1 with July 26th branch, the problem is not occuring.
this probably has to do with the extension not being contained in internetConfig, so it's possible the mappings on os9 and osx are different. if you adjust the IC mappings to remove these extensions on os9, does it crash?
To try to reproduce the problem under 9.1, I removed .exe and .bmp from the file mapping section (Advanced tab) in the Internet control panel. Restarted machine and launched N6.1 branch. Clicking on the either link (BMP or EXE) still displays the Download dialog with no crash.
ok, can we get a stacktrace?
From trunk carbon build (8-1) ********** Date/Time: 2001-08-01 11:18:13 -0700 PID: 220 Command: Netscape 6 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0: #0 0x00163450 in HashCode__5nsCRTFPCcPUi () #1 0x01c9c870 in 0x1c9c870 () #2 0x00142318 in Put__11nsHashtableFP9nsHashKeyPv () #3 0x01eec29c in AddMimeInfoToCache__26nsExternalHelperAppServiceFP11nsIMIMEInf () #4 0x01eed514 in GetFromExtension__20nsOSHelperAppServiceFPCcPP11nsIMIMEInfo () #5 0x01eeaf1c in GetTypeFromExtension__26nsExternalHelperAppServiceFPCcPPc () #6 0x01eeb4dc in GetTypeFromURI__26nsExternalHelperAppServ () #7 0x0457b6b0 in GetContentType__12nsFTPChannelFPPc () #8 0x01edca40 in 0x1edca40 () #9 0x01edc570 in OnStartRequest__18nsDocumentOpenInfoFP10nsIRequestP11nsISuppor () #10 0x0457c6d4 in OnStartRequest__12nsFTPChannelFP10nsIRequestP11nsISupports () #11 0x0457d914 in DelayedOnStartRequest__20DataRequestForwarderFP10nsIRequestP11 () #12 0x0457dd38 in OnDataAvailable__20DataRequestForwarderFP10nsIRequestP11nsISup () #13 0x01db5e2c in HandleEvent__22nsOnDataAvailableEventFv () #14 0x01dc2030 in HandlePLEvent__23nsARequestObserverEventFP7PLEvent () #15 0x001b6c98 in PL_HandleEvent () #16 0x001b6b14 in PL_ProcessPendingEvents () #17 0x0015f494 in ProcessPendingEvents__16nsEventQueueImplFv () #18 0x01efec60 in ProcessPLEventQueue__26nsMacNSPREventQueueHandlerFv () #19 0x01efea24 in RepeatAction__26nsMacNSPREventQueueHandlerFRC11EventRecord () #20 0x01f2790c in DoRepeaters__8RepeaterFRC11EventRecord () #21 0x01f12f30 in DispatchEvent__16nsMacMessagePumpFiP11EventRecord () #22 0x01f12850 in DoMessagePump__16nsMacMessagePumpFv () #23 0x01f120e0 in Run__10nsAppShellFv () #24 0x01cba1f4 in Run__17nsAppShellServiceFv () #25 0x00093dfc in main1__FiPPcP11nsISupports () #26 0x00094b6c in main () Thread 1: #0 0x7000424c in _syscall () #1 0x706584b8 in _ProcessReadyEvent () #2 0x706582b0 in _CarbonSelectThreadFunc () #3 0x70014f04 in __pthread_body () Thread 2: #0 0x70059b68 in _semaphore_wait_signal_trap () #1 0x70016110 in _semaphore_wait_signal () #2 0x70015f78 in __pthread_cond_wait () #3 0x70015d18 in _pthread_cond_wait () #4 0x70653be0 in _BSD_pthread_cond_wait () #5 0x70653bc0 in _CarbonConditionWait () #6 0x7065557c in _CarbonOperationThreadFunc () #7 0x70014f04 in __pthread_body () Thread 3: #0 0x70059b48 in _semaphore_timedwait_signal_trap () #1 0x7003f7f8 in _semaphore_timedwait_signal () #2 0x70015f68 in __pthread_cond_wait () #3 0x7003f7c4 in _pthread_cond_timedwait_relative_np () #4 0x7029b590 in _TSWaitOnConditionTimedRelative () #5 0x7029cdac in _TSWaitOnSemaphoreCommon () #6 0x702e5f98 in _TSWaitOnSemaphoreRelative () #7 0x702e7208 in _TimerThread () #8 0x70014f04 in __pthread_body () Thread 4: #0 0x70059b68 in _semaphore_wait_signal_trap () #1 0x70016110 in _semaphore_wait_signal () #2 0x70015f78 in __pthread_cond_wait () #3 0x70015d18 in _pthread_cond_wait () #4 0x7029b550 in _TSWaitOnCondition () #5 0x7029cd94 in _TSWaitOnSemaphoreCommon () #6 0x7029cce4 in _TSWaitOnSemaphore () #7 0x7029cba8 in _AsyncFileThread () #8 0x70014f04 in __pthread_body () Thread 5: #0 0x70059b68 in _semaphore_wait_signal_trap () #1 0x70016110 in _semaphore_wait_signal () #2 0x70015f78 in __pthread_cond_wait () #3 0x70015d18 in _pthread_cond_wait () #4 0x70653be0 in _BSD_pthread_cond_wait () #5 0x70653bc0 in _CarbonConditionWait () #6 0x70653ab4 in _CarbonInetOperThreadFunc () #7 0x70014f04 in __pthread_body () PPC Thread State: srr0: 0x00163450 srr1: 0x0000f030 vrsave: 0x00000000 xer: 0x00000018 lr: 0x00143258 ctr: 0x0014323c mq: 0x00000000 r0: 0x00142318 r1: 0xbfffe650 r2: 0x002ae000 r3: 0x00000000 r4: 0xbfffe774 r5: 0x0435c570 r6: 0x00000000 r7: 0x00000000 r8: 0x00000000 r9: 0x00000001 r10: 0x00000001 r11: 0x6a57eae0 r12: 0x002a7248 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x002b4934 r17: 0x00000000 r18: 0x00000000 r19: 0x002bdf40 r20: 0xbfffeb3c r21: 0x00000000 r22: 0xbfffe77c r23: 0x01c9c870 r24: 0x0435c570 r25: 0xbfffe780 r26: 0x01c9da60 r27: 0xbfffe76c r28: 0x0435c570 r29: 0x002bdd38 r30: 0x002be2e4 r31: 0x00000000 **********
nav triage team: marking p2, nsbeta1+, and mozilla0.9.4
So the problem here is that 1) InternetConfig returns a mapping with no mime type string for .exe and .bmp and 2) nsCRT::HashCode barfs (under OS X) since we dereference the input char*, which in this case is null. I will attach a patch to address 1. I'm surprised we haven't died in 2 more often, my guess is that we just happen to always pass a non-null char* into nsCRT::HashCode, which kinda makes sense. However, maybe nsCRT::HashCode should be a bit more bulletproof.
Created attachment 44587 [details] [diff] [review] if IC returns empty mime type, set mime type to octet stream
*** Bug 90793 has been marked as a duplicate of this bug. ***
*** Bug 93152 has been marked as a duplicate of this bug. ***
*** Bug 86775 has been marked as a duplicate of this bug. ***
I'm able to reproduce this same crash when attempting to forward certain emails such as a update notification bug report from bugzilla. Tested on Aug 8th build (2001-08-08-05) under Mac OS 10.0.4. Steps to reproduce: 1) In Mail, select a notification message from Mozilla.org. 2) Click on Forward button. 3) Crash should occur. Stack trace should be the same as the one provide earlier in the report.
Just added patch to have nsCRT::HashCode handle a null char* input. Not sure that '0' is the best return value, but I couldn't think of anything better. Looking for r= and sr=
*** Bug 81901 has been marked as a duplicate of this bug. ***
We discussed this fix, and came up with a better one (don't send in null in the first place), so I'm expecting a new patch.
well, nsCRT::HashCode should still be bulletproof enough to never crash.
The reason we get a null is because mimetype.get() passes in a null since mimetype is empty. In nsMimeInfo::SetMIMEType(), we check for the null and return NS_ERROR_NULL_POINTER. So I guess the fix isn't much different than the one I posted other than setting the mime type to the empty string instead of octet-stream.
Added kw: nsenterprise+, Priority: P1
Just logged bug 96322 to deal with protecting nsCRT::HashCode() from null. Unfortunately, it was assigned to kandrot, sigh.
r=pink (for attach_id=44587)
patch from attach_id=44587 has been checked in, marking fixed because this is the root cause of the crash, strengthening nsCRT::HashCode is just a little bit of icing on the cake and it's in bug 96322 anyway ;-)
vrfy fixed using 2001.08.27.05-comm bits on 10.0.4. tested with a N6setup.exe from sweetlou's ftp site and a .bmp image from chris' 2001-07-31 16:38 test case.