330912 - Failure to load and recognize properly multiple dlls extension

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Jacek]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Properly created and installed native XPCOM extension works only if consists of single dll module. Multi dll extensions when installed in typical extension directory tree fail to be recognised properly by extension manager (do not show up in compreg.dat). When forced to be recognized (i.e. by providing identical single dll without dependecies on any other custom dlls) extension does not work when called. Call to nsIJSCID.CreateInstance for given extension CID fails with error 0x80570015.

Workaround is to install dlls on which main extension module depends into well known locations searched during dll loading i.e. directory from which executable loaded, system directory. Symptoms and workaround indicate that extension loading logic is flawed. Instead of providing mechanism for extension encapsulation through containment in single installation point, the real requirement is to install multi dlls extensions into privileged places available for users with admin privileges only. Very simple solution to the problem would be to use SetDllDirectory (Win XP SP 1 and 2003 or later) or to add PATH variable pointing to extension directory (older systems).



Reproducible: Always

Steps to Reproduce:
1. Create mutli dll native extension
2. Install on the system 
3. Componenet is not recognized and does not appear in compreg.dat

4. Create single dll native extension with identical interface
5. Install on the system
6. Component is recognized and appears in compreg.dat
7. Replace single dll with multi dll extension in installation directory
8. Try creating object using JavaScript
9. Call to nsIJSCID.CreateInstance for given extension CID fails with error 0x80570015

10. Copy dependecies to the main extension module into well known locations
11. Call from JavaScript is successfull.

Actual Results:  
Reproducible errors as above.

Expected Results:  
Successfull loading of all extension modules from extesnion directory tree.

The real problem is that extension modular design is an only reasonable decision when multiple browsers are to be supported with different extension technologies  (XPCOM and COM). Main extension functionality is located in common module and communication interfaces are in separate browser specific modules. Obviously worker module can be installed into well known directory, and even it should happen if many browsers are to be supported at the same time, but this situation would anyway require use of installation technologies other than XPInstall. In case of single browser support an XPInstall installation will not be sufficient.

Comment 1

[:Mook]

For a workaround, please refer to devmo article:
http://developer.mozilla.org/en/docs/Using_Dependent_Libraries_In_Extension_Components

Please see bug 254732 comment 6 too.  I haven't managed to convince him yet ;)

Comment 2

[Jacek]

(In reply to comment #1)
> For a workaround, please refer to devmo article:
> http://developer.mozilla.org/en/docs/Using_Dependent_Libraries_In_Extension_Components

Unfortunately, what it is propesed there is to use dependancy resolution by hand what I find to be of dubious value for any even moderately complex solution. Operating systems have built in functionality to do that for us so no need to hard code it by hand. Just small change to extensions loading logic
would suffice here.

Comment 3

[Benjamin Smedberg]

I'm not sure I understand what you actually want. The SetDllDirectory function doesn't allow you to specify a set of directories (AFAICT). WinXP assembly resolution can be made to work using probing locations. We don't want to munge the PATH (and that doesn't work on linux/mac anyway).

Comment 4

[Jacek]

(In reply to comment #3)
Actually I am asking only to set new library search path during loading of a given extension providing as one of the solutions call to SetDllDirectory.

Here is a msdn description of SetDllDirectory behaviour.

"The SetDllDirectory function affects all subsequent calls to the LoadLibrary and LoadLibraryEx functions. After calling SetDllDirectory, the DLL search path is:

The directory from which the application loaded. 
The directory specified by the lpPathName parameter (.. passed to SetDllDirectory ..). 
The system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is System32. 
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System. 
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory. 
The directories that are listed in the PATH environment variable. 

To revert to the default search path used by LoadLibrary and LoadLibraryEx, call SetDllDirectory with NULL."

My understing of mozilla extension loading process is rather limited (have not studied the code) but I suppose that before main extension module would be loaded the call to SetDllDirectory indicating extension installation directory would be sufficient to solve the problem.

I do not find anything sacred in environment settings to abstain from using it as a tool to improve application. Obviously manipulating environment variables is limited in its effect to a running process and would suffice as well. 

I am neither linux nor mac guru, however, to my knowledge there is a plenty of methods to alter shared libraries search patterns on these systems.

Stub which you have written is a good workaround for project with very few direct and indirect dependencies but is absolutely a nightmare solution to larger projects - have you ever tried to figure out by hand dependency tree of a medium sized project - as an example try using DirectX and .NET in your extension (it's real life project). Firefox loads roughly 50 modules while working with common web pages, medium sized extension may load next 20 to 30 modules.

In case of my projects I have no problem with current mozilla behaviour since my applications are rolled out using an msi installer which is capable to install everywhere and they use their own updating system. So I am totally independent of XPInstall limitations.

Comment 5

[Benjamin Smedberg]

You can't install a "local" directx or .net, and that's way outside the scope of an XPI-shipped extension anyway. The use of SetDllDirectory is a platform-specific hack which I don't wnt to promote.