532141 - Crash in [@ NormalizeColor] from CreateDIBSection

Status: RESOLVED DUPLICATE of bug 538642

(Core :: Widget: Win32, defect)

Description

[Marcia Knous [:marcia]]

Bug 529734#c7 indicates this crash is in the same module as that bug, but timeless indicates it would need a different fix. So I think it is easier to track the work in a separate bug.

http://tinyurl.com/yh8o38v is a link to all of these crashes in B4, but crashes have been occurring in the earlier betas as well.

Comment 1

[timeless]

From bug 529734 comment 7:
Signature    NormalizeColor
bp-43691918-0e8d-4cf8-9cc6-d91b62091123
Time     2009-11-23 11:33:07.516401
Uptime    570
Last Crash    573 seconds before submission
Product    Firefox
Version    3.6b3
Build ID    20091115182845
Branch    1.9.2
OS    Windows NT
OS Version    5.1.2600 Service Pack 2
CPU    x86
CPU Info    GenuineIntel family 6 model 15 stepping 13
Crash Reason    EXCEPTION_FLT_DIVIDE_BY_ZERO
Crash Address    0x5acf4268
User Comments    
Processor Notes     
Crashing Thread
Frame     Module     Signature [Expand]     Source
0     icm32.dll     NormalizeColor     
1     icm32.dll     MyNewAbstractW     
2     icm32.dll     CMCreateProfileW     
3     mscms.dll     InternalCreateProfileFromLCS     
4     mscms.dll     CreateProfileFromLogColorSpaceW     
5     gdi32.dll     IcmCreateProfileFromLCS     
6     gdi32.dll     mulff3_c     
7     gdi32.dll     mulff3_c     
--- call is to CreateDIBSection ---
8     xul.dll     nsDragService::CreateDragImage    
widget/src/windows/nsDragService.cpp:160
9     xul.dll     nsDragService::InvokeDragSession    
widget/src/windows/nsDragService.cpp:255
10     xul.dll     nsBaseDragService::InvokeDragSessionWithImage    
widget/src/xpwidgets/nsBaseDragService.cpp:291

Comment 2

[timeless]

Attachment: draft

Comment 3

[timeless]

ehsan: can someone please file a bug with Microsoft for this? Their code is dividing by zero....

Comment 4

[(no longer active)]

(In reply to comment #3)
> ehsan: can someone please file a bug with Microsoft for this? Their code is
> dividing by zero....

Well, Shaver has some Microsoft contacts, I personally don't! :)  CCing him.

Comment 5

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

This looks similar to a cooliris-related bug they mentioned with problems in GDI colour management, too, but I can't remember which.

I've pinged Microsoft about it.

Comment 6

[timeless]

shaver: ah yes, i remember those bugs, and thanks for pinging.

Comment 7

[Jesse Ruderman]

timeless, do you still want this patch given the change happening in bug 533035?

Comment 8

[timeless]

hrm, given that we know their code *sometimes* crashes for other reasons, i'm ok with keeping this patch.

Comment 9

[Andreas Gal :gal]

If it crashes with other reasons, this patch doesn't help. The other patch lets us actually complete the operation. Any particular technical reason why we want to keep this patch?

Comment 10

[timeless]

oh, oops, i forgot that each patch was tailored to the specific crash, the related patch catches access violations....

yeah, we can drop this.

Comment 11

[Andreas Gal :gal]

This would be a good test case. Can you make this crash on demand? I would love to verify that my patch works in-browser. I haven't been able to make library code misbehave on demand so far.

Comment 12

[timeless]

sorry, marcia found this by using crash-stats. someone should check to see if any of the reporters are mozillans.

Comment 13

[Jesse Ruderman]

Bug 514583 is the closest thing we have to a reproducible bug (on Windows).  We should probably write a bad plugin/extension so we can test the fix for bug 533035 across platforms.

Comment 14

[chris hofmann]

looks like this has risen to the #18 topcrash on early 3.6 final release data.

I notice that

http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/448d0d2d310c/widget/src/windows/nsDragService.cpp#l160

near the top of the stack.  nsDragService.cpp took a change to fix 514148, hang dragging a mail attachment over a firefox window, a=blocker, r=roc

wonder if that is related.

one comment indicates "I was selecting text with my mouse,then it broke."

several other comments are in other languages, and it looks like the problem happens a lot for those that hit it.

Comment 15

[chris hofmann]

hitting 3.6 more than other releases for some reason and concentrated on Windows NT 5.1.2600 

checking --- 20100121-crashdata.csv NormalizeColor
release total-crashes
              NormalizeColor crashes
                         pct.
all     210776  96      0.00045546
3.0.15  1697    1       0.000589275
3.0.16  1236            0
3.5.5   4720            0
3.5.6   4349            0
3.5.7   131698  21      0.000159456
3.6     11534   66      0.00572221
3.6b5   3111    13      0.00417872
3.6b4   1445    5       0.00346021
3.6b3   512             0
3.6b2   664             0
3.6b1   1013            0

all releases
   1 3.0.12
   1 3.0.15
   2 3.0.17
   2 3.5
   2 3.5.2
   1 3.5.4
  21 3.5.7
  48 3.6
   5 3.6b4
  13 3.6b5

os breakdown
46      0.479167        Windows NT5.1.2600 Service Pack 3
40      0.416667        Windows NT5.1.2600 Service Pack 2
7       0.0729167       Windows NT5.1.2600 Dodatek Service Pack 3
2       0.0208333       Windows NT5.1.2600 Dodatek Service Pack 2
1       0.0104167       Windows NT5.1.2600 Service Pack 1

Comment 16

[Alfred Kayser]

As there is a valid patch, why not submit it, so that with the first fix release this easy fix is included?

Comment 17

[timeless]

alfred: roughly speaking, i don't baby sit patches i write. and philor who does doesn't look for patches i write in bugs where i'm not the assignee very frequently. basically, if this has sufficient reviews, then anyone with push privs is welcome to deal with the pain of doing a push.

Comment 18

[Jeff Muizelaar [:jrmuizel]]

Why are we crashing with EXCEPTION_FLT_DIVIDE_BY_ZERO? Shouldn't that be masked?

Comment 19

[Jesse Ruderman]

Yes, it's masked now that bug 533035 is fixed.  But maybe we still want to fix this code to not divide by zero.

Comment 20

[timeless]

jesse: it isn't our code, it's microsoft's....

Comment 21

[timeless]

Attachment: try server approved version

Comment 22

[timeless]

Attachment: try server approved version

oops, with the right bug number :)

Comment 23

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #22)
> Created an attachment (id=424562) [details]
> try server approved version
> 
> oops, with the right bug number :)

Presumably CreateDIBSection is assuming that floating point division by zero does not throw an exception. I don't think we should be patching around this hole because I expect we'll just run into it someplace else. Instead, I think we should be trying to prevent the floating point exception control from being changed behind our back.

Comment 24

[Damon Sicore (:damons)]

OK.  So, what's next here?  Is this patch good enough?  Does someone else need to review or request approval? It's #18 on crash-stats, and we need to do something.

Comment 25

[Mike Beltzner [:beltzner, not reading bugmail]]

Next steps are:
 - land this on trunk
 - see if it's the right fix
 - if so, nominate for landing on the 1.9.2 branch

Comment 26

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #25)
> Next steps are:
>  - land this on trunk
>  - see if it's the right fix
>  - if so, nominate for landing on the 1.9.2 branch

I don't think this is the right fix for reasons explained in comment #23. So I think landing this on trunk is a bad first step.

Comment 27

[u273419]

From the user, whose FF 3.6 crashes creates these bug reports: I narrowed down the possibilities of Firefox crashing at only one website:

http://commons.wikimedia.org/w/index.php?title=Special:Upload&uselang=fromwikimedia

I really hope this helps.

Comment 28

[nobuyuki.nyuu]

