71010 - entry point not found (nsInputFileStream/nsLocalString)

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[rsalexan]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.9) Gecko/20010305
BuildID:    2001030505

NSPR:EventReceiver:mozilla.exe - Entry point not found
The procedure entry point ?Recycle@nsString@@SAXPAV1@@Z could not be located on
the dynamic link library xpcom.dll

This occurs every time I start Mozilla. I can 'ok' through this and mozilla then
starts fine.

Reproducible: Always
Steps to Reproduce:
start mozilla by clicking on the quickstart icon

Comment 1

[Fabian Guisset]

Sounds like bug 60791
reassigning to profile manager

Comment 2

[Conrad Carlen (not reading bugmail)]

Sure doesn't sound like profile mgr to me. Back to XPCOM - for lack of a better
place.

Comment 3

[dales]

It appears that my bug report (Bug ID# 75702) is a duplicate of this one, though 
with a slight difference ... 

I only see the "entry point not found" error on first run of an installation and 
do not see it if running from a non-Installer build even on first run.

Dale

Comment 4

[dales]

*** Bug 75702 has been marked as a duplicate of this bug. ***

Comment 5

[dales]

I am running Mozilla Build ID: 2001041704 on WinNT 4 w/ SP5.

I am now encountering the Entry Point Not Found error report when I am in
Bugzilla and I enter a bug ID to find.  The title (as in earlier reports here
and in Bug ID 75702) identifies Mozilla.exe, but the specific error message in
this case mentions a different entry point in xpcom.dll:
 
"Entry point ??0nsInputFileStream@@QAE@ABV0@@Z could not be located in dynamic
link library xpcom.dll."

As in the other cases, dismissing the error dialog lets Mozilla continue
(apparently) with what was requested.

             Dale

Comment 6

[dales]

More on the Entry Point Not Found bug when interacting with Bugzilla forms:

Other form controls, buttons etc., in Bugzilla also trigger the Entry Point Not
Found in xpcom.dll errors. I don't know if all do, but the Commit and Login
buttons do, however the Reset button does not trigger the error.

          Dale

Comment 7

[James Ballantine]

I've been getting the Entry Point not found on startup with the past couple of
nighlty builds, but the entry point is:
   ??0nsInputFileStream@@QAE@ABV0@@Z also in xpcom.dll
I'm running an NT 4 box

Comment 8

[Steve Chapel]

This is the error I get:
    NSPR:EventReceiver: mozilla.exe - Entry Point Not Found
    The procedure entry point ??0nsInputFileStream@@QAE@ABV0@@Z could not be
located in the dynamic link library xpcom.dll

But I get it only the first time start Mozilla after I unzip a new build. I've
noticed this with the last few nightly builds on Windows 2000.

Comment 9

[Phil Peterson]

Confirming. I see this too. Nominating for mozilla 0.9. Can't do a milestone
build with these warning dialogs.

Comment 10

[Edward Kandrot]

*** Bug 76045 has been marked as a duplicate of this bug. ***

Comment 11

[Scott Collins]

I'll bet this is related to the code ordering stuff.  An entry point named by
code-ordering files, but no longer exists?  A symbol that looks like an
out-of-lined |inline| function?  Then it complains at load time?  Perhaps
because the function is no longer out-of-lined?  dprice can probably fix this in
30 seconds or less.

Comment 12

[Phil Peterson]

Please also look at the form submission symptom in bug 76045, if only to make
sure it's really a dup.

Comment 13

[dprice (gone)]

I guess that I don't fully understand the problem.

Are you saying that when the linker re-orders the functions in xpcom.dll it is
picking up some inline functions and moving them to a place where they are no
longer inline?  If that's the case we'd have to tweak trace.dll to ignore inline
functions.  We are currently skipping over any function with a displacement
greater than 0.

When the linker finds a function in the order files that is not in the .obj
files, it throws a warning and ignores it.

I don't see this on Windows 2000 when I run a build from yesterday.  Is it an NT
4 only problem?

CCing waterson and jband, they may have better insights.

Comment 14

[James Ballantine]

as of the 4/19 nightly (bld 2001041804) on an NT 4.0 system,
the error message only appears on the first run of the program 
after I unzip the DL,

Comment 15

[bear_phillips]

I have a Dell Inspiron with Windows 2000 and I see it when submitting forms.  I 
am running the 4/19 build

Comment 16

[chris hofmann]

report from one user shows 
When I run Netscape 6.5 I always get the following error:
Procedure entry point ?Recycle@NString@@SAXPAV1@@Z could not be located in
dynamic link library xpxom.dll
2001042304  I also seen this error msg from previous builds.

putting this on 0.9.1

Comment 17

[Phil Peterson]

0.9.1? Ugh. I get this error every time I submit a form. Isn't there something
we can do for 0.9?

Comment 18

[jap3003]

I used to get: 

(title)NSPR:EventReceiver: mozilla.exe - Entry Point Not Found
(dialog contents)The procedure entry point ??OnsInputFileStream@@QAE@ABV0@@Z
could not be located in the dynamic link library xpcom.dll.  [OK]

on starting every nightly build right after unzipping it (no other times; it
went away after the first start).  After removing the d:\moreapps\moz-nightly
directory tree and unzipping into it afresh back into there, the dialogs
stopped.  I haven't seen it since.  Anyone else want to verify that this is what
caused it to go away?  [NT4, SP6a+]

Since it's a really annoying bug, should we bump it up a couple of severity
levels?  I didn't want to do this since I'm fairly new.

Comment 19

[Randy Slemko]

Yes, I just confirmed this on Win2000. I've been unzipping the nightlies to the
same folder as previous builds (milestones etc.) and experiencing the popups
after each unzip. I deleted the entire directory structure and unzipped again
into a fresh folder with no popups on startup this time.

Comment 20

[Johnny Stenback (:jst)]

Isn't this just due to bad depend builds, or random libraries remaining in the
install directory that are being picked up by the component loader? I've never
seen this with installer installed builds.

Comment 21

[lchiang]

I believe this does happen with installer builds.  I've gotten one report via
email from an AOL employee who ran into this problem with our installed builds.
 This person probably has never had any debug builds on his system.

Comment 22

[u17130]

Same prob on the installer builds.  I only use the installer builds, installing 
over the previous nights installation everyday.  Get the exact same pop up 
error as the non-installer builds.  

Also I would like to note that I do not get this error on launching mozilla, 
either from the start menu / quickstart icon / or desktop... I only get this 
error when I attempt to submit information to a form.

Finally, can we jack the severity up to normal and mozilla .9 .... this is 
probably the most annoying bug and showstopper I have ever seen in 1 year of 
using Mozilla with w2k.  

Comment 23

[dales]

Re: IS it in Installer builds?
 
YES ... I have seen it in every installer build for a long time ... in fact as
of today's experience, I'd say it's been there since the Installer builds on
WinNT 4 have stopped asking if I want to delete the existing directory.
 
Today, like ususal, I did an installer build over the existing directory and
when the program went into its "first run" the unfound entry point error dialog
appeared.
 
I cancelled the run, deleted the existing Mozilla directory from the path
"C:\Program Files\Mozilla.org\Mozilla" and reinstalled.  On this "first run"
there was NO error dialog.
 
I have never seen this on a non-installer build because I have always manually
deleted the existing directory, if there was one.  I have also never seen it on
a Mac build because the Mac installer still asks if you want to delete the
existing directory and does it, like the WinXX installers used to do.
 
Bring back the delete and the problem may be solved.
 
Dale

Comment 24

[jap3003]

I don't know about the rest of you, but I'd really like to know what causes it. 
So we know that the symptoms go away after a delete and re-install.  Is it a
gronky lib that got introduced several builds back and was never overwritten? 
Or maybe it's no longer necessary, but the dependency is in there,
notwithstanding?

Comment 25

[dales]

I am sorry, my "solved" was incorrect ... I should have said "side stepped".
 
I agree, the problem should actually be solved by determing what's causing it
and fixing that so it doesn't come back to bite again.

I am also happy to report that I just downloaded build 2001043004 and did
another on-top-of-existing-installation install.  This time I got no error
dialog on the first run.  I don't know if my deleting the previous directory
cleaned up something that had hung around a long time or if something was done
in the installer version for this build, but for now it's looking clearer than
it has in a long time.

Dale

Comment 26

[John Bandhauer]

dveditz: Is the installer expected to remove all DLLs when installing over an 
installation? What about old plugins that may be registered as components? Do 
you see a way for this error to be coming up due to 'leftover' DLLs?

At this point it looks to me like we have no evidence to say whether this 
problem is likely to be an installer sort of problem - that we can understand 
and deal with - OR if this is order-file related voodoo that we *must* figure 
out through experimentation and research. This is not an area where we want to 
accept a WORKSFORME resolution and walk away.

Comment 27

[extremely]

When digging through the list of files on my harddrive that have
"nsInputFileStream" in them, I stumbled across "psmglue.dll" in the "components"
directory.  Whilst all the other files were dated today or yesterday, this one
was modified April 9, 2001 and created March 26th...

Removing just this file and restarting moz seems to have made it go away.

Best of all, others have spotted this, <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=77927">Bug #77927</a>,

Comment 28

[dprice (gone)]

*** Bug 76045 has been marked as a duplicate of this bug. ***

Comment 29

[dprice (gone)]

fixing 77927 should fix this as well.

Comment 30

[Fabian Guisset]

*** Bug 79364 has been marked as a duplicate of this bug. ***

Comment 31

[Fabian Guisset]

*** Bug 79545 has been marked as a duplicate of this bug. ***

Comment 32

[Keyser Sose]

*** Bug 79815 has been marked as a duplicate of this bug. ***

Comment 33

[dprice (gone)]

new entry point not found bugs keep cropping up.  We're not seeing a real win
for the ordering that's there now.  So after talking this over with waterson,
choffman and kandrot I'm going to disable the use of the win32.order files
unless MOZ_COVERAGE is set.  This will turn it off for the optimized builds.

here's a diff for your enjoyment:

Index: dll.inc
===================================================================
RCS file: /cvsroot/mozilla/config/dll.inc,v
retrieving revision 3.6
diff -u -r3.6 dll.inc
--- dll.inc     2001/02/15 23:04:33     3.6
+++ dll.inc     2001/05/10 00:23:11
@@ -83,7 +83,7 @@
 !ifdef MAPFILE
                /MAP:$(MAPFILE)
 !endif
-!if exist(win32.order) && !defined(MOZ_DEBUG)
+!if exist(win32.order) && !defined(MOZ_DEBUG) && defined(MOZ_COVERAGE)
         /ORDER:@win32.order
 !endif
         $(LFLAGS)

Comment 34

[John Bandhauer]

Disabling the win32 ordering stuff until it can be shown to make a significant 
difference is fine by me. But, at least one of the "entry point not found" 
errors was clearly caused by the old psmglue.dll being left over from previous 
installations (I can confirm this). I believe(?) that installer bug has since 
been fixed. I think there is a serious question about installer cleanup here. 

Is there any clear evidence that the win32 order stuff was contributing to this 
entry point problem?

It seems like the installer strategy changed somewhere along the way so that it 
no longer whacks *all* old stuff and instead removes only stuff it expects 
to need to remove. Is this the case? This *might* well be a good thing in a 
world of third party components (is that the reason for the installer change?). 
But it requires more careful maintainence to keep things working smoothly as the 
codebase evolves. It is also questionable since the third party need to keep in 
sync with our evolving codebase anyway... There is no promise that components 
that work with mozilla version X will not cause a crash of mozilla version X+1.

Comment 35

[chris hofmann]

lets get this turned off for 0.9.1 and the betas that will come from that branch
until we learn more from rogc cord work and other investigations.

Comment 36

[Sean Su]

yes, I have turned off the "nuke from orbit" feature under the windows 
installer.  I was afraid that we might accidently delete the user's entire hard 
drive, if memory and/or file table were corrupted.

There was one case that I've read that the user had lost his entire [program 
files] folder after installing mozilla using the windows installer.  Even though 
it was not reproduceable, I removed the "nuke from orbit" feature.

