Closed Bug 79520 Opened 23 years ago Closed 23 years ago

./mozilla crashs on first start, if not run as install user

Categories

(Core Graveyard :: Profile: BackEnd, defect)

Product:
Core Graveyard
Component:
Profile: BackEnd
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 42184

People

(Reporter: BenB, Assigned: ccarlen)

References

Details

(Keywords: crash) 

From bug 42184 (modified):
su userA (owns <installfolder>)
THERE=<installfolder>
(cd $THERE; ./regxpcom)
(cd $THERE; ./regchrome)
touch $THERE/chrome/user-skins.rdf
touch $THERE/chrome/user-locales.rdf
Do not run mozilla as userA. Instead try it as userB.


I tried that, but upon first start as normal user, ./mozilla crashed:
[userB <installfolder>]$ ./mozilla
./run-mozilla.sh ./mozilla-bin
MOZILLA_FIVE_HOME=<installfolder>
LD_LIBRARY_PATH=<installfolder>:<installfolder>/plugins
LIBRARY_PATH=<installfolder>:<installfolder>/components
SHLIB_PATH=<installfolder>
LIBPATH=<installfolder>
ADDON_PATH=<installfolder>
MOZ_PROGRAM=./mozilla-bin
MOZ_TOOLKIT=
moz_debug=0
moz_debugger=
New location for profile registry and user profile directories is ->
/home/<userB>/.beonex

I then started ./run-mozilla.sh as normal user - all were fine. After that,
./mozilla started fine, too.
Blocks: 42184
Keywords: crash
is there any reason why this is NO dupe of 42184, which you mentioned??
You need write access to the install dir for the first run (bug 42184). So if
you start Mozilla as a different user (this bug) you don't have write access to
the install dir and you fail.
That it works after the first start (just like in bug 42184) make it looking
even more like a dupe.

> is there any reason why this is NO dupe of 42184, which you mentioned??

It depends on that bug: it is a part of it.

> That it works after the first start (just like in bug 42184)

No. bug 42184 is primarily about he fact that I have to run it once as the user
who owns the install. Here, I'm running it once as another user.

Actually, it could be that this bug is completely unrelated to bug 42184 and
that Mozilla just crashes on the first start.


*** This bug has been marked as a duplicate of 42184 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Please explain. I explicitly said, that this is *not* identical to bug 42184.
REOPENing.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Actually, you said it might not be the same.  It appears to be the same bug, but
approached from a different way of getting at it.  Please explain why you think
it is not the same bug, to help me understand.  Thanks.
Actually, it is not an XPCOM bug, so I am re-assigning it to the default owner.
 He might know what the problem with this bug is, and better understand what is
going on.
Assignee: kandrot → ssu
Status: REOPENED → NEW
Component: XPCOM → Installer
QA Contact: scc → gemal
QA Contact: gemal → gbush
*** Bug 91314 has been marked as a duplicate of this bug. ***
I reported the duplicated bug.  Sorry.

Hrm.  What it looks like to me is that there is a larger problem, causing
segv's.  What is happening, at least in last night's CVS, is that it is trying
to open a file.  [This is based upon truss output on Solaris 8] This file does
not exist [errno is ENOENT], so Mozilla tries to create it.  This fails, since
the user does not have write permission [errno is EACCES].  It then appears that
Mozilla is blindly assuming that the file has been created, and then re-opens
the file, but gets -1 [ENOENT].  Here's the relevant truss -f -rall -wall
output: ====
21958:  open("/usr/local/src/building/mozilla-raw/bin/component.reg", O_RDWR)
Err#2 ENOENT
21958:  stat("/usr/local/src/building/mozilla-raw/bin/component.reg",
0xFFBEEEB0) Err#2 ENOENT
21958:  open("/usr/local/src/building/mozilla-raw/bin/component.reg",
O_RDWR|O_CREAT|O_TRUNC, 0666) Err#13 EACCE
S
21958:  open("/usr/local/src/building/mozilla-raw/bin/component.reg", O_RDONLY)
Err#2 ENOENT
21958:      Incurred fault #6, FLTBOUNDS  %pc = 0xFF184E78
21958:        siginfo: SIGSEGV SEGV_MAPERR addr=0x0000004C
21958:      Received signal #11, SIGSEGV [caught]
21958:        siginfo: SIGSEGV SEGV_MAPERR addr=0x0000004C
21958:  sigprocmask(SIG_SETMASK, 0xFEAEF010, 0x00000000) = 0
21958:  sigaction(SIGSEGV, 0xFFBEEFE0, 0x00000000)  = 0
21958:  sigprocmask(SIG_SETMASK, 0xFEAFADE0, 0x00000000) = 0
21958:  setcontext(0xFFBEF198)
21958:      Incurred fault #6, FLTBOUNDS  %pc = 0xFF184E78
21958:        siginfo: SIGSEGV SEGV_MAPERR addr=0x0000004C
21958:      Received signal #11, SIGSEGV [default]
21958:        siginfo: SIGSEGV SEGV_MAPERR addr=0x0000004C
21958:    *** process killed ***
21943:  waitid(P_PID, 21958, 0xFFBEF000, WEXITED|WTRAPPED|WNOWAIT) = 0
21943:  ioctl(0, TIOCGPGRP, 0xFFBEEFBC)     = 0
21943:  ioctl(0, TCGETS, 0x000391B8)      = 0
21943:  waitid(P_PID, 21958, 0xFFBEF000, WEXITED|WTRAPPED) = 0
Segmentation Fault
21943:  write(2, 0x00039085, 19)      = 19
21943:     S e g m e n t a t i o n   F a u l t\n
21943:  brk(0x0003D798)         = 0
21943:  brk(0x0003D598)         = 0
21943:  unlink("/tmp/sh219430")       = 0
21943:  llseek(0, 0, SEEK_CUR)        = 534280
21943:  _exit(139)
====

Maybe we should first create a macro for use when open()-ing a file, like
Stevens does in APUE.  We can call it OPEN or something.  This then make sure
that we're getting a positive int back from the open and, if not, gracefully
exits if told to.  This can then pretty much be dropped down in place of the
open()s, with maybe *one* extra argument: message to say if the open fails.

For the record, the following are the files [and directories] created when
Mozilla is started initially:

bin/
    component.reg  [the villain of the truss output above]all-locales.rdf
    chrome/
           all-locales.rdf
           all-packages.rdf
           all-skins.rdf
           user-locales.rdf
           user-skins.rdf
           overlayinfo/
                       communicator/content/overlays.rdf
                       editor/content/overlays.rdf
                       messenger/content/overlays.rdf
                       navigator/content/overlays.rdf
    components/
               xpti.dat
               xptitemp.dat

Hope this helps.

*** Bug 100109 has been marked as a duplicate of this bug. ***
this bug looks more like dupe of bug 42184, than one that blocks it.  You are
experiencing the same permissions problem eventhough you are running into this
bug using different users.

I also fail to see how this could be an install problem.  It looks like your
output points to profiles.  Trying the profile folks to see if they have a clue.

Are you still able to reproduce this?
Assignee: ssu → ccarlen
Component: Installer → Profile Manager BackEnd
QA Contact: gbush → ktrina
It's not a profile mgr problem since the problem was caused by XPCOM component
registration creating/opening component.reg. All of the files created by profile
mgr are in ~/ so there should not be access problems. I also think it's a dup of
bug 42184.

*** This bug has been marked as a duplicate of 42184 ***
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
Verified as a dupe of bug 42184
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.