Closed Bug 204668 Opened 22 years ago Closed 20 years ago

Linux/Windows Reproducible Crash Tests

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: mjennings.usa, Unassigned)

Details

(Keywords: crash, hang)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4 Subject: Linux/Windows Reproducible Crash Tests In Windows, I've had numerous crashes of Mozilla. See the TalkBack info at the bottom. I decided to run a test in Linux. I chose Knoppix because there is no configuration and no hard drive. This removes the issue that something about my configuration may be different. EQUIPMENT FOR WINDOWS TEST: Dedicated uninterruptible power supply Intel 815EEA2 motherboard P3, 833 MHz Matrox G450 video card, Matrox driver 5.88.061, dated 25 feb 03. EQUIPMENT FOR KNOPPIX TEST: I downloaded an ISO of Knoppix 3.2 and used it to boot a computer that is dedicated to testing Mozilla. The computer has: Dedicated uninterruptible power supply Intel 845G motherboard (standard, and old enough that all problems may have been found) Celeron 1.8 GHz No hard drive Graphics Blaster PCI video card with Cirrus Logic chipset (The hardware recognition under Knoppix is perfect. No configuration is necessary. Mozilla is started from an icon on the task bar.) BUGZILLA BUILD IDENTIFIERS: Knoppix Linux test: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4 Windows XP test: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 This is the test: KNOPPIX TEST: Open 20 instances of Mozilla. Open several tabs in each instance. This is stable under Knoppix. Then begin closing some tabs and opening others. ALL TABS and ALL INSTANCES of Mozilla browser will crash. There is no TalkBack in Knoppix Mozilla apparently. Other programs that were running at the same time are unaffected; this proves that there is no problem with power. Knoppix crashes often occur after some period, when the computer is unattended. After a Mozilla crash Mozilla can be restarted and used normally, without reloading the OS. WINDOWS TEST: ALL TABS and ALL INSTANCES of both Mozilla Browser and Mozilla Mail crash after use involving many instances and closing and opening tabs. Other programs are unaffected. After a Mozilla crash Mozilla can be restarted and used normally, without reloading the OS. Below is the TalkBack incidents list for the Windows XP tests. (TalkBack does not appear in the Knoppix crashes.) There were many more Windows crashes than are shown below; sometimes TalkBack does not appear. See also: http://bugzilla.mozilla.org/show_bug.cgi?id=203516 Both the original reporter and I were using Matrox video cards. The Knoppix test uses a different card, so apparently Matrox drivers are not the problem. Thoughts: Mozilla is an EXTREMELY important project. People use a browser as a window on the world. The world is socially and technically dependent on having a good browser. Not everyone in the world uses a computer, but everyone is dependent on leaders who do. The Mozilla design is excellent, the crashing is the only major problem. ___________________________________ Talkback incidents (in Windows XP): ___________________________________ Note that TalkBack does not allow copying and pasting the incidents. I used a Windows program, Count Characters v. 3.0, available free from http://www.funduc.com/ to copy the list to the Clipboard. Note also that TalkBack often does not start. There were many more crashes than shown here. Status Incident ID Captured At Type Comments in Queue 04/30/2003 04:19 AM program Crash 14 INSTANCES of Mozilla browser and one instance of Mozilla composer crashed. No sent TB19550606Y 04/27/2003 05:53 AM program Crash ALL INSTANCES OF MOZILLA CRASHED! sent TB19473544Q 04/24/2003 13:15 PM program Crash ALL INSTANCES OF MOZILLA CRASHED. This occurred after viewing a PDF file in Mozi sent TB19075052G 04/12/2003 04:53 AM program Crash Mozilla was failing, so I closed all instances and tabs. When I closed the last sent TB18405568Z 03/24/2003 08:28 AM program Crash ALL TABS OF ALL INSTANCES OF MOZILLA CRASHED!!!!! sent TB4896725G 04/06/2002 10:36 AM program Crash sent TB4669453Q 03/31/2002 12:43 PM program Crash forwarding e-mail sent TB4658710G 03/31/2002 03:26 AM program Crash Trying to load a PDF file. Probably clicking on many things at the same time. sent TB4325679G 03/21/2002 17:34 PM program Crash sent TB3888809Q 03/11/2002 00:43 AM program Crash Changing themes Reproducible: Always Steps to Reproduce: 1. Run Mozilla in Windows XP or Knoppix Linux. 2. Open many instances of Mozilla browser, and many tabs in each instance. 3. Close some tabs and instances, and open others. Actual Results: Mozilla always crashes. All instances stop functioning in Windows, and disappear in Knoppix.
Keywords: crash, stackwanted
Whiteboard: TB18405568Z
can you reproduce crash with latest nightly build ?
TB18405568 is empty ..
Keywords: stackwanted
Whiteboard: TB18405568Z
do you still crash using latest build ?
Product: Browser → Seamonkey
1 year no response. Resolving as WFM. Feel free to reopen if you can reproduce the problem with current builds.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
The Firefox version of this bug is 222660. https://bugzilla.mozilla.org/show_bug.cgi?id=222660 Apparently, nothing has changed in the latest builds. However, the bug is very difficult to characterize. See bug 222660 for a discussion that apparently applies equally to Mozilla. Note that there is considerable contention concerning 222660. Some people say that a bug should not be reported unless it can be fully characterized.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
The question is: Do you still can reproduce this with a current Seamonkey (Mozilla Suite) build? For this bug report is the Firefox report irrelevant. So please answer this question, otherwise I'll resolve this bug again. Without a submitted Talkback ID (i.e. crash report was processed by the talkback server) is this report useless.
Assignee: asa → general
QA Contact: asa → general
You said, "So please answer this question, otherwise I'll resolve this bug again. Without a submitted Talkback ID (i.e. crash report was processed by the talkback server) is this report useless." Apparently you did not read the bug reports. There is no TalkBack ID, because the bug never communicates with TalkBack. You seem to be saying, "If you, the bug reporters, don't do an amount of work I specify, I will feel free to pretend that there have been no reports of crashes." If there are such social rules applying to the Mozilla Project, please post them so that we can all see them before we try to help. Facts about this bug: 1) It is very difficult to characterize. Initial reports of bugs often create a chaotic situation, until the chaos can be resolved. This bug is much worse than most. It has been reported for years, since version 0.61 of Mozilla. 2) The problem is worse with Mozilla than with Firefox in the recent versions I tried. 3) This bug eventually always crashes all windows and tabs of both Mozilla and Firefox. With most usage patterns, this takes many days or weeks. 4) Apparently this bug always results in Mozilla or Firefox using all the CPU cycles, something that was not noticed during the early years of testing. When those programs use 99% of CPU cycles, every operation of every program, not just Mozilla and Firefox, takes 100 times longer, making users think the OS has crashed. Suggestions: 1) Fix TalkBack, so we don't lose that information. Maybe there could be a "Write everything to disk" mode that the more dedicated testers could turn on. Holding everything in memory cannot be useful when the bug is essentially crashing the OS. Maybe some testers could have a version of TalkBack that would have a "Trigger TalkBack Report" menu choice. If you read the reports, this bug always results in Mozilla or Firefox using 98% or 99% of CPU cycles. The result is that the user always terminates Firefox, or restarts the OS. Nothing can be recorded by TalkBack, because there is never a message to TalkBack from Mozilla or Firefox that those programs are in trouble. 2) Recognize that some bugs are far more difficult to find than others, and that poorly characterized reports may be better than nothing in difficult cases. 3) Read the end of bug 222660. Someone has reported an area of code that seems like a good candidate for causing this problem. 4) Recognize that the reporters of bugs are doing the best they can, under the circumstances that apply to them. 5) Recognize that no one is implying anything negative about the Mozilla team. This is a very difficult bug to characterize. 6) Recognize that the bug reporters are doing their best, and are slowly understanding the bug better.
oh brother. first, if you feel like reporting this bug on linux using a vendor released version of mozilla then you'll have to get symbols from your vendor (you're free to download an official mozilla.org linux build which includes talkback). your original report included talkback incident ids, although one was listed as empty (did you manually ask talkback to submit a report?). without some form of a stack trace (note: this is not strace, do *not* send an strace), we can't even resolve this bug as a duplicate. just because you think this bug is important and unique doesn't mean it is, we just can't tell because there's no stack trace. next, while you might think you have 'instances' of mozilla, you almost certainly just have many windows because of a magical feature called xremote (which vendors tend to configure). it is possible to run multiple distinct instances of mozilla on windows and linux, but you're more likely to be annoyed by the profile manager than benefit from it, especially if your intent is to crash. fwiw talkback for windows was finally improved to allow you to copy incident ids. i don't need fully characterized bugs, but i do need useful hints, a web page to visit, preferably a stack trace, ...
1.) Does the problem still exist in Mozilla 1.7.6/1.8b1 or a recent trunk build? Note: The Firefox problem is handled in the other bug report. So if this is not reproducible with current Mozilla Suite versions, then this bug should be closed. 2.) (In reply to comment #7) See comment 8 and ... > You seem to be saying, "If you, the bug reporters, don't do an amount of work I > specify, I will feel free to pretend that there have been no reports of > crashes." No, no. You have to understand me and others: We see a lot of bug reports with insufficient information, so no-one can resolve this. In particular for crashes we need the stack to help to find the real cause, because no-one could reproduce it we don't have a stack. Without is fixing almost impossible. I came to this because it is a quite old report with no progress. > 4) Recognize that the reporters of bugs are doing the best they can, under the > circumstances that apply to them. I know and I do the same. :-) I let this report as is and let others with more power and knowledge decide what to do. Thanks for testing/using Mozilla.
Keywords: hang
An idea: Create a latest build of Firefox and Mozilla with a stack dump menu choice. This is in response to your saying "In particular for crashes we need the stack to help to find the real cause, because no-one could reproduce it we don't have a stack. Without it fixing almost impossible." If I could do voluntary stack dumps, I could post the most relevant ones. Both Mozilla and Firefox usually show they are sick long before a crash. I can sympathize with this: "We see a lot of bug reports with insufficient information..." However, what's happening here is not a case of sloppy, less educated reporters. This bug is genuinely difficult to characterize. I realize that, under the circumstances, it was difficult to realize that this situation is different.
unfortunately stack traces don't work that way, the stack trace you'd get from such a menu item would be to the act of dispatching the menuitem. get a debug build with symbols and crash on linux. use ./mozilla -g -d gdb run bt
Hi Michael Are you able to specify 1. The latest version of Mozilla (Application Suite) that you have used to reproduce this problem 2. The number of windows and tabs that you had opened when it crashed 3. The total number of windows and tabs that you had to open in order to get it to crash If you can do that then someone with a debug build of Mozilla may be able to produce a stack trace. If I can reproduce the problem, then I can mark it as confirmed. btw - I'm running Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050302 which doesn't appear to have the same problem Thanks Simon
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This is a showstopper bug. After Mozilla, Firefox, or Thunderbird have been in use for several days, all of the latest versions of those programs (Mozilla 1.7.11, Firefox 1.07, and Thunderbird 1.06) begin taking a large amount of CPU time, even when idle, and eventually crash. When I post comments to Slashdot, such as this one, http://slashdot.org/comments.pl?sid=163772&cid=13678221 generally there are replies from people saying that they have stopped reporting showstopper bugs because they are not fixed. I first reported this bug 2 1/2 years ago. One reply to another comment suggested the bug was associated with the way Mozilla products handle plugins. See https://bugzilla.mozilla.org/show_bug.cgi?id=222660 This is the same bug, apparently. This bug is associated with unreasonable memory use, too.
Hi Michael I'm running Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050302 I notice you say you have the problem with 1.7.11, whereas I don't have that problem with 1.8b, it is possible that this has already been fixed Are you able to confirm whether or not you can reproduce this with 1.8b (preferably same version as above). I you can, then I'm happy to work with you to try and identify the cause of the problem Thanks Simon
We have been discussing this bug on Slashdot again today: Title of comment: I reported the crashing 2 1/2 years ago! http://slashdot.org/comments.pl?sid=165784&cid=13831071 The parent comment that started the discussion about memory management problems is here: http://slashdot.org/comments.pl?sid=165784&cid=13828636 Note that it is not only me who has seen this bug for years. The answer from Mozilla people has often been: "Did you try the latest version, compiled last night? The problem may be fixed." By the time I can test the latest version, there is a new version, and I get the same answer again. Another answer I've often seen is: "Tell us exactly what causes this bug and we will fix it." Unfortunately, maybe the only way to characterize the bug would be to work carefully using a debugger. Since the many, many people who have reported this bug have had no credibility with Mozilla developers, it seems to me probable that work done with a debugger would also have no credibility. In any case, such work would require a will to work on the bug, and considerable cooperation, from Mozilla people. I have spent more than 20 hours in testing and reporting this bug, and many people who have posted comments on Slashdot have said they have spent hours reporting it, too. I've often seen problems in software that are as difficult to characterize as this one. (For example, on three occasions in my life I've found compiler or assembler bugs.) It's true this bug will require considerable sleuthing from a carefully logical, scientifically minded investigator. But in my view that is just part of being a programmer. It would be very helpful if Mozilla people would stop saying this bug does not exist and begin a dialog about how to characterize it. What is the purpose of denial? Judging from comments I've seen on Slashdot and my own testing on several computers, this bug always occurs, provided Firefox or Mozilla browsers stay open long enough, and enough windows and tabs are opened. Some people report the problem occurs with few windows and tabs. I've seen that, too, but rarely. I've seen this problem with every release version of Firefox since version 0.8, at least. The last time I saw this high CPU use memory mismanagement crash I was using Firefox 1.07. This problem exists under Linux, I've found, but is less severe. I have not tested recent versions under Linux. The problem under Windows XP SP2 with all critical updates applied is so severe that it sometimes makes the OS unusable. In that case it is necessary to close all other programs also, and re-boot the computer, a real time-waster. I've just spent another hour reporting this bug. Will my time be wasted again? Will I get another argumentative response? Or, can we begin doing the work that needs to be done? If we had cooperated from the beginning, the time already spent would have been enough to find and fix the bug, I think.
I'm not going to bother to read this whole bug, but basically, we need stack traces from these crashes to be able to know what's going on here. http://kb.mozillazine.org/Talkback And before you ask, all the talkback IDs posted here are way past expired; i.e. not available to us anymore.
Quote from Additional Comment #17 From Adam Guthrie, 2005-10-20 20:22 PDT: "I'm not going to bother to read this whole bug, but basically, we need stack traces from these crashes to be able to know what's going on here." If you had bothered, you would have learned this: 1) The crashes are easily reproducible. If you care to "bother", you can see the problem for yourself. 2) Talkback does not function in reporting this bug. The TalkBack reports are useless, or non-existent. 3) People on Slashdot are reporting they are upset because the Mozilla team does not fix showstopper bugs like this one (especially this one). They are migrating to Opera, which is now free. That's sad, because Firefox is a more usable browser, in my opinion. 4) You are unlikely to understand this bug if you don't read the bug reports. This bug is very difficult to characterize.
I can't reproduce this bug and nobody else seems to be able here on bugzilla. It can't be a showstopper because we would have much more bug reports if this bug would be very easy to reproduce bug and please don't use the "they move to browser XYZ because of this" story. A developer must reproduce this crash if this should be fixed and that is the whole problem.
Reply to Comment #19: After many, many hours of writing about this, I have developed the conclusion that no one at Mozilla actually read the reports thoroughly. Is that true? Many of the Slashdot comments say this same thing: Use Firefox enough, open enough web pages, and it will eventually begin eating memory and CPU time unreasonably. The bug has been stable for 2 1/2 years, through many versions of Mozilla browser and Firefox. Over the years I have tested Mozilla and Firefox browsers on several computers, and the bug is the same on all of them. Some people are reporting that the bug is less of a problem under Linux. When I tested, it was the same, except that the bug crashes Windows XP SP2, and not Linux. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=222660 which I now recognize is the same bug. My guess is that fixing this bug would reveal issues that, when fixed, would make Firefox easier to maintain. Firefox and Mozilla have some big problem with the way they handle memory use. If someone reads the responses with the sensibility of a sociologist, the tone of the responses is one of defiance, not interest or cooperation.
"After many, many hours of writing about this" geez, YOU don't get it. Numerous people have tried to help you and no one has said in this bug "Michael we don't believe this happened to you". What they have written, is to ask you for information which is certainly obtainable by you since you are clearly computer-literate, but which YOU seem to ignore (after all, after your initial report it was 2 years before you posted again). As long as YOU insist on not supplying any URL (you do know how to access history?) nor a build string or anything new or remotely useful, you can expect this to stay unconfirmed. You say you want this fixed - then forget about socialology and what's written in slash dot and what's written in other bugs - stick to one item only, one crash, and provide specific details, and perhaps then you won't have wasted 2.5 years and everyone else's time (including mine) who have taken the time to read this and tried to help you. GU.
Please don't post replies to this bug if you are not willing to read the detailed reports from many people. There is no URL that causes this problem, as far as anyone is aware. For 2 1/2 years, all builds have had the same problem. Mentioning URLs and builds just indicates that person replying has not read the bug reports. As many people have mentioned in the links already supplied, the crashes, memory mismanagement, and hogging of CPU time are easily reproduced. However, it does take several days.
This bug lacks anything resembling useful information other than comment 0, which is out of date (and was already out of date when the bug was reported). If you want to actually report a bug (and see it fixed), please test with a trunk build from .mozilla.org and provide the information necessary to diagnose the bug. If you want to test Mozilla products from a distro vendor, send the reports to the distro vendor.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → INVALID
Quote from Comment #23: "This bug lacks anything resembling useful information..." That is not correct. This bug report provides: 1) A completely reliable means of demonstrating the crashes, memory mismanagement, and hogging of CPU time. This information is supported by numerous reports. If you care to demonstrate the bug to yourself, you can. 2) Discussions by several people about why they think the bug occurs. 3) Useful notes. For example, most of the time there is not an actual crash. The "crash" is actually Firefox or Mozilla browser using 99% or 100% CPU time. 4) Discussion of the fact that the bug is very difficult to characterize.
You need to log in before you can comment on or make changes to this bug.