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

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.

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

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.

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.

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

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

re-assigning away from michaelp ....

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.

works for me on win95. moving to m6

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.

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.

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

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.

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

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