62361 - Profile Migration fails when remotely logging into HPUX

Status: VERIFIED FIXED

(Core Graveyard :: Profile: Migration, defect, P3)

Description

[Shannon Diener]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108
Netscape6/6.0
BuildID:    20001121

Profile migration does not occur when remotely logging into an HP-UX machine.
We tried to rlogin into HPUX from Linux (setting display to Linux) and profile
migration does not occur.  Migration also does not occur when remotely logging
into an HPUX machine from another HPUX machine.  It does work when logging into
Linux from HPUX.

Reproducible: Always
Steps to Reproduce:
1.  From an HPUX (or Linux) machine remotely log into an HPUX machine
2.  set display to the machine whose console you are currently sitting at
3.  remove your .mozilla directory
4.  run mozilla

Actual Results:  No dialog appears to indicate that profile migration is
occurring.  Once the browser appears, you get the default profile.

Expected Results:  A dialog should appear prompting to migrate a profile.  Once
browser appears your settings should be in place.

Comment 1

[Shannon Diener]

updating QA contact

Comment 2

[Shannon Diener]

accepting bug

Comment 3

[John Gaunt (redfive)]

the netscape -installer switch doesn't migrate the profile over the rlogin
connection either. Locally it works, however this may just be the default
behavior that is working locally

Comment 4

[Jimmy Uen]

This profile migration works fine with remotely logging into a Linux machine
from another Linux machine. So this is a HP-UX platform specific problem. I have
tested with the Linux 6.0 RTM build.

Comment 5

[Raghu Sakleshpur]

This bug occurs on  solaris platform too. I tested between solaris 2.8 and
solaris 2.7. The display was set on the solaris 2.8 system. Some debug messages
seen were as follows:

candyapples% ./netscape_debug
----------- Running Netscape 6 -------------
./run-mozilla.sh ./mozilla-bin
MOZILLA_FIVE_HOME=.
 
LD_LIBRARY_PATH=./Cool:.:/home/raghu/xp/dist/lib:/lib:/usr/lib:/export/home/moz6/dist/lib
          LIBPATH=.:./Cool
       SHLIB_PATH=.:./Cool
      XPCS_HOME=./Cool
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
Inside Migrate Profile routine.
start of pref migration
failed to migrate properly.  err=-2142044161
creating new nsJSAimChatRendezvous
Setting content window
*** Pulling out the charset
Loading page specified via openDialog

Comment 6

[John Gaunt (redfive)]

we may be looking at different problems. we don't get a failure notice, it just
appears we never try to migrate. here is some of our output, the key output
being the ProfileManager : CreateNewProfile line. It looks like your error line
might be coming from a call to nsPrefMigration::ProcessPrefsCallback in
mozilla/profile/pref-migrator/src/nsPrefMigration.cpp from the
ProfileMigrationController function.

nNCL: registering deferred (0)
###!!! ASSERTION: Invalid registryName: 'registryName', file
nsProfileAccess.cpp, line 1209
###!!! Break: at file nsProfileAccess.cpp, line 1209
ProfileManager : CreateNewProfile
Profile Name: default
Profile Dir: /u/jgaunt/.mozilla

gLockFileName netscape.cfg

gLockVendor netscape
Opening file cookies.txt failed
Opening file cookperm.txt failed

Comment 7

[John Gaunt (redfive)]

in nsProfileAccess.cpp (Get4xProfileInfo()) a call is made that queries the
environment variable USER. when accessing another computer through rlogin that
variable is not set for HP ( at least in all the examples we have seen - ksh,
csh ). The return value from that  call is used to set the profile name for the
6.0 profile. However we also have the HOME variable which in most cases ( better
than 90% ? ) will contain the username as the last directory.

Is it possible to merely pull this name from the home directory string? Is it
advisable?  Perhaps instead if we dont' get a value after querying the USER
variable we can make a call to the os to get the username? Should we be using
such a low-level call?

Comment 8

[John Gaunt (redfive)]

adding racham to the bug.

racham? are you the right one to help here?

Comment 9

[John Gaunt (redfive)]

It has been suggested that we use LOGNAME instead of the USER environment
variable as it appears LOGNAME is guarenteed to be there where USER is not.
Doing some more research...

George: is Sun seeing this problem? I want to make sure we get a fix that will
work for any version of Unix ( including Linux )

Comment 10

[John Gaunt (redfive)]

sorry for spam,
just to clarify, it's not broken in linux right now, but we may have to change
the way it is working and THAT needs to work in linux and other Unixes.

Comment 11

[drapeau]

John: don't know if it's happening on Solaris.  Raghu posted earlier to this
bug, but as you point out, it appears to be a different problem.

Raghu: would you please try this while remotely logged in, see if the problem
happens?  (or delegate)

Comment 12

[John Gaunt (redfive)]

the LOGNAME fix appears to work, we're testing on Linux and preparing a diff
file. It will consist basically of a #define for the LOGON string and a
PR_GetEnv call using that instead of the #define for the USER string. I'll post
two diffs, one for the OEM branch and one for the trunk, since there is quite a
bit of difference between the 2 locations.

Comment 13

[John Gaunt (redfive)]

Attachment: OEM branch patch

Comment 14

[John Gaunt (redfive)]

Attachment: TRUNK patch

Comment 15

[John Gaunt (redfive)]

Found in the Stevens Unix book:
FIPS 151-1 requires that a login shell must define the environment variables
HOME and LOGNAME.

so it looks like LOGNAME is a safer bet.

Comment 16

[John Gaunt (redfive)]

adding sspitzer and selmer, looking for approval for trunk checkin.
a=???

have emailed [e-mail] trolling for sr=

Comment 17

[racham]

r=racham for trunk patch. After getting sr=, if you need help with checking in,
please let me know.

Conrad Carlen is the ProfileManager module owner now. Mozilla.org's module
owners page will soon be reflecting this. Adding to the cc list now.

Comment 18

[Conrad Carlen (not reading bugmail)]

As far as HOME vs. LOGNAME, I'll pass to somebody with more Unix savvy. While
you're at this, the NS_ASSERTION(registryName, "Invalid registryName"); should
be moved inside the #if defined(XP_PC) || defined(XP_MAC). It's not used on Unix
and the assertion is mis-leading. 

Comment 19

[John Gaunt (redfive)]

For clarification, its USER vs LOGNAME. HOME is still needed.

I noticed the ASSERTION and that in Unix we call that function with nsnull,
ensuring that is asserts everytime. I'm adding a change to move that inside the
#if defined ( XP_PC ... ) block. will repost patches.

Comment 20

[Shannon Diener]

Reassigning to John

Comment 21

[John Gaunt (redfive)]

Attachment: new OEM patch ( ver 2 )

Comment 22

[John Gaunt (redfive)]

Attachment: new Trunk patch ( ver 2 )

Comment 23

[Shannon Diener]

John's patch fixes the OEM branch - profile migrates and assertion is gone

Comment 24

[Brendan Eich [:brendan]]

