dp: I found this nasty bug tonight that was causing me to die in purify (both viewer and apprunner). What was happening was the NSGetFactory function in view/src/nsViewFactory.cpp wasn't initializing rv, and ended up returning 0xdeadbeef when run under purify. This caused the component registration code to think the NSGetFactory had failed. Here's where the real fun began... nsNativeComponentLoader::GetFactory got the error back from GetFactoryFromNSGetFactory (line 149) and then proceeded to delete the dll object (line 168) causing the actual DLL to get unloaded. This DLL housed the methods of mViewManager in DocumentViewerImpl (layout/base/src/nsDocumentViewer.cpp) whose code was in the call stack. This code went on to invoke a method on mViewManager (PresShell::Init(nsIDocument *,nsIPresContext *,nsIViewManager *,nsIStyleSet *) [nsPresShell.cpp:525]) whose DLL was unloaded, which caused an exception that purify then choaked on. This caused main to be executed again which ended up running NS_InitXPCOM again and finally dying because servMgr was null!
Very very impressive sleuthing! Scary behavior too! However, it's not clear we can do a darn thing about it. It might make sense that we have a little program that tests the factory's in each component and makes sure that they all succeed?
mmh! I think we can do something kipp. raptorview.so is linked into app and is hosting components. It is registered as "CID blah is in this lib" nsRegisterComponentLib: If we instead switch it over to nsRegisterFactory() and statically create the factory by calling a new method say NS_ViewGetFactory(), then xpcom wont be required to do a load and unload of this library. What do you think ?
Upping priority on this.
Umm, if the viewmanager is both linked into the app AND hosting components, then that should be fixed, don't you think?
Yes absolutely. That is the case with a few dlls. (remember I was talking to you about what you though the impact of these was and we just didn't know). Options would be: 1. make the dll a component and move it to components directory. This would mean the link to the dll would have to be removed. I think that would be a challenge. 2. remove the registrations of component from the dll and make them as factory registrations. This is more quantified and we can do this. I am going to fix this with (2) unless the owner sez they are in the process of making it a component (like ramiro has said htmlpars will be a component).
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Raptor view is a component now.
warren, can you help us verify this bug? If you agree the resolution is correct, please mark it as Verified. Thanks.
You need to log in before you can comment on or make changes to this bug.