WTC, I agree, that wasn't really clear. It sounded like it may have been because of the way the shared library was being loaded using dlopen(); the problem report said: "We were having a problem with name collisions, so use RTLD_NOW|RTLD_GROUPT as the mode parameter to dlopen()." Does that make sense to you?
-- POC "Wan-Teh Chang" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]... > POC wrote: > > The original problem is at > > http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=aiud hj%24k041%40ripley.netscape.com&prev=/groups%3Fdq%3D%26num%3D25%26hl%3Den%26 lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26group%3Dnetscape.public.mozilla.crypto%26s tart%3D150 > > > > In a nutshell, the user's shared lib was crashing the program when it > > attempted to load an NSS shared lib in the process memory using > > dlopen(). From reading the article, it sounded like the calling > > process environment (pointed to by char **environ) needs to always be > > *not NULL* otherwise when NSS_init is called, which then calls > > RNG_SystemInfoForRNG(), a crash could result... > > > > Shouldn't NSS check for situations when the calling process' > > environment is null? > > We could do that. But I want to know how the calling > process's environment could be null in the first place. > > Wan-Teh >
