Closed Bug 195654 Opened 22 years ago Closed 22 years ago

Mac OS X builds don't startup, crash on launch

Categories

(SeaMonkey :: General, defect, P1)

Product:
SeaMonkey
Component:
General
Platform:
PowerPC
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.4alpha

People

(Reporter: samir_bugzilla, Assigned: dougt)

References

Details

Attachments

(1 file)

patch v1
2.78 KB, patch
Details | Diff | Splinter Review 
The application will not startup (i.e., show the first window) starting with
2003-03-01 trunk builds of mozilla and netscape on Mac OS X.  This appears to be
a smoketest blocker.  Assigning to Jan for some quick traction on this issue.
Severity: normal → blocker
Priority: -- → P1
Target Milestone: --- → mozilla1.4alpha
*** Bug 195649 has been marked as a duplicate of this bug. ***
dupe of 195600? 
[i don't know if the same issue occurs for Mac]
Indeed, on Mac OSX 10.2.4 I've the same problem.



User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.4a) Gecko/20030228
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.4a) Gecko/20030228

As of build 20030301 the Mozilla browser doesn't startup anymore.
After 2 or 3 seconds from launch, Mozilla stops and my Mac returns to the finder.

Reproducible: Always

Steps to Reproduce:
1. Doubleclick Mozilla
2. wait a few seconds
3. OS returns to the finder, no Mozilla startup

Actual Results:  
Mozilla will not launch

Expected Results:  
Open the browser programm and start surfing


Using the 20030228 11 build still works fine !
I can no longer start the app after I deleted compreg.dat and xpti.dat files (to
force registration of components)
This looks like a regression after dougt's landing.
I'll try to backout it im my tree.

Confirming, backing out of dougt's changes fixes this problem.
Attached patch patch v1 — — Splinter Review 
varga, can you try this patch out?
Don't you want

#if defined(XP_UNIX) && !defined(XP_MACOSX)

?
yeah, that would be bery much preferable.
This patch doesn't seem to fix the problem.
It's been checked in anyway (probably accidentally).
Assignee: varga → dougt
03-Mar-2003 10:36  15.1M  downloaded and unstuffed, Virex 7.2 scanned it. It
won't start - the icon just bounces a little and then nothing.

I have similar issues with the nightly/latest-1.3, 2003-02-28-10-trunk,
2003-03-01-03-trunk and 2003-03-02-03-trunk, they all download, unstuff; however
Virex 7.2 does not scan the file. Virex launches and then just sits there, no
dialog other than my DATs appear upto date. Launching Mozilla results in the
icon just bounces a little and then nothing. At least one of these builds caused
Console to lanch and display a crash log. At this point I do not know which one
caused that.

The last good / uasble build I have is from the 2003-02-28-03-trunk. Details -
Mozilla 1.4a 2003022803

This is my first post here, advise if needed.
*** Bug 195723 has been marked as a duplicate of this bug. ***
My data points:

Latest-trunk 20030302 silently fails to launch, whereas latest-1.3 20030228
crashes with the following Console log:

dyld: /Applications/Mozilla/Mozilla.app/Contents/MacOS/mozilla-bin can't open
library: /usr/lib/libdl.0.dylib  (No such file or directory, errno = 2)
Mar  3 10:18:46 Frankie crashdump: Crash report written to:
/Users/fuy/Library/Logs/CrashReporter/mozilla-bin.crash.log

Sorry, didn't save the crash log, but could easily reproduce it if desired.
Summary: Mac OS X builds don't startup → Mac OS X builds don't startup, crash on launch
*** Bug 195593 has been marked as a duplicate of this bug. ***
don't mix the trunk and the 1.3 build crashes. they're probably unrelated.
This bug is tracking the trunk build DOA while bug 195435 is about the 1.3 OSX
build (or lack thereof)
I see the following in my syslog when trying to launch a trunk build:

Mar  3 09:47:11 Hugh-Caleys-Computer /usr/libexec/fix_prebinding: /Users/hcaley/
Mozilla.app/Contents/MacOS/mozilla-bin couldn't be prebound in the past, and pro
bably can't be prebound now.
Mar  3 09:47:11 Hugh-Caleys-Computer /usr/libexec/fix_prebinding: 2003-03-03 09:
47:11 -0800: prebinding for mozilla-bin done.
Mar  3 09:49:11 Hugh-Caleys-Computer /usr/libexec/fix_prebinding: fix_prebinding
 quitting for now. 
If libregviewer.dylib is present in the components dir, we crash with this stack:

#0  0x00ebdd68 in nsGenericModule::RegisterSelf(nsIComponentManager*, nsIFile*,
char const*, char const*) (this=0x33be70, aCompMgr=0x226e60, aPath=0x33bb00,
registryLocation=0x78b300
"abs:/Users/conrad/Development/TRUNK/MachSrc/mozilla/dist/MozillaDebug.app/Contents/MacOS/components/libregviewer.dylib",
componentType=0xefdfac "application/x-mozilla-native") at
nsGenericFactory.cpp:475/Users/conrad/Development/TRUNK/MachSrc/mozilla/xpcom/glue/
#1  0x00e5b3f8 in nsNativeComponentLoader::SelfRegisterDll(nsDll*, char const*,
int) (this=0x227180, dll=0x33a020, registryLocation=0x78b300
"abs:/Users/conrad/Development/TRUNK/MachSrc/mozilla/dist/MozillaDebug.app/Contents/MacOS/components/libregviewer.dylib",
deferred=0) at
nsNativeComponentLoader.cpp:388/Users/conrad/Development/TRUNK/MachSrc/mozilla/xpcom/components/
#2  0x00e5c9fc in nsNativeComponentLoader::AutoRegisterComponent(int, nsIFile*,
int*) (this=0x227180, when=0, component=0x33bb00, registered=0xbffff560) at
nsNativeComponentLoader.cpp:825/Users/conrad/Development/TRUNK/MachSrc/mozilla/xpcom/components/
#3  0x00e5ad1c in nsNativeComponentLoader::RegisterComponentsInDir(int,
nsIFile*) (this=0x227180, when=0, dir=0x2327b0) at
nsNativeComponentLoader.cpp:236/Users/conrad/Development/TRUNK/MachSrc/mozilla/xpcom/components/
#4  0x00e5a9f0 in nsNativeComponentLoader::AutoRegisterComponents(int, nsIFile*)
(this=0x227180, aWhen=0, aDirectory=0x2327b0) at
nsNativeComponentLoader.cpp:176/Users/conrad/Development/TRUNK/MachSrc/mozilla/xpcom/components/
#5  0x00e56eb0 in nsComponentManagerImpl::AutoRegisterImpl(int, nsIFile*, int)
(this=0x226e60, when=0, inDirSpec=0x0, fileIsCompDir=1) at
nsComponentManager.cpp:3082/Users/conrad/Development/TRUNK/MachSrc/mozilla/xpcom/components/
#6  0x00e57d30 in nsComponentManagerImpl::AutoRegister(nsIFile*) (this=0x226e60,
aSpec=0x0) at
nsComponentManager.cpp:3290/Users/conrad/Development/TRUNK/MachSrc/mozilla/xpcom/components/
#7  0x00dd8758 in NS_InitXPCOM2 (result=0x0, binDirectory=0x0,
appFileLocationProvider=0x0) at
nsXPComInit.cpp:556/Users/conrad/Development/TRUNK/MachSrc/mozilla/xpcom/build/
#8  0x00007108 in main (argc=1, argv=0xbffffadc) at
nsAppRunner.cpp:1574/Users/conrad/Development/TRUNK/MachSrc/mozilla/xpfe/bootstrap/
#9  0x000027d4 in _start (argc=1, argv=0xbffffadc, envp=0xbffffae4) at
/SourceCache/Csu/Csu-45/crt.c:267/SourceCache/Csu/Csu-45/
#10 0x00002654 in start ()
(gdb) 

mLibraryDependencies contains garbage.
Remove libregviewer.dylib and it launches just fine.

regviewer was removed from the build last week, see bug 181136.
reporters - 

make sure that you do a clobber build.  You must clobber and rebuild *everything*. 

Has anyone done that and still sees this problem?  
i cannot launch the 2003.03.03.11 commercial mach-o build. dbl-click the icon,
it bounces a few times in the Dock, then disappears. no Console output.
the 11 o'clock respin wasn't a clobber build.  A full clobber will take 4-5 hours.

AFAICT, all of the reports here (0, 1, 3-5, 12, 13-14, 15, and 21) refer to
downloaded nightlies rather than self-built. Sorry, I guess we're too trusting.
no need yet.  just spoke with jj and what he did was totally correct.
there are no XPT files in the nightly build.  that is causing the crash.


Sean: Any idea how this problem can be resolved?
Looks like a possible packaging problem as dougt identified in comment 25: I
copied netscape.xpt from the 2003022803 build to this morning's (2003030303)
build's components directory and the app started up.

Should this bug go to jj or leaf to look at the verification build boxes?
I have not seen a similar bug for WinXP, but I am getting the same result.  
Downloading the daily for WinXP I get a crash on startup.  No talkback as it 
seems to crash too early.  It crashes before the spash screen.  Clobbering 
mozilla user directory makes no difference.
If this is truly caused by the lack of .xpt files, then it sounds more like a
build or packaging issue than anything because there's no installer for the Mac
OSX system.

Either of these could be happening:
 * build did not generate .xpt files
 * build generated .xpt files, but was not packaged up
build/release.

let me know if I can help.
Assignee: dougt → jj
my bug.  was backed out.
Assignee: jj → dougt
Keywords: smoketest
By the way, I can't reproduce what William Stuart is seeing.

I just installed today's mozilla trunk build on WinXP SP1 and mozilla started up
just fine.  I installed into a new directory.
I think the WinXP bug that William Stuart is seeing is related to
http://bugzilla.mozilla.org/show_bug.cgi?id=195618

Try installing in a new directory. Deleted the mozilla user directory doesn't
have any affect. You need to delete the mozilla app directory.
Back to the original issue: Mac OS X build DOA.The nightly automation fails to execute xpt_link (which merges all .xpt files into a single one mozilla.xpt) which explains the lack to .xpt files in the build, and the consequent crash.xpt_link gets built from here:mozilla/xpcom/typelib/xpt/tools/xpt_linkand here's the output from the nightly build:> FATAL ERROR:> Duplicate IID detected (aa610f20-a889-11d3-8c81-000064657374) in> interface ::nsILocalFile from components/xpcom_io.xpt> and> interface ::nsINativeComponentLoader from components/xpcom_components.xptIn order to get a usable build out and tested and the tree open asap, I'll repackage today's build by hands with all the xpt files.Then a xpcom person should look at why xpt_link fails.
yup.  my bug.  the backout of my changes from yesterday should do the trick.

Downgrading to critical.
Severity: blocker → critical
Keywords: smoketest
uh oh, comment #34 was entered with a browser that apparently doesn't know how
to handle line breaks properly :-/
Here it is again:

Back to the original issue: Mac OS X build DOA.
The nightly automation fails to execute xpt_link (which merges all .xpt files
into a single one mozilla.xpt) which explains the lack to .xpt files in the
build, and the consequent crash.

xpt_link gets built from here:mozilla/xpcom/typelib/xpt/tools/xpt_link
and here's the output from the nightly build automation when running it:
> FATAL ERROR:
> Duplicate IID detected (aa610f20-a889-11d3-8c81-000064657374) in
> interface ::nsILocalFile from components/xpcom_io.xpt
> and
> interface ::nsINativeComponentLoader from components/xpcom_components.xpt

In order to get a usable build out and tested and the tree open asap, I'll
repackage today's build by hands with all the xpt files.

Then a xpcom person should look at why xpt_link fails, or how to avoid the
"Duplicate IID".

---
Dougt, with your recent changes backed out, will xpt_link behave tomorrow morning?

as I stated in #35 and in email, yes - all is fixed.
respin 2003-03-03-15-trunk launch fine.  However a new failure is present on the
2003-03-04-03-trunk build.... see bug 195897.

marking fixed per comments #35 and #38
Status: NEW → RESOLVED
Closed: 22 years ago
Keywords: smoketest
Resolution: --- → FIXED
The latest Nightly
mozilla-mac-MachO.dmg.gz 04-Mar-2003 06:57     1k 

There seems a problem to maintain ?
today's nightly corruption is a different problem. see bug 195897.
corrupted bits have been removed from ftp
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: