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.

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 ***

Please explain. I explicitly said, that this is *not* identical to bug 42184. REOPENing.

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.

*** 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?

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 ***

Verified as a dupe of bug 42184