Closed Bug 302536 Opened 18 years ago Closed 18 years ago
crash [@ ns
Event State Manager::Update Cursor ] when visiting and/or printing a page on www .vdab .be
1.61 KB, text/html
235 bytes, text/html
18.48 KB, text/plain; charset=utf-8
15.25 KB, text/html
7.43 KB, application/x-zip-compressed
9.38 KB, text/plain; charset=UTF-8
6.81 KB, patch
|Details | Diff | Splinter Review|
1.61 KB, patch
|Details | Diff | Splinter Review|
2.17 KB, text/html; charset=UTF-8
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b4) Gecko/20050727 SeaMonkey/1.0a Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b4) Gecko/20050727 SeaMonkey/1.0a Every day my dad would go to www.vdab.be to look for job offers. Almost every day SeaMonkey would crash during his visit. The visit is such a routine that he doesn't know what he did prior to the crash. Today I noticed it crashing when printing a page on the site. I could reproduce it. Printing Google works fine, though. Yet when I was initially typing this bug report, SeaMonkey also crashed by having the site in a tab. I've included TalkBack IDs. There are a lot of them. Reproducible: Always Steps to Reproduce: 1. Go to http://www.vdab.be/ 2. Click "Werk Zoeken" 3. Choose selections from the pulldown menus 4. Click "Zoeken" 5. Click "Toon Jobs" 6. Click on one of the offers 7. Print the page Actual Results: SeaMonkey will crash a few seconds after sending the commands to the printer driver. Expected Results: Not have crashed. TB7353636Z TB7426469Y TB7503541E TB7812815M TB7885445H TB7886042W TB7889075K TB7889605X
OS: other → Windows 95
Version: unspecified → Trunk
Stack Signature nsEventStateManager::UpdateCursor fc813fd9 Product ID MozillaTrunk Build ID 2005072705 Trigger Time 2005-07-28 08:55:52.0 Platform Win32 Operating System Windows 95 4.0 build 67306684 Module GKLAYOUT.DLL + (00111f87) URL visited local page User Comments Printing. Since Last Crash 1341 sec Total Uptime 37173 sec Trigger Reason Invalid operation Source File, Line No. c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp, line 2376 Stack Trace nsEventStateManager::UpdateCursor [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp, line 2376] nsEventStateManager::PreHandleEvent [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp, line 487] PresShell::HandleEventInternal [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp, line 6354] PresShell::HandleEvent [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp, line 6193] nsViewManager::HandleEvent [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp, line 2549] nsViewManager::DispatchEvent [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp, line 2236] HandleEvent [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp, line 174] nsWindow::DispatchEvent [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp, line 1241] nsWindow::DispatchMouseEvent [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp, line 5930] ChildWindow::DispatchMouseEvent [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp, line 6181] nsWindow::WindowProc [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp, line 1418] KERNEL32.DLL + 0x35d9 (0xbff735d9) KERNEL32.DLL + 0x2222f (0xbff9222f) 0x00638bec
Summary: crash when visiting and/or printing a page on www.vdab.be → crash [@ nsEventStateManager::UpdateCursor ] when visiting and/or printing a page on www.vdab.be
> URL visited local page > User Comments Printing. Please pay no heed to the URL. It was a left-over from a previous crash that I forgot to remove.
Assignee: general → events
Component: General → Event Handling
Product: Mozilla Application Suite → Core
QA Contact: general → ian
-> me for now
Assignee: events → cbiesinger
Priority: -- → P1
is this a regression?
It very well may be. My dad has been visiting that site for years, doing the same things.
hmm, I don't crash... (winxp)
SeaMonkey can still be faithfully crashed by printing a job offer on that site. Got a crash because of that today. TB8362878M
that points to the line: 2413 dbaron 1.582 SetCursor(cursor, container, haveHotspot, hotspotX, hotspotY, 2414 aTargetFrame->GetWindow(), PR_FALSE); Is it possible that a bad target frame pointer is passed to this function? (but non-null, that's checked in the line above)
I don't crash here on winxp. maybe 9x specific :-/ I do get this assertion twice: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/tables/nsTableRowGroupFrame.cpp&rev=3.345&cvsroot=/cvsroot&mark=1042-1043#1040
I'm told 1.7.x doesn't crash
Regression window: 2005063006 - works 2005070106 - broken The IDs come from the directories I downloaded the builds from. The ID of the actual build may vary by one hour.
Worksforme on Linux.
crash Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051012 SeaMonkey/1.1a Talkback ID: TB10739762H Followed steps to repeat, but did a Print Preview instead of printing. Crashed after about five or ten seconds, just when I was thinking it is wfm :-(
crash Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051012 SeaMonkey/1.1a TB10741698M, TB10739762H Steps to reproduce: 1. Go to http://www.vdab.be/ 2. Click "Werk Zoeken" 3. Choose selections from the pulldown menus I selected the first entry of the first three puldown menus. Beroep:Bedienden Regio:Vlaanderen Diploma:Leercontract+2de grad ... 4. Click "Zoeken" 5. Click "Toon Jobs" 6. Click on one of the offers I clicked the first offer: http://www.vdab.be/mijnvdab/jobs/wz/jobs.jsp?ID=1384110&sess=2&action=DETAIL 7. Click File->PrintPreview Print Preview opens, doesn't crash as long as you don't move the mouse. There is a navigation menu with vdab Logo in the top region of the print preview. When you hover over this menu, Seamonkey crashes. 8. Move mouse to navigation menu in the top of the page: crash
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051012 SeaMonkey/1.1a TB10842033H, TB10841970W, TB10841921Z Simple steps to reproduce: 1. load http://www.vdab.be/ 2. Print Preview 3. hover over the Welkom.....VDAB heading
produced TB10842945X Steps to repeat: 1. load testcase, JS enabled 2. Print-Preview 3. hover 4. if not crashing on hover, close PrintPreview
there is a map on the banner, it crashes in Print Preview if you hover over the unspecified areas. In the original file there are areas specified on the tabs, you can hover over the areas, you crash when you hover over a region in the image not specified by an <area>.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051016 Firefox/1.6a1 TB10844637Y crash on URL or testcase? TB10846011M crash on hovering minimal testcase in Print Preview TB10846220G crash on hovering after PrintPreview Steps to reproduce: 1. Load testcase Attachment 200070 [details] 2. open PrintPreview 3. close PrintPreview 4. hover over banner
reduced testcase made from original URL. Load, open&close PrintPreview, then hover over the tabs, i.e. <area>s, no crash. You crash when leaving the area and entering the image.
<html><head><TITLE>302536</TITLE></head> <body bgcolor="#ffffff"> <img src="https://bugzilla.mozilla.org/mozilla-banner.gif" alt="" usemap="#mainmenu" border="0" height="60" width="630"> <map name="mainmenu"></map> </body></html> After Print or Preview hover over the banner and watch your favourite Gecko crashing.
Attachment #200070 - Attachment is obsolete: true
WFM Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051028 SeaMonkey/1.1a Print Preview both testcases and URL
Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8) Gecko/20051030 SeaMonkey/1.0b Still crashes on the branch.
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20051030 SeaMonkey/1.0b tested on testcases and URL, Print Preview only Win98SE, BuildID: 2005103012
That's odd. I'm using the same branch build with the same build hour. Crashed on both testcases. Tested a latest-trunk build that happens to be of the same day. Crashed on the minimal testcase: TB11326174X
Crash on latest Firefox branch build: TB13571401. Only on reduced testcase. Requesting blocking126.96.36.199 because -crash bug -affects Firefox and SeaMonkey Standard8 thought this might be helpful: http://talkback-public.mozilla.org/talkback/fastfind.jsp? search=1&searchby=stacksig&match=contains &searchfor=+nsEventStateManager%3A%3AUpdateCursor&vendor=MozillaOrg &product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid
Need a trunk-tested patch before we would take for the branch. If you get that you can request branch approval for the patch.
sounds like this is a floating point exception during an fstp instruction, not happening in debug builds. -> default owner
Assignee: cbiesinger → events
I am unable to reproduce this on a german win95b with a canon bj10e printer driver, on neither the "reduced testcase" nor the "minimal testcase". (the system configuration was a freshly installed windows 95 "with usb support", with installed vmware tools, and the mentioned printer driver). I used SeaMonkey 1.0. my steps to reproduce were: - load the testcase - hover over the banner a bit - file|print preview - again, hover over the banner - click the "Close" button - hover again over the banner no crash.
Did you use both debug and regular builds? I thought of something odd: could it be related to my resolution, 640x480?
only regular builds (the official release) hm... not impossible... what bit depth are you using?
Regular builds? Okay then. Because as you know, debug builds didn't crash on me. I use 24-bit colours.
It would be quite useful to have the registers for a talkback incident for this crash. (Even the registers from one of the crash dialogs would be useful, assuming I can download the build in question afterwards.) Or does somebody already know on which instruction it's crashing? comment 29 suggests biesi does.
TB17628451 as html with bugzilla queries and bonsai links in case the talkback server is done or the record deleted like the rest of the records in this bug.
Apparantly TalkBack requires IE, so I couldn't send my talkback to the server. That's why the ZIP file. This talkback is of the latest Firefox 1.5 from the 1.8.0 branch, running on Windows 95.
If those were attempts to answer my question, they don't help. It's always easy to find new talkback incidents by searching, but talkback doesn't have the information I need. (It used to, but something broke that.) I just need the register info from the windows crash dialog that you get if you don't have talkback (or at least that you used to get) for an occurrence of this crash in Fx 188.8.131.52 release.
Ah, you mean this? SEAMONKEY heeft een uitzondering 10H veroorzaakt in module GKLAYOUT.DLL op 0137:6037980f. Registers: EAX=604a32c8 CS=0137 EIP=6037980f EFLGS=00010246 EBX=01cab934 SS=013f ESP=0065f54c EBP=0065f594 ECX=00bbfb00 DS=013f ESI=0208a528 FS=0cd7 EDX=00000000 ES=013f EDI=0208a520 GS=0000 Bytes in CS:EIP: d9 1c 24 ff 75 ec ff 75 f8 ff 75 fc 56 ff 50 68 Stack-dump: 00bbfb00 01c8bea4 00bbf9f4 00000000 0065f830 0208a520 0208a528 00000000 00000003 0065f5ac 00000001 01c8bea4 01aeac04 0065f5ac 00000001 01c8bea4
Yes, except that's not from the Firefox 184.108.40.206 release build, since that doesn't have a gklayout.dll. And without the build, I can't do much with the addresses there. How about one from the official release build?
This is the a 1.8.0 nightly of Firefox 220.127.116.11. FIREFOX heeft een uitzondering 10H veroorzaakt in module FIREFOX.EXE op 0137:006a19e4. Registers: EAX=00a07188 CS=0137 EIP=006a19e4 EFLGS=00010246 EBX=018cd040 SS=013f ESP=00d1f42c EBP=00d1f474 ECX=0285c5e0 DS=013f ESI=02852a38 FS=27a7 EDX=00000000 ES=013f EDI=02852a30 GS=0000 Bytes in CS:EIP: d9 1c 24 ff 75 ec ff 75 f8 ff 75 fc 56 ff 50 68 Stack-dump: 0285c5e0 018ccdd4 0285c044 00000000 00d1f710 02852a30 02852a38 00000000 00000003 00d1f48c 00000001 018ccdd4 026099e4 00d1f48c 00000001 018ccdd4 Didn't think of the release build when doing this. I'll get right on it, even though there probably hasn't been a check-in for 1.8.0 yet.
Crash on Firefox 18.104.22.168 release build. FIREFOX heeft een uitzondering 10H veroorzaakt in module FIREFOX.EXE op 0137:006a12c0. Registers: EAX=00a06178 CS=0137 EIP=006a12c0 EFLGS=00010246 EBX=018c23bc SS=013f ESP=00d1f438 EBP=00d1f480 ECX=02363b10 DS=013f ESI=0230e368 FS=0d2f EDX=00000000 ES=013f EDI=0230e360 GS=0000 Bytes in CS:EIP: d9 1c 24 ff 75 ec ff 75 f8 ff 75 fc 56 ff 50 68 Stack-dump: 02363b10 018c2150 02365594 00000000 00d1f71c 0230e360 0230e368 00000000 00000003 00d1f498 00000001 018c2150 0227c6d4 00d1f498 00000001 018c2150
wfm Mozilla/5.0 (Windows; U; Win98; de; rv:22.214.171.124) Gecko/20060308 Firefox/126.96.36.199 and Seamonkey 1.0.1, tested on reduced and minimal testcase only, Win is win98 Standard Edition + SP1 * IE5.x +++ benoît seems to see the crash from using win95.
This is the disassembly from the Firefox 188.8.131.52 release. Note where the EIP register in the info above lines up in this disassembly.
put hotspotY into space on stack 6a12b9: d9 5c 24 04 fstps 0x4(%esp) I guess this is it. :) I'm no real developer (yet), though.
(In reply to comment #44) >Note where the EIP register in the info above lines up in this disassembly. Well it sort of makes sense for an unmasked floating-point exception.
So, after looking at the intel docs, I think the exception is coming from the line before. (I don't remember whether things are consistent or not on whether EIP has advanced at the top of the stack; I know it always has advanced for function calls, since the saved EIP on the stack is the address to return to. I could just check another crash, but this makes sense.) In particular, FLD gives a floating point exception if the source operand is a denormal value, which 0x00000001 is (zero biased-exponent, nonzero fraction). See volume 2A (instruction set reference, part 1) and Volume 1 sections 4.2.2 and 4.8 of http://developer.intel.com/design/pentium4/manuals/index_new.htm So the question is where that value is coming from; it does appear consistently on the stack that I analyzed.
(And the other coordinate doesn't look so sensible either; I'd expect integers most of the time.)
The combination of the reduced testcases and all this analysis led to the problem, which I now see: nsImageFrame::GetCursor doesn't call FillCursorInformationFromStyle at all if map is non-null but map->IsInside returns false.
Target Milestone: --- → mozilla1.8.1alpha2
Attachment #219103 - Flags: superreview?(bzbarsky) → superreview+
So, although this patch does fix bug 177273, it isn't really right. We should really be getting the cursor style from the area, IMO.
Comment on attachment 219109 [details] [diff] [review] patch And for reviewers I should point out that areas match the :-moz-any-link rule in ua.css that specifies cursor:pointer under the same conditions that a elements do. (In fact, areas can sometimes be a elements.)
Attachment #219109 - Flags: approval-branch-1.8.1?(bzbarsky)
(In reply to comment #34) > Or does somebody already know on which instruction it's crashing? comment 29 > suggests biesi does. (Benoît had this in a debugger at one point, that's where I had that information from. My x86 asm knowledge wasn't good enough to debug that further)
Comment on attachment 219109 [details] [diff] [review] patch I'm once again impressed with your debugging. so is this XXX comment still correct, given that you do use the area content now: //XXX This will need to be rewritten once we have content for areas I assume that this won't give any "wrong parent style context" warnings?
Attachment #219109 - Flags: review?(cbiesinger) → review+
Attachment #219109 - Flags: superreview?(bzbarsky) → superreview+
Attachment #219109 - Flags: approval-branch-1.8.1?(bzbarsky) → approval-branch-1.8.1+
This is a lower risk patch for the 1.8.0 branch.
So, FWIW, WinIE6 is even more broken than our old behavior: if an image is inside a link or has a cursor style, then there are no cursor changes as the user moves over imagemaps. (That's unambiguously broken for the inside-a-link case, IMO.) So I think the only compatibility issue posed by this (trunk) patch is compatibility with ourselves: before the patch, the cursor style on an image with an imagemap applied only to the imagemap-active parts; now it applies to exactly the opposite parts. But I still think it's the right thing to do. The patch makes us significantly more compatible with Opera and Konqueror: the only difference is that they don't pick up 'cursor' on areas, but instead just forces it to the link cursor for areas that are links (i.e., what our default stylesheet does).
(In reply to comment #56) > I assume that this won't give any "wrong parent style context" warnings? I'm pretty sure that requires creating a frame with the style context.
Checked in to trunk.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
(In reply to comment #59) > (That's unambiguously broken for the inside-a-link > case, IMO.) Er, maybe it's not so broken, but anyway...
Just a note. I will only be able to verify this when it lands on a 1.8 branch. Eagerly awaiting that landing. :)
Fix checked in to MOZILLA_1_8_BRANCH.
Comment on attachment 219109 [details] [diff] [review] patch >RCS file: /cvs/mozilla/layout/generic/nsImageFrame.cpp,v > //XXX This will need to be rewritten once we have content for areas > //XXXbz We have content for areas now.... >-NS_METHOD >+NS_IMETHODIMP > nsImageFrame::GetCursor(const nsPoint& aPoint, bz, is this the re-write referenced in the XXX comment, if so, should both XXX comments be removed?
On yesterday's late SeaMonkey "1.8 branch" build running on Windows 95, both the minimal and reduced testcases don't cause a crash anymore. dbaron, you're my hero. :) My dad's happy with his birthday present. It was his birthday yesterday. ;) -> VERIFIED
Status: RESOLVED → VERIFIED
Comment on attachment 219182 [details] [diff] [review] 1.8.0 branch patch approved for 1.8.0 branch, a=dveditz for drivers
Attachment #219182 - Flags: approval184.108.40.206? → approval220.127.116.11+
Fix checked in to MOZILLA_1_8_0_BRANCH. I'd appreciate if you could verify that it's fixed in tomorrow's 1.8.0 branch builds as well, since the fix there is different (lower-risk; no behavior changes for the cases that didn't crash).
Sure, will do. I have to say that I'm already compiling a 1.8.0-based build with this and other fixes, though. :)
Sorry for being late with this, I forgot about it after waiting for a fresh nightly build with the fix. Just tested with a fresh 1.8.0 build, and it doesn't crash on either of the two testcases. I've been using an own compiled build with the (1.8.0) patch included for weeks without a crash on this, too. No crash after printing either. I think it's safe to say this has been fixed. :)
*** Bug 338082 has been marked as a duplicate of this bug. ***
verified on the 1.8.0 branch using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20060508 Firefox/22.214.171.124. Ran both test cases with no crash. Although I didn't specifically test Win 95, Comment 70 indicates that we should be okay there.
Crash Signature: [@ nsEventStateManager::UpdateCursor ]
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.