Closed Bug 35277 Opened 24 years ago Closed 24 years ago

Scroll down Crash on specific URL

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jmbelo, Assigned: karnaze)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [nsbeta2-]) 

Go to:
http://www.space.com/spaceimagined/tv/fifth_trek_000405.html
Press <down> or use the "scroll down thing" to go to the botton of the page.
Expected Results: To see the end of the page.
Actual Results: Mozillas *gone*, it doesn't crash, it simply *goes* away
Reproducibility: Allways
Additional Information: It doesn't appen on www.slashdot.org, nor on www.cnn.com
nor on www.sapce.com.

Build ID: 2000040908
On M14/Windows 98, I have no problems.





But if I scroll down on 2000040815/Windows 95, it crashes and takes down the

entire system. BSOD with fatal exception OE at address 0237:BFF9A25B, and then

it brings up one of those grey-bordered white boxes, reading, GPF(I think?) in

module <unknown> at address Bff7:00000013, with one button: CANCEL. Then I have

to reboot. I've done this twice already.





*** Bug 35278 has been marked as a duplicate of this bug. ***
confirmed using m14 (build ID: 2000022820) on win98.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Rather than Mozilla just "disappearing" for me, I got a GPF when scrolling down 
near the bottom.

Details of the GPF:
MOZILLA caused an invalid page fault in
module KERNEL32.DLL at 0167:bff87ede.
Registers:
EAX=c00309c4 CS=0167 EIP=bff87ede EFLGS=00010212
EBX=0068f3a8 SS=016f ESP=0058ff94 EBP=00590000
ECX=bc015900 DS=016f ESI=81783a90 FS=0f97
EDX=bff76855 ES=016f EDI=005901e4 GS=0000
Bytes at CS:EIP:
53 56 57 8b 30 83 7d 10 01 8b 4e 38 89 4d f8 75 
Stack dump:


This might be a problem with the source or something that's being displayed, 
since it only happens on that page at a certain point.  Having trouble coming 
up with a better component to attribute this to.

Changing OS and Platform to all.
OS: Windows NT → All
Hardware: PC → All
I tried it again using the mousewheel and going much slower.  The error seems 
to kick in right as the bottom of that cyan-colored table comes into view.

I also got a different GPF this time, hope this helps somewhat:

MOZILLA executed an invalid instruction in
module <unknown> at 0000:00000017.
Registers:
EAX=0068f638 CS=0167 EIP=00000017 EFLGS=00010207
EBX=0068f6c8 SS=016f ESP=00590098 EBP=005900c0
ECX=44015900 DS=016f ESI=8178bb44 FS=12f7
EDX=bff76855 ES=016f EDI=0059016c GS=0000
Bytes at CS:EIP:
f0 df 94 00 f0 53 ff 00 f0 00 00 63 05 28 00 56 
Stack dump:
0059009c 0000016f bff76849 0059016c 0068f6c8 00590188 00590144 00590280 
bff76855 0068f6c8 00590154 bff87fd5 0059016c 0068f6c8 00590188 00590144 
Confirmed with 2000-04-09-08-M15 on WinNT; Mozilla crashes so quickly that
neither Talkback nor Dr. Watson notice. Memory used by Mozilla is reported
as available by Task Manager after the crash. This could be un-neighbourly
in Win9x-land, where apps run in a shared memory space -- Mozilla's memory
could not have been properly freed. The comments from danielpeng@bigfoot.com 
2000-04-09 regarding Win95 seem to bear this out.

Over several trials, the crash always happened after pageing down the third or 
fourth time.
Severity: normal → critical
Keywords: crash
OS: All → Windows NT
Hardware: All → PC
Summary: Scroll down Crash → Scroll down Crash on specific URL
The crash does come as the bottom edge of the cyan table is just about to 
become visible. Inspecting that table's HTML, the only thing that looked odd
was the values for width, cellpadding, and size attributes, which had an 
extraneous space inside the quote marks: " 191". Fixing that made no difference,
though.
Tried it under Linux using build ID 2000041316, didn't crash the browser, it
appears to be a Windows only bug. I'll take a look again next time I've got a 98
or NT machine available.

Crashed Windows 98 using Mozilla nightly 2000041308

MOZILLA caused an invalid page fault in
module KERNEL32.DLL at 0187:bff87ede.
Registers:
EAX=c00308b0 CS=0187 EIP=bff87ede EFLGS=00010212
EBX=0068f314 SS=018f ESP=0058ffdc EBP=00590048
ECX=005901fc DS=018f ESI=8198f348 FS=8bbf
EDX=bff76855 ES=018f EDI=00590224 GS=0000
Bytes at CS:EIP:
53 56 57 8b 30 83 7d 10 01 8b 4e 38 89 4d f8 75 
Stack dump:


are any of you still seeing this in current nighty builds?
No crash with 2000-04-22-08-M16 on WinNT; page displays fine.
WORKSFORME on 20000428 W95. 
                                                                                
jmbelo@bes.pt - are you still seeing this?

Gerv
jmbelo@bes.pt - are you still seeing this?

yes
I am unalbe to reproduce the crash with 050808 build under NT.  The page does
scroll unusually slow for me though.  There is all kinds of <layer> stuff going
on at that page I think.  That may be the problem.  Over to Layout for a look.
Assignee: asadotzler → troy
Component: Browser-General → Layout
QA Contact: jelwell → petersen
It does not crash with 5/9/2000 build on WINNT, but scroll performance is slow.
I think this is another case of long tables painting too much when scrolling.
I tried both gfx and native scrollbars (Both perform about the same.)
Assignee: troy → karnaze
It doesn;t happen with build 2000041805 (M15 milestone)
Not with keydown, pagedown or the scroll thingy..
I'll be downloading the nightly build then
(right after I automate downloading it..hmmm :)
Status: NEW → ASSIGNED
Target Milestone: --- → M17
Adding nsbeta2 keyword since table scrolling performance is a known performance 
bottleneck.
Keywords: nsbeta2
[nsbeta2-]
Whiteboard: [nsbeta2-]
Removing nsbeta2, crash keywords, adding qawanted.
Keywords: crash, nsbeta2 → qawanted
THis still worksforme with mozilla build 071108 on NT and 98.
Adding crash keyword
Keywords: crash
Adding nsbeta2 keyword to bugs with nsbeta2 triage value in status field so the 
queries don't get screwed up
Keywords: nsbeta2
I tried this with build 2000081008 in w2k and all was fixed.
I didn't see it in build 2000081008 running windows 2K.
Seem to be just fine now, build 20000816 on NT
OK, I've not seen this bug recently on NT 4.0 (latest build tested 2000081508).
Also no crash on N6 PR2 and M17. It's time to squash the bug. Marking FIXED as
I've seen the bug before but can't reproduce it now so something somewhere must
have changed and fixed it!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Marking verified pere last comments.
Status: RESOLVED → VERIFIED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.