Closed Bug 91726 Opened 23 years ago Closed 23 years ago

Crash clicking on .exe file from web page

Categories

(SeaMonkey :: UI Design, defect, P1)

Product:
SeaMonkey
Component:
UI Design
Platform:
PowerPC
macOS
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.4

People

(Reporter: lchiang, Assigned: paulkchen)

References

Details

(Keywords: crash, Whiteboard: OSX+)

Attachments

(3 files)

Dialog screen shot
11.29 KB, image/gif
Details
if IC returns empty mime type, set mime type to octet stream
891 bytes, patch
Details | Diff | Splinter Review
bulletproof nsCRT::HashCode some
528 bytes, patch
Details | Diff | Splinter Review 
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?
Assignee: sdagley → pchen
Component: Browser-General → XP Apps
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.
QA Contact: doronr → sairuh
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.
Attached image Dialog screen shot — 

    
    

    
  
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?

Keywords: crash
Whiteboard: OSX+

    
    

    
  
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
Keywords: nsbeta1+
Priority: -- → P2
Target Milestone: --- → 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.

    
    

    
  
*** 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
Keywords: nsenterprise+
Priority: P2 → 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 ;-)
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
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.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: