23018 - "xpcom.dll" reports invalid entry point when starting browser

Status: VERIFIED INVALID

(Core :: XPCOM, defect, P3)

Description

[herrig]

When launching mozilla, "xpcom.dll" reports an invalid entry point when called
by "necko_keyword.dll" and "pics.dll".

I'm using Win NT 4.0 with Service Pack 5

Later! - T

Comment 1

[John Morrison]

[e-mail] : can you elaborate a bit on the specific messages, steps
to reproduce, what build of Mozilla (date) you are running, a  Dr. Watson stack
trace if you have one, etc. Otherwise, this is impossible to reproduce (and
therefore not much can be done). Just add your comments to this bug report.
Thanks a lot!

Comment 2

[herrig]

As requested:

Here's what the dialog boxes say when trying to access "xpcom.dll":

"The procedure entry point ??RnsCreateInstance@@UBEIABUnsID@@PAPAX@Z could not
be located in the dynamic link library xpcom.dll"

And again:

"The procedure entry point ??0nsString@@QAE@PBG@Z could not be located in the
dynamic link library xpcom.dll"

I'm using build ID 2000010308 (the build from last night) but this problem also
occured using the M12 release. The browser continues to load after these error
messages occur.

Later! - T

Comment 3

[John Morrison]

[e-mail] : The browser actually runs after these messages?

 Also, in your first message : '"xpcom.dll" reports an invalid entry point when
called by "necko_keyword.dll" and "pics.dll".' -- were necko_keyword and pics
part of the error message dialog? As in 'called from ...'. (I assume yes, but
want to be sure).

Thanks again.

Comment 4

[herrig]

Yup. True statements. When the dialogs pop up with the invalid entry point
messages, I see at the command prompt that "necko_keyword.dll" and "pics.dll"
failed to do something. Here's what I see from the command console:

**************************************************
nsNativeComponentLoader: SelfRegisterDll(F:\mozilla\bin\components\necko_keyword
.dll) Load FAILED with error: error 0
**************************************************
**************************************************
nsNativeComponentLoader: SelfRegisterDll(F:\mozilla\bin\components\pics.dll) Loa
d FAILED with error: error 0
**************************************************
nNCL: registering deferred (0)
WEBSHELL+ = 1
...
...
...

and so on.

Hope this helps! - T

Comment 5

[John Morrison]

Thanks [e-mail]. Passing this on to dp/XPCOM where the
nsNativeComponentLoader knowledge is ...

Comment 6

[Suresh Duddi (gone)]

mmh! wierd. The browser should fail miserably and mozilla shouldn't even execute
if a dll entry point cannot be found.

Dan, can you help with your windows expertise here on possible cause.

Comment 7

[John Morrison]

dp -- what happens if auto-registration finds obsolete (old) DLLs
in ./components?

I just had a look, and there are no necko_keyword.dll and pics.dll files in the
M12 .zip or in yesterdays builds either. I believe necko_keyword.dll is now
nkkeyword.dll (although I can't, in a quick look, find where the pics
components are). Hmm ...

Comment 8

[Daniel Veditz [:dveditz]]

What is happening is that XPCOM wants to register a new component, tries to
load it which fails because the OS can't match the required imports. This won't
kill mozilla itself because we are loading components dynamically.

I have also seen this when you install an optimized component into a debug
build. The root cause is fragile C++ (non-XPCOM) linkage to helper classes in
libxpcom, things like nsCRT, nsString, etc.  The mangled C++ names are
compiler-specific, possibly debug-vs-optimized specific, and of course we
change the classes which will break things at load time rather than causing a
crash when an interface changes. (interfaces eventually will not--should not,
anyway--change so this problem should be avoidable for XPCOM interfaces. No
such luck for raw C++, the reason for COM in the first place of course.)

That said, I have no idea why [e-mail] is having this problem. I'd
recommend deleting the offending components and rebuilding. Perhaps a
dependency was missed, perhaps those are old components that aren't used
anymore. In fact, I do not have either of those .dlls on a recent clobber
build. pics appears gone, and the other is now nkkeyword.dll

I'm going to mark this invalid based on the .dll names. If this happens with
other libraries let us know.  Even on depend builds I recommend regularly
blowing away the dist/../bin and dist/../lib directories to eliminate old
cruft.  Be careful of blowing away any dist include directories or you will
trigger a full rebuild, though a periodic full clobber build is not a bad idea
from time to time.

Comment 9

[John Morrison]

So [e-mail] : try deleting pics.dll and necko_keyword.dll from
your ./components directory, and starting Mozilla. If this eliminates the
error messages, could you please marked this bug as VERIFIED. Thanks.

Comment 10

[Suresh Duddi (gone)]

I would even say, delete your install directory and do a fresh install.

Comment 11

[John Morrison]

Yes, you should delete the install directory and do a fresh install (for the
variety of reasons dp noted above). However, I was kind of curious if just
nuking these two, apparently obsolete dlls is sufficient to resolve this
specific case (i.e., for future reference, when people get these errors, but
can run the browser (which puzzled me), then check the reported dlls -- are
they current or leftover cruft). Thanks.

Comment 12

[herrig]

Yup. Nuked the install, and unzipped fresh stuff, and that cured the problem.

Thanks again! - T

Comment 13

[John Morrison]

Thanks [e-mail]. Since [e-mail] is QA, I'll mark this
as VERIFIED.