Closed
Bug 84104
Opened 23 years ago
Closed 23 years ago
M091 topcrash in [@ nsExternalHelperAppService::GetTypeFromFile]
Categories
(Core :: Networking: File, defect)
Tracking
()
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: jband_mozilla, Assigned: dougt)
Details
(Keywords: crash, topcrash)
Crash Data
Attachments
(1 file)
486 bytes,
text/plain
|
Details |
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.
Reporter | ||
Comment 1•23 years ago
|
||
-->dougt
Assignee: neeti → dougt
Component: Networking → Networking: File
QA Contact: benc → tever
Assignee | ||
Comment 3•23 years ago
|
||
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...
Assignee | ||
Comment 4•23 years ago
|
||
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]
Comment 6•23 years ago
|
||
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]
Assignee | ||
Comment 7•23 years ago
|
||
This looks like the topcrasher I fixed post 0.9.1.
Assignee | ||
Comment 8•23 years ago
|
||
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 ago → 23 years ago
Resolution: --- → FIXED
Comment 9•23 years ago
|
||
Marking verified, this stack trace is not showing up in the trunk analysis.
Status: RESOLVED → VERIFIED
Updated•13 years ago
|
Crash Signature: [@ nsExternalHelperAppService::GetTypeFromFile]
You need to log in
before you can comment on or make changes to this bug.
Description
•