14130 - DLLs unloaded prematurely (aka xpcom trapeze act!)

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P2)

Description

[Warren Harris]

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!

Comment 1

[kipp]

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?

Comment 2

[Suresh Duddi (gone)]

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 ?

Comment 3

[Suresh Duddi (gone)]

Upping priority on this.

Comment 4

[kipp]

Umm, if the viewmanager is both linked into the app AND hosting components, then
that should be fixed, don't you think?

Comment 5

[Suresh Duddi (gone)]

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).

Comment 6

[Suresh Duddi (gone)]

Raptor view is a component now.

Comment 7

[gerardok]

warren, can you help us verify this bug? If you agree the resolution is correct,
please mark it as Verified. Thanks.