Closed
Bug 1135772
Opened 9 years ago
Closed 9 years ago
Null out the return value on error in QI in nsXPCWrappedJS
Categories
(Core :: XPConnect, defect)
Core
XPConnect
Tracking
()
RESOLVED
FIXED
mozilla39
Tracking | Status | |
---|---|---|
firefox39 | --- | fixed |
People
(Reporter: mccr8, Assigned: mccr8)
Details
Attachments
(1 file)
1.73 KB,
patch
|
smaug
:
review+
|
Details | Diff | Splinter Review |
From bug 723248: (In reply to David :Bienvenu from comment #12) > I did a quick look through the mailnews and mozilla code, and the mailnews > code is all OK (once I fixed nsMsgDatabase.cpp) and almost all the mozilla > code looks fine, though there are a few suspicious things: > > nsXPCWrappedJS::QueryInterface return an error without nulling the out param > if !isValid(). > > AudioSession::QueryInterface() fails to null the out param on error. > > same for ReadbackManagerD3D10::QueryInterface and > COMMessageFilter::QueryInterface > > nsXTFElementWrapper::QueryInterface is a little suspicious
Assignee | ||
Comment 1•9 years ago
|
||
AudioSession and COMMessageFilter look like they are not XPCOM classes, so I will leave them alone. I'm guessing they are regular Windows COM classes. ReadbackManagerD3D10 does not seem to exist, but I assume it was similar. nsXTFElementWrapper seems to not exist any more, so maybe this can just be about the nsXPCWrappedJS QI.
Assignee | ||
Updated•9 years ago
|
Component: General → XPConnect
Summary: Null out the return value on error in QI in more places → Null out the return value on error in QI in nsXPCWrappedJS
Assignee | ||
Comment 2•9 years ago
|
||
try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=22b490430a79 This is in XPConnect, but just some QI changes, so maybe you can review.
Attachment #8568241 -
Flags: review?(bugs)
Comment 3•9 years ago
|
||
Comment on attachment 8568241 [details] [diff] [review] Return null on failure in nsXPCWrappedJS's QueryInterface. > nsXPCWrappedJS::QueryInterface(REFNSIID aIID, void** aInstancePtr) > { >+ *aInstancePtr = nullptr; >+ > if (nullptr == aInstancePtr) { >- NS_PRECONDITION(0, "null pointer"); >+ NS_PRECONDITION(false, "null pointer"); > return NS_ERROR_NULL_POINTER; > } if (nullptr == aInstancePtr) { makes now no sense. So, move *aInstancePtr = nullptr; after the 'if' check or perhaps just remove the 'if'
Attachment #8568241 -
Flags: review?(bugs) → review+
Assignee | ||
Comment 4•9 years ago
|
||
Good point. For some reason I failed to realize that was the return value. I just moved it later to avoid possibly triggering a null deref in some random place. https://hg.mozilla.org/integration/mozilla-inbound/rev/448d1795215f
https://hg.mozilla.org/mozilla-central/rev/448d1795215f
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox39:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in
before you can comment on or make changes to this bug.
Description
•