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:
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
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.
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.
And another update: Trying to delete the new profile again, including all files, always triggers a crash, too.
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?
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).
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?
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.
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 ?
> 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).
Prime95 is good for testing your system under heavy CPU load: http://www.mersenne.org/freesoft.htm
'Target Milestone' should only be set by the assignee. Clearing it.
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