4703 - surf demo 9, then demo 10

Status: VERIFIED FIXED

(Core :: Layout: Images, Video, and HTML Frames, defect, P1)

Description

[john.milton]

version 990406 (about: doesn't show version number)

sometimes crash, sometimes screen has background of "horizontal hold"
type noise, then re-load caused crash below. Very repeatable


APPRUNNER caused an invalid page fault in
module <unknown> at 0000:28bff768.

Registers:
EAX=0076f59d CS=0177 EIP=28bff768 EFLGS=00010246
EBX=0076f59d SS=017f ESP=00670038 EBP=00670058
ECX=006700dc DS=017f ESI=81634d8c FS=2a07
EDX=bff76859 ES=017f EDI=00670104 GS=0000
Bytes at CS:EIP:

Stack dump:
bff7684d 00670104 0076f59d 00670120 006700dc 00670210 bff76859 0076f59d 006700ec
bff87fc0 00670104 0076f59d 00670120 006700dc 28bff768 006702c8

Comment 1

[rickg]

Chris -- this shows that demo9 is pretty bad. It's either a frame bug, or a
rendering bug (maybe even both). All I did to reduce this was use demo9 source,
but substitute a simple html document for each frame (just one line of text).
This is a top priority bug fix.

Comment 2

[leger]

rickg says top priority, marking as so and putting on M4.

Comment 3

[karnaze (gone)]

If this is the bug where demo 9 looks very bad then this was fixed late this
afternoon by Kipp. I will wait until tomorrow for the revised optimized bits to
declare it fixed. I was not able to get it to crash on WinNT optimized 4/8. I
hope it is not a Win98 problem.

Comment 4

[karnaze (gone)]

I went sample 10 without going to sample 9 first and on the 4/8 6:35pm optimized
WinNT build from the ftp site, it crashed. My debug build of 4/8 1pm (or so) did
not crash but did not show anything on the page. Reassigning to Michael an CCing
Kevin.

Comment 5

[Claudius Gayle]

*** Bug 4683 has been marked as a duplicate of this bug. ***

Comment 6

[chris hofmann]

lets get beppe and leger to reconfirm the problem in the final m4
builds and release note any problems that still exist.
moving to m5

Comment 7

[Bruce Mitchener]

re-assigning away from michaelp ....

Comment 8

[Peter Trudelle]

Yup, reliable crash on NT using today's optimized bits, even going directly to
#10.  I don't see how this has anything to do with XPToolkit though, or why it
was assigned to me.  Is Michael on vacation?  reassigning to RickG for possible
re-triage.

Comment 9

[chris hofmann]

works for me on win95.
moving to m6

Comment 10

[rickg]

Chris -- before I spend a bunch of time digging into this, can you please run it
on your test machines and let me know if its still an issue? Thanks.

Comment 11

[Christine Hoffman]

Using 5/17 Apprunner on Win 95, Win 98. Win NT, Linux and Mac8.5 (5/16 build on
Mac).

(1) Open demo #9
(2) Open demo #10
(3) Open demo #9
(4) Open Demo #10

Application crashes across platform with the following details:
APPRUNNER caused an invalid page fault in module RAPTORVIEW.DLL at
 0137:01d55cbf.

Call stack:
nsViewManager::RenderViews
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1200]
nsViewManager::Refresh
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 521]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1646]
HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 67]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 414]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 431]
nsWindow::OnPaint
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2800]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2166]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 475]
KERNEL32.DLL + 0x3663 (0xbff73663)
KERNEL32.DLL + 0x22894 (0xbff92894)
0x0788c48

Viewer does not crash. The crash occurs trying to get back to the frames page.

Comment 12

[rickg]

Patrick -- this is an important bug to fix for M6. Please take a look.

Comment 13

[Patrick C. Beard]

I've got a fix for this:  in nsViewManager.cpp there are global drawing surfaces,
but view manager specific rendering contexts that only get created when the
global surfaces were too small. The fix is to always create the local rendering
contexts if they are NULL, using the global drawing surfaces. This also fixes bug
#5062.

Comment 14

[Patrick C. Beard]

*** Bug 5062 has been marked as a duplicate of this bug. ***

Comment 15

[rubydoo123]

this now works, no crashes, no freezes! marking verified