196520 - Mozilla Dumps 90% of the time on Start Up

Status: RESOLVED WONTFIX

(SeaMonkey :: General, defect)

Description

[Travis Chase]

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.

Comment 1

[Sergei Dolgov]

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.

Comment 2

[Travis Chase]

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.

Comment 3

[Sergei Dolgov]

*** Bug 190885 has been marked as a duplicate of this bug. ***

Comment 4

[Travis Chase]

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.

Comment 5

[Sergei Dolgov]

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

Comment 6

[Paul]

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.

Comment 7

[Sergei Dolgov]

Just got this problem when tried to start BeZilla freshly built from 1.3 release
sources

Comment 8

[Sergei Dolgov]

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

Comment 9

[Paul]

Sergei, I was having similar issues, until I removed the compreg.dat file in mozilla/components.

Comment 10

[Serge Gautherie (:sgautherie)]

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 :-<)

Comment 11

[Travis Chase]

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

Comment 12

[Sergei Dolgov]

Nothing helped with build from 1.3 release sources (run from dist/bin) but build
from 1.4 trunk works again

Comment 13

[Sergei Dolgov]

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.

Comment 14

[Travis Chase]

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