221422 - Unix builds after 2003/09/13 don't start when run with a relative path

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Philip K. Warren]

The last working daily build for AIX was on 2003/09/13. All subsequent builds
fail to start, exiting with return code 4. I have not yet been able to check out
a build from that time to see exactly what the problem is, but initially I think
it may have something to do with the checkin for Bug 179834.

Comment 1

[Philip K. Warren]

These are the checkins between 2003/09/13 08:00:00 and 2003/09/14 08:00:00:

http://makeashorterlink.com/?L23D51F16

Comment 2

[Benjamin Smedberg]

Hrm, hase someone got a debug build? If my checkin is to blame you will get some
interesting warnings during startup. Really, though, I can't see how I would be
to blame for this unless nsTHashtable itself was misbehaving.

Comment 3

[Philip K. Warren]

I am in the process of building an updated trunk debug build. I believe the last
time I tried to bring one up it gave errors about not being able to find
res://gre/... files, which is why I thought it might have something to do with
the checkin for Bug 179834.

Comment 4

[Philip K. Warren]

Attachment: Mozilla startup log

This is a log from the startup of a debug build on AIX.

Comment 5

[Benjamin Smedberg]

Philip, can you run the following script in xpcshell (the debug build) and post
back the results?

const C = Components.classes;
const I = Components.interfaces;

dirService = C["@mozilla.org/file/directory_service;1"].getService(I.nsIProperties);

appDir = dirService.get("CurProcD", I.nsIFile);
print("Applicaiton directory is: " + appDir.path + "\n");

greDir = dirService.get("GreD", I.nsIFile);
print("GRE directory is: " + greDir.path + "\n");

ioS = C["@mozilla.org/network/io-service;1"].getService(I.nsIIOService);
resHandler = ioS.getProtocolHandler("resource");

resHandler = resHandler.QueryInterface(I.nsIResProtocolHandler);
greMapping = resHandler.getSubstitution("gre");

print("resource://gre/ mapping = " + greMapping.spec + "\n");

Comment 6

[Philip K. Warren]

$ LIBPATH=. ./xpcshell -f xpcshell.script

Application directory is: /home/pkw/sb/moz14/src/nsmoz/mozilla/obj-opt/dist/bin

GRE directory is: /home/pkw/sb/moz14/src/nsmoz/mozilla/obj-opt/dist/bin

