Closed
Bug 36784
Opened 24 years ago
Closed 24 years ago
Running Mac installer results in crash.
Categories
(Core Graveyard :: Installer: XPInstall Engine, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
M16
People
(Reporter: depman1, Assigned: samir_bugzilla)
References
Details
(Keywords: smoketest, Whiteboard: [dogfood+] sgehani's target fix date: 05/04)
Attachments
(3 files)
Mac only. afternoon build 2000-04-21-13-M16. 1. Download "MozillaInstaller-M16" from ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/2000-04-21-13-M16/ 2. Install from "Mozilla Installer - M16" folder. 3. Double click on Mozilla Installer. 4. Press Accept. 5. Press Continue (twice). 6. Press Install. Result: It shows "Extracting installer files" in the progress dialog. A few seconds later, we get a crash: "Application unexpectantly quit, because an error of type 3 occurred." No talkback available. Expected: Complete installation.
Assignee | ||
Comment 1•24 years ago
|
||
Don's nsIFile changes landed at 13:05 pm so this very well could have caught the changes mid-checkin. Let's wait for Monday's official builds. Re-test and report results. If the crash persists let's revisit this.
Comment 2•24 years ago
|
||
This is occurring with build 2000042408 will attach stack crawl
Comment 3•24 years ago
|
||
samir, can you take a look at this crash?
Assignee: cathleen → sgehani
Comment 5•24 years ago
|
||
Mac Commercial installer is crashing also-same build
Assignee | ||
Comment 6•24 years ago
|
||
Return addresses on the stack point to XPI_Init (a xpistub entry point). Grace, Are we seeing this crash on Win32 and/or Linux? Also, can you please attach a stack crawl (type 'sc' in MacsBug once you crash into it). (The attachment above only contains the return addresses.) Thanks.
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: --- → M16
Comment 7•24 years ago
|
||
I am seeing an error on Win Installer- see bug 36962, -229 error, failing at install of XPInstall engine on Linux - it appears to install despite a core dump after the messages about removing directories- haven't written that up yet
Comment 10•24 years ago
|
||
Here is stack crawl for later build on 4/24 On Netscape6 installer- no download is done- installer starts with 'extracting files' as in Moz installer
Comment 11•24 years ago
|
||
Assignee | ||
Comment 12•24 years ago
|
||
XPIStub horkage fixes checked in. However, the XPInstall engine still looks like it is not installing correctly. The installer will remain horked till the engine is fixed. Will follow up with a dependency bug number.
Assignee | ||
Comment 13•24 years ago
|
||
Fixes to 37075 resolve this. In conjunction with my xpistub changes, the Mac installer is now fixed and should work in tomorrow's builds.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 14•24 years ago
|
||
MacInstaller is failing - downloads, extracts and dies build 2000-04-27-08M16
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 15•24 years ago
|
||
Investigating... again.
Status: REOPENED → ASSIGNED
Whiteboard: [dogfood+] → [dogfood+] sgehani's target fix date: 04/28
Comment 16•24 years ago
|
||
Reproduced with last three nightly builds, MacOS 8.6. Exactly as described in the original report.
Assignee | ||
Comment 17•24 years ago
|
||
The autoregistration of interfaces (new code) in the context of xpistub is assuming things about the components directory. This problem was masked by the XPInstall engine and xpistub bustage. That makes a total of three areas that were horked for the Mac installer this week. Two have been resolved (xpistub and XPInstall engine horkage) and the third (autoregostration of interfaces) should be fixed shortly yielding a working Mac installer by the beginning of next week. (Similar horkage was observed in the Linux installer earlier this week. Hopefully this will fix Linux too. The autoregistration of interfaces problem did not manifest on Windows because we do extra black magic before calling xpistub -- change cwd.)
Assignee | ||
Comment 18•24 years ago
|
||
Fixes checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 19•24 years ago
|
||
Comment 20•24 years ago
|
||
Mozilla Installer and Netscape Installer crashing at end of navigator install portion (typical install) build 2000-05-02-08M16
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 21•24 years ago
|
||
Samir, can this be related to the fact that there is no "Component Registry" in xpcom.xpi ? If so, you can add a dependency to bug #24312
Assignee | ||
Updated•24 years ago
|
Whiteboard: [dogfood+] sgehani's target fix date: 04/28 → [dogfood+] sgehani's target fix date: 05/04
Assignee | ||
Comment 23•24 years ago
|
||
Grace, These are the return addresses. Can you type "sc" in teh debugger and log the stack crawl when you get a chance. Thanks.
Assignee | ||
Comment 24•24 years ago
|
||
The mozilla installer installs xpcom.xpi alone just fine. It crashes after browser.xpi has finalized the last file.
Comment 25•24 years ago
|
||
sc gives me nothing: message says CurStackBase does not seem to apply- dumping 4k
Assignee | ||
Comment 26•24 years ago
|
||
OK, this is the third distinct bug that is being tracked here, for the record. It appears to be memory corruption during the XPInstall engine run on a .xpi with a large number of files (~1,000).
Assignee | ||
Comment 27•24 years ago
|
||
This bug is fixed. The XPInstall engine dies at the end of browser.xpi's finalize phase even in the browser context. David opened bug 37957 regarding this new crasher. Marking this fixed and adding a dependency on 37957. This bug can be verified by installing just mail.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Depends on: 37957
Resolution: --- → FIXED
Comment 28•24 years ago
|
||
but Navigator always installed! Will have to wait to verify
Assignee | ||
Comment 29•24 years ago
|
||
Use the Mozilla Installer and uncheck Navigator in the Components dialog.
Comment 30•24 years ago
|
||
we can definately check against the mozilla installer :-) to see that Samir's fix is working. However, I agree with Grace, that we really can't mark this verified, till we check with commercial build, which is currently masked/blocked by another bug. (after all, that's what we're shipping :-) )
Reporter | ||
Comment 31•24 years ago
|
||
Both Grace and I verified this against today's commercial and Mozilla installers. builds 2000-05-09-08.
Status: RESOLVED → VERIFIED
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•