surf demo 9, then demo 10

VERIFIED FIXED in M6

Status

()

P1
critical
VERIFIED FIXED
20 years ago
3 months ago

People

(Reporter: john.milton, Assigned: beard)

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: need someone to go isolate this.)

(Reporter)

Description

20 years ago
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

Updated

20 years ago
Assignee: don → rickg

Updated

20 years ago
Assignee: rickg → karnaze
Priority: P3 → P1

Comment 1

20 years ago
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.

Updated

20 years ago
Severity: major → critical
Component: Apprunner → HTMLFrames
QA Contact: 3853 → 3849
Target Milestone: M4

Comment 2

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

Comment 3

20 years ago
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.

Updated

20 years ago
Assignee: karnaze → michaelp

Comment 4

20 years ago
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

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

Updated

20 years ago
Target Milestone: M4 → M5

Comment 6

20 years ago
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

Updated

20 years ago
Assignee: michaelp → trudelle

Comment 7

20 years ago
re-assigning away from michaelp ....

Updated

20 years ago
Assignee: trudelle → rickg

Comment 8

20 years ago
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.

Updated

20 years ago
Whiteboard: need status update.

Updated

20 years ago
Whiteboard: need status update. → need someone to go isolate this.
Target Milestone: M5 → M6

Comment 9

20 years ago
works for me on win95.
moving to m6

Updated

20 years ago
Assignee: rickg → chrisd

Comment 10

20 years ago
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.

Updated

20 years ago
Assignee: chrisd → rickg

Comment 11

20 years ago
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.

Updated

20 years ago
Assignee: rickg → beard

Comment 12

20 years ago
Patrick -- this is an important bug to fix for M6. Please take a look.
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 13

20 years ago
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.
(Assignee)

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
(Assignee)

Comment 14

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

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 15

20 years ago
this now works, no crashes, no freezes! marking verified

Updated

4 months ago
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.