From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) BuildID: 2000041808 Browser crashes upon any attempt to access any menus. This only occurs when using multi monitors. Starting in single monitor mode works fine, but menus then always appear on primary monitor. Reproducible: Always Steps to Reproduce: 1. Load Mozilla in multi monitor mode 2. Access a menu 3. Actual Results: Core dump. No menu. Expected Results: Menu should appear

um. eek!

cc'ing hyatt, our resident body with multiple monitors.

tried on Win2K with 2 monitors, build from 4/18, late afternoon. works for me.

I think it may be a bit hasty to resolve this bug as yet. There has been a post on slashdot by a user that's having a similar problem in Win2k, I've replied to that post encouraging them to add comments to this bug. I've also contacted the reporter to ask for more specific details (e.g. graphics cards used, talkback ID's, other crash data, etc)

well, when we get that feedback, we'll reopen it. until then, no one here can reproduce it.

I was able to reproduce this with the m15 release in win98. Mozilla starts normally, but as soon as you try to pull down any menu, mozilla crashes. My configuration is: Win98 SE, Nvidia riva tnt2 ultra as the primary, Voodoo3 3000 as the secondary. They are both running at 1024x768x32 resolution. The tnt is my righthand display.

so is the monitor configuration like this: --------- -------- | primary | | 2ndary | --------- -------- or is it like this? --------- --------- | 2ndary | | primary | --------- --------- that might make all the difference....

-------- --------- | 2ndary | | primary | -------- --------- also, here is some more info: the same thing happens with build id: 2000041908 if i move the mozilla window to the secondary disp, and then try to open a menu, mozilla becomes unresponsize, /but does not crash/

I'm using a Matrox G400 MAX with PowerDesk v5.52.015. AGP, 32MB Graphics memory, Intel P3 650 Coppermine 256MB system memory, Primary monitor on the left 1152x864, secondary on the right 1024x768, both at 32bit color.

any chance of getting stack traces???

I was sent this by d.l.goodliffe: MOZILLA caused an invalid page fault in module GKGFXWIN.DLL at 0187:60a41c7b. Registers: EAX=00000000 CS=0187 EIP=60a41c7b EFLGS=00010246 EBX=00000000 SS=018f ESP=0068efc4 EBP=0068efdc ECX=0068efd0 DS=018f ESI=00000000 FS=4347 EDX=800097b0 ES=018f EDI=0068efec GS=0000 Bytes at CS:EIP: d8 4e 14 d9 ee d8 d9 df e0 9e 77 08 d8 05 b8 36 Stack dump: 0068f1fc 01b417e0 00000000 00000360 00000480 026676c0 0068effc 60a423d1 0068efec 01b417e0 00000000 00000000 00000000 00000000 0068f018 60b30841 the above created with m15 2000041805

thanks, but that doesn't help me at all.

d.l.goodliffe@ncl.ac.uk or akersmc@clarkson.edu : if you are using a talkback-enabled mozilla build (such as): ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip and submit the talkback report with your email address entered into it, then we can dig up the stack trace from there. Update the bug report if you submit a report from one of these crashes. Thanks.

i sent in a talkback report as akersmc@clarkson.edu, here is the stack trace if this makes things easier: [ 0] A3 22 AE 60 94 ED 68 00 F9 29 AE 60 B4 ED 68 00 [.".`..h..).`..h.] [ 10] 5A 09 BD 60 D0 ED 68 00 D2 0B 50 01 68 F0 68 00 [Z..`..h...P.h.h.] [ 20] 87 ED 4F 01 00 F2 68 00 DE E9 4F 01 A8 F2 68 00 [..O...h...O...h.] [ 30] 52 5B 4C 01 64 F3 68 00 AB 41 45 01 84 F3 68 00 [R[L.d.h..AE...h.] [ 40] 34 FE 47 01 AC F3 68 00 ED 6E 76 60 10 F5 68 00 [4.G...h..nv`..h.] [ 50] F1 D5 77 60 FC F5 68 00 BD B9 77 60 20 F6 68 00 [..w`..h...w` .h.] [ 60] A5 EA 4F 01 88 F7 68 00 EC E7 4F 01 94 F7 68 00 [..O...h...O...h.] [ 70] 68 E5 4F 01 44 F8 68 00 9F 05 48 01 80 F8 68 00 [h.O.D.h...H...h.] [ 80] 0C 1E 36 60 C8 F8 68 00 58 9D 36 60 24 F9 68 00 [..6`..h.X.6`$.h.] [ 90] 33 28 36 60 40 F9 68 00 AB 52 B2 60 50 F9 68 00 [3(6`@.h..R.`P.h.] [ A0] F1 52 B2 60 64 F9 68 00 64 79 B2 60 F4 F9 68 00 [.R.`d.h.dy.`..h.] [ B0] 95 7C B2 60 04 FA 68 00 DB 70 B2 60 34 FB 68 00 [.|.`..h..p.`4.h.] [ C0] A8 56 B2 60 68 FB 68 00 3B 36 F7 BF 88 FB 68 00 [.V.`h.h.;6....h.] [ D0] 07 44 F9 BF 9C FB 68 00 DA 8B 68 00 B8 19 F7 BF [.D....h...h.....]

i don't need a hex dump of the stack, i need a backtrace with the routines on the call stack and the routine the PC was in when it crashed.

Like so .... (Thanks akersmc@clarkson.edu). http://cyclone/reports/SingleIncidentInfo.cfm?dynamicBBID=9032547 nsDeviceContextWin::ComputeFullAreaUsingScreen [d:\builds\seamonkey\mozilla\gfx\src\windows\nsDeviceContextWin.cpp, line 217] nsDeviceContextWin::GetDeviceSurfaceDimensions [d:\builds\seamonkey\mozilla\gfx\src\windows\nsDeviceContextWin.cpp, line 696] ScreenImpl::GetWidth [d:\builds\seamonkey\mozilla\dom\src\base\nsScreen.cpp, line 95] nsMenuPopupFrame::SyncViewWithFrame [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuPopupFrame.cpp, line 547] nsMenuFrame::OpenMenuInternal [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuFrame.cpp, line 592] nsMenuFrame::AttributeChanged [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuFrame.cpp, line 477] nsCSSFrameConstructor::AttributeChanged [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, line 9434] StyleSetImpl::AttributeChanged [d:\builds\seamonkey\mozilla\layout\base\src\nsStyleSet.cpp, line 1076] PresShell::AttributeChanged [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 2677] nsXULDocument::AttributeChanged [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp, line 1483] nsXULElement::SetAttribute [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp, line 2834] nsXULElement::SetAttribute [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp, line 1471] nsMenuFrame::OpenMenu [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuFrame.cpp, line 499] nsMenuFrame::ToggleMenuState [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuFrame.cpp, line 385] nsMenuFrame::HandleEvent [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuFrame.cpp, line 277] PresShell::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 3163] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 811] nsViewManager2::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1355] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 69] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 515] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 532] nsWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3238] ChildWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3443] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2396] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 741] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x24407 (0xbff94407) 0x00688bda

ok, i've discovered that the app is totally unresponsive when on the left monitor and the right monitor is primary, so i can't even test this situation to see if menus crash.

after trying all the various combinations, it appears clear that win2k doesn't have any of these problems. sigh. I tried the offset monitors, the primary being above/below the secondary, etc and no problems. There is a problem with the negative coordinate space that is a separate bug i filed last week (assigned to hyatt). I can't tell if it crashes when in neg coord space because the browser becomes unresponsive to all clicks, hence i can't test the menus. I'll try to build a two-headed 98 box sometime.

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

bug #36239 (same stack trace; steps to repro) noted that he was running on win2k server and could get the crash. However, he also noted that this could not be reproduced with a debug build on the same machine/monitors. (Yes, can't reproduce in debug is not good news).

*** This bug has been marked as a duplicate of 36479 ***

verified dup