From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011230 BuildID: 2001123017 Browser crashes on startup displaying message: /users/students4/level4/murdocsj/l4apps/mozilla/run-mozilla.sh: line 72: 2696 Segmentation fault $prog ${1+"$@"} Reproducible: Always Steps to Reproduce: Run "mozilla" Actual Results: Crash Expected Results: Normal startup The Mozilla binary is on an a NFS mounted drive. I (the owner of the files) can run Mozilla without any problem, however this bug occurs with another person. Permissions seem to be set correctly and I ran the shell script on the "Installation" section of the Release Notes. Mozilla 0.9.5 worked fine. Installation was made from the mozilla-i686-pc-linux-gnu-0.9.7-MathML-SVG-XMLterm.tar.gz file. Backtrace from GDB: Starting program: /users/students4/level4/murdocsj/l4apps/mozilla/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 1024 (LWP 2632)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 2632)] 0x401374a0 in nsComponentManagerImpl::FreeServices () at eval.c:41 41 eval.c: No such file or directory. in eval.c (gdb) bt #0 0x401374a0 in nsComponentManagerImpl::FreeServices () at eval.c:41 #1 0x400ffc91 in NS_ShutdownXPCOM () at eval.c:41 #2 0x080502b2 in main () at eval.c:41 #3 0x404cb177 in __libc_start_main (main=0x8050168 <main>, argc=1, ubp_av=0xbfffefe4, init=0x804b66c <_init>, fini=0x8050fcc <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbfffefdc) at ../sysdeps/generic/libc-start.c:129

The stack shows you're already in shutdown (unless it's bogus due to lack of debugging symbols, which is possible). The more interesting question is probably why you're already in shutdown rather than in startup.

where you uninstalling something?

I wasn't uninstalling anything. This version of Mozilla was installed in a new directory. The Segfault occurred on the first run of the browser, invoked simply by "mozilla". I do not know why it is in the shutdown process.

confirming

dbaron makes a good assertion - why is mozilla shutting down early. I can not reproduce this running the 0.9.7 mozilla build. where did you download: mozilla-i686-pc-linux-gnu-0.9.7-MathML-SVG-XMLterm.tar.gz

I downloaded the file from http://ftp.mozilla.org/pub/mozilla/releases/mozilla0.9.7/mozilla-i686-pc-linux-gnu-0.9.7-MathML-SVG-XMLterm.tar.gz Another user has tried Mozilla, using the same install (mounted by NFS) and the bug was the same. I tried downloading the standard binary distribution (without MathML, new SVG, and XMLterm) from http://ftp.mozilla.org/pub/mozilla/releases/mozilla0.9.7/mozilla-i686-pc-linux-gnu-0.9.7-MathML-SVG-XMLterm.tar.gz and it worked without any problem. This would seem to indicate that the bug could be something to do with the differences between the two packages. Should you have difficulty duplicating the bug then the things that differ between my installation and a standard one are mainly that the mozilla directory is in my home directory, it is owned by me (non root user) but used by other non root users, and that my home directory is on a NFS mounted drive (Solaris). Perhaps one of these factors is contributing to the problem. Also I have the Java plugin installed (a symlink from the JDK 1.3.1 installation) and the Shockwave flash plugin.

I get these same problems with any cvs build after November 24th, at least up to January 07. I am recompiling Jan 07 right now (deleted last compile, oops...) i'll be back with more info.

try without the plugins please.

I just tried running that build from my NFS mounted drive without any problems. without plugins. Could you try without plugins? I will try do download the JRE and flash....

I just added JRE 1.3.0 and flash and could startup fine. :-/

I just compiled Jan07 cvs here with the following options: ./configure --disable-debug --enable-optimize="-O3 -mcpu=k6 -fomit-frame-pointer -fexpensive-optimizations" gmake finished. # ./mozilla /usr/bin/mozilla-cvs-Jan07/dist/bin/run-mozilla.sh: line 72: 20543 Segmentation fault $prog ${1+"$@"} Now, I'm not a progammer of any sort here. I would like to help out as much as possible, please instruct me further so i can give you the data you guys need.

Bug 1170787 might be related to this.

which bug?

Gee, I knew i'd do that. MISTYPE. Bug 117087

chris, do these build options look sane?

I compiled Jan09 cvs with the following configure options: ./configure --disable-debug --enable-optimize="-O -mcpu=k6" I did this on the thought of trying as few compile flags as possible which I think should not cause problems. Result: Build completed, running dist/bin/mozilla runs as expected. I'll do more tests tommorrow gradually adding the flags I had before, to try to locate a problem flag.

I haven't heard any reports on -fexpensive-optimizations but -O3 builds are only known to work with more recent versions of gcc3 and sometimes intermittently with gcc2.95.x. Changing the target cpu scheduler (-mcpu) or opcodes that are used (-march) shouldn't matter. Oh, -fomit-frame-pointer won't work at all. xptcall needs the fp to work.

-fexpensive-optimizations is turned on with -O2 or higher. You could also try -fstrict-aliasing (not necessary with gcc3). Bug 53486 has a long discussion about optimization.

I think that this bug is INVALID, although it may be a dup of some other "using this gcc option does work" bug.

Doug, I'm not a Mozilla developer, so I don't know the criteria for an INVALID bug, but I'm not sure whether this is one. The build that the Segfault occurred with is a standard one, downloadable from http://www.mozilla.org/releases/. I didn't compile it myself. If the problem is due to a GCC optimisation then perhaps this flag should be removed from the distribution build of the SVG/MathML Mozilla. Also I don't think the crash is due to my setup, since it does not occur for the non SVG build. I will try running without plugins, however I cannot do this until Monday since I do not have access to the system in question until then.

I guess I am trigger happy. reopening....

SVG-Mathml-xmlterm is not a standard build despite it's presence on http://www.mozilla.org/releases/. The build was contributed by someone outside of mozilla.org & netscape's usual build automation system therefore there are no guarantees that it was built using acceptible build flags. Dawn, who contributed the SVG-Mathml-xmlterm build? This bug should be reassigned to them. And what happened to the required READMEs for each tarball that would identify the contributor? Contributed builds should be cleared marked on the releases page.

The README was right there in the tarball where it belongs. I've pasted it below. The build was created by David Hallowell who is a usual mozilla.org build contributor. It looks like he did --enable-optimize the normal way. David do you have some kind of gcc settings or environment variables set that affect optimization? -------------------------------------------------------- Mozilla 0.9.7 i686 Linux - MathML/SVG - David Hallowell built on Slackware Linux Options (.mozconfig): ac_add_options --disable-tests ac_add_options --disable-debug ac_add_options --enable-optimize ac_add_options --without-jpeg ac_add_options --without-zlib ac_add_options --without-png ac_add_options --enable-mathml ac_add_options --enable-crypto ac_add_options --enable-svg ac_add_options --with-extensions=default,xmlterm,irc,inspector Dependencies: /lib/ld-linux.so.2 /lib/libc.so.6 /lib/libdl.so.2 /lib/libm.so.6 /lib/libpthread.so.0 /usr/X11R6/lib/libX11.so.6 /usr/X11R6/lib/libXext.so.6 /usr/i386-slackware-linux/lib/libstdc++-libc6.1-1.so.2 /usr/lib/libgdk-1.2.so.0 /usr/lib/libglib-1.2.so.0 /usr/lib/libgmodule-1.2.so.0 /usr/lib/libgtk-1.2.so.0 -- David Hallowell david.hallowell@ukuug.org bugzilla email: dave532@uklinux.net

I have tried Mozilla without any plugins (apart from libnullplugin.so) and it still crashes. However it only crashes for users who do not own the files. It works fine for me, but for two other people who only have read permissions to the directory it crashes. This seems to be quite strange for an optimisation bug, is it likely that the compile options are to blame for this?

I built cvs Jan09 2002 with the following configure options: ./configure --disable-debug --enable-optimize="-O2 -mcpu=k6 -fstrict-aliasing" mozilla built successfully. But it segfaults with the now familar line 72 message. I will try later without -fstrict-aliasing, and see how that works out.

where are their profiles being stored? They do need to have write permission to this location.

Is this the same bug? The latest mozilla build (dated 11-Jan-2002) crashes every time I start it. This is what I did (using Win NT 4.0 Workstation SP6): I downloaded mozilla-win32-0.9.7-installer.exe and installed into a new directory, the downloaded mozilla-win32-talkback.zip, unzipped it and copied the files over those from the milestone release. My profiles, mail files, etc. have been in use since version 0.9. My profile wants to launch mozilla mail and nothing else. Every time I start mozilla 0.9.7 it crashes, and NT sais the instruction at 0x78001231 couldn't read memory at 0x00000000. Quality Feedback Agent doesn't notice the crash.

I compiled cvs mozilla from Jan12 2002 with the following configure options: ./configure --disable-debug --enable-optimize="-O2 -mcpu=k6 -march=i586" And I get the familiar line 72 bit and segfault. I will try without -march later tonight (slow box).

Okay, I compiled Jan 12 2002 cvs mozilla with the following configure flags: ./configure --disable-debug --enable-optimize="-O2 -mcpu=k6" builds successfully, segfaults with the infamous line 72 bit. I'm thinking -O2 is the culprit, Jan 09 2002 cvs built and ran with -O instead of O2 and the rest left the same. I will test this now, be back in a few hours.

DougT: I haven't changed any from the defaults concerning profiles, so I would imagine that the users profile will be held in their home folder (~/.mozilla). This is a NFS mounted drive and I see no reason why they would not have write permission to it (unless Mozilla removed them).

Okay. I configured Jan 09, 12 and 13 cvs this way: ./configure --disable-debug --enable-optimize="-O -mcpu=k6" Jan 09 built and ran successfully as I said in a previous comment. Jan 12 and 13 both build, yet with the same flags, they both segfault with the famous line 72 bit. I'm not sure what else I could do here to help, this doesn't make much sense to me.

Do a build following the instructions here: (note lines 2 and 3) http://www.mozilla.org/build/distribution.html I am not familar with every combination that you are trying.. Heck, I don't even know if that configure line is the same as listed above, but lets all get on the same page.

I'm sorry I'm not willing to download the full source again being on dial up. If there is something else I might be able to do that doesn't involve downloading the full source again, please let me know. Cheers

do a clobber build, then rebuild as described if you will.

Downloaded yesterday's (19 jan) nightly build today. Like all builds before, it crashes on startup. Do they ever try to run the software before they publish it?

Hans, sarcasm will get you nowhere. If this was failing for more than a *very* few people, we would stop all development and look at the problem. Asa, can you offer some installation tips so that we can ensure that Hans has a clean install?

Doug, sorry, of course you're right. I was getting annoyed spending literally hours downloading new versions (every download takes 20 minutes). The milestone build didn't crash. I downloaded nightly builds (at least) on 13 Jan, 15 Jan, 20 Jan, and 24 Jan. The 15 Jan ZIP was unreadable at all, and all other builds crashed during startup. I even tried to shut down every service that is not a part of WinNT but it didn't help. I removed 0.9.7 completely, then installed the milestone to a new directory, then copied the latest build over it, and it crashed again. I don't have DevStudio on my PC, is there anything else I can do to help you track down the problem?

Feb07 cvs compiles, AND runs with the -O3 flag. In the past, it would compile but segfault on run. The flags I used on my K6-2 300 was -O3 -mcpu=k6 -march=i586 . The difference in speed all around is VERY noticeable, with a page rendering twice as fast or more than before.

hans, what is the link to the file which crashes for you?

Doug, not quite sure what you mean. The command line in the Windows .lnk file? It's "D:\Programme\Mozilla.org\Mozilla_0.9.7\mozilla.exe" (no spaces around, no command line options). I'm going to try a more recent build in a few days and will report again.

Crashes with Feb 14 CVS, compiling with ac_add_options --disable-xprint ac_add_options --disable-tests ac_add_options --disable-accessibility ac_add_options --disable-debug ac_add_options --disable-dtd-debug ac_add_options --disable-pedantic ac_add_options --enable-optimize="-O3 -s -m686 -fomit-frame-pointer -malign-loops=0 -malign-functions=2 -malign-jumps=0" ac_add_options --enable-strip-libs ac_add_options --enable-mathml #uncomment to enable mathml ac_add_options --enable-crypto #uncomment to add PSM/SSL support now I'm trying to recompile with different optimize options and w/o mathml, let's see after a few hours.. backtrace: #0 0x401abe12 in XPTC_InvokeByIndex () at eval.c:88 #1 0x4082bdc8 in NSGetModule () from /opt/src/mozilla/dist/bin/components/libxpconnect.so #2 0x246c8bff in ?? () at eval.c:88 Cannot access memory at address 0x31565755

we don't work with this option: omit-frame-pointer Sorry.

Hans, what I want to know is the exact location of where you downloaded the executible from and exact steps to reproduce the bug. :-)

Doug, I downloaded the milestone from http://ftp.mozilla.org/pub/mozilla/releases/mozilla0.9.7/mozilla-win32-0.9.7-installer.exe and the nightly builds from http://ftp.mozilla.org/pub/mozilla/nightly/latest/. Are there any other places I should try? I installed the milestone following instructions, into the directory Mozilla_0.9.7 that was created during the install process. The milestone wored fine, apart from the fact that it crashed when I closed it (but this bug was addressed elsewhere I believe). After d/l'ing the nightly (filename mozilla-win32-talkback.zip), I unzipped it into a seperate directory, then copied the content of this directory over the files in the Mozilla_0.9.7 directory. (I made sure mozilla wasn't running.) All subdirs were copied along. I used windows drag&drop to copy everything in one go. From then on, mozilla crashed immediately after startup. I'm moving on to 0.9.8 today.

Correction to my previous comment: The filename for the milestone was mozilla-win32-0.9.7-installer.exe.

Changed to 0.9.8 milestone yesterday. Doesn't crash. Downloaded latest nightly today. Crashes again. Maybe there's something I'm missing about installing the nightly. Have been trying to locate documentation om mozilla.org, but haven't found it.

Try renaming your ~/.mozilla directory and ensure that you are not installing over a preexisting client.

Ouch! I just read comment 44. This is not the correct way to upgrade. it is an all or nothing system. Delete your prior installation then upgrade - or - upgrade into a clean directory. Open if problem still exists.