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.
I never experineced this on /. with any trunk build.
wfm using windows, linux a lot of builds between then and now.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Reporter, do you have talkback disabled or does it just not come up after the crashes?
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.
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]
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)
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)
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?
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.
Pipelining is not and never has been activated. Deleted XUL.mfl -- problem still occurs. --rdg (reporter)
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?
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.
Uninstalled Mozilla, deleted "program files\mozilla.org" subdirectory completely reinstalled a Mozilla 1.2.1. Problem still occurs. -rdg (reporter)
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!
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)
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.)
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 -
Assignee: asa → rogerl
QA Contact: asa → pschwartau
Duping against bug 160602 (by way of bug 192002) - *** This bug has been marked as a duplicate of 160602 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → DUPLICATE
Marking Verified Duplicate. email@example.com: thank you for this report. You have been cc'ed on bug 160602 so you can follow progress on this issue -
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.