John.
Ulrich von Zadow wrote:
John Bandhauer wrote:
Well, I'm still not seeing why you should run into this problem.
Thanks again for your help. Your examples - especially the xpc_noisy class - were really helpful in figuring out what was going on.
It looks like we've found the problem. It turns out that xpconnect and js were both working as expected, but I'm skipping ahead...
First a few facts that might be important. We *think* they were not the cause of the problem:
- We build the Mozilla 1.4 Release Source Tree with gcc 3.3 on an out-of-the-box SuSE 8.2 distribution, with all settings to default, except DEBUG off
- We used a slightly modified Mozilla 1.4 Release Source Tree to compile under Visual Studio .NET 2003 with all settings to default, except /Z7 to get embedded debug symbols
- We use our own build environment to build our components outside the mozilla tree, using only includes and libs from the dist tree
- We patched xpctest_calljs.cpp and included all required xpctest_* files to build them outside the tree, and changed UUIDs and class names to avoid conflicts with original xpctest_* components
- We used the xpctest_noisy – object to track refcounf changes in both the example you provided as well as wrapping it with our code
We observed the following behaviour:
- *Everything* works as expected with our Linux–NonDebug Build, both our own code as well as your examples
- With our Windows Debug-build, both our own code as well as your examples showed the leakage behaviour
We did not verify the behaviour with a Linux-Debug build or a Windows-Non-Debug build yet, but we think that possibly *every* Mozilla Debug-build will potentially show this behaviour.
What happens is almost too simple and too incredible to believe it: Depending on some #define-settings, nsCOMPtr will have a destructor that does not make any calls to Release() when it is destroyed. In Debug builds, NSCAP_FEATURE_DEBUG_PTR_TYPES is set by default. After some pre-processor magic, the empty destructor in http://lxr.mozilla.org/seamonkey/source/xpcom/glue/nsCOMPtr.h#402 gets compiled while compiling xpcom, and somehow it gets silently used by some components. Other messages in n.p.m.* lead us to believe that this function is there to prevent unresolved externals. Is is supposed to be called at all? What was supposed to prevent it from being called (as opposed to being linked)?
We solved the problem for us by commenting out #define NSCAP_FEATURE_DEBUG_PTR_TYPES in http://lxr.mozilla.org/seamonkey/source/xpcom/glue/nsCOMPtr.h#96 ,
but we are not sure yet how we could run into it, and whether we built and used xpcom in a way it shouldn’t have been, or whether just every DEBUG build will suffer this problem.
Now - we're guessing that there's something different about our compile settings that causes this to happen, and we'd like to know what it is. In any case, our feeling is that a smart pointer destructor such as this one laying around is a bit like an unlocked, loaded gun in your pocket, ready to shoot you in the foot any time you move.
Again, thank you very much for you immediate and helpful response. At least this problem gave us the opportunity to dive deeper into the workings of the SpiderMonkey and XPConnect. We have rarely seen examples for such beautiful C-Code like in SpiderMonkey, and the Mozilla platform is very important and a useful foundation for our cross-platform development.
Thank You
Pavel Mayer (pavel<at>artcom<dot>de)
Ulrich Zadow
PS: Without the intention of decrying hard and great work, in our opinion nsCOMPtr seems to be an huge trouble spot because it has some basic flaws. It can fail under a large number of circumstances, and the convenience of allowing to mix raw pointers and smart pointers in expressions always calls for trouble, but again, no offense intended.
_______________________________________________ Mozilla-xpcom mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-xpcom