I also removed it because it would nuke 3rd party files/plugins (as jband had 
indicated) not installed by our installer.  It's really bad to delete files we 
didn't install.

QA has already been informed that they need to add an additional test to their 
set of test cases.  They need to find out the file difference (only obsolete 
files) after installation of the latest build of mozilla ontop of a previous 
build as compared to an installation into a new folder.

Once this set of obsolete files have been determined, the installers will need 
to be updated to remove such files (like it does with psmglue.dll - bug 77927).  
Actually, we can update the install scripts as we find such files.

Even though this is more work, it is the rigth way to handle obsolete files and 
product upgrades, and not use a "nuke from orbit" feature.

Comment 37

[dprice (gone)]

resolving this as fixed.  

Comment 38

[lchiang]

Have gotten two reports ([e-mail] and [e-mail])with getting 
an entry point error on startup using today's build.  Error is:  "The procedure 
entry point ... could not be located in the dynamic library xpcom.dll."  This is 
on Win2K

Will reopen this bug report.

If you want a new bug report, pls let me know. Thank you.

Comment 39

[John Bandhauer]

It would help if someone took the time to record the actual string you represent 
by '...'. 

We *really* need to nail the issue of whether this is:

a) a failure of the installer to remove old dlls.
b) some old plugin that the installer doesn't think it should remove
c) a broken built part we should not be installing
d) something even remotely associated with the win32.order files
e) something else.

