(2013/03/01 11:10), ISHIKAWA, Chiaki wrote:
(2013/02/27 22:35), ISHIKAWA, Chiaki wrote:
(2013/02/27 0:53), Neil wrote:
ishikawa wrote:
By the way, does looking at IDL header/declaration files help me to figure out
where the double is returned?
You would have to peek in the locals on the stack to find out exactly
which interface is being called. I don't know how to do this.
I must be doing something wrong.
But at link time, I got the missing symbol for DumpJSStack.
Thinking that the C symbol was incorrectly accessed in mangled form,
I added the C extern declation for it, and
still no luck.
Do I have to enable some compile time magic
in MOZCONFIG to make DumpJSStack avaiable to Thunderbird?
(Wait, is it possible that DumpJSStack is available only in
Firefox?)
TIA
The link problem was solved. I should have not tried to call DumpJSStack() from
within Value.h.
Reason of the failure:
I tried to call DumpJSStack() when the error occurred, but my
declaration of DumpJSStack() near the beginning of Value.h as below
backfired.
extern "C" {
void DumpJSStack(void);
}
I forgot that Value.h is also included (indirectly) by
nsXPConnect.cpp where DumpJSStack() is defined.
After macro expansion, DumpJSStack() is declared
as folows.
__attribute__((visibility("default"))) void DumpJSStack()
{
[...]
}
g++ compiler complained about the mismatch of visibility attributes,
and it seemd g++ basically ignored the visibility and thus hide the
symbol (i.e., not export the DumpJSStack symbol.)
/TB-NEW/TB-3HG/new-src/mozilla/js/xpconnect/src/nsXPConnect.cpp: In function
‘void DumpJSStack()’:
/TB-NEW/TB-3HG/new-src/mozilla/js/xpconnect/src/nsXPConnect.cpp:2708:45:
warning: ‘void DumpJSStack()’: visibility
attribute ignored because it [-Wattributes]
In file included from ../../../dist/include/js/PropertyKey.h:15:0,
from ../../../dist/include/jsapi.h:32,
from
/TB-NEW/TB-3HG/new-src/mozilla/js/xpconnect/src/xpcpublic.h:11,
from
/TB-NEW/TB-3HG/new-src/mozilla/js/xpconnect/src/xpcprivate.h:98,
from
/TB-NEW/TB-3HG/new-src/mozilla/js/xpconnect/src/nsXPConnect.cpp:14:
../../../dist/include/js/Value.h:28:6: warning: conflicts with previous
declaration here [-Wattributes]
More reason to reduce the warning during compilation of TB:
[META] Fix compiler 'Build Warnings'
https://bugzilla.mozilla.org/show_bug.cgi?id=187528
I failed to notice the compiler warning until
I found libxul.so contained PrintJSStack,
DumpJSEval, and DumpCompleteHeap which are declared right next to
DumpJSStack, but not the DumpJSStack itself, then I checked the compilation
of preprocessed nsXPConnect.cpp and found the issue.
So after simply removing the conflicting declation and giving up to
call DumpJSStack in the code itself, I tried call DumpJSStack() from gdb when
valgrind/memcheck offered to let me connect to the process with gdb,
But no luck (?)
TB trapped calling abort, and "make mozmill" framework offered to
let me connect to the process, and I connected with gdb.
(gdb) where
#0 0x380ff84c in ?? ()
#1 0x08b3189f in ah_crap_handler (signum=11)
at /TB-NEW/TB-3HG/new-src/mozilla/toolkit/xre/nsSigHandlers.cpp:88
#2 0x08b3d48f in nsProfileLock::FatalSignalHandler (signo=11,
info=0xbe96f730, context=0xbe96f7b0)
at /TB-NEW/TB-3HG/objdir-tb3/mozilla/toolkit/profile/nsProfileLock.cpp:190
#3 <signal handler called>
#4 0x09e2988b in DOUBLE_TO_JSVAL (d=-6.510615555426901e+18)
at ../../../dist/include/js/Value.h:1720
#5 XPCConvert::NativeData2JS (lccx=..., d=0xbe970068, s=0xbe970240,
type=..., iid=0xbe970094, pErr=0xbe970064)
at /TB-NEW/TB-3HG/new-src/mozilla/js/xpconnect/src/XPCConvert.cpp:105
#6 0x09e65e15 in NativeData2JS (pErr=0xbe970064, iid=0xbe970094, type=...
[...]
Issueing "up" a few times.
(gdb) list
1715 */
1716 jsval_layout l;
1717
1718 if ( VALGRIND_CHECK_MEM_IS_DEFINED(&d, sizeof(d)) != 0 )
1719 {
1720 MOZ_ASSERT(0);
1721 }
1722
1723 if (MOZ_UNLIKELY(d != d))
1724 l.asBits = 0x7FF8000000000000LL;
(gdb) call DumpJSStack()
Cannot find user-level thread for LWP 1936: generic error
An error occurred while in a function called from GDB.
Evaluation of the expression containing the function
(DumpJSStack()) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) t
[Current thread is 1 (Thread 0x42fd1c0 (LWP 1936))]
Well, the user-level thread 1936 is the one we are looking at, isn't it(?).
Maybe trapping modified the stack or something, and postmortem debugging
does not allow calling DumpJSStack()
(Maybe I should call a dummy routine and set breakpoint on that function
in advance instead of relying on abort and "make mozmill" test framework.)
Still investigating.
Again, any hints for debugging the data flow between XPCOM -> JavaScript
(and figuring out what service returns uninitizlied 8 octet,
i.e. double in an easy manner) will be appreciated.
TIA
We are making a real progress on this bug thanks to Neil's offline suggestion.
Those who are interested can check the latest post to
Bug 845187 - JavaScript interpreter encounters an uninitialized
memory from XPCOM interface (thunderbird)
TIA
(I am testing a patch right now. The result will be in by tomorrow.)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
