Closed Bug 84104 Opened 23 years ago Closed 23 years ago

M091 topcrash in [@ nsExternalHelperAppService::GetTypeFromFile]

Categories

(Core :: Networking: File, defect)

x86
Windows NT
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla0.9.2

People

(Reporter: jband_mozilla, Assigned: dougt)

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(1 file)

I'm running a non-DEBUG with symbols build of the 0.9.1 branch on NT.

I've seen this crash with the browser just pointed at tinderbox and left 
unattended to update on its own.

The crash is in nsExternalHelperAppService::GetTypeFromFile called from 
nsFileIO::Open. The aFile param is apparently null (and dereferencing that 
pointer is where it crashes). This is curious because the code flow shows that 
nsFileIO::Open would have just called a method on that mFile member.\ 
(mFile->IsDirectory). Perhaps IsDirectory managed to use its null 'this' without 
disaster? Or maybe we are seeing cross thread chaos here?

*aContentType points to "application/x-unknown-content-type"

I'll attach the stack I have.
Attached file crash stack
-->dougt
Assignee: neeti → dougt
Component: Networking → Networking: File
QA Contact: benc → tever
related to http://bugzilla.mozilla.org/show_bug.cgi?id=71397, if not a dup. 

I am with you an that assumption that this is a threading fu.  Maybe we are 
getting a close() on thread 1, while still in Open() on thread 2... 


Status: NEW → ASSIGNED
Keywords: crash
Target Milestone: --- → mozilla0.9.2
yup, this is a dup of 71397

*** This bug has been marked as a duplicate of 71397 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Adding [@ ] in the summary for future Talkback tracking
Summary: crash in nsExternalHelperAppService::GetTypeFromFile → crash in [@ nsExternalHelperAppService::GetTypeFromFile]
Reopening this bug because the bug it is duped on is marked fixed and has a 
different stack trace...

This is a topcrash for M091.  Added topcrash keyword

Here are comments/urls from recent crashes:

     (31732806) Comments: using composer
     (31731155) Comments: Started typing an URL in the address bar (just got to 
the first few letters - ww)
     (31725393) Comments: middle click to open a new window on link
     (31714446) URL: http://gaydar.co.uk
     (31713549) URL: http://www.linuxtoday.com
     (31713549) Comments: Er... Not sure. I typed the URL
     (31699742) Comments: Just opened the browser and clicked on the url enter 
bar and started pressing the
delete key to delete the url address
     (31694394) URL: www.berlitz.com
     (31667325) URL: www.msnbc.com
     (31667325) Comments: I had just clicked on a story when it crashed.  I 
usually open up multiple windows
when I browse.
     (31640120) URL: http://softwaredev.earthweb.com/java
     (31640120) Comments: loading website

Here's a stack trace from the 2001060713 build

Incident ID 31750722 
nsExternalHelperAppService::GetTypeFromFile 
[d:\builds\seamonkey\mozilla\uriloader\exthandler\nsExternalHelperAppService.cpp
, line 1398] 
nsFileIO::Open [d:\builds\seamonkey\mozilla\netwerk\base\src\nsFileStreams.cpp, 
line 179] 
nsFileTransport::Process 
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsFileTransport.cpp, line 643] 
Status: RESOLVED → REOPENED
Keywords: topcrash
Resolution: DUPLICATE → ---
Summary: crash in [@ nsExternalHelperAppService::GetTypeFromFile] → M091 topcrash in [@ nsExternalHelperAppService::GetTypeFromFile]
This looks like the topcrasher I fixed post 0.9.1.
marking as fixed.  Please verify that there isn't a sc that looks like this post
0.9.1 + ~3 days.
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Marking verified, this stack trace is not showing up in the trunk analysis.
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsExternalHelperAppService::GetTypeFromFile]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: