Closed Bug 196520 Opened 22 years ago Closed 21 years ago

Mozilla Dumps 90% of the time on Start Up

Categories

(SeaMonkey :: General, defect)

x86
BeOS
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: cloveious, Assigned: asa)

References

Details

User-Agent: Mozilla/3.0 (compatible; NetPositive/2.2.1; BeOS) Build Identifier: 2003030811 BeOS R5 Mozilla 1.4a Thread Name: MozillaError:segment violationTeam ID:2259 Thread ID:26995EIP: 0xeaeccbbbloading symbolssegment violation occurrednsDocShell::GetInterface(nsID const &, void **):GetInterface__10nsDocShellRC4nsIDPPv:+02c7 eaeccbbb: * 088b movl (%eax), %ecxMozilla: Reproducible: Always Steps to Reproduce: 1. Boot up Mozilla2.3. Actual Results: Mozilla dumps on startup Expected Results: Booted Normally The problems started on the 6th, I cleaned out everything to do with mozilla installed this new nightly build but the same problems continue, it works fine the first couple times it boots up, but then it fails afterwards. One it fails it just keeps failing on startup untill its all cleaned out and reinstalled again.
Wondering if those symptoms http://bugzilla.mozilla.org/show_bug.cgi?id=190885 reached now even standard nighties. Travis - can you do following test - overwrite chrome folder in this 1.4 by chrome from some recent working build and tell me if it still don't start.
I replaced the chrome directory with the chrome directory from build 2003030309 and it starts up okay, Ive closed and started it a few times and it boots up properly.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 190885 has been marked as a duplicate of this bug. ***
Im not sure what changed but its not happening currently with build 2003031011 Its stable and starts up fast, and hasn't crashed yet in more then 20 start ups.
As we observed this problem with different builds (since January 2003) i think i don't close/worksforme this bug until we know or can guess reason or it won't happen again for long time. But i'm unsure if it is worth Blocker severity
I have not had this problem yet, so I agree, severity should be changed, but, we can't close it yet. Setting Severity to critical.
Severity: blocker → critical
Just got this problem when tried to start BeZilla freshly built from 1.3 release sources
got similar behaviour when played in working build with user_pref("nglayout.debug.disable_xul_cache", true/false); seems good candidate for DUP of famous [Bug 169777] "Corrupted XUL.mfl / XUL.mfasl / XUL FastLoad File freezes/hangs (not crashes)" inspite they said that the bug is fixed
Sergei, I was having similar issues, until I removed the compreg.dat file in mozilla/components.
Reply to comment 8: BEFORE anything else, verify the two prerequisites for bug 169777: 1) Once you've find a failing case, all next Mozilla startups must fail at the same point. 2) If you delete XUL.mfl, Mozilla must work again immediately (untill next failure). Assuming the conditions are verified: First, you DON'T want to play with 'nglayout.debug.disable_xul_cache' ! ((c) jrgm ;-)) The one preference to test for bug 169777 WOULD be 'user_pref( "nglayout.debug.disable_xul_fastload", true );'. From the previous comments, I would guess that it is NOT bug 169777, but it could be like one of thoses related bugs jrgm worked on also !? Unless you have steps to reproduce, I guess the easiest way to know is to upload your ("corrupted") XUL.mfl file so that jrgm could run its checking tool on it. (forgive me jrgm :-<)
This bug still appears in the premade nightly builds 2003031011 started doing it again this morning, it goes away with reboot the computer, somthing to do with Windows code perhaps? :P
Nothing helped with build from 1.3 release sources (run from dist/bin) but build from 1.4 trunk works again
Per comment http://bugzilla.mozilla.org/show_bug.cgi?id=196520#c10 Playing with that "nglayout.debug.disable_xul_cache", which is don't allowed to play with easily reproduces situation on my machine. E.g. if i had nglayout.debug.disable_xul_cache, ture in preferences - Mozilla started ok. Once removed from prefs.js or user.js it peoduced exactly to situation described in bug.
Im Closing, this bug, Im not sure it is a problem anymore. But i don't have a recent build of Mozilla to confirm it, If BeZilla is still crashing at startup, or starts again feel free to reopen
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.