On (2013年02月25日 18:54), Neil wrote: > ISHIKAWA, Chiaki wrote: > >> So the problem is in the interface between XPCOM and JavaScript. Or that >> the routine on the other side of XPCOM forgets to return a valid value and >> instead leaves uninitialized memory in the data passed to the interface. >> Ugh, really hard bug to debug :-( > > I agree, this sounds like the most likely reason. > >> If anyone has a good idea how to debug this further BEYOND this XPCOM >> interface, I will appreciate it very much. >> [This is why I wanted to know WHAT JS file, what line, etc., the >> JavaScript interpreter is calling, etc. Maybe this time, we need to learn >> WHAT SERVICE is invoked using XPCOM interface? > > Normally I would suggest calling DumpJSStack() but that goes to > Thunderbird's output, not gdb's, so you would need to have a way of > capturing that. >
Thank for the suggestion of DumpJSStack(). I will investigate where the output of DumpJSStack() goes in the case of thunderbird. (Debug console, or the terminal emulator where TB is invoked, etc.) By the way, does looking at IDL header/declaration files help me to figure out where the double is returned? (To be honest, I am not sure if the data tag that suggests the returned value is double is not corrupted or not, but I would assume XPCOM, and RPC in general, tends to have the data type statically determined at the time of compilation (or invocation) and not depend on the blob data stream returned by the remote side. So I assume data type is double, and then maybe I can find out what type of call is made in the JavaScript side.) I will register the previous post in bugzilla in edited form. (It was too lengthy to make it through the newsgroup-to-maillist gateway, it seems.) Thank you again. Chiaki _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
