Closed Bug 302536 Opened 19 years ago Closed 18 years ago

crash [@ nsEventStateManager::UpdateCursor ] when visiting and/or printing a page on www.vdab.be

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P1)

x86
Windows 95
defect

Tracking

()

VERIFIED FIXED
mozilla1.8.1alpha2

People

(Reporter: benoit, Assigned: dbaron)

References

(Blocks 1 open bug, )

Details

(6 keywords, Whiteboard: [patch])

Crash Data

Attachments

(9 files, 4 obsolete files)

1.61 KB, text/html
Details
235 bytes, text/html
Details
18.48 KB, text/plain; charset=utf-8
Details
15.25 KB, text/html
Details
7.43 KB, application/x-zip-compressed
Details
9.38 KB, text/plain; charset=UTF-8
Details
6.81 KB, patch
Biesinger
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review
1.61 KB, patch
bzbarsky
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review
2.17 KB, text/html; charset=UTF-8
Details
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
Keywords: crash
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
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)
TB8515736E
I'm told 1.7.x doesn't crash
Keywords: regression
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.
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 
Attached file reduced testcase (obsolete) —
produced TB10842945X

Steps to repeat:
1. load testcase, JS enabled
2. Print-Preview
3. hover
4. if not crashing on hover, close PrintPreview
Attached file minimal testcase (obsolete) —
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>.
Attachment #200063 - Attachment is obsolete: true
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
Keywords: testcase
Attached file reduced testcase
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.
Attached file minimal testcase
<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 blocking1.8.0.1 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
Flags: blocking1.8.0.1?
Need a trunk-tested patch before we would take for the branch. If you get that you can request branch approval for the patch.
Flags: blocking1.8.1?
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1-
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 1.5.0.2 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 1.5.0.2 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 1.5.0.2.

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 1.5.0.2 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:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2
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 1.5.0.2 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.
Attached patch patch (obsolete) — Splinter Review
Assignee: events → dbaron
Status: NEW → ASSIGNED
Attachment #219103 - Flags: superreview?(bzbarsky)
Attachment #219103 - Flags: review?(cbiesinger)
Whiteboard: [patch]
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.
Attached patch patchSplinter Review
Attachment #219103 - Attachment is obsolete: true
Attachment #219109 - Flags: superreview?(bzbarsky)
Attachment #219109 - Flags: review?(cbiesinger)
Attachment #219103 - Flags: review?(cbiesinger)
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.
Attachment #219182 - Flags: superreview?(bzbarsky)
Attachment #219182 - Flags: review?(bzbarsky)
Attachment #219182 - Flags: approval1.8.0.3?
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. :)
Attachment #219182 - Flags: superreview?(bzbarsky)
Attachment #219182 - Flags: superreview+
Attachment #219182 - Flags: review?(bzbarsky)
Attachment #219182 - Flags: review+
Fix checked in to MOZILLA_1_8_BRANCH.
Keywords: fixed1.8.1
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: approval1.8.0.3? → approval1.8.0.3+
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).
Keywords: fixed1.8.0.3
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:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4. Ran both test cases with no crash. Although I didn't specifically test Win 95, Comment 70 indicates that we should be okay there.
No longer depends on: 380075
Depends on: 402648
No longer depends on: 402648
Flags: blocking1.8.1?
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.

Attachment

General

Creator:
Created:
Updated:
Size: