Closed Bug 797510 Opened 8 years ago Closed 8 years ago

###!!! ASSERTION: hmm? CanCallNow failed in XPCWrappedNative::CallMethod.

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed)

RESOLVED FIXED
blocking-basecamp +
Tracking Status
firefox18 --- fixed
firefox19 --- fixed

People

(Reporter: gwagner, Assigned: schien)

References

Details

Attachments

(1 file)

During b2g startup:

###!!! ASSERTION: hmm? CanCallNow failed in XPCWrappedNative::CallMethod. We are finding out about this late!: 'rv == NS_ERROR_XPC_SECURITY_MANAGER_VETO', file /Users/idefix2/code/gaia/isrc/js/xpconnect/src/XPCWrappedNative.cpp, line 2367
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component does not have requested interface [nsISettingsServiceCallback.handle]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "JS frame :: jar:file:///system/b2g/omni.ja!/components/SettingsService.js :: <TOP_LEVEL> :: line 87"  data: no]
************************************************************
This issue is also mentioned in bug 626893, bug 604312, and bug 490984. I don't know enough about the underlying XPConnect code to comment on root causes or set dups, but I was getting killed by this and I think I know how to fix it in the calling code.

I started getting this error when I modified some code in my complex binary Thunderbird extension so that a javascript driver routine for XHR actions was converted from a model of simple listener callbacks, to one where the callbacks are managed by a js generator implementing an async framework. So at least in my case the problem might be related to use of generators.

But I found that the callbacks methods where the error was occurring were missing QueryInterface results for the requested interface (one had no QI, the other had a QI but did not list the needed interface).

When I added correct QIs in the javascript methods, the problem went away (or so I hope, it is intermittent only occurring about 25% of the time).
I'll take a look at this bug.
Assignee: nobody → schien
DOMFMRadioParent doesn't provide correct QueryInterface, therefore, XPConnect cannot determine whether callback object has |handle| method or not.
I found DOMFMRadioParent registers itself as a nsISettinsServiceCallback and a nsIObserver, so we need to declare both interfaces in QI.
Attachment #669879 - Flags: review?(justin.lebar+bug)
Attachment #669879 - Flags: feedback?(pzhang)
Comment on attachment 669879 [details] [diff] [review]
Bug 797510 - add QI for DOMFMRadioParent

Sure!
Attachment #669879 - Flags: review?(justin.lebar+bug) → review+
https://hg.mozilla.org/mozilla-central/rev/887b293a2fd3
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
blocking-basecamp: --- → ?
blocking-basecamp: ? → +
edmorley, do you have guidance as to whether I should be setting status-firefox19 to fixed as well?
Only if security, or else tracking+ on trunk, aiui.
Duplicate of this bug: 794422
Attachment #669879 - Flags: feedback?(pzhang)
You need to log in before you can comment on or make changes to this bug.