247542 - M17 crash [@ SBCopyDir32To16Clip()][@ SBCopyDir32To16() ] on loading ca.yahoo.finance.com and finance.yahoo.com

Status: VERIFIED FIXED

(Core Graveyard :: Image: Painting, defect)

Description

[Jeremy Coghill]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040517 Camino/0.8b
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040517 Camino/0.8b

Camino, Mozilla and Firefox crash when attempting to load ca.finance.yahoo.com
and finance.yahoo.com.  The first nightly builds that exhibited this problem
were from June 8, 2004.

Reproducible: Always
Steps to Reproduce:
1. load the offending websites
2. refresh a couple of times if it hasn't crashed, should do so then

Actual Results:  
Browser crashes and Talkback is loaded

Expected Results:  
Page should have loaded without crashing the browser

I am using Mac OSX 10.2.8

Comment 1

[Jeremy Coghill]

Attachment: Crash log

Comment 2

[Mike Pinkerton (not reading bugmail)]

not a camino-specific bug

Comment 3

[Mike Pinkerton (not reading bugmail)]

this is a topcrash introduced on June 8 by the changes to mac imageLib. it could
be related to the leak crash that was fixed 2 days ago.

Jeremy, can you retest with a build from 6/17 or later?

Comment 4

[Jeremy Coghill]

The latest camino nightly 2004061708 still exhibits the behaviour.  I did submit
another Talkback event when it crashed, the ID is TB137797X

Comment 5

[Simon Fraser [no longer active]]

Can someone pin this down to a specific image on the page? It's likely to be a
GIF with transparency, that's being scaled.

Comment 6

[jhp (no longer active)]

Jeremy, just to clarify, you specifically tested the 2004-06-07 Camino 0.8 build
and this crash did not happen, but you did crash using the 0.8 release from the
following day?

Also, is your screen set to thousands or millions of colors?

Comment 7

[Jeremy Coghill]

I'm not certain if this is helpful or not, but if you shrink the camino window
so that there is only small area open at the top of the page visible, say an
inch or so, you will be able to successfully load the page.  Then you can try
slowly enlarging the browser window to reveal more and more of the page until it
crashes.  From what I can see, it crashes as you get close to displaying the
bottom of the graph on the left side of the page.  I checked this against
ca.finance.yahoo.com, but not finance.yahoo.com, so am not certain if this same
thing happens on that site.

Comment 8

[Jeremy Coghill]

(In reply to comment #6)
> Jeremy, just to clarify, you specifically tested the 2004-06-07 Camino 0.8 build
> and this crash did not happen, but you did crash using the 0.8 release from the
> following day?
> 
> Also, is your screen set to thousands or millions of colors?

Yes, I tested with the 2004-06-07 builds for both Camino and Mozilla, and they
worked fine.  Testing with the builds from 2004-06-08 is when the crashes
started to occur.

I have my screen set to thousands of colours.

Comment 9

[Jeremy Coghill]

weird, I changed my display to millions and it no longer crashes using the
2004-06-17 builds.

Comment 10

[jhp (no longer active)]

The only image that hits the RectStretch code on that page is the "Yahoo! Chat"
image on the right hand side.

I set my display to Thousands to test, but could not recreate.  However, I am
using OS X 10.3.4, not 10.2.8.

Comment 11

[jhp (no longer active)]

Attachment: testcase

Testcase with only bubbles.gif.

Jeremy, could you try this out and see if this crashes under Thousands of
colors.

Comment 12

[Jeremy Coghill]

I tried the testcase with thousands of colours selected and does not fail on my
setup, this is with the 2004-06-17 camino build.

Comment 13

[jhp (no longer active)]

In the crash log, the function called from nsImageMac::Draw is CopyBits, which
would seem to suggest the call at
http://lxr.mozilla.org/mozilla/source/gfx/src/mac/nsImageMac.cpp#292.  No idea
why that would be crashing, though.

Jeremy, do you have your own debug build of Camino?

Comment 14

[Jeremy Coghill]

(In reply to comment #13)
> In the crash log, the function called from nsImageMac::Draw is CopyBits, which
> would seem to suggest the call at
> http://lxr.mozilla.org/mozilla/source/gfx/src/mac/nsImageMac.cpp#292.  No idea
> why that would be crashing, though.
> 
> Jeremy, do you have your own debug build of Camino?

No, I don't have my own debug build, I have just been using the nightly
releases.  I haven't built the code before as I was under the impression that
you needed xcode to build these.  If I'm wrong about that, I'd be willing to try
and get a debug build together, though it may take a bit of hand holding to get
me up to speed on the build process.

Comment 15

[Mike Pinkerton (not reading bugmail)]

yes, xcode and 10.3+ are requirements for building (thanks apple).

Comment 16

[Jeremy Coghill]

What about for Mozilla or Firefox?  Do you need 10.3+ to build those as well? 
If I can build either of them with the tools I currently have, then perhaps we
can track down where the issue really is as each of those browsers displays the
same behaviour as Camino with this bug.

Comment 17

[Mike Pinkerton (not reading bugmail)]

yes, you can build ff/sm on 10.2

Comment 18

[jhp (no longer active)]

Attachment: patch

It seems that there is an OS bug if any of the CopyBits functions are called
with srcCopy.  If we pass ditherCopy to CopyDeepMask(), some images can look
bad when running under Thousands of colors (bug 239701).  If we pass srcCopy to
CopyDeepMask() or call CopyMask() (which does srcCopy implicitly), then we
crash.

So, this patch backs out bug 239701 (ugly images under thousands of colors are
better than a crash).  It also moves the call to CopyBits in nsImageMac::Draw
back under the print case, making any draw to screen code go through
nsImageMac::CopyBitsWithMask, where CopyBits is called with ditherCopy.  

I think this should take care of most of the crashers.	As for the badly drawn
images discussed in bug 239701, I don't think there is much that can be done,
other than moving over to using Quartz.

Comment 19

[jhp (no longer active)]

Attachment: patch (diff -w)

Same patch, but more legible.

Comment 20

[jhp (no longer active)]

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

Comment 21

[jhp (no longer active)]

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

Comment 22

[jhp (no longer active)]

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

Comment 23

[jhp (no longer active)]

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

Comment 24

[jhp (no longer active)]

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

Comment 25

[jhp (no longer active)]

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

Comment 26

[jhp (no longer active)]

For all those now copied on this bug, a workaround is to set your screen depth
to millions of colors.

Comment 27

[Dan Karlsson]

Has anyone tried to see if there could be a workaround using the fact that the
crash depends on the filename? (See Bug 247498)

Different filenames suggests that the bug could be somewhere else, and that this
only is the symptom...

Comment 28

[Mike Pinkerton (not reading bugmail)]

the ugly images (amazon.com star ratings, for example) were one of the highest
visible and highest reported glitches in camino's rendering. while i agree bad
images are better than not crashing, can we simply not fix it the right way?

Comment 29

[jhp (no longer active)]

I think the right way to fix this is to switch to using Quartz to render images
(bug 245407); I haven't found a way to work around these issues in QuickDraw. 
Unfortunately, I haven't had time to continue work on that patch.  Plus, the
changes are so great that it's not something you would want to pick up for
Camino 0.8.

Comment 30

[Stuart Morgan]

If this crash is in fact fixed in 10.3, it might be worth using gestalt or
appkit checks to give 10.3 users the fix for the ugly images bug.

Comment 31

[Mike Calmus]

The crash seems to apply to 10.3 as well. I experienced it on HomeDepot.com (one
of the duplicates of this one) running 10.3.4.

Comment 32

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 151177 [details] [diff] [review]
patch (diff -w)

r=pink

i wish there was another way, but we need this ASAP for 0.8f

Comment 33

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 151177 [details] [diff] [review]
patch (diff -w)

smfr? thoughts?

Comment 34

[jhp (no longer active)]

Comment on attachment 151177 [details] [diff] [review]
patch (diff -w)

Seeking approval.  This patch fixes a regression that led to crashes on some
user's machines.

Comment 35

[jhp (no longer active)]

Comment on attachment 151177 [details] [diff] [review]
patch (diff -w)

Seeking approval.  This patch fixes a regression that led to crashes on some
user's machines.

Comment 36

[Mike Kaply [:mkaply]]

Comment on attachment 151177 [details] [diff] [review]
patch (diff -w)

a=mkaply

Comment 37

[jhp (no longer active)]

Checked in to trunk, 1.7.1, and aviary.

For all those copied on this bug, this fix will make it in to tomorrow's Camino
build. Please download it and test it and report if you still see any crashes.

Comment 38

[Mike Pinkerton (not reading bugmail)]

should 239701 be reopened then?

Comment 39

[Jeremy Coghill]

Should last nights Camino build, 2004062108 (v0.8b+), have had this patch in it?
 If the patch did make into the latest download, then I am still seeing the
crash when setting the display to thousands of colours (OSX 10.2.8).

Comment 40

[Mike Pinkerton (not reading bugmail)]

2004062208 is the first build that would have this as the patch landed in the
afternoon on the 21st.

Comment 41

[halim.boussoualine]

I have just downloaded Camino 2004062108 (v0.8b+) and it seems that the problem
is gone on frenchmozilla.sourceforge.net and http://ca.finance.yahoo.com/ with
thousands of colors.

Thanks for the fix

Comment 42

[Mike Pinkerton (not reading bugmail)]

I repeat, 2004062108 does not have this fix. It was landed 5 hours after this
build started.

Comment 43

[halim.boussoualine]

Sorry for comment 41, I read your mail too quickly. Strangely though the camino
build I downloaded does not crash anymore on frenchmozilla.sourceforge.net
though this site crashes (I have just tested it a few minutes ago) with Mozilla
1.7. Something was fixed, no ?

Comment 44

[jhp (no longer active)]

Everyone copied, please test with the latest Camino 0.8 or Mozilla nightly.  The
builds that are out today include the patch in this bug.  Please post if you are
still seeing any related crashes.

Comment 45

[Bob]

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

Comment 46

[Stuart Morgan]

Appears to be fixed with 20040622 Camino branch build. With an older build I get
crashes on http://frenchmozilla.sourceforge.net/ (one of the dupes) at Thousands
of colors, but with 6/22 I don't get crashes no matter how many times I
visit/reload/shift-reload (although I do get the old image distortion).

I'll hold off marking FIXED, in case someone else can still see a crash.

Comment 47

[Kathleen :Brade]

Is this problem listed in the release notes for 1.7?

It's really bad and lead to a bad impression for me (and probably many others
given the number of duplicates).  It'd be good to list the workaround (switch to
millions of colors) for those who do run into it.

Comment 48

[Mike Pinkerton (not reading bugmail)]

it's listed in the camino 0.8 release notes :)

Comment 49

[jhp (no longer active)]

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

Comment 50

[jhp (no longer active)]

-> fixed

Comment 51

[jhp (no longer active)]

verified per comment #46

Comment 52

[Jay Patel [:jay]]

updating with topcrash info for tracking...

Comment 53

[Christian :Biesinger (don't email me, ping me on IRC)]

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