Closed Bug 22092 Opened 25 years ago Closed 25 years ago

Reproducible mozilla crash on W95 build 1999121712

Categories

(Core :: Layout, defect, P3)

x86
Windows 95
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: stephena, Assigned: vidur)

References

()

Details

(Keywords: crash)

Okay, this one is complicated to reproduce so follow these steps exactly. Running W95 build 1999121712. Shut down any running mozillas. Launch a fresh mozilla Goto the URL listed, http://home.hiwaay.net/~stephena/page1.html WAIT for the page to completely load. Click on "Florida man faces federal charges for Columbine Internet Threat" WAIT for the second page to completely load Click on the back button QUICKLY BEFORE the first page is finished loading: double-click in the addr bar to highlight the entire entry and type in a URL (eg www.slashdot.org) Hit enter to go to the URL you just typed. *CRASH* This was a hard bug for me to reproduce, but once I got the hang of it I can get it to crash 4/5 times. Their seems to be a couple keys to getting the crash to rear its head. 1) The address you type must be someplace you have not gone in your current session (hence I say start a fresh mozilla). If I do this on a mozilla that has already been to slashdot, it will not crash if that's the address I use. A DNS thing? 2) The crash works best if you hit enter for the URL you typed at the point in page rendering when it has rendered the CNN headings and sidebar links, but not the text yet. Not too hard, but takes a time or two practice. If it is a layout timing thing I should tell you I'm using: 56K modem C6-200 running W95 OSR2 user_pref("content.notify.backoffcount", 3); user_pref("content.notify.interval", 4000); user_pref("content.notify.ontimer", true); Now I think this is going to be a real bear to boil down to a "simple" testcase. I'll try, but no garuntees.
This bug appears to be an artifact of some part of mozilla's processing and probably not related to the HTML content of the pages. I say this because I was able to reproduce this bug by: Starting a fresh mozilla going to abcnews.com following a link to a story about the dude caught with bomb stuff reading the article and then hitting the back button While loading, entering the url www.random.com and hitting enter. It would be a high coincidence if both CNN and abcnews' webpages had the same strange HTML to prompt this bug. I will be trying to isolate any timing issues that may/may not be involved instead of trimming the HTML down.
Slashdot to a "Read More" link back then www.random.com crashes as well. The only key issues I can find here seem that the "first" page needs to be long (take a while to load) and that the sooner you enter the URL after going back to the first page the better the chances of causing the crash. For this last case I tried doing it but letting the page render about 50% (seat of the pants est.) and then entered the URL - no crash. Hmm... I wonder if it has to do with number of page reflows....
Although significantly more difficult to do so, I was able to reproduce the crash with: user_pref("content.notify.ontimer", false); With notify.ontimer turned off, I believe mozilla is spawning a lot more page reflows and it's harder for me to get the URL entered in the first X reflows. To test this gut instinct, I'm turning timed reflows back on but making the time between reflows much longer. Hopefully that will yield more insight.
Twiddling with the timed reflow preferences further proved inconclusive to me. I think I've taken this bug description as far as I can. It needs some stack traces or debug output I think.
I've found that my steps to reproduce need not be so strict in a few areas. Basically you start with a fresh browser. Then you go to a long page (eg. www.cnn.com) then you go somewhere else (follow a link) then once most of the second page has loaded, you use the back button. Then before the first page loads very much you go somewhere else. I thought you had to hand type URLs, and stuff but it seems it's easier to reproduce than I thought. I went to CNN's main page, followed a link. Read about the democratic debate. Hit back, then pretty soon (before it loaded much of the main page) clicked on one of their feature links (food with feelings). Sure enough, it crashed. I hope we can nail this one down because I'm beginning to think it is responsible for 90% of all mozilla crashes that I experience.
Yep, stephena. I can reproduce this 1999121708 WinNT.
changing assignment from nobody@netscape.com to nobody@mozilla.org
[Correcting assignation from "nobody@netscape.com" to "nobody@mozilla.org".]
This bug appears to have slipped under the rug. While more difficult to reproduce, I was still able to reproduce it under build 2000010408. I am reassigning to "owner of selected component" hoping that it will fall to somebody other than nobody.
This bug causes at least five page faults per day on me. It was filed over a month ago. Is there a chance it could at least get assigned to somebody?
Assignee: nobody → gagan
Component: Browser-General → Networking
QA Contact: nobody → tever
Updating QA contact.
reflow related?
Assignee: gagan → troy
Component: Networking → Layout
QA Contact: tever → petersen
Re-assigning to Vidur, because it's content sink related
Assignee: troy → vidur
Sorry this got moved around so much. I can't seem to recreate it on the 1/26/2000 build using either the URL bar typing or link clicking schemes described. stephena@hiwaay.net, could you confirm that it still exists? If it still does for you, it's probably timing related - something that it will make it oh so much fun to debug.
Well... I'm pretty sure it still happens. However, I just downloaded today's nightly build and got "The XPCOM.DLL file is linked to missing export KERNEL32.DLL:GetFileAttributesExA. So... doesn't look like I'll be getting any testing done on this version. I report back tomorrow assuming tomorrows build actually starts.
stephena: the 'XPCOM ...' problem is bug #25028. Maybe fixed in tomorrow's builds (but maybe a little longer) -- see bug for details. vidur: I have dup'd this with builds after 12/18 (perhaps as late as 01/10), but I had tried with 01/21 and couldn't do it. But, yes, my sense of the crash is that it is timing related (oodles of fun -- although, I think that this has more to do with either necko or "history" -- but that is purely my guess).
I just got done trying to reproduce this bug in M13. I was not able to. However, if at all possible, I would like to withold resolving this bug for a period of time. In my tests I found that mozilla has a new bug which may be masking this crash. I found that when you click on a link while a page is reflowing (from a back operation) mozilla incorrectly registers the new link to load as the present location. The crash I originally reported was most easily reproduced by clicking on a link during the reflow after a back. It may be that the crash is still there but not showing up since the link click is not registering as a new link. One of the odd pecularities of the original bug was that you had to link to somewhere you had not been before (in that session). So it is quite possible that this mishandling of the link click is masking this bug. I'll go try and find the bug associated with this mishandling or file a new one.
Adding "crash" keyword to all known open crasher bugs.
Keywords: crash
I'm still not able to reproduce this. There's been enough change to the webshell loading process that I don't doubt that the original bug has been fixed (and possibly replaced with a new set :-)). stephena@hiwaay.net, can you confirm that this no longer appears on a recent build. Thanks.
Yes, I agree. I am unable to reproduce this bug. While the other page loading link click is still broken, I will concentrate on seeing that get fixed. If this bug should become a problem once that is fixed I will file a new bug and reference this one. In the meantime, I guess it's only fair to call this fixed.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed in the Feb 29th build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.