If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Random crashes in Firefox 0.9

RESOLVED WORKSFORME

Status

()

Firefox
General
--
critical
RESOLVED WORKSFORME
14 years ago
13 years ago

People

(Reporter: TGOS, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040612 Firefox/0.8.0+

The preview crashes about every 2 to 5 minutes on my system. It even crashed 
while trying to file this bug report (on form submission). You want talkback?

TB91730H
TB90712G
TB90625Q
TB90525X
TB90493Y
TB90489W

Flash crashes it, many images on a page crashes it, form submission crashes it. 
I tried different preview builds, all have the same problem.

Reproducible: Couldn't Reproduce
Steps to Reproduce:

Comment 1

14 years ago
Does it happen on a specific URL ? which one ?
Have you installed any extension ?
Please try with a clean install/new profile and no extension
(Reporter)

Comment 2

14 years ago
Here's another one with the latest nightly of 0.9 branch:

TB91802Z

No, it doesn't happen at a specific URL, it happens everywhere and all the 
time. It even happened when I tried to file a bug on this page (I wrote that, 
didn't I?).

No, I have no extensions installed other than the DOM Inspector (the only thing 
shown in the Extension entry from the Tools menu, and it's part of the Firefox 
package itself; I have not installed anything afterwards). Despite that, I'm 
sure I have no extension.

Yes, I have tried a fresh profile, no change. Don't get me wrong, but I don't 
understand this question each time. There never ever has been a single problem 
I encountered so far, that could be solved by a fresh profile. And second, you 
can't force users to trash their profile on each upgrade, so Firefox just has 
to work with an old profile.

The reason for filing this bug is that somebody can use these talkback IDs to 
get stack traces and a detail describtion of the problem. I'm a programmer 
myself and I could find the real problem myself and give a much more detailed 
describtion of the crashes, but I don't know how to turn a talkback ID into 
something useful, like stack trace and C/C++ code of the line causing the crash 
and its surroundings.
(Reporter)

Comment 3

14 years ago
Here's one with a new profile as fresh as it can get:

TB91856Q

And here's one crashing when I tried to just start Firefox:

TB91860X

With that new profile after the first crash.
(Reporter)

Comment 4

14 years ago
And another update:

Trying to delete the new profile again, including all files, always triggers a 
crash, too.

Comment 5

14 years ago
You can look up your talkback IDs here:
http://talkback-public.mozilla.org

There are 3 different crashes in the TB reports you list:
nsLineLayout::VerticalAlignFrames
nsXBLPrototypeBinding::GetRuleProcessors
js_CompareStrings

With such random instability, is the system itself stable?
Can it run memtest86 overnight with zero errors?
(Reporter)

Comment 6

14 years ago
Wow, thanks for the link to the talkback ID page! I didn't even know the page
exists.

TB91856Q and TB91860X are both access violation crashes in line:
	c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/js/src/jsstr.c,
line 2715

With identical stack trace! A coincident? I don't think so.


TB91802Z, TB90525X, TB90625Q, TB90712G, TB91730H and TB90493Y are access
violation at 

c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsLineLayout.cpp,
line 1979

This time the stack trace differs for some reports. But look, always the same
line that causes the crash. How can this be a coincident?


And TB90489W is a different crash:
	c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/xbl/src/nsXBLPrototypeBinding.cpp,
line 918



If the system was instable, I would expect crashes to appear more randomly (e.g.
in case of a memory problem, random lines using malloc, realloc or free should
cause crashes). The system can't be really stable, it's Windows(tm) after all
;-) But it's stable enough to not have other applications crash and Firefox 0.8
also didn't crash every 2 to 15 minutes.


I don't know about memtest86, but I can let it run tomorrow over the day (over
night is not such a good idea, the PC is too close to my bed and too noisy for
comfortable sleep).
(Reporter)

Comment 7

14 years ago
I just ran memtest86 for 2 hours now, no error found. I don't think there is 
something wrong with my system. Do you have other tests I could run, like a 
melt down test for the CPU or graphics card?
(Reporter)

Comment 8

14 years ago
Changed subject, as also final release crashes. Here is another Talkback of the
final release:

TB103245X

