Another thing to look at is the possibility that the interface description in the idl/h file is out of sync with the description that is being loaded from the xpt file at runtime. This can certainly happen if you use the idl compiler manually and experiment with different method signatures. Also, you have of course generated a unique uuid for your interface.
You don't show the JS code you are using to call that interface. But, if the JS code is passing anything other than a string for the first param and an object for the second param then you likely have such an xpt mismatch. If xpconnect correctly knows about the target interface (i.e. the xpt info loaded matches the idl sig you show) then it would not pass through any call whose second param was not a JSObject given that sig.
It is possible to puzzle through the xpti.dat in your components directory to see if it is referencing the .xpt file you expect. And you could use xpt_dump on your .xpt file to see that it has a sig that matches your idl file.
You should certainly sort this problem out before changing the sig, but FWIW, the more usable way to return a value in an interface method is to do something like:
string bar(in string one);
or even
void bar(in string one, [retval] out string two);
In both cases the C++ sig of the method will be identical to what you already have, but the JS caller can use a much more natural call style of:
var output = foo.bar("input")
Hope this helps.
John.
J. Michael Caine wrote:
NS_IMETHODIMP Foo::Bar(const char *one, char **two)The problem here, narrowed down a bit, is that the second arg is coming in with a value of 0x01 - certainly not a valid memory address. Any ideas about how it could have been set to this value by the JS interpreter or XPConnect or whomever?
