Closed Bug 54311 Opened 24 years ago Closed 24 years ago

Crash (illegal instruction) or hang on startup, MacOS 9 only

Categories

(SeaMonkey :: Build Config, defect, P3)

PowerPC
All
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: Kanef, Assigned: ccarlen)

Details

(Keywords: crash)

Attachments

(1 file)

Build id 200092616 crashes while starting up on my Mac G3 running MacOS 9.0.4. I downloaded the installer twice and installed three times, and none of them work, even on a fresh boot. It works on a Mac 8600 running MacOS 8.6. I will attach a MacsBug StdLog. It happens every time, as long as I trash the Component Registry file. If I don't, then the next time it's started it hangs instead of crashing, with the splash screen saying it's registering PSMGlue.shlb.
Attached file MacsBug StdLog (deleted) —
Keywords: crash
unable to reproduce this crash on OS9. Have you deleted your mozilla folder in /documents, your mozilla registry in /Preferences and you're previous mozilla install directory?
I've just tried cleaning up as specified above. I deleted Macintosh HD:System Folder:Preferences:Mozilla Versions Macintosh HD:System Folder:Preferences:Mozilla Registry Macintosh HD:Documents:Mozilla: When I reinstall from the same installer and start Mozilla, it hangs with the splash screen showing "Componment registration finished". I can switch to other applications, but Mozilla is hung. It creates new files with the above names before hanging. I deleted the files again, downloaded a fresh copy of http://ftp.mozilla.org/pub/mozilla/nightly/2000-09-26-16-MN6/ MacMozillaInstaller.sea.bin into a different folder name, ran the installer, creating a folder with a new name, and ran Mozilla. Same thing happened.
I tried the latest installer version and also the one in http://ftp.mozilla.org/pub/mozilla/nightly/2000-09-28-08-M18/ and both produce a Mozilla that hangs on startup as before. Stack trace shows 0ED6A379 PPC 0047FB4C EmToNatEndMoveParams+00014 0ED6A300 PPC FFCE3A3C MPSecondaryInitializeAPI+001F4 The good news is that the ones that don't involve an installer work fine. Both mozilla-mac-MN6 and mozilla-mac-M18 from http://ftp.mozilla.org/pub/mozilla/nightly/latest/ (the versions dated 28-Sep-2000 06:06 and 13:18) launch successfully.
Summary: Crash (illegal instruction) on startup, MacOS 9 only → Crash (illegal instruction) or hang on startup, MacOS 9 only
over to installer.
Assignee: asa → ssu
Component: Browser-General → Installer
QA Contact: doronr → gemal
I'll take QA on this.
QA Contact: gemal → asa
Reproduced hang with 9/29 installer on a different machine, a G4 running MacOS 9.
Shouldn't this go directly to sgehani? ;)
what Eli said.
Assignee: ssu → sgehani
Over to component owner.
Assignee: sgehani → ssu
QA Contact: asa → gemal
Oops. I meant Build Config component owner.
Assignee: ssu → cls
Component: Installer → Build Config
QA Contact: gemal → granrose
Reassigning to jj.
Assignee: cls → jj
QA Contact: granrose → gbush
ups...
QA Contact: gbush → granrose
oh joy, another funky mac crash on startup bug. jj's out til 10/9 so this won't get looked at for a bit. cc'ing some mac folks as an fyi.
Stack has file locator on it, so cc conrad: 00000000 PPC 1F17AB5C 0EDF4640 PPC 1F165498 main+00130 0EDF45E0 PPC 1F16484C main1(int, char**, nsISupports*)+006DC 0EDF4330 PPC 1EF14670 nsAppShellService::CreateHiddenWindow()+000FC 0EDF4270 PPC 1EF15A7C nsAppShellService::JustCreateTopWindow(nsIXULWindow* , nsIURI*, i nt, int, unsigned int, int, int, nsIXULWindow**)+001D0 0EDF41D0 PPC 1EF088CC nsWebShellWindow::Initialize(nsIXULWindow*, nsIAppShell*, nsIURI *, int, int, int, unsigned int, int, int, nsWidgetInitData&)+0068C 0EDF3FD0 PPC 1ED80F0C LoadURI__10nsDocShellFPCwUi+003AC 0EDF3D10 PPC 1ED76578 nsDocShell::LoadURI(nsIURI*, nsIDocShellLoadInfo*, unsigned int) +003B8 0EDF3C50 PPC 1ED8A70C nsDocShell::InternalLoad(nsIURI*, nsIURI*, nsISupports*, int, in t, const char*, nsIInputStream*, nsIInputStream*, unsigned int, nsISHEntry*)+ 00290 0EDF3BD0 PPC 1ED8D170 nsDocShell::DoURILoad(nsIURI*, nsIURI*, nsISupports* , int, int, const char*, nsIInputStream*, nsIInputStream*)+002D8 0EDF3A70 PPC 1ED8E5B4 NS_OpenURI(nsIChannel**, nsIURI*, nsIIOService*, nsILoadGroup*, nsIInterfaceRequestor*, unsigned int, unsigned int, unsigned int)+000AC 0EDF39E0 PPC 1E186F74 nsIOService::NewChannelFromURI(nsIURI*, nsIChannel** )+0011C 0EDF3950 PPC 1EDDAC18 nsChromeProtocolHandler::NewChannel(nsIURI*, nsIChannel**)+0036C 0EDF36C0 PPC 1EDC08D8 nsChromeRegistry::ConvertChromeURL(nsIURI*, char**)+ 00154 0EDF3310 PPC 1EDCE2A4 nsChromeRegistry::GetProfileRoot(nsCString&)+00098 0EDF31C0 PPC 1EF19668 nsFileLocator::GetFileLocation(unsigned int, nsIFileSpec**)+0007 0 0EDF3120 PPC 1EF18BB0 nsSpecialFileSpec::operator= (nsSpecialFileSpec::Type)+003D8 Kanef, do you have Mac OS 9 multiple users on, or anything odd like that?
From the last entry in the stack trace above, that's where GetProfileDirectory in nsFileLocations.cpp is being called. Looking for what could cause that to crash.
Considering that all I can determine from the stack trace is that GetProfileDirectory was being called and that it this function is complex in its interraction with the profile mgr, it's hard to pin down. IMO, the best thing to do is get rid of nsFileLocations (bug 38626) and avoid this convoluted code.
doesn't sound like this is going to make RTM. rtm- to drop off untriaged crasher radar.
Keywords: rtm
OS: All
Whiteboard: [rtm-]
jj should not own this bug.
Assignee: jj → ccarlen
Whiteboard: [rtm-]
I can't say this is fixed because I could never reproduce it but (1) It was happening in nsFileLocations and (2) nsFileLocations is not used anymore.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I can still reproduce the hang with the 9/28/00 installer, and it works fine in 2000101708 from that installer. Marking as fixed. For the record, no, I wasn't running Multiple Users. I did have some server volumes mounted with AppleShare.
marking verified.
Status: RESOLVED → VERIFIED
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: