189816 - moz just goes away

Status: VERIFIED DUPLICATE of bug 160602

(Core :: JavaScript Engine, defect)

Description

[rdg]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

mozilla ends abruptly.  no error dialog.  no feedback agent.  works on IE6.0

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Benedikt Kantus]

I never experineced this on /. with any trunk build.

Comment 2

[James Graham]

wfm using windows, linux a lot of builds between then and now.

Comment 3

[rdg]

After this situation occurred all morning long, it has stopped as suddenly as it
began.  Must have been something bizarre on the net or at slashdot.  Bug closed
by originator.

Comment 4

[rdg]

the immediate exit of moz is back.  only occurs when browsing to http://slashdot.org

this problem is repeatable, but does not occur all of the time.  it occurs most
of the time though.

please review comments from earlier.

Comment 5

[Andreas Kunz]

Reporter, do you have talkback disabled or does it just not come up after the
crashes?

Comment 6

[Andrew Hagen]

Confirming on Mozilla 1.3 alpha build: 2003012008, Windows 98. Seeing this on
http://mozillazine.org/ forums. I opened the first four forums in separate tabs.
Then, Mozilla crashed. No Talkback data is available, because the Talkback agent
was not invoked.

HTTP Pipelining was enabled. 

Possibly a duplicate of bug 189749.

Comment 7

[Galen Thurber]

I recently dropped 1.3a in favor of 1.2.1 and have experienced application
vanishing in both versions. 1.3a was too unstable to even use.  1.1 was working
great!  Moz 1.2.1 vanishes less than 1.3a for me, and it does not seem to matter
what I'm doing: JRE140, e-mail check, switching tabs ... poof moz vanishes. The
failure rate for me with 1.2.1 is around 1in6  with 4in6 times causing memory
leaks that cause hard boot the oter 1in6 times moz 1.2.1 works.
win98SE 96megs nvidia mx400 [latest drivers]

Comment 8

[rdg]

As far as I know, the talkback feature is installed and operational. 
 It appears to be installed when selecting the browser installation. 
 I have not, knowing, disabled it.  If there are settings that you 
would like me to check, please advise.

Moz just ends with a dialog box indicating a failure to read a memory location.

It is still happening today.

--rdg (reporter)

Comment 9

[rdg]

My system is Win2K, Moz 1.2.1, with "About" that reads
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

My failure is on 1st attempt to http://slashdot.org in main window. 
 Same failure if opened in a tabbed window.

-rdg (reporter)

Comment 10

[Andrew Hagen]

Reporter, do you have HTTP Pipelining enabled? Disable it and see if that makes
a difference. If it doesn't, than try deleting the "xul.mfl" file in your
profile directory. Does that help?

Comment 11

[Andreas Kunz]

Please also note that reporter's build is almost two months old and lots of
crashes have been fixed in recent nightlies.

And nobody can tell if the problem in comment #6 is the same one. At least I am
browsing mozillazine regularly without problems with current nightlies...

Not every crash without talkback coming up has necessarily the same cause. So
bug 189749 is about talkback not recording a crash, but that does not make this
bug here a duplicate. This bug is about a certain not reported crash, not about
not reporting crash stacks in general.

Comment 12

[rdg]

Pipelining is not and never has been activated.
Deleted XUL.mfl -- problem still occurs.

--rdg (reporter)

Comment 13

[Andrew Hagen]

Reporter, if you have not done this already, try this: uninstall Mozilla, delete
the "program files\mozilla.org" subdirectory (you could leave the plugins
subdirectory alone, however), and install a new copy of Mozilla. Does the
problem still occur?

Comment 14

[Galen Thurber]

1.2.1 
I made sure no moz was running then I deleted xul.mfl and restarted browser.
That created a fatal memory leak requiring a cold boot. Next 5 startups of
browser  are working. HTTP pipelining DISABLED [never was on]

I can't use 1.3a it is way too unstable.

Comment 15

[rdg]

Uninstalled Mozilla, deleted "program files\mozilla.org" subdirectory completely
reinstalled a Mozilla 1.2.1.

Problem still occurs.

-rdg (reporter)

Comment 16

[Galen Thurber]

hope this is relevant. For my 1.2.1 and 1.3a it looks like enigmail add on was
the culprit. Enigmail.jar lingers in the chrome directory and it looks like it
was causing around 90% failure rate, with it gone and not installed 1.3a is
behaving normal with the last 15 starts causing no crashes. What a relief!

Comment 17

[rdg]

I am not using any plugins or skins.  I have worked my way back from 1.2.1 all
the way to 1.0.2 -- BEFORE the crashes on slashdot.org have stopped.  This is
really unpleasant, as there are many improvements in the current release.

-rdg (reporter)

Comment 18

[Andrew Hagen]

Thanks for the reports, Galen Thurber. That helps narrow it down.

Reporter, could you try creating a new profile, just for testing purposes? Does
the problem continue to occur with a new profile?

(Soon Mozilla 1.3 beta will be released. It has a lot of improvements, and you
should try it when it becomes available.)

Comment 19

[Phil Schwartau]

This is a duplicate of bug 192002,
"Application quits when displaying http://slashdot.org".

The analysis there implicated JS Engine; specifically
calls that the site makes to (new Date).getTime().

The crash that causes, in turn, is bug 160602.
Reassigning to JS Engine before duping -

Comment 20

[Phil Schwartau]

Duping against bug 160602 (by way of bug 192002) -

*** This bug has been marked as a duplicate of 160602 ***

Comment 21

[Phil Schwartau]

Marking Verified Duplicate.

[e-mail]: thank you for this report. You have been cc'ed
on bug 160602 so you can follow progress on this issue -