dprice: are you going to attack this today? Do you want to reassign it to 
installer people? or what?

Comment 40

[John Bandhauer]

dbragg's mail to the hook today suggests that he might be a good owner for this 
bug if it is a real ongoing problem. cc'ing him

Comment 41

[Sean Su]

Marek reports:
  "the procedure entry point ??_7nsLocalString@@6B@ could not be located in the 
[...] xpcom.dll".

I'm going to try to do upgrade installs (from 6.0->6.01->daily builds) to see if 
I can run into this problem.

Comment 42

[dbragg]

I'm looking in to this too.  The think is, if my stuff was a problem we'd have
seen it last week.  The thing I checked in last night was for the case of
6.0x->latest version update installs only.  If Marek was using a daily build
from earlier than Wed. of last week and then updated to today he'd very likely
have this problem.

Comment 43

[Sean Su]

I found the culprit files:
  ...\components\gkhtml.dll
  ...\components\mozucth.dll

there are other obsolete files that I've noticed too:
  oji.dll  (not sure if this is ours)
  ...\components\signed.dll

I'll update the native win32 installer to remove all of the above mentioned 
files.  This is bug 81601

Comment 44

[dbragg]

So Sean, Marek was running the installer and not un update and these are simply
obsolete files.  Is that what you're saying?  If so, this is unrelated to my
recent check-ins.

