266214 - Browser will not start after install (xpcom_core.dll not found)

Status: VERIFIED FIXED

(SeaMonkey :: General, defect)

Description

[Bill Mason]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041024 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041024 Firefox/0.9.1+

This build will not start after installing.  Trying to start it gets a error
dialog with the missing file message.  This file, however, is in the C:\Program
Files\Common Files\mozilla.org\GRE\1.8a5_2004102604 directory.

Reproducible: Always
Steps to Reproduce:
1.



May be related to FF bug 266149, where the installer will not finish due to an
xpcom_core.dll error.

Comment 1

[Bill Mason]

The 2004102507 build does not have this problem.
Broken in the 2004102606 build,

Comment 2

[Gérard Talbot]

I confirm all this.
error message: "(...) xpcom_core.dll was not found (...)"
while trying to install Mozilla 1.8a5 build 20041026 under XP Pro SP2.

I was able to install Firefox 0.11 build 20041026 rv:1.7.3 without problems.

Comment 3

[Bill Mason]

(In reply to comment #2)
> I was able to install Firefox 0.11 build 20041026 rv:1.7.3 without problems.

Aviary is unaffected, but the FF trunk is. I opened bug 266149 on that.

Comment 4

[Scott Talbot]

xpcom_core.dll exists in the zip builds but doesn't appear to be being packaged
into the installer builds.
It seems to be fallout from fixing bug 262218.

Comment 5

[Darin Fisher]

sorry, i thought i made all the necessary packaging changes... apparently not :(

Comment 6

[Darin Fisher]

hmm... 2004-10-26-06-trunk/windows-xpi/xpcom.xpi contains xpcom_core.dll, so
maybe it is just not being installed properly.  has anyone tested the stub
installer?
ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2004-10-26-06-trunk/mozilla-win32-stub-installer.exe

Comment 7

[Bill Mason]

(In reply to comment #6)
> hmm... 2004-10-26-06-trunk/windows-xpi/xpcom.xpi contains xpcom_core.dll, so
> maybe it is just not being installed properly.  has anyone tested the stub
> installer?

I was using the stub installer when I found this problem/wrote this bug.

Comment 8

[Darin Fisher]

ok, now that i'm in windows ;-)

i see what the problem is... it looks like xpcom_core.dll is getting installed
correctly, but that we aren't setting the PATH environment variable correctly.

that said, it appears that we actually have separate copies of NSPR in both the
mozilla install directory and the GRE install directory.  that's shocking to me,
and it indicates that one solution to this problem would be to duplicate
xpcom_core.dll similarly, but that seems just awful.

instead, it seems like we should set the PATH environment variable after
selecting which GRE to load (i.e., just before actually loading xpcom.dll).

Comment 9

[Darin Fisher]

Attachment: v1 patch

This patch solves the problem on my system.  However, it has one major
drawback: it means that existing embedders of the GRE may be screwed unless
they are similarly setting the PATH environment variable before loading
xpcom.dll.

Comment 10

[Darin Fisher]

I went ahead and applied this fix to the trunk to make the nightly windows
installer builds work again.

Comment 11

[Darin Fisher]

marking FIXED, please reopen if tomorrow's builds don't work! ;-)

Comment 12

[Erik Fabert]

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

Comment 13

[Bill Mason]

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

Comment 14

[Bill Mason]

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

Comment 15

[Jorge Vidal Wulff]

I just installed build 2004102705 and after installing I get a weird error about
something not found in xpcom.dll, but after closing that, the software runs fine.

Comment 16

[Bill Mason]

The 2004102706 builds install and will run, but an error occurs after the
install when the browser starts:

Mozilla.exe - entry point not found. the proceedure entry point

??1nsCOMPtr_base@@QAE@XZ 

could not be located in the dynamic link library xpcom.dll

The browser does run after installation, but I filed bug 266291 on this issue.

Comment 17

[Jorge Vidal Wulff]

Yep, but it only happens on the very first run of mozilla, subsequent runs are OK.

Comment 18

[Alan Smedley]

This bug/error message is still happening in the latest Nightly Build (2004102805)

"The procedure entry point ??InsCOMPtr_base@@QAEQXZ could not be located in
dynamic link library xpcom.dll"

for confirmation and to help me resolve another/different error I had totally
uninstalled Mozilla, cleaned the registry, then reinstalled version 1.7.3 and
this Nighlty build over that. 

Comment 19

[Bill Mason]

(In reply to comment #18)
> This bug/error message is still happening in the latest Nightly Build (2004102805)
> 
> "The procedure entry point ??InsCOMPtr_base@@QAEQXZ could not be located in
> dynamic link library xpcom.dll"

Yes, that's why bug 266291 is still open.  See comment 16.

Comment 20

[Benjamin Smedberg]

Comment on attachment 163531 [details] [diff] [review]
v1 patch

Oof, I guess, even though this breaks old glue clients.

Comment 21

[Jorge Vidal Wulff]

Still happens w/build 2004102906...

Comment 22

[Darin Fisher]

> (From update of attachment 163531 [details] [diff] [review])
> Oof, I guess, even though this breaks old glue clients.

spoke with bsmedberg about this over irc.  the savings grace is that old glue
clients that were using GRE_Startup would be unaffected since GRE_Startup did a
strict version check.  moreover, if anyone was not using GRE_Startup, then they
most certainly would have to set the PATH environment variable before loading
xpcom.dll since xpcom.dll used to depend on nspr4.dll which lives along side
xpcom.dll.  mozilla.exe did not have to set the PATH previously because it
already had a duplicate copy of nspr4.dll (and other libs) installed along side it.

Comment 23

[Mats Palmgren (inactive)]

This still occurs on Linux, see bug 266922.

Comment 24

[jesse]

Can we reopen this?  I am getting this after running the 1.7.7 installer. 
Browser still starts after the error message though.  this did not occur with
1.8b installer.  This is on winXP