uncaught exception: [Exception... "Component returned failure code: 0x80040111 
(NS_ERROR_NOT_AVAILABLE) [nsIResProtocolHandler.getSubstitution]"  
nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: 
xpcshell.script :: <TOP_LEVEL> :: line 16"  data: no]

Comment 7

[Benjamin Smedberg]

Ugh! That's bad, and would cause the other problems in that log. Without a
machine for testing I'm somewhat at a loss, but I would start by putting
printf()s in nsResProtocolHandler::Init() or stepping through that function to
see whether anything is failing there. Could you also run the TestHashtables
test program and see whether that reports any failures?

Comment 8

[Philip K. Warren]

Attachment: TestHashtables logfile

As far as I can tell, the output of TestHashtables looks ok. Its pretty verbose
though.

Comment 9

[Philip K. Warren]

Ok here is a log (NSPR_LOG_MODULES=nsResProtocol:5) with some additions by me:

This is for the first call to AddSpecialDir in Init():

1[20057f48]: nsResProtocolHandler::AddSpecialDir(aSpecialDir="CurProcD",
aSubstitution="")
1[20057f48]:
file->nativePath="/home/pkw/sb/mozilla/trunk/mozilla/obj-debug/dist/bin"
1[20057f48]: nsResProtocolHandler::SetSubstitution(root="", baseURI=0x20aadcb8,
baseURI->Path="/home/pkw/sb/mozilla/trunk/mozilla/obj-debug/dist/bin/")

This is for the second call to AddSpecialDir in Init():

1[20057f48]: nsResProtocolHandler::AddSpecialDir(aSpecialDir="GreD",
aSubstitution="gre")
1[20057f48]: file->nativePath="."
1[20057f48]: nsResProtocolHandler::SetSubstitution(root="gre",
baseURI=0x20aae168, baseURI->Path="/")

So for some reason, when run with the command "./mozilla" in dist/bin, the GreD
variable is set to ".", which when turned into a nsIURI gets the path "/".

Now when I run Mozilla with its full path (i.e.
/home/pkw/sb/mozilla/trunk/mozilla/obj-debug/dist/bin/mozilla), it starts
correctly and I get the following log entries:

1[20057f48]: nsResProtocolHandler::AddSpecialDir(aSpecialDir="CurProcD",
aSubstitution="")
1[20057f48]:
file->nativePath="/home/pkw/sb/mozilla/trunk/mozilla/obj-debug/dist/bin"
1[20057f48]: nsResProtocolHandler::SetSubstitution(root="", baseURI=0x209d0748,
baseURI->Path="/home/pkw/sb/mozilla/trunk/mozilla/obj-debug/dist/bin/")

1[20057f48]: nsResProtocolHandler::AddSpecialDir(aSpecialDir="GreD",
aSubstitution="gre")
1[20057f48]:
file->nativePath="/home/pkw/sb/mozilla/trunk/mozilla/obj-debug/dist/bin"
1[20057f48]: nsResProtocolHandler::SetSubstitution(root="gre",
baseURI=0x209d0bf8,
baseURI->Path="/home/pkw/sb/mozilla/trunk/mozilla/obj-debug/dist/bin/")

In the Mozilla startup script, the MOZILLA_FIVE_HOME variable is set to `dirname
$0`, so in the first case it is ".", in the second one it is
"/home/pkw/sb/mozilla/trunk/mozilla/obj-debug/dist/bin". Maybe there is just a
path that needs to be normalized somewhere?

Comment 10

[Benjamin Smedberg]

Beautiful work. That is a problem, because initializing a nsILocalFile with a
relative path doesn't work, but we don't fail properly. I can think of several
solutions

1) make initializing an nsILocalFile work correctly with a relative path (i.e.
make the path absolute during initialization)

2) in the standalone glue, use some sort of helper function to make a relative
path absolute

3) in the run-mozilla script, make the MOZILLA_FIVE_HOME absolute (using `pwd` I
suppose).

Comment 11

[Philip K. Warren]

You probably just want to call nsILocalFile->Normalize at the right location, I
just can't find where that is right now. Where is the GreD directory initialized?

Comment 12

[Benjamin Smedberg]

It appears that normalize() is already called. The comments for nsILocalFile
specifically disallow initializing it with a relative path.

http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsDirectoryService.cpp#256

Comment 13

[Philip K. Warren]

I don't know if that's where the value for NS_GRE_DIR is being set. I added some
printfs to nsDirectoryService::Get() and nsDirectoryService::Set(), and here's
what I'm seeing:

nsDirectoryService::Get(prop=GreD)
Found GREDir value in mProviders
nsDirectoryService::Set(prop=GreD)
Setting GreD to path .

Then later on:

nsDirectoryService::Get(prop=GreD)
Found GREDir value in hash

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

somewhat related: bug 183871 comment 31

Comment 15

[robert somerville]

Hack # 3 has solved my problems with Mozilla-solaris-sparc2.7 ,probably related
to bugs 221405 220777,221048, etc. etc . etc. 

"3) in the run-mozilla script, make the MOZILLA_FIVE_HOME absolute (using `pwd` I
suppose). "

Comment 16

[Philip K. Warren]

Attachment: Patch v1

Seems to fix the problem on my end...

Comment 17

[robert somerville]

Hack #3 only seems to work if I run it directly from my build directory, just in
case that question was directed at me

Comment 18

[Philip K. Warren]

Reassigning bug.

Comment 19

[Philip K. Warren]