(In reply to comment #27)
> From the user, whose FF 3.6 crashes creates these bug reports: I narrowed down
> the possibilities of Firefox crashing at only one website:
> 
> http://commons.wikimedia.org/w/index.php?title=Special:Upload&uselang=fromwikimedia
> 
> I really hope this helps.

I have experienced crashes on nearly every site which uses a commondialog to prompt for a file to upload, not just that site.  However, that is the only thing from my standpoint as a user that I see happening in common with the crashes I experience

Comment 29

[Benjamin Smedberg]

It's possible that some shell extension is resetting the FPU exception bit. If this is the case bug 538642 ought to fix it.

Comment 30

[u273419]

(In reply to comment #28)
Wikimedia web page doesn't visibly use a commondialog of Windows, but probably calls and passes an incorrect value, but then, what do I know? Also, it's the only site I upload files. I write this to clarify my work environment.

Comment 31

[u273419]

(In reply to comment #29)
> It's possible that some shell extension is resetting the FPU exception bit. If
> this is the case bug 538642 ought to fix it.

All the FF add-ons and all the video plugins are disabled. It still crashes randomly.

Comment 32

[u273419]

(In reply to comment #29)
> It's possible that some shell extension is resetting the FPU exception bit. If
> this is the case bug 538642 ought to fix it.

All the FF add-ons and all the video plugins are disabled. It still crashes randomly.

Comment 33

[u273419]

(In reply to comment #30)
> (In reply to comment #28)
> Wikimedia web page doesn't visibly use a commondialog of Windows, but probably
> calls and passes an incorrect value, but then, what do I know? Also, it's the
> only site I upload files. I write this to clarify my work environment.

I apologize about the stupid comment regarding the commondialog. Of course it calls on the dialog. My thinking cap got blown off in the snowstorm and the brain froze. 
If it's the commondialog, is there a solution for it?

Comment 34

[nobuyuki.nyuu]

Hello, I just wanted to add that on boards with wakaba-style codebases which have a drop-down option to redirect back to the same page rather than to the threadlist, submitting a post with an image attached seems to crash less often, but this doesn't appear to be consistent.  Whenever I crash it is typically after part of the next page redirected to is being rendered, but not completely finished rendering (ie:  I can see the next page loading).  When redirecting to the same page, it appears as if it doesn't have to render a different page and maybe this causes it to crash less (?)  This might just be me misinterpreting the observation, but if there's a difference in how 3.6 and beyond handle cdlgs and redirected page rendering it might be worth noting.

Comment 35

[timeless]

imre: i've proposed moving the common dialogs out of process. that would fix it. i don't know if i filed a bug for it. let's not sidetrack this bug with that problem.

Comment 36

[u273419]

(In reply to comment #35)
> imre: i've proposed moving the common dialogs out of process. that would fix
> it. i don't know if i filed a bug for it. let's not sidetrack this bug with
> that problem.

Thanks timeless. Call me crazy but perhaps the problem originates from the video card? Perhaps all those who have this problem would post their card make and model? I have strong reasons for asking this. Mine is an desktop ATI Radeon X1330/1500.

Comment 37

[timeless]

it could be any shell extension, and it's quite possible that your video card included one (it's stupid that it would, but i've seen them do that). but really, this is offtopic.

if you can reproduce this problem, can you please try a nightly from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ and try to reproduce it there? if you can, please provide an incident id, that'll make me more comfortable about pushing. if you can normally reproduce, but can't w/ the nightly, please indicate as much.

Comment 38

[u273419]

(In reply to comment #37)
> it could be any shell extension, and it's quite possible that your video card
> included one (it's stupid that it would, but i've seen them do that). but
> really, this is offtopic.
> 
> if you can reproduce this problem, can you please try a nightly from
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ and try to
> reproduce it there? if you can, please provide an incident id, that'll make me
> more comfortable about pushing. if you can normally reproduce, but can't w/ the
> nightly, please indicate as much.

Hi timeless and thanks for helping. I downloaded firefox-3.7a3pre and installed it. All extensions were uninstalled but all the plugins remained and most are outdated.
It crashed but not the same site as usual, and here is the report it generated: 
http://crash-stats.mozilla.com/report/index/32833ceb-0aa8-46ad-a477-c59182100311
I hope this is what you were looking for.

Comment 39

[u273419]

Well, I am using the 3.7a3pre for the past three days without any crashes, which ended after installing the subsequent build on 2010-03-12 AM. No more crashes, so uninstalled 3.6 altogether and not looking back. Also processed 1,000+ images to Wikimedia without a single crash while using the Windows common dialog.

Still not using any extensions in 3.7a3pre, and believe that the increased speed is due to this, and not to any magical improvement. In the past, I also tested Version 3.6 without extensions and it was just as fast.

Comment 40

[nobuyuki.nyuu]

hello bug fixers, I just wanted to let you know that the crashing issue for me was solved about 2 updates ago.  Thank you very much, I think whatever you guys did solved the problem.  (Did you end up sandboxing the common dialog?)

Comment 42

[LegNeato]

Clearing "needed" as the bug this was duped to is already in 1.9.2.