274671 - mfcembed.exe cannot run outside of GRE directory

Status: RESOLVED INVALID

(Core :: IPC, defect)

Description

[Andrew Morrow]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910

If I download matching versions of Mozilla for Win32, both the installer and
the *.zip file, and attempt to use mfcembed.exe, I find that I cannot
successfully use it anywhere except in the GRE directory.


Reproducible: Always

Steps to Reproduce:
1.  Download both the installer and the zip file for Mozilla .  For instance, 

http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7.3/mozilla-win32-1.7.3-installer.exe

http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7.3/mozilla-win32-1.7.3.zip


2. Extract mfcembed.exe from the zip file and copy it to the GRE directory.

3.  Run mfcembed.exe.  It works OK.

4. Add the GRE directory to your path.  For instance:

C:\Program Files\Common Files\mozilla.org\GRE\1.7.3_2004091008

I will add the 8-character name to avoid the spaces:

set PATH=C:\PROGRA~1\COMMON~1\mozilla.org\GRE\1.7.3_2004091008;%PATH%

5. Move mfcembed.exe to some other directory and run it.  Now it fails.


Actual Results:  
mfcexec.exe failed when it was not in the GRE directory.

When mfcexec.exe failed, I debuged it and got this trace:

I have a rough traceback via MSVC 6.0 :

PLDS4!60f914c4
IPCDC! 6121331a
XPPREF32! 612b70c6
XPPREF32! 612b4e08
XPCOM! 61d243d3
PROFILE! 616833c3
MFCEMBED! 00407f4a
MFCEMBED! 00402c98
MFCEMBED! 004026cc


Expected Results:  
mfcembed.exe should work even when it does not reside in the GRE directory.


I have not identified the exact lines of code, but I expect that the problem is
probably just a simple initialization that mozilla.exe does do that mfcembed.exe
does not do.  This is important because several other technologies (JDIC,
K-melon, ...) rely on mfcembed.exe as the baseline for embedding.

Comment 1

[Andrew Morrow]

One other note:  In gdb, the crash is reported as

0x60f915c4 in plds4!PL_HashTabAdd ()
0x6121331a in ipcdc!NSGetModule ()

Oooh. I noticed I copied that first hex address wrong in my bug report.  It is
0x60f915c4, as I indicate here.

Comment 2

[George Z.]

Yes, I did meet the same problem and tried to setting some environment variables
such as MOZILLA_FIVE_HOME to fix it, but failed. 

As an embeddable component, it should be often included in a 3rd party
application, copying it introduces additional problem, at least, there is the
permission problem to copy a file to the GRE or Mozilla directory. Any fix or
work around is appreciated !  

Comment 3

[Andrew Morrow]

I have noticed that if I create a "components" subdirectory where I have
mfcembed.exe, then in some cases, I get valid-looking xpti.dat and compreg.dat
files before it fails.

Comment 4

[George Z.]

I think Shane Kirk <[e-mail]> pointed out the root cause in a reply
to my post:
http://www.mail-archive.com/[e-mail]/msg05079.html
"... it seems to me that mfcembed is looking for the components it needs
within the directory local to the executable. 

NS_NewNativeLocalFile(nsDependentCString(T2A(path)), TRUE,
getter_AddRefs(mreAppDir));
(http://lxr.mozilla.org/mozilla/source/embedding/tests/mfcembed/MfcEmbed.cpp#423)

And path is set from a call to GetModuleFileName.

It later uses mreAppDir in the embedding initialization. If it can't
find the components directory and the stuff in it, it **** out every
time. This seems to be the case with all of the embedding examples.

I'm betting if you modify it so mreAppDir gets set to the directory
for the MRE or even the unzipped mozilla binary path it'll work just
fine. Maybe via an environment variable? 
..."

I verified that if setting mreAppDir to a mozilla binary path or a GRE directory
path specifically, mfcembed.exe runs without needing to be copied.

Comment 5

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 6

[Benjamin Smedberg]

mfcembed is no more