Changing QA contact.

Comment 20

[Philip K. Warren]

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

Comment 21

[Philip K. Warren]

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

Comment 22

[robert somerville]

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

Comment 23

[Doug Turner (:dougt)]

Comment on attachment 132828 [details] [diff] [review]
Patch v1

where is the path coming from?	Is it from an env var or from the gre.conf
file?  Why can't that just be normalized?

Comment 24

[Philip K. Warren]

This path is coming from the MOZILLA_FIVE_HOME environment variable. I changed
the GRE code to normalize the path so it behaves consistently with the
GetCurrentProcessDirectory function in nsDirectoryService.cpp (snippet shown here):

251     char *moz5 = PR_GetEnv("MOZILLA_FIVE_HOME");
252 
253     if (moz5)
254     {
255         localFile->InitWithNativePath(nsDependentCString(moz5));
256         localFile->Normalize();
257         *aFile = localFile;
258         return NS_OK;
259     }

Comment 25

[Doug Turner (:dougt)]

can you move the normalization into GetGREDirectoryPath()

Comment 26

[Philip K. Warren]

Attachment: Patch v2

This patch moves the normalization into GetCurrentProcessDirectory(). This
assumes this only place where relative paths will be coming from is the
MOZILLA_FIVE_HOME environment variable, and not from GRE configuration files.

Comment 27

[Doug Turner (:dougt)]

Comment on attachment 133422 [details] [diff] [review]
Patch v2

r=dougt

Comment 28

[Doug Turner (:dougt)]

Comment on attachment 133422 [details] [diff] [review]
Patch v2

what about the #ifdef's?

Comment 29

[Doug Turner (:dougt)]

nevermind that last comment, we are in a "#elif defined(XP_UNIX)"

Comment 30

[Darin Fisher]

Comment on attachment 133422 [details] [diff] [review]
Patch v2

>Index: xpcom/glue/standalone/nsGREDirServiceProvider.cpp

>+        if (realpath(moz5, buf))
>+            resultPath = strdup(buf);
>+        else
>+            resultPath = strdup(moz5);

reading the linux (rh9) man page on realpath doesn't give
me much confidence that this is going to always work.

this bit is interesting:

CONFORMING TO
       In  BSD	4.4 and Solaris the limit on the pathname length is MAXPATHLEN
       (found in <sys/param.h>). The SUSv2 prescribes PATH_MAX	and  NAME_MAX,
       as  found in <limits.h> or provided by the pathconf() function. A typi-
       cal source fragment would be

	      #ifdef PATH_MAX
		path_max = PATH_MAX;
	      #else
		path_max = pathconf (path, _PC_PATH_MAX);
		if (path_max <= 0)
		  path_max = 4096;
	      #endif

       The BSD 4.4, Linux and SUSv2 versions always return  an	absolute  path
       name. Solaris may return a relative path name when the path argument is
       relative.  The prototype of realpath is given in  <unistd.h>  in  libc4
       and libc5, but in <stdlib.h> everywhere else.

the bit about Solaris returning a relative path is very concerning.  are you
sure this is what we want here?  seems to me that using realpath is just
opening
a big can of portability problems.

Comment 31

[Darin Fisher]

Comment on attachment 133422 [details] [diff] [review]
Patch v2

well, ok... seems like nsLocalFileUnix.cpp uses realpath in this manner, so
maybe _nevermind_ ;-)

r/sr=darin

though, i still wonder about what that man page was saying... seems like we
should worry, no?

Comment 32

[Philip K. Warren]

Fixed.

Checking in nsGREDirServiceProvider.cpp;
/cvsroot/mozilla/xpcom/glue/standalone/nsGREDirServiceProvider.cpp,v  <-- 
nsGREDirServiceProvider.cpp
new revision: 1.22; previous revision: 1.21
done

Comment 33

[lhecking]

Yep, it's working now on Solaris (original bug #221048). Thanks!