Would help if I post my userChrome.css, userContent.css and user.js config file
here? BTW, I meanwhile even delete all Folders named Mozilla, Firebird and
Firefox in my home directory's application support folder to make sure all
profile data is recreated. However, I then moved my old user.js and .css files
there. As Firefox's crash was reproducible even when using a blank profile, I
don't think it really matter.
Summary: Random crashes on 0.9 preview → Random crashes in 0.9
(Reporter)

Updated

14 years ago
Summary: Random crashes in 0.9 → Random crashes in Firefox 0.9
(Reporter)

Updated

14 years ago
Component: Browser-General → General
Product: Browser → Firefox
Target Milestone: --- → Firefox0.9
Version: Trunk → unspecified

Comment 9

14 years ago
Did you check your hard drive for errors ?
Are you sure the firefox download is not corrupted ?
What is special about your machine ? Do you have several processors ?
Multithreading ? 64 bits ?
(Reporter)

Comment 10

14 years ago
> Did you check your hard drive for errors ?

No, I didn't explicitely check it for errors, which is a bit hard for a NTFS
drive. I can schedule a full scan, but this just checks for file system
consitency, it doesn't really perform a read/write test of every single sector
on the drive. I think I somewhere have a DOS bootdisk around with an appropriate
tool (from Maxtor).

However, both my HDs support SMART and if a reading error would have been
detected, the BIOS would halt on next reboot and tell me about it. Also
Seagate's SMART tool says that no SMART errors have been reported.


> Are you sure the firefox download is not corrupted ?

I thought the installer version verifies that autmotically using checksums. At
least the ZIP version does (as every file's CRC is checked after decompression),
so I can just assume it is correct, I guess.

> What is special about your machine?

Nothing.
AMD Athlon (Socket A) 1000 MHz, ASUS A7V133A (latest stable BIOS Version, hasn't
changed since late 2003), Hercules NVidia GeForce2 MX, 384 MB SDRAM RAM 133 MHz,
WinXP + Service Pack 1. All mainboard and IDE drivers (as well as graphics
driver) are up to date. Used Asus Probe yesterday to verify that voltage and
temperature are within acceptable limits. Two HDs from Maxtor (40 and 80 Gig),
main partitition (where Firefox is installed) NTFS, the other ones all FAT32.

> Do you have several processors?

No.

> Multithreading?

Of course, otherwise Firefox wouldn't even run, I guess ;-) Or doesn't it run
more than one thread.

You probably meant Hyperthreading. That's Intel only, I have AMD.

> 64 bits?

Nope.

I also have a soundcard from Creative Labs (some SBLive model) and a network
adapter from SMC. My HDs are connected to the on-board Promise controller (both
master on channel 0 and 1). The standard IDE controller has a CD-Burner (slave)
and a DVD-ROM device (master) on channel 0 and an Iomega 250 MB ZIP drive
(master) on channel 1.  All devices operating as UDMA-33 devices, except the
bigger HD, which is UDMA-66

I don't know what else I could mention about it. Do you know a test suite I can
run under Windows XP, that tests if my system is stable? E.g. something that
permanentelly performs CPU load or reads and writes larger parts of memory
(under Windows, as when using memtest86, which has it's own boot disk, it says
the memory tests were all fine).

Comment 11

14 years ago
Prime95 is good for testing your system under heavy CPU load:
http://www.mersenne.org/freesoft.htm

Comment 12

13 years ago
'Target Milestone' should only be set by the assignee. Clearing it.
Target Milestone: Firefox0.9 → ---
(Reporter)

Comment 13

13 years ago
Okay, after clearing all profile data (for the 5th time), all registry data,
deleting all plug-ins and installing 0.9.1 on a "clean" system (clean in the
sense of: As if no Mozilla related product had ever touched the system), I seem
to have a stable Firefox again. At least I had no crash for several days
(compared to a crash every 10-20 minutes before).

I'm sorry for the trouble, but I really don't know what has changed on my
system. I ran all CPU, RAM and HD related test programs I could find and they
all came to the same result: My system has no errors.

The only change I made was increasing my virtual memory by 128 MB (not RAM, just
swap). Do you think the crashes could have been cause by the system running out
of virtual memory? However, I didn't notice much swap activity. But it's true,
Firefox eats VM like popcorn. There are three bugs about possible memory leaks
in FF.

Setting this bug to WFM
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.