Nelson B Bolyard wrote:
On 2010-02-19 00:01 PST, Marty <n...@comcast.martyamodeo> wrote:
For anyone who might have cared, it looks like this is a case of missing
some of the Firefox DLLs from my program's search path. It looks
(behavior-wise... haven't checked the code) like the OS/2-specific code
for the dynamic loader in SECMOD_AddNewModule is not checking its return
codes for failure to locate needed subsequent DLLs, and I get a GPF
instead of a more informative message about not being able to find the
needed module.
Once I copied all of the needed DLLs, my app now starts up every time,
regardless of whether or not Firefox is running.
Just out of curiosity, why did having Firefox running have any impact on
other processes' ability to use/find DLLs?
Is it the case that, in OS/2, all processes share a common pool of loaded
DLLs? When one process loads a DLL, does that DLL then become available to
all the other running processes? Does that DLL then get used in place of
other DLLs with the same name when other processes attempt to load a DLL by
the same name?
Not quite, but the effect is the same. The OS first checks if it has
already loaded a given DLL, and if so, just maps some local process
addresses to the existing paging area of the DLL (to be physically
loaded from disk on demand). If the DLL has not been allotted any
paging area, then it is assigned one and this area is mapped back in the
requesting process' local address space.
There is a workaround where a user or program can tell the loader to
always load a unique copy of a DLL, to avoid conflicts with differing
versions of a DLL with the same name.
So in this case, the NSSCKBI DLL loaded successfully as a "new" DLL in
my process, but it dynamically loads several DLLs itself, and one or
more of these could not be located (because they were not in my LIBPATH
and were not in the current directory) and wasn't already loaded.
Somebody did not check for failure to load these DLLs and this caused a
general protection fault (probably by calling a pointer to a function
which has not been supplied by the requested DLL). When Firefox was
running, all of these DLLs were loaded, so it didn't need to search for
the DLL file itself in order to use it.
--
[Reverse the parts of the e-mail address to reply.]
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
