Closed
Bug 71010
Opened 24 years ago
Closed 23 years ago
entry point not found (nsInputFileStream/nsLocalString)
Categories
(SeaMonkey :: Installer, defect)
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
Comment 1•24 years ago
|
||
Sounds like bug 60791
reassigning to profile manager
Assignee: joki → ccarlen
Component: Event Handling → Profile Manager BackEnd
QA Contact: gerardok → gbush
Comment 2•24 years ago
|
||
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
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
Comment 7•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
Confirming. I see this too. Nominating for mozilla 0.9. Can't do a milestone
build with these warning dialogs.
Comment 10•24 years ago
|
||
*** Bug 76045 has been marked as a duplicate of this bug. ***
Comment 11•24 years ago
|
||
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
Comment 12•24 years ago
|
||
Please also look at the form submission symptom in bug 76045, if only to make
sure it's really a dup.
Comment 13•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
I have a Dell Inspiron with Windows 2000 and I see it when submitting forms. I
am running the 4/19 build
Comment 16•24 years ago
|
||
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
Comment 17•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
*** Bug 76045 has been marked as a duplicate of this bug. ***
Comment 30•24 years ago
|
||
*** Bug 79364 has been marked as a duplicate of this bug. ***
Comment 31•24 years ago
|
||
*** Bug 79545 has been marked as a duplicate of this bug. ***
Comment 32•24 years ago
|
||
*** Bug 79815 has been marked as a duplicate of this bug. ***
Comment 33•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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.
Assignee | ||
Comment 36•24 years ago
|
||
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•24 years ago
|
||
resolving this as fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 38•24 years ago
|
||
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 → ---
Comment 39•24 years ago
|
||
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•24 years ago
|
||
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
Assignee | ||
Comment 41•24 years ago
|
||
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•24 years ago
|
||
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.
Assignee | ||
Comment 43•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
I installed yesterday's build on the pit cam system. I see the
problem there. you can check it out.
Assignee | ||
Comment 46•24 years ago
|
||
Don, this is not your problem. Tis mine. It's actually bug 81601.
Assignee | ||
Comment 47•24 years ago
|
||
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•24 years ago
|
||
sean - perhaps you may want to inquire with Sun folks for this oji file.
Assignee | ||
Comment 49•24 years ago
|
||
changing component to installer and reassigning this to myself.
Assignee: dprice → ssu
Status: REOPENED → NEW
Component: XPCOM → Installer: XPI Packages
Assignee | ||
Comment 50•24 years ago
|
||
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: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 51•24 years ago
|
||
*** Bug 82866 has been marked as a duplicate of this bug. ***
Comment 52•24 years ago
|
||
*** Bug 84659 has been marked as a duplicate of this bug. ***
Comment 53•24 years ago
|
||
*** Bug 85068 has been marked as a duplicate of this bug. ***
Comment 54•23 years ago
|
||
*** Bug 85209 has been marked as a duplicate of this bug. ***
Comment 55•23 years ago
|
||
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 → ---
Comment 56•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
*** Bug 85885 has been marked as a duplicate of this bug. ***
Comment 59•23 years ago
|
||
*** Bug 88418 has been marked as a duplicate of this bug. ***
Comment 60•23 years ago
|
||
*** Bug 88585 has been marked as a duplicate of this bug. ***
Comment 61•23 years ago
|
||
*** Bug 88845 has been marked as a duplicate of this bug. ***
Comment 62•23 years ago
|
||
*** Bug 89304 has been marked as a duplicate of this bug. ***
Comment 63•23 years ago
|
||
*** Bug 89434 has been marked as a duplicate of this bug. ***
Comment 64•23 years ago
|
||
*** Bug 89871 has been marked as a duplicate of this bug. ***
Comment 65•23 years ago
|
||
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•23 years ago
|
||
*** Bug 90245 has been marked as a duplicate of this bug. ***
Comment 67•23 years ago
|
||
*** Bug 90796 has been marked as a duplicate of this bug. ***
Comment 68•23 years ago
|
||
*** Bug 92227 has been marked as a duplicate of this bug. ***
Comment 69•23 years ago
|
||
*** Bug 92227 has been marked as a duplicate of this bug. ***
Comment 70•23 years ago
|
||
*** Bug 94108 has been marked as a duplicate of this bug. ***
Comment 71•23 years ago
|
||
*** Bug 95333 has been marked as a duplicate of this bug. ***
Comment 72•23 years ago
|
||
*** Bug 94380 has been marked as a duplicate of this bug. ***
Comment 73•23 years ago
|
||
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: 24 years ago → 23 years ago
Resolution: --- → FIXED
Comment 74•23 years ago
|
||
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)
Updated•20 years ago
|
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.
Description
•