Comment 45

[chris hofmann]

I installed yesterday's build on the pit cam system.  I see the
problem there.  you can check it out.

Comment 46

[Sean Su]

Don, this is not your problem.  Tis mine.  It's actually bug 81601.

Comment 47

[Sean Su]

If you delete:
  ...\components\gkhtml.dll
  ...\components\mozucth.dll

The error messages should disappear.  Does anyone know if it's okay to delete 
the oji.dll file?  anyone? anyone?  It looks like it was part of 6.01 an no 
longer in the latest builds.

Oji.dll is not causing the error message, only the first two listed files.  But 
I'd still like to remove oji.dll since it seems obsolete.

Comment 48

[lchiang]

sean - perhaps you may want to inquire with Sun folks for this oji file.   

Comment 49

[Sean Su]

changing component to installer and reassigning this to myself.

Comment 50

[Sean Su]

marking this bug fixed because patches were attached and checked in with bug 
81601.

1) install Netscape 6.01
2) install one of the daily builds ontop of 6.01
3) ...\components\gkhtml.dll and ...\components\mozucth.dll should have been 
removed.

1) install Netscape 6.0 (into a clean folder)
2) install one of the daily builds ontop of 6.0
3) ...\components\gkhtml.dll and ...\components\mozucth.dll should have been 
removed.

Comment 51

[Keyser Sose]

*** Bug 82866 has been marked as a duplicate of this bug. ***

Comment 52

[Fabian Guisset]

*** Bug 84659 has been marked as a duplicate of this bug. ***

Comment 53

[Matthias Versen [:Matti]]

*** Bug 85068 has been marked as a duplicate of this bug. ***

Comment 54

[Matthias Versen [:Matti]]

*** Bug 85209 has been marked as a duplicate of this bug. ***

Comment 55

[Dawn Endico]

