16600 - startup problems if no write access to component.reg

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P3)

Description

[Ben Bucksch (:BenB)]

If I install moz with another user then the one, who first starts it, moz exits
w/o error after
MOZILLA_FIVE_HOME=/mnt/user/src/linux/mozilla/obj-linux/dist/bin
  LD_LIBRARY_PATH=/mnt/user/src/linux/mozilla/obj-linux/dist/bin
      MOZ_PROGRAM=./apprunner
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
nsNativeComponentLoader: autoregistering begins.

when i start moz with a user, that as write access to MOZILLA_FIVE_HOME, it
starts under this user, but crashes under every other (not having write access)
saying:
Assertion failure: (offset < reg->hdr.avail), at
/usr/src/mozilla/modules/libreg/src/reg.c:1533

If I change access rights, moz starts.

I'm using CVS yesterday, no debug, optimized on redhat 6.0 (egcs-2.91.66)

Comment 1

[Daniel Veditz [:dveditz]]

If the registry has already been created, why are these additional users trying
to re-run autoreg?

And even if they are, how did the filesize get screwed in the registry header?
sounds like the registry was never closed properly. The "self-repair" code
doesn't get run in read-only mode I just noticed, but it shouldn't have to, of
course. We have to make sure the registry gets flushed or closed properly!

Comment 2

[Mike Shaver (:shaver emeritus)]

I'll make you a deal, Dan.  You provide nsIRegistry::flush, and I'll make the
component manager flush at the end of autoreg.

OK?

Comment 3

[Daniel Veditz [:dveditz]]

I've got NR_RegFlush sitting in my tree. I'll start on nsIRegistry::Flush.

Comment 4

[Daniel Veditz [:dveditz]]

Flush is checked in. You can also accomplish the same thing by closing the
registry.  Even if the underlying refcount doesn't allow the file to physically
close I still flush at that point.

Comment 5

[Daniel Veditz [:dveditz]]

I don't know if calling flush is going to solve this problem. On windows at
least I've verified that NR_ShutdownRegistry *is* getting called, which will
flush and close the registry.

I'm unclear on why this is failing.

Comment 6

[Mike Shaver (:shaver emeritus)]

Ben, does this still happen?

Comment 7

[Ben Bucksch (:BenB)]

No, component.reg is created with 664.

However, it still coredumps, if component.reg doesn't exist and it has no write
access to MOZILLA_FIVE_HOME.

Comment 8

[Mike Shaver (:shaver emeritus)]

got a stack trace?

Comment 9

[Ben Bucksch (:BenB)]

No.

Comment 10

[Kevin Puetz]

This just bit me on linux/powerpc when I forgot tonclude a components.reg in the
M15 tarball, I'll get you a stack trace for it.

Comment 11

[Ben Bucksch (:BenB)]

The meta bug got [nsbeta2+].

Comment 12

[Daniel Veditz [:dveditz]]

I don't understand this bug. We won't run without a component.reg, but we don't 
need to write to it once a correct one exists. The original problem was that we 
created it incorrectly the first time, but it must be created as part of the 
installation procedure. Run "regxpcom" if you don't want to run mozilla itself 
to do it.

Comment 13

[Ben Bucksch (:BenB)]

Daniel, when I last tested it (half a year ago), it crashed. it shouldn't.

Apart from that: If I understood jtang (or whoever it was) correctly, the
component.reg and corresponding file for JS components are just some kind of
cache for the registration. We could just issue a bold warning and then
go on running, if we can't write the "cache".

Comment 14

[Jeffrey Baker]

I can't reproduce this with linux 2000080409 M18.  I untarred the nightly as
root, then started it as jwb, and everything worked fine.  Suggest WFM.

Comment 15

[leger]

Per asa "We're not seeing this in mozilla M17 builds."

Comment 16

[Ben Bucksch (:BenB)]

> Suggest WFM.

If anything, this is /fixed/. This bug was there some time ago.

Comment 17

[Grace Bush]

I installed M17 build (2000080414) as gbush and paw was able to run using his 
login
worksforme

Comment 18

[Daniel Veditz [:dveditz]]

The basic bug was *fixed*; I worked on part of it so I know. I believe this bug 
was left open for the case when there was no component.reg at all (an 
installation failure, basically) when we probably could just build and keep 
the info in memory -- but that should be reopened as a new bug.

I'm going to mark this fixed.

Comment 19

[David Krause]

Are you sure this bug is fixed.  I'm using a cvs tip build from about 6 hours ago.

[david@ender mozilla]$ strace -e open -f ./mozilla 2>&1 | grep Permission
[pid 18332] open("/usr/local/mozilla/component.reg", O_RDWR) = -1 EACCES
(Permission denied)

This is after running mozilla once with a user that has write permission to
create the initial files and register the components.

Comment 20

[Ben Bucksch (:BenB)]

David, does Mozilla work? This bug is about Mozilla not working at all, if the
user who first starts Mozilla (or maybe later) has no write access to the inst bin.

Comment 21

[David Krause]

Ben, ok maybe this is fixed and there is a separate bug.   I don't think mozilla
should be opening that file as RDWR (read-write) after the first run though.
I'm going to mark this bug as fixed again.  Should we make a separate bug for
this issue?

Comment 22

[Daniel Veditz [:dveditz]]

I believe there already is such a bug. Mozilla first tries to open the 
component.reg RW, but if it can't it tries RO. It doesn't fail so it's not this 
bug, but I remember someone reporting it.

The porkjockies may do away with component.reg in its current form anyway, hang 
out there for more info.