Closed
Bug 71010
Opened 23 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•23 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•23 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•23 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•23 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•23 years ago
|
||
Confirming. I see this too. Nominating for mozilla 0.9. Can't do a milestone build with these warning dialogs.
Comment 10•23 years ago
|
||
*** Bug 76045 has been marked as a duplicate of this bug. ***
Comment 11•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 years ago
|
||
*** Bug 76045 has been marked as a duplicate of this bug. ***
Comment 30•23 years ago
|
||
*** Bug 79364 has been marked as a duplicate of this bug. ***
Comment 31•23 years ago
|
||
*** Bug 79545 has been marked as a duplicate of this bug. ***
Comment 32•23 years ago
|
||
*** Bug 79815 has been marked as a duplicate of this bug. ***
Comment 33•23 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•23 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•23 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•23 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•23 years ago
|
||
resolving this as fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 38•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 years ago
|
||
Don, this is not your problem. Tis mine. It's actually bug 81601.
Assignee | ||
Comment 47•23 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•23 years ago
|
||
sean - perhaps you may want to inquire with Sun folks for this oji file.
Assignee | ||
Comment 49•23 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•23 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: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 51•23 years ago
|
||
*** Bug 82866 has been marked as a duplicate of this bug. ***
Comment 52•23 years ago
|
||
*** Bug 84659 has been marked as a duplicate of this bug. ***
Comment 53•23 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: 23 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
•