Reopening this because there are four bugs that were filed after this bug
was closed and marked as duplicate of this. I'm looking at this because I was
asked to relnote this bug but I'm not sure what to say.

Comment 56

[timeless]

The relnote i'd suggest is:
The most likely reason for receiving this error message is installing a new 
mozilla over an old mozilla.  mozilla.org does not recommend ever doing this, 
it is wholy unsupported and can lead to problems such as this one.  Workaround: 
install mozilla elsewhere.  If you have specific information about your problem 
you can of course add it to bug 71010.

Comment 57

[extremely]

How about this slightly more diplomatic version?

----
Unfortunately this bug is caused by dynamically linked files left over from 
older installs that the newer installers don't know to erase.  This is a 
side-effect of fast-paced development.  Newer Mozilla installs don't dare wipe 
the directory for fear of removing something user-installed like a plugin or 
test code or second-party component.  

The easiest solution is to wipe the mozilla directories and perform a fresh 
install.  That will of course entail reinstalling plugins and other add-in 
components.  

The more confident user might wish to sort the sub-directory "components" by 
file creation time and look for a couple of old files.  Most of the files after 
a fresh install should have the same date so they should stick out rather 
obviously.  Remove those files to a safe place and restart Mozilla.  You'll 
want to kick all the tires and look for odd failures. I that happens try adding 
things back in manually one at a time or reinstalling 3rd party add-ons that 
fail.
----

maybe Mozilla should reserve "components" for itself and mark those files with 
it's own version number? Perhaps the xpcom.dll shouldn't be loading things from 
that directory it doesn't know for sure matches it's expectations?  Force 3rd 
party stuff to plugins or somewhere else?

Comment 58

[Matthias Versen [:Matti]]

*** Bug 85885 has been marked as a duplicate of this bug. ***

Comment 59

[Matthias Versen [:Matti]]

*** Bug 88418 has been marked as a duplicate of this bug. ***

Comment 60

[Matthias Versen [:Matti]]

*** Bug 88585 has been marked as a duplicate of this bug. ***

Comment 61

[Matthias Versen [:Matti]]

*** Bug 88845 has been marked as a duplicate of this bug. ***

Comment 62

[Matthias Versen [:Matti]]

*** Bug 89304 has been marked as a duplicate of this bug. ***

Comment 63

[Matthias Versen [:Matti]]

*** Bug 89434 has been marked as a duplicate of this bug. ***

Comment 64

[Matthias Versen [:Matti]]

*** Bug 89871 has been marked as a duplicate of this bug. ***

Comment 65

[Matthias Versen [:Matti]]

Endico: Can we get this in the release notes ?

BTW: Bug 82430 is the same bug. (misssing entry point in xpcom.dll, works after 
a complete reinstall)

Comment 66

[Chase Tingley]

*** Bug 90245 has been marked as a duplicate of this bug. ***

Comment 67

[Tuukka Tolvanen (sp3000)]

*** Bug 90796 has been marked as a duplicate of this bug. ***

Comment 68

[Matthias Versen [:Matti]]

*** Bug 92227 has been marked as a duplicate of this bug. ***

Comment 69

[timeless]

*** Bug 92227 has been marked as a duplicate of this bug. ***

Comment 70

[Matthias Versen [:Matti]]

*** Bug 94108 has been marked as a duplicate of this bug. ***

Comment 71

[Chase Tingley]

*** Bug 95333 has been marked as a duplicate of this bug. ***

Comment 72

[Ferdinand]

*** Bug 94380 has been marked as a duplicate of this bug. ***

Comment 73

[Daniel Veditz [:dveditz]]

This bug is now a useless mess. How many different "missing entry point"
problems are lumped into the same bug? Each and every one is a different
build/configuration/packaging issue, and although similar in cause and effect
each will usually have to be fixed individually.

I'm closing this bug. Most of the early ones are fixed and the
NS_NewGenericModule problems are covered in bug 94108. If you find new and
*different* missing entry points please file separate bugs, and put the entry
point name in the bug summary to discourage future lumping.

Comment 74

[Daniel Veditz [:dveditz]]

Added two early culprits of many of the dupes in this bug to the summary to
forestall reopening.

Comment 75

[Grace Bush]

verified