nsIMIMEService.getTypeFromURI(null) crashes [@ nsExternalHelperAppService::GetTypeFromURI(nsIURI*, nsACString_internal&) ]

RESOLVED FIXED in mozilla6

Status

Core Graveyard
File Handling
--
critical
RESOLVED FIXED
6 years ago
10 months ago

People

(Reporter: Dave Garrett, Assigned: timeless)

Tracking

({crash})

Trunk
mozilla6
crash

Firefox Tracking Flags

(status2.0 ?, status1.9.2 ?, status1.9.1 ?)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
I stumbled across this when attempting to write drag & drop support for a file.

Easy test: execute this in the Error Console for an crash:
Components.classes["@mozilla.org/mime;1"].getService(Components.interfaces.nsIMIMEService).getTypeFromURI(null);

3.6.13 on Windows:  bp-3cc36a71-f34d-4ebe-ac6f-b7d502110210
3.6.13 on Linux:    bp-29bd2e99-cddc-43c0-81fe-7a50d2110210
4.0b12pre on Linux: bp-915d00df-c282-42b0-a675-92edb2110210

http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/0c159bd1d600/uriloader/exthandler/nsExternalHelperAppService.cpp#l2693

Looks like it just needs a null check for aURI up top.
(Reporter)

Comment 1

6 years ago
getTypeFromFile also crashes -> filed bug 633240
Keywords: crash
(Reporter)

Updated

6 years ago
Component: General → File Handling
QA Contact: general → file-handling
(Reporter)

Comment 2

6 years ago
Not a candidate for blocking, as far as I can tell. It's been this way since at least Firefox 3.0 and I don't see a way to get at this from the web, though if anyone else does please say so. Requesting wanted+ for all affected branches.
status1.9.1: --- → ?
status1.9.2: --- → ?
status2.0: --- → ?
(Assignee)

Comment 3

6 years ago
Created attachment 515545 [details] [diff] [review]
patch
Assignee: nobody → timeless
Status: NEW → ASSIGNED
Attachment #515545 - Flags: review?(cbiesinger)
Attachment #515545 - Flags: review?(cbiesinger) → review+
(Reporter)

Comment 4

6 years ago
These two crash bugs (bug 633232 & bug 633240) have reviewed one-line patches. Any reason they can't land now? They should at least be able to land on Trunk at this point, I would think. Could they also make Firefox 4.0.1 too?
(Assignee)

Updated

6 years ago
Keywords: checkin-needed
http://hg.mozilla.org/mozilla-central/rev/42768e2b3a4c
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
Crash Signature: [@ nsExternalHelperAppService::GetTypeFromURI(nsIURI*, nsACString_internal&) ]

Comment 6

6 years ago
How can this be tested?
thanks.
(Reporter)

Comment 7

6 years ago
(In reply to comment #6)
> How can this be tested?

These two bugs (bug 633232 & bug 633240) both have the necessary one line tests in their descriptions. Just run that one line anywhere with chrome privileges. The lazy test is to dump it into the Error Console code evaluation field, but a proper test could be written to run it if desired. When either is run on anything prior to the fix landing in Gecko 6 it crashes and with the fix it throws an invalid pointer exception as one would expect.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.