Do the FreeBSD variants all support LOGNAME now?  I'm way out of date as a Unix
hacker (kernel/networking code at SGI from '85-92), maybe everyone who is POSIX
does LOGNAME and only the Linuxes and *BSDs do USER?

/be

Comment 25

[Jim Dunn]

adding colin and cls since they are other 'unix variants' freaks

Comment 26

[Colin Blake]

On OpenVMS:

At build time, I have LOGNAME defined, but not USER.
At run time, I have USER defined, but not LOGNAME.

I can change either of these without too much difficultly, for example, if I
need LOGNAME as run time. Just let me know.

Colin.

Comment 27

[John Gaunt (redfive)]

hrmm...  I thought they were all Posix compliant, unix and linux versions. 
Perhaps the solution will be to test them both, LOGNAME first then USER.

Comment 28

[John Gaunt (redfive)]

Attachment: OEM branch diff with LOGNAME and USER checks

Comment 29

[John Gaunt (redfive)]

This latest diff will check first LOGNAME and if that returns null or empty
string it will check USER and then proceed. If neither are set the profile will
not get migrated.

a trunk diff will follow...

Comment 30

[John Gaunt (redfive)]

Attachment: TRUNK diff with LOGNAME and USER checks

Comment 31

[Denis Antrushin]

why not to set profile name to 'default' if either LOGNAME and USER 
are not set? 

Comment 32

[Conrad Carlen (not reading bugmail)]

>why not to set profile name to 'default' if either LOGNAME and USER are not set?
We're using profile name here to find an existing 4.x profile. Why might it be
named 'default'? Why not 'Rumplestiltskin'? If a directory of that name does not
exist or if a profile of that name does exist, this routine will return without
doing anything. In other words, a guess at the name is probably not going to get
us much.

Comment 33

[Margaret Chan]

I just want to provide some info here.  I finally got a chance to check this
out on the Solaris platform.  Below is what I've found:

When I tried to reproduce the bug using Netscape6 (FCS) for Solaris, I've got
similar error as what Raghu has reported.

If I tried to reproduce the bug with my recent mozilla build (using the OEM
branch tag), I saw the same assertion statement as what John has reported
instead.  However, my profile seemed to be migrated anyway.  I saw the migration
confirmation dialog and things appeared to be migrated when I brought
up the browser afterwards.  I have not tried applying the patch to
see what the difference the patch has made.  I'll report any updated information
when I get to apply the patch to the OEM branch.

Comment 34

[Margaret Chan]

Just get to apply the patch to my mozilla tree (using the OEM branch).  The
only difference I can see is that the assertion statement is gone now.
As I've said earlier, I don't see any profile migration problem on my
Solaris box.

Comment 35

[John Gaunt (redfive)]

The result of the USER/LOGNAME call actually gets used for the new name of the
6.0 profile, not to find the old profile ( since we use the HOME variable for
that and there is only one directory - .netscape/ that holds everything ).
Setting the variable as default is actually a good idea ( duh john ), as it will
allow the profile to be migrated even if there is no USER or LOGNAME variable
set ( a situation that I can't really imagine happening, but I guess... ).

Comment 36

[John Gaunt (redfive)]

Attachment: v4 of patch, sets profileName to "default" if USER and LOGNAME come back null

Comment 37

[John Gaunt (redfive)]

previous diff is for the OEM branch.

will get a trunk up soon. Can someone please review the string handling closely
( with regard to assignment of "default" ). thanks. -jg

Comment 38

[John Gaunt (redfive)]

Attachment: v4 of patch ( TRUNK ), set profileName to "default"

Comment 39

[Conrad Carlen (not reading bugmail)]

If we didn't get the profile name from any of the environment vars, isn't it
still nsnull when the call to ProfileExists() happens. If we don't have a
profile name and "default" is going to be used, do it before calling
ProfileExists().

Comment 40

[John Gaunt (redfive)]

Ok, creating attachments that set the default in the right place. Wasn't sure
how to deal with the char* stuff and didn't want to add a bunch of dup/free
stuff, so I changed the existing char*s to nsCAutoStrings and everything worked.
BUT there could be allocation/deallocation stuff I don't know about. I have both
OEM branch and TRUNK 

Comment 41

[John Gaunt (redfive)]

Attachment: OEM branch, patch with proper default

Comment 42

[John Gaunt (redfive)]

Attachment: TRUNK, patch with proper default

Comment 43

[Conrad Carlen (not reading bugmail)]

That's good - in terms of where the default is set.

The way the nsCAutoStrings are being used with PR_GetEnv I think will leak.

> nsCAutoString unixProfileName( PR_GetEnv(PROFILE_NAME_ENVIRONMENT_VARIABLE) );

That string is not going to own and thus free the memory returned by
PR_GetEnv(). Unless we have a string class which will take ownership of the
buffer passed to it, you should get the result of PR_GetEnv() into a temp var,
construct the nsCAutoString with that, and then free the temp var.

Comment 44

[John Gaunt (redfive)]

I'm told that the nsCAutoString tempStr( char* ) copies the char* into a stack
buffer, and that it won't leak. This would appear to alleviate the other
possible issue of the environment variable changing or moving before this
operation is finished, since we would copy the char* instead of only having a
pointer into the environment list.

Comment 45

[Conrad Carlen (not reading bugmail)]

Right, nsCAutoString tempStr( char* ) does copy the char* into a stack
buffer. But what happens to the memory returned by PR_GetEnv from which it was
copied? Looking at the existing code, it's not being freed either. Question is -
is that right? It's not a fault with your patch though.

Comment 46

[John Gaunt (redfive)]

from what I can tell ( from reading Stevens ) the environment variables get
passed into the program and stored in memory. All getenv does is return a
pointer into that space, which is why it's dangerous to always count on that
pointer because if any environment variables are redfined or added the
environment list can move. Thereby giving one a pointer to an old variable. It
doesn't appear that getenv allocates any memory at all.

I did run a little test that called getenv 50 times and stored in a char*. I
didn't see any increase in memory. In addition the address pointed to was always
the same as returned by the the getenv call and was always constant. ( unless I
called putenv and then it changed as the environment list moved )It was also a
high number ( initially ) which points to the list being in the correct place in
high memory, above the stack, with the command line args.

Comment 47

[Conrad Carlen (not reading bugmail)]

Alright, sounds good. Thanks for looking into that. It seems that, since
PR_GetEnv is our own, somebody should have put a comment in the header about
whether to free what it handed back. r=ccarlen

Comment 48

[(not reading, please use [e-mail] instead)]

john, ccarlen and racham are the people to ask for reviews.

there is some documentation on those environment variables, but it might be
slightly out of date.

see http://www.mozilla.org/unix/installer.html

conrad, once this patch makes it into the trunk, can you update (and take
ownership) of that document?

Comment 49

[Conrad Carlen (not reading bugmail)]

Yes. I'll make sure it's still accurate an updated with the additions made by
this patch.

Comment 50

[John Gaunt (redfive)]

Note: this has been checked into the OEM branch, but not the trunk yet. Have
never recieved sr=.

Comment 51

[Shannon Diener]

Works great on the OEM_BRANCH!  Remotely logged into HPUX from Linux and from
another HPUX box, my profile migrated from both.  

Comment 52

[John Gaunt (redfive)]

sr=bienvenu from email

thanks

Comment 53

[John Gaunt (redfive)]

Checked into trunk. IT's DEAD!!!!

Comment 54

[John Gaunt (redfive)]

This fix didn't take on SunOS 5.6. complained about ambiguous cast from
nsCAutoString to bool in the if ( ! unixProfileName ||  section
SO....
anyone know a good way to deal with these strings?

Comment 55

[John Gaunt (redfive)]

error conditions:

c++ -o nsProfileAccess.o -c -DOSTYPE=\"SunOS5\" -DOJI   -I../../dist/include
-I../../dist/include      -I/usr/openwin/include   -fPIC  -fno-rtti
-fno-handle-exceptions -O  -DNDEBUG -DTRIMMED -DMOZILLA_CLIENT -include
../../config-defs.h -Wp,-MD,.deps/nsProfileAccess.pp nsProfileAccess.cpp
../../dist/include/nsAReadableString.h: In method `int
basic_nsAReadableString<short unsigned int>::Compare(const short unsigned int *)
const':
In file included from ../../dist/include/nsAWritableString.h:29,
                 from ../../dist/include/nsIAtom.h:19,
                 from ../../dist/include/nsString2.h:47,
                 from ../../dist/include/nsString.h:42,
                 from nsProfileAccess.h:24,
                 from nsProfileAccess.cpp:22:
../../dist/include/nsAReadableString.h:888: warning: conversion to `const
basic_nsAReadableString<short unsigned int> &' from rvalue
`basic_nsLiteralString<short unsigned int>'
../../dist/include/nsAReadableString.h: In method `int
basic_nsAReadableString<char>::Compare(const char *) const':
../../dist/include/nsAReadableString.h:888: warning: conversion to `const
basic_nsAReadableString<char> &' from rvalue `basic_nsLiteralString<char>'
nsProfileAccess.cpp: In method `unsigned int
nsProfileAccess::Get4xProfileInfo(const char *)':
nsProfileAccess.cpp:1127: ambiguous conversion from `nsCAutoString' to `bool'
nsProfileAccess.cpp:1127: candidate conversions include `const char *' and `char
*' nsProfileAccess.cpp:1127: `class nsCAutoString' used where a `bool' was
expected nsProfileAccess.cpp:1127: in argument to unary !
nsProfileAccess.cpp:1128: ambiguous conversion from `nsCAutoString' to `bool'
nsProfileAccess.cpp:1128: candidate conversions include `const char *' and `char
*' nsProfileAccess.cpp:1128: `class nsCAutoString' used where a `bool' was
expected nsProfileAccess.cpp:1128: in argument to unary !
nsProfileAccess.cpp:1134: ambiguous conversion from `nsCAutoString' to `bool'
nsProfileAccess.cpp:1134: candidate conversions include `const char *' and `char
*' nsProfileAccess.cpp:1134: `class nsCAutoString' used where a `bool' was
expected nsProfileAccess.cpp:1134: in argument to unary !
nsProfileAccess.cpp:1137: ambiguous conversion from `nsCAutoString' to `bool'
nsProfileAccess.cpp:1137: candidate conversions include `const char *' and `char
*' nsProfileAccess.cpp:1137: `class nsCAutoString' used where a `bool' was
expected nsProfileAccess.cpp:1137: in argument to unary !
nsProfileAccess.cpp:1149: ambiguous conversion from `nsCAutoString' to `bool'
nsProfileAccess.cpp:1149: candidate conversions include `const char *' and `char
*' nsProfileAccess.cpp:1149: `class nsCAutoString' used where a `bool' was
expected nsProfileAccess.cpp:1149: ambiguous conversion from `nsCAutoString' to
`bool' nsProfileAccess.cpp:1149: candidate conversions include `const char *'
and `char *' nsProfileAccess.cpp:1149: `class nsCAutoString' used where a `bool'
was expected nsProfileAccess.cpp:1149: ambiguous default type conversion for
`operator &&' ../../dist/include/nsBufferHandle.h: At top level:
../../dist/include/nsBufferHandle.h:163: warning: types cannot be defined inside
reinterpret_cast
../../dist/include/nsBufferHandle.h:163: warning: types cannot be defined inside
reinterpret_cast
gmake[3]: *** [nsProfileAccess.o] Error 1 gmake[3]: Leaving directory
`/export2/tinderbox/SeaMonkey/SunOS_5.6_Depend/mozilla/profile/src' gmake[2]:
*** [install] Error 2 gmake[2]: Leaving directory
`/export2/tinderbox/SeaMonkey/SunOS_5.6_Depend/mozilla/profile' gmake[1]: ***
[install] Error 2 gmake[1]: Leaving directory
`/export2/tinderbox/SeaMonkey/SunOS_5.6_Depend/mozilla' gmake: *** [build] Error 2

Comment 56

[geetha.vaidyanaathan]

I am seeing this problem of Migration if I am remotely logged onto another Sparc
machine . 

Proxies , Bookmarks , addressbook nothing gets migrated
I have tried to remotely log on to another Solaris 2.8 machine from my machine
which is Solars 2.7 , removed my ~/.mozilla and then bring NS6.0A 

Following is the output snippet.. while running netscape_debug

----------------

...
Registering plugin 19 for: "application/x-java-bean;version=1.3","Java(tm)
Plug-in",""
Registering plugin 20 for:
"application/x-java-bean;jpi-version=1.3.0_02","Java(tm) Plug-in",""
start of pref migration
failed to migrate properly.  err=-2142044161
creating new nsJSAimChatRendezvous
Setting content window
*** Pulling out the charset
Loading page specified via openDialog
in SetSecurityButton
Error loading URL http://www.sun.com/: 804b0002 
...


------------------------------------
BTW.. it is also trying to load www.sun.com instead of
sunweb.central (which is what is set as Hompage in my Netscape4.x)

Comment 57

[geetha.vaidyanaathan]

Adding CC

Comment 58

[John Gaunt (redfive)]

Attachment: Super-cool patch for the trunk, fixed gcc 2.7.3.2 compilation problem

Comment 59

[John Gaunt (redfive)]

Attachment: OEM version of appove patch, since original patch was already checked into branch, this one looks a little different

Comment 60

[John Gaunt (redfive)]

Just added 2 new patches. The ONLY things different in these patches are the way
I test the nsCAutoString for null, the logic hasn't changed any. Please verify I
still have module owner approval/review just to be safe. :-)

adding scc to the cc list, since he gave me the string fix asking for his sr=

Comment 61

[Scott Collins]

might be better as

  nsCAutoString profileLocation(unixProfileDirectory +
NS_LITERAL_CSTRING("/.netscape"));

...depending on how |profileLocation| is used in the rest of the function.
sr=scc, I understand you will look at changing this along with your next round
of fixes.

Comment 62

[John Gaunt (redfive)]

fixed in trunk and Netscape_6_0_OEM_BRANCH

Comment 63

[Barrett Lindstrom]

Verified fixed on OEM_branch build 20010214 (HP beta release) on HPUX 11.00