Closed Bug 51164 Opened 24 years ago Closed 24 years ago

linux builds not shipping with component.reg

Categories

(SeaMonkey :: Build Config, defect, P3)

Product:
SeaMonkey
Component:
Build Config
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: xalkina, Assigned: granrosebugs)

References

(
URL
)

Details

(Keywords: crash, helpwanted)

Attachments

(2 files)

strace output for last downloaded build (this morning, local time)
80.62 KB, text/plain
Details
strace -f ./mozilla
81.52 KB, text/plain
Details
They crash little after testing for a file called 'component.reg'.
past two builds i've seen it not start for all kind of odd reasons, one was not finding "box.css", another simply terminated with "error 01" Funny thing is that it will often start OK when trying a couple of times more. Currently using linux m18 2000090206.
Christos, could this be related to bug 16600? R.K.Aa, what you are describing sounds like bug 41414, which has been marked WONTFIX since it is caused by a bug in glibc.
What are the "last two builds"? Worksforme on 2000090208
Latest builds are just latest builds when I can't get them started to see their ID. Where else could I find it? Anyway, now downloading latest to check again.
2000090206: had to try and start 5 times before moz actually started now: These errors appeared (- separates different attempts) WEBSHELL+ = 1 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userChrome.css' failed. Error code: 16389 CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://communicator/skin/box.css' failed. Error code: 16389 - CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userChrome.css' failed. Error code: 16389 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userContent.css' failed. Error code: 16389 - CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userChrome.css' failed. Error code: 16389 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userContent.css' failed. Error code: 16389 WEBSHELL+ = 2 CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://communicator/skin/formatting.css' failed. Error code: 16389 - CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userChrome.css' failed. Error code: 16389 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userContent.css' failed. Error code: 16389 WEBSHELL+ = 2 CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://global/skin/splitter.css' failed. Error code: 1638
Tried with latest build (which i still cannot tell). Tried more then 25 times, but can't get it to start. Touched component.reg, mozilla still refuses to start.
touch ~/.mozilla/default/chrome/userChrome.css - the file doesn't exist, there's a bug to change the text to a descriptive warning. touch ~/.mozilla/default/chrome/userContent.css - same. There used to be a way to get the build info from a file. Try asking in #mozilla on irc.mozilla.org
userChrome.css and userContent.css isn't the problem. The problem is that moz doesn't start when it fails to load files that ARE actually present.
2000090308 Starting moz first time with this and the previous build (and profile existed) I get this in console, and moz does not start till i start it again: $ ./mozilla & [2] 846 [dark@localhost package]$ ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=. LIBRARY_PATH=. SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= RegSelf Shift_JIS to Unicode converter complete RegSelf EUC-JP to Unicode converter complete RegSelf ISO-2022-JP to Unicode converter complete RegSelf Unicode to Shift_JIS converter complete RegSelf Unicode to EUC-JP converter complete RegSelf Unicode to ISO-2022-JP converter complete RegSelf Unicode to jis_0201 converter complete RegSelf Unicode to jis_0208-1983 converter complete RegSelf Unicode to jis_0212-1990 converter complete RegSelf Unicode to Big5 converter complete RegSelf Unicode to x-x-big5 converter complete RegSelf Big5 to Unicode converter complete *** Deferring registration of sample JS components -*- filepicker: registering (all right -- a JavaScript module!) registerSelf for remoteControl *** Registering -chat handler. *** Registering x-application-irc handler. *** Registering irc protocol handler. *** Registering sample JS components WEBSHELL+ = 1 WEBSHELL+ = 2 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userChrome.css' failed. Error code: 16389 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userContent.css' failed. Error code: 16389 -*- filepicker: Unloading component. *** Unloading sample JS components [2]+ Done ./mozilla
Don't know if it's related, but recently on my system, Mozilla will not load up. Here's what happens: [wd@dormcam package]$ ./mozilla ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=. LIBRARY_PATH=. SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= [wd@dormcam package]$
I had this problem with last two builds as well... yesterday and today. I had updated my rehdat 6.1 with redhat's new security fixed glibc. After going back to the glibc that came with 6.1, the problem has gone away. The glibc that came with redhat 6.1 is ... [kdowling@ken] ~ $ rpm -q glibc glibc-2.1.2-11 The one from 'updates' is... glibc-2.1.3-19.i386.rpm So, to me, this appears to be glibc related, just as discussed in bug 41414.
Just FYI, I have *not* updated the glibc libraries on my system, and I cannot load Mozilla as of a couple days ago. See my last above message for what happens. Is this a different problem altogether?
This build... 8026447 Sep 3 09:35 mozilla-i686-pc-linux-gnu.tar.gz ... crashes for me during startup. Each and every time. No window is rendered and no error messages in console. The build from Sep. 1 started fine. $ rpm -q glibc glibc-2.1.3-15
All recent builds start and run properly on Slackware Linux 7.1, kernel 2.4.0-test7.
FYI Slackware 7.1 is glibc 2.1.2
I am writing this comment on build 2000-09-03-08-M18. I think it crashed on startup the first time I ran it, but since then it's been OK. Has anybody seen this on a debug build so they can get a stack trace (or even an opt build with symbols)?
Is anyone still seeing this? If yes, please try getting perhaps a talckback build to crash with. There is a bug on new window performance enhancement (49141) for those interested.
Yes, I'm getting this problem still. I can't use Mozilla on my system anymore at all. I don't get a talkback, either. I've tried deleting my ~/.mozilla directory, and I've also tried using the "installer" version of Mozilla. See my comment at 2000-09-03 14:24 above for how far I get.
Severity: normal → blocker
*** Bug 51225 has been marked as a duplicate of this bug. ***
Marking confirmed since many people see this (although I don't). Also retitling to make it easier to find.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Last two builds for Linux don't open a window → Linux builds crashing on startup for some people
I'm adding the smoketest keyword in the absence of information. It would be useful to know: * what percentage of people see it (and why some, and not others) * whether there is a workaround (such as moving .mozilla aside)
Keywords: smoketest
I agree with dbaron. Can anyone who still sees this with a new build after removing mozilla and with a new profile get the isntaller build and install talkback so that we have a stacktrace? Could you also state your linux version/distro?
Keywords: smoketest
Keywords: crash
Latest build i downloaded seems to be 2000090408, by checking file sizes in the download directories. Mozilla still won't start. I've already removed my .mozilla dir. I haven't upgraded my system lately, it's an RH6.2, based on glibc-2.1.3-15
RedHat 6.1 glibc-2.1.2-11 On my system Mozilla doesn't start, nor does it generate any talkback info. It just quietly dumps me back to my shell prompt.
Attached file strace -f ./mozilla —
My recent attachment shows the output from "strace -f" on the installer build (55208 Sep 4 09:27 mozilla-i686-pc-linux-gnu-installer.tar.gz) BuildID = "2000090408" (from ".../components/talkback/master.ini")
Some questions for those who are seeing the bug: * Did you install into your home directory or a system directory? Who owns the files for mozilla? * Which build did you download (installer, talkback, -sea (whatever that is), normal tar.gz, etc.)?
BTW, this bug seems to be covering multiple issues. The one for which this (and the duplicate) was originally reported seems to be the one where you see *no output* from mozilla. Perhaps the other symptoms should be other bugs? I'm not sure.
Ah-ha! I think you're onto something David. Running Mozilla as root works! (It's something that I'd *never* do otherwise... but it does work) I have a cron job that automatically downloads Mozilla and extracts it to /tmp/package Here's what the files look like: -rwxrwxr-x 1 8482 wheel 1656 Jun 16 20:54 mozilla I have no clue what this user "8482" is... Perhaps the user used to create the tar.gz package at Mozilla? What I find strange is that I have used this cron script to get Mozilla for quite a while now, and things just stopped working a couple days ago.
Works for me too when "root" starts Mozilla!
Strange things going on here: After succesfully starting Mozilla as "root", I can now start it as normal user.
Do you know if the UID/GID for component.reg were the same in older builds, or if that changed recently? It makes sense that it works once you run as root. component.reg only needs to be changed when one of the shared libraries is recompiled. The build is supposed to be run once when the build is done so that the distributed component.reg is correct. It's not yet clear where the problem lies, but more info could help.
Summary: Linux builds crashing on startup for some people → Linux builds installed as root crashing on startup
Since workaround exists, removing smoketest but nominating nsbeta3.
Keywords: smoketest → nsbeta3
As workarounds exist, why not fix it? Mozilla tries to create the file components.reg (it is not present in the linux package), it fails with a permission denied (the common user has no permission to write/create this file) then it segfaults. If started as root all works fine as the file component.reg can be created. So I think that the fix here shouldn't be so hard to find.
Helpwanted: we accept patches, feel free to write one. Since we have a workaround I'm reducing severity to major.
Severity: blocker → major
Keywords: helpwanted
Whiteboard: [workaround]
Yep... you beat me to it Diego... In the builds that were working fine, there already was a file called component.reg in the .tar.gz file. In the latest builds where I can't get it to work, there is no component.reg file in the archive. It bombs because I can't create a file in the /package directory as a regular user.
OK, leaf, why is components.reg not in the package? (Which package is it not in?)
I'm using mozilla-i686-pc-linux-gnu.tar.gz I also had the same trouble with the installer version for linux too. (installed as root, run as normal user)
Ok, here's my take on this bug. I really think this bug is actually 2 separate bugs that are already filed. 1) Many people recently upgraded to a newer glibc in the past several days. I think that they are seeing bug 41414, which was determined to be a bug in that particular glibc. 2) The rest of the people here seem to be having problems with write access to certain files. Mozilla has to be run once to create several files, such as component.reg. Please see bug 41057 "Mozilla should not need write access to the binary directory." and bug 42184 "Mozilla-bin must not write to bin dir during installation". CCing BenB, dveditz, and dougt to get their take on this.
david krause is spot on, i believe. component.reg is generated either at startup by mozilla-bin, or by regxpcom (a helper tool to pre-generate component.reg); i think that's the root of the originally reported problem.
ok, as david krause pretty much ofudn the problems, and they being already known, marking this invalid. Sadley, there is no other resolution for this.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Eh? A working component.reg is supposed to be shipped with every build. If it's not, that's a bug. Didn't this work until recently?
INVALID is not an adequate solution, because this *is* a problem with Mozilla. REOPENing. If the problem is known, either fix it, or mark it a dup or wontfix or whatever.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Since M10 i have always installed in the /tmp directory. I have write access there, i unpack as my own user, files belong to me, and this has always worked before, till this bug entered the scene. Is there some reason i suddenly am denied access to the /tmp/package ? In particular since it WILL start - one out of 20 times or thereabouts if i only write ./mozilla & OR: It will start almost EVERY time - IF i start it with ./mozilla -g -d gdb and then WAIT one minute before i type "run". This isn't a bug about lack of write access to create new files. The files are there. Moz simply doesn't find them. I did upgrade to latest errata of glibc but that was after this bug happened to me first time. If it is a glibc bug - why hasn't it taken effect before? I've used just about every nightly since ...sometime last year. File component.reg exists, belonging to my user, but still moz intermittanly fails loading it. This is from todays kickstart session where i did NOT wait one minute before typing "run". ALl the files moz didn't find already exists and belong to my user: [dark@localhost dark]$ cd /tmp/package [dark@localhost package]$ ./mozilla & [1] 680 [dark@localhost package]$ ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=. LIBRARY_PATH=. SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= WEBSHELL+ = 1 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userChrome.css' failed. Error code: 16389 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userContent.css' failed. Error code: 16389 WEBSHELL+ = 2 CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://communicator/skin/box.css' failed. Error code: 16389 [1]+ Done ./mozilla [dark@localhost package]$ ./mozilla & [1] 697 [dark@localhost package]$ ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=. LIBRARY_PATH=. SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= WEBSHELL+ = 1 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userChrome.css' failed. Error code: 16389 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userContent.css' failed. Error code: 16389 WEBSHELL+ = 2 [1]+ Done ./mozilla [dark@localhost package]$ ./mozilla & [1] 713 [dark@localhost package]$ ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=. LIBRARY_PATH=. SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= WEBSHELL+ = 1 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userChrome.css' failed. Error code: 16389 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userContent.css' failed. Error code: 16389 WEBSHELL+ = 2 [1]+ Done ./mozilla [dark@localhost package]$ ./mozilla -g -d gdb ./run-mozilla.sh -g -d gdb ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=. LIBRARY_PATH=. SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=1 moz_debugger=gdb /usr/bin/gdb ./mozilla-bin -x /tmp/mozargs732 GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... (gdb) run Starting program: /tmp/package/./mozilla-bin (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 744 (manager thread)] [New Thread 742 (initial thread)] [New Thread 745] WEBSHELL+ = 1 [New Thread 746] CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userChrome.css' failed. Error code: 16389 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userContent.css' failed. Error code: 16389 WEBSHELL+ = 2 [New Thread 757] CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://communicator/skin/button.css' failed. Error code: 16389 Program received signal SIGSEGV, Segmentation fault. 0x82fd618 in ?? () (gdb) quit The program is running. Exit anyway? (y or n) y [dark@localhost package]$ ./mozilla -g -d gdb ./run-mozilla.sh -g -d gdb ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=. LIBRARY_PATH=. SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=1 moz_debugger=gdb /usr/bin/gdb ./mozilla-bin -x /tmp/mozargs762 GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... (gdb) run Starting program: /tmp/package/./mozilla-bin (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 774 (manager thread)] [New Thread 772 (initial thread)] [New Thread 775] WEBSHELL+ = 1 [New Thread 776] CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userChrome.css' failed. Error code: 16389 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userContent.css' failed. Error code: 16389 WEBSHELL+ = 2 [New Thread 777] Program exited with code 01. (gdb) quit [dark@localhost package]$ ./mozilla -g -d gdb ./run-mozilla.sh -g -d gdb ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=. LIBRARY_PATH=. SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=1 moz_debugger=gdb /usr/bin/gdb ./mozilla-bin -x /tmp/mozargs782 GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... (gdb) run Starting program: /tmp/package/./mozilla-bin (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 794 (manager thread)] [New Thread 792 (initial thread)] [New Thread 795] WEBSHELL+ = 1 [New Thread 796] CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userChrome.css' failed. Error code: 16389 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userContent.css' failed. Error code: 16389 WEBSHELL+ = 2 [New Thread 797] [New Thread 799] CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://global/skin/checkbox.css' failed. Error code: 16389 Program received signal SIGSEGV, Segmentation fault. 0x82604e8 in ?? () (gdb) quit The program is running. Exit anyway? (y or n) y [dark@localhost package]$ ./mozilla -g -d gdb ./run-mozilla.sh -g -d gdb ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=. LIBRARY_PATH=. SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=1 moz_debugger=gdb /usr/bin/gdb ./mozilla-bin -x /tmp/mozargs846 GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... (gdb) run Starting program: /tmp/package/./mozilla-bin (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 858 (manager thread)] [New Thread 856 (initial thread)] [New Thread 859] WEBSHELL+ = 1 [New Thread 860] CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userChrome.css' failed. Error code: 16389 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userContent.css' failed. Error code: 16389 WEBSHELL+ = 2 [New Thread 861] Program exited with code 01. (gdb) run Starting program: /tmp/package/./mozilla-bin (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 864 (manager thread)] [New Thread 862 (initial thread)] [New Thread 865] WEBSHELL+ = 1 [New Thread 866] CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userChrome.css' failed. Error code: 16389 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userContent.css' failed. Error code: 16389 WEBSHELL+ = 2 [New Thread 867] [New Thread 868] CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://global/skin/splitter.css' failed. Error code: 16389 Program received signal SIGSEGV, Segmentation fault. 0x82b8b68 in ?? () (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) n Program not restarted. (gdb) quit The program is running. Exit anyway? (y or n) y [dark@localhost package]$ run bash: run: command not found [dark@localhost package]$ ./mozilla -g -d gdb ./run-mozilla.sh -g -d gdb ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=. LIBRARY_PATH=. SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=1 moz_debugger=gdb /usr/bin/gdb ./mozilla-bin -x /tmp/mozargs911 GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... (gdb) run Starting program: /tmp/package/./mozilla-bin (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 923 (manager thread)] [New Thread 921 (initial thread)] [New Thread 924] WEBSHELL+ = 1 [New Thread 925] CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userChrome.css' failed. Error code: 16389 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userContent.css' failed. Error code: 16389 WEBSHELL+ = 2 [New Thread 926] Program exited with code 01. (gdb) bt No stack. (gdb) run Starting program: /tmp/package/./mozilla-bin (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 929 (manager thread)] [New Thread 927 (initial thread)] [New Thread 930] WEBSHELL+ = 1 [New Thread 931] CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userChrome.css' failed. Error code: 16389 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///home/dark/.mozilla/default/chrome/userContent.css' failed. Error code: 16389 WEBSHELL+ = 2 [New Thread 932] [New Thread 933] CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://global/skin/formatting.css' failed. Error code: 16389 Program received signal SIGSEGV, Segmentation fault. 0x82c2418 in ?? () (gdb) bt #0 0x82c2418 in ?? () #1 0x400c2374 in nsProxyObjectManager::GetProxyForObject () from /tmp/package/./libxpcom.so #2 0x40587f41 in NSGetModule () from /tmp/package/components/libnecko.so #3 0x40fb7ad7 in NSGetModule () from /tmp/package/components/libgklayout.so #4 0x40e99e6e in NSGetModule () from /tmp/package/components/libgklayout.so #5 0x40e9aa88 in NSGetModule () from /tmp/package/components/libgklayout.so #6 0x40e9c4ed in NSGetModule () from /tmp/package/components/libgklayout.so #7 0x40e9c386 in NSGetModule () from /tmp/package/components/libgklayout.so #8 0x40e9bfc5 in NSGetModule () from /tmp/package/components/libgklayout.so #9 0x40e9ba1a in NSGetModule () from /tmp/package/components/libgklayout.so #10 0x40e99064 in NSGetModule () from /tmp/package/components/libgklayout.so #11 0x40e9921e in NSGetModule () from /tmp/package/components/libgklayout.so #12 0x40e9876f in NSGetModule () from /tmp/package/components/libgklayout.so #13 0x405882d6 in NSGetModule () from /tmp/package/components/libnecko.so #14 0x405c4516 in NSGetModule () from /tmp/package/components/libnecko.so #15 0x405c44da in NSGetModule () from /tmp/package/components/libnecko.so #16 0x405be95d in NSGetModule () from /tmp/package/components/libnecko.so #17 0x40576b2e in NSGetModule () from /tmp/package/components/libnecko.so #18 0x40576550 in NSGetModule () from /tmp/package/components/libnecko.so #19 0x400bc603 in PL_HandleEvent () from /tmp/package/./libxpcom.so #20 0x400bc516 in PL_ProcessPendingEvents () from /tmp/package/./libxpcom.so #21 0x400bd29d in nsEventQueueImpl::ProcessPendingEvents () from /tmp/package/./libxpcom.so #22 0x406d9ebf in NSGetModule () from /tmp/package/components/libwidget_gtk.so #23 0x406d9c7d in NSGetModule () from /tmp/package/components/libwidget_gtk.so ---Type <return> to continue, or q <return> to quit--- #24 0x40879aca in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0 #25 0x4087b186 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #26 0x4087b751 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #27 0x4087b8f1 in g_main_run () from /usr/lib/libglib-1.2.so.0 #28 0x407a37b9 in gtk_main () from /usr/lib/libgtk-1.2.so.0 #29 0x406da3ac in NSGetModule () from /tmp/package/components/libwidget_gtk.so #30 0x4045b11a in inflate_mask () from /tmp/package/components/libnsappshell.so #31 0x804da27 in JS_PushArguments () #32 0x804de86 in JS_PushArguments () #33 0x4025a9ab in __libc_start_main (main=0x804dd7c <JS_PushArguments+11244>, argc=1, argv=0xbffff8b4, init=0x804acf0 <_init>, fini=0x80534a4 <_fini>, rtld_fini=0x4000ad00 <_dl_fini>, stack_end=0xbffff8ac) at ../sysdeps/generic/libc-start.c:92 (gdb) quit The program is running. Exit anyway? (y or n) y [dark@localhost package]$ find ./* component.reg |grep component.reg ./component.reg component.reg [dark@localhost package]$ ls -la component.reg -rw-rw-r-- 1 dark dark 366290 Sep 5 11:18 component.reg [dark@localhost package] I am more tempted to belive this problem is related to bug 51267: "Intermittent failure loading CSS from JARs"
The previous extremely long comment describes a bug that is not the one described here, and should be filed separately.
If this is about needing to be root to run first time, then this is a dupe of existing bugs. If you think this is a totally new bug, then I agree to leaving this open. It just seems that there are a few bugs reproted in this bug. Perhaps a new fresh bug on the new issue should be opened.
so this is either 41057 "Mozilla should not need write access to the binary directory." or 42184 "Mozilla-bin must not write to bin dir during installation" correct? or am I missing something?
The problem here is that we used to ship a working component.reg, and now we don't.
so is this something that belongs to build config?
Assignee: asa → cls
Status: REOPENED → NEW
Component: Browser-General → Build Config
QA Contact: doronr → granrose
changed summary to accurately reflect bug. taking from cls.
QA Contact: granrose → leaf
Summary: Linux builds installed as root crashing on startup → linux builds not shipping with component.reg
Status: NEW → ASSIGNED
this time actually reassigning bug...
Assignee: cls → granrose
Status: ASSIGNED → NEW
looking at the mozilla tarballs, the component.reg file was in the 8/29/00 8am build, but not in the 8/29/00 8pm build. So someone checked in something during that period that stopped component.reg from being created. I am not seeing any errors in the build log file from component.reg. The URL for the query is in the URL link above if someone wants to take a crack at it.
URL: http://bonsai.mozilla.org/cvsquery.cg...
Status: NEW → ASSIGNED
looking at the linux build system, regxpcom is there, and if you run it it creates a component.reg. there were some changes made to the automation for hpux in that time frame. I've backed those changes out to test if that makes regxpcom start to work again on linux. we'll know more after tonight's build completes.
ccing jdunn so he's aware of the problem and the testing going on. probably no hpux component.reg tonight.
Hmm, I just checked a tarball today and the component.reg is definitely not there. Both the strace's show that also. I was getting mixed up with the fact that normally mozilla modifies the component.reg on startup but it doesn't create it. Is it possible for mozilla to create the component.reg on startup or can that only be part of the build process? I'm assuming not since some people here seem to be unable to start mozilla even with write permissions to bin directory. But then others here seem to be able to create the component.reg. I am smoking something or is that right?
Whiteboard: [workaround]
Yes, Mozilla creates the component.reg file if it does not already exist. Now, if Mozilla is run by a normal user the first time, Mozilla will find that there is no component.reg file, try to create it, and since there is no write access to the directory, it craps out. If it's run by root, it creates the component.reg file just fine.
If that is truely the case, then this bug can probably be marked as a dup of bug 42184. Even if we supply a component.reg in the tarball you still have to run mozilla as root or as a user with write permissions to create the rdf files in chrome and the xpti.dat files in components. If not then themes and mailnews do not work either. I've also noticed that mozilla likes to modify the component.reg during the first several startups. The way to test that is to copy the component.reg to another file and diff it each time you start mozilla. After the initial creation it changed it two more times before it left it alone.
Also see John Bandhauer's last comment in bug 39808, especially comment #2. "1) There is no conceptual difference between what we do with xpti*.dat and component.reg. I don't even see why we are talking about one file and not the other. 2) We are not currently shipping either file - they are created on first startup. 3) There is no clear better place to put them. These are not just 'per user' or 'per browser' they are 'per installation of xpcom'." Another noteworthy bug is bug 16600 "startup problems if no write access to component.reg" which has been fixed since it works fine after the first startup/registration/install of mozilla.
Ok, it looks like we're heading towards a goal where Mozilla can't just be untarred and dumped into a directory; it needs to be "installed" before it works. My cron job for automatically downloading and unpacking Mozilla for use worked perfectly up until about a week ago, but not anymore. I can almost accept that. BUT, I go and try the Mozilla Installer. (as root of course) Which, I would think should "Install Mozilla". Not quite. I immediately go to run Mozilla as a regular user. (being that running non-sysadmin tasks as root is a big no-no in the *NIX world) Sorry... doesn't work. Mozilla needs to create component.reg in the mozilla directory and it can't do that. I would *really* like for my cron job to continue working. But at the very least, I would think that the Mozilla Installer should work! If creating the component.reg file is a one-time shot and is system-wide for the installation of Mozilla, why doesn't the Mozilla Installer do it?
Just relax, we're working on shipping a component.reg with the tarball again; looks like a couple of stray lines added to the automation to get regxpcom to run on hpux (ha!) broke the running of regxpcom on linux. We backed out the change, and, sure enough, today's tarball has a pre-built component.reg. Knock yourself out.
OK. I'm happy now. ;-) According to the summary, this bug should be marked as fixed, eh? There are several different issues described here I think, but they all seem to be filed under separate bugs.
yes, this bug is now solely focused on why linux isn't shipping a component.reg in the mozilla-i686-gnu-pc-linux.tar.gz file which it should be doing (and jband is incorrect, we *do* ship a component.reg file - it saves on startup time). We've found the problem, now I'll figure out the best fix (probably to modify the mozilla/xpinstall/packager/Makefile.in to do the regxpcom rather than the automation) and check it in. Once it's checked in, I'll mark resolved/fixed. all the other issues mentioned here are covered under other bugs. If anyone cc'd on this bug feels they have a new issue, they need to file a new bug solely on that issue.
*** Bug 51575 has been marked as a duplicate of this bug. ***
Filed new bug 51677 about the final steps to making multi-user work. "Ship pre-generated chrome files if possible"
Every crash and "not found css" error that has cause moz to fail start the past weeks was cured when i upgraded to the latest RH errata of glibc! glibc 2.1.3-21 rpms were released on the 7th. The startup errors users of mozilla encountered is specifically referred to in the errata. I'm mentioning this here because SOME of the dups here are caused by flaws in glibc 2.1.3-19 and possibly earlyer releases of glibc 2.1.3. I have not had a single problem after i upgraded, nor with component.reg. Before the upgrade; these last weeks with moz was one eternal horror of crashes on startup.
Build ID: 2000091106, "complete" install over Internet with the installer. RH 6.2 / glibc 2.1.3-21. Install as "root". Despite upgrade of glibc to 2.1.3-21 (as of www.redhat.com/errata/) I still have to run once as root, before I can run as myself. I did erase $HOME/.mozilla/ first. However I see one improvement: No more complaints about missing .css files during startup. So the new glibc has certainly helped in some way. I feel somewhat confused, whether I report this to the appropriate bug. If I don't, please suggest a better one.
Svante, check out bug 42184 and bug 41057
*** Bug 52098 has been marked as a duplicate of this bug. ***
*** Bug 52941 has been marked as a duplicate of this bug. ***
2000-09-18-21 seems to be ok. Downloaded and gunzipped as root, started as normal user and it works.
I still see Mozilla dying with an 0920 build if I unpack the tarball and then have root do "chmod -R root:root package". Mozilla will either die almost immediately with no warning message or strace shows it appears to get stuck in a loop just calling poll. In either case, no windows ever appear. Here's some data that may be useful. If I unpack the tarball as a normal user, I see there's a component.reg. If I run regxpcom, it changes component.reg a lot. If I then run regchrome, it changes these files: package/chrome package/chrome/all-packages.rdf package/chrome/all-locales.rdf package/chrome/all-skins.rdf package/chrome/overlayinfo package/chrome/overlayinfo/communicator package/chrome/overlayinfo/communicator/content package/chrome/overlayinfo/communicator/content/overlays.rdf package/chrome/overlayinfo/navigator package/chrome/overlayinfo/navigator/content package/chrome/overlayinfo/navigator/content/overlays.rdf package/chrome/overlayinfo/messenger package/chrome/overlayinfo/messenger/content package/chrome/overlayinfo/messenger/content/overlays.rdf package/chrome/overlayinfo/editor package/chrome/overlayinfo/editor/content package/chrome/overlayinfo/editor/content/overlays.rdf If I now run Mozilla, these files are changed: package/chrome package/chrome/user-locales.rdf package/chrome/user-skins.rdf package/component.reg If I change the file owner after I run regchrome the Mozilla does not start and behaves as above. The key is the user-*.rdf files. Without them Mozilla does not work.
Moving back and forth... 2000-09-20-08 once again needs to be run as root before being able to open a normal-user window.
I believe there may be a connection between this bug, and 41057 which complains that the user should not be required to have write access to the installation directory. In my testing I found that the build process does not create component.reg. Instead it is created *in the installation directory* the first time the program is run. Having the user write into the installation directory is a "bad thing" as it prevents us from doing a shared installation.
No, read bug 41057 more carefully -- that one describes needing to write to the bin directory after the first run, which are simply bugs. There was a bug 42184 split off to describe needing to write on the first run which is an architectural issue that needs to be addressed separately (and which this could help).
> yes, this bug is now solely focused on why linux isn't shipping a > component.reg in the mozilla-i686-gnu-pc-linux.tar.gz file which it should > be doing Downloaded latest nightly. It contains a component.reg file. Marking FIXED. The other problems reported here recently are bug 41057 / bug 42184.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Before you close this, is the component.reg the right one? Mozilla scribbles all over the shipped copy so I wonder.
I have no idea. Reopen, if necessary.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: