User-Agent: Build Identifier: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.6) Gecko/20040126 Mozilla doesn't come up. This started happening from last week. Reproducible: Always Steps to Reproduce: 1.run mozilla 2. 3. Actual Results: Nothing happens. Expected Results: Mozilla should have started
Created attachment 141603 [details] output after setting NSPR_LOG_MODULES=all:5. I am attchaing the log that I got by setting NSPR_LOG_MODULES=all:5.
Attachment #141603 - Attachment description: log → output after setting NSPR_LOG_MODULES=all:5.
Does it core? Or just not start? Any chance it is similar to bug 231104 that Phil found in Jan? Unfortunately I can't process the nspr log file, I am away and have limited net access. It would probably be more useful to just post either the last couple of offending lines or the lines that appear to be the error (i.e. compare a good nspr log output with one from this build using "mozilla about:blank"). And as always make sure you try running from a new profile.
would need a patch to block 1.7a at this point...
Flags: blocking1.7a? → blocking1.7a-
chris hofmann wrote: > would need a patch to block 1.7a at this point.. I wish we could avoid it that this platform is broken every 2nd milestone... ;-(
It doesn't core. it doesn't just start. The last few offending lines are pasted here. Afetr printing this stuff it never comes up. -1071967584[1400348c0]: WARNING: Cannot create startup observer : service,@mozilla.org/typeaheadfind;1, file nsAppStartupNotifier.cpp, line 113 WARNING: Cannot create startup observer : service,@mozilla.org/typeaheadfind;1, file nsAppStartupNotifier.cpp, line 113 -1071967584[1400348c0]: WARNING: dependent window created without a parent, file nsWindowCreator.cpp, line 128 WARNING: dependent window created without a parent, file nsWindowCreator.cpp, line 128 GFX: dpi=116 t2p=0.0833333 p2t=12 depth=24 we don't handle eBorderStyle_close yet... please fix me ++WEBSHELL == 1 ++DOMWINDOW == 1
without a DEC champion stepping forward to look into this, not going to block the release of beta.
Flags: blocking1.7b? → blocking1.7b-
is this still a problem? it looks like loading up typeaheadfind failed. have you tried clobbering extensions/typeaheadfind (or the whole tree) and rebuilding?
I had some success lately in tracking down the problem. When I removed the --enable-svg from .mozconfig script and built mozilla, I am able to bring the browser up. I am working towards a fix for this.
I think this is not a blocker anymore.
Alex: Can you take a look at this issue, please ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I don't see how the SVG code could lead to typeaheadfind not starting. Can you paste your .mozconfig, please? Which SVG rendering engine (gdi+,libart,cairo) are you using? Have you tried a clobber build?
Well, when I enabled SVG the browser itself is not coming up. I was using libart engine when I foud this problem. I removed the mozilla directory and pulled all over again, but still saw that mozilla not coming up. But, as I said earlier, I get the browser up when I removed the following lines from my .mozconfig ac_add_options --enable-svg mk_add_options MOZ_INTERNAL_LIBART_LGPL=1 MOZ_INTERNAL_LIBART_LGPL=1 The .mozconfig that gets me the browser working is ac_add_options --enable-tests ac_add_options --enable-debug ac_add_options --disable-optimize ac_add_options --enable-crypto
> ac_add_options --enable-svg > mk_add_options MOZ_INTERNAL_LIBART_LGPL=1 > MOZ_INTERNAL_LIBART_LGPL=1 These options are not sufficient to build SVG support. See the SVG build instructions at http://www.mozilla.org/projects/svg/build.html. (You need to specify a renderering engine, e.g. "ac_add_options --enable-svg-renderer-libart") If the renderer option is omitted, your build should stop with an error during the compilation of the SVG code. There is a bug (#234185) on adding a check that a renderer has been defined at configure time.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.