Closed Bug 71010 Opened 23 years ago Closed 23 years ago

entry point not found (nsInputFileStream/nsLocalString)

Categories

(SeaMonkey :: Installer, defect)

x86
Windows 2000
defect
Not set
minor

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: rsalexan, Assigned: ssu0262)

References

Details

(Keywords: helpwanted, qawanted, relnote)

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
Sounds like bug 60791
reassigning to profile manager
Assignee: joki → ccarlen
Component: Event Handling → Profile Manager BackEnd
QA Contact: gerardok → gbush
Sure doesn't sound like profile mgr to me. Back to XPCOM - for lack of a better
place.
Assignee: ccarlen → scc
Component: Profile Manager BackEnd → XPCOM
QA Contact: gbush → kandrot
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
*** Bug 75702 has been marked as a duplicate of this bug. ***
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
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
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
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.
Confirming. I see this too. Nominating for mozilla 0.9. Can't do a milestone
build with these warning dialogs.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla0.9
*** Bug 76045 has been marked as a duplicate of this bug. ***
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.
Assignee: scc → dprice
Please also look at the form submission symptom in bug 76045, if only to make
sure it's really a dup.
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.
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,
I have a Dell Inspiron with Windows 2000 and I see it when submitting forms.  I 
am running the 4/19 build
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
Target Milestone: --- → mozilla0.9.1
0.9.1? Ugh. I get this error every time I submit a form. Isn't there something
we can do for 0.9?
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.
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.
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.
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.
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.  
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
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?
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
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.
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>,
*** Bug 76045 has been marked as a duplicate of this bug. ***
fixing 77927 should fix this as well.
Depends on: 77927
*** Bug 79364 has been marked as a duplicate of this bug. ***
*** Bug 79545 has been marked as a duplicate of this bug. ***
*** Bug 79815 has been marked as a duplicate of this bug. ***
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)
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.
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.
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.
resolving this as fixed.  
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Have gotten two reports (marek@netscape.com and marina@netscape.com)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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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?
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
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.
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.
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
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.
I installed yesterday's build on the pit cam system.  I see the
problem there.  you can check it out.
Don, this is not your problem.  Tis mine.  It's actually bug 81601.
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.
sean - perhaps you may want to inquire with Sun folks for this oji file.   
changing component to installer and reassigning this to myself.
Assignee: dprice → ssu
Status: REOPENED → NEW
Component: XPCOM → Installer: XPI Packages
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.
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
*** Bug 82866 has been marked as a duplicate of this bug. ***
*** Bug 84659 has been marked as a duplicate of this bug. ***
*** Bug 85068 has been marked as a duplicate of this bug. ***
*** Bug 85209 has been marked as a duplicate of this bug. ***
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
URL: n/a
Target Milestone: mozilla0.9.1 → ---
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?
*** Bug 85885 has been marked as a duplicate of this bug. ***
*** Bug 88418 has been marked as a duplicate of this bug. ***
*** Bug 88585 has been marked as a duplicate of this bug. ***
*** Bug 88845 has been marked as a duplicate of this bug. ***
*** Bug 89304 has been marked as a duplicate of this bug. ***
*** Bug 89434 has been marked as a duplicate of this bug. ***
*** Bug 89871 has been marked as a duplicate of this bug. ***
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)
*** Bug 90245 has been marked as a duplicate of this bug. ***
*** Bug 90796 has been marked as a duplicate of this bug. ***
*** Bug 92227 has been marked as a duplicate of this bug. ***
*** Bug 92227 has been marked as a duplicate of this bug. ***
*** Bug 94108 has been marked as a duplicate of this bug. ***
*** Bug 95333 has been marked as a duplicate of this bug. ***
*** Bug 94380 has been marked as a duplicate of this bug. ***
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Added two early culprits of many of the dupes in this bug to the summary to
forestall reopening.
Summary: entry point not found → entry point not found (nsInputFileStream/nsLocalString)
verified
Status: RESOLVED → VERIFIED
QA Contact: kandrot → gbush
Product: Browser → Seamonkey
Component: Installer: XPI Packages → Installer
QA Contact: agracebush → general
You need to log in before you can comment on or make changes to this bug.