216397 - crashes when attempting to load bitmap files [@ nsImageMac::CopyBitsWithMask]

Status: RESOLVED FIXED

(Core Graveyard :: GFX: Mac, defect)

Description

[seth]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030622 Camino/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030622 Camino/0.7+

i have tested the webpage, which i am the webmaster of, three times, twice with
bitmaps and jpegs loading and once with only jpegs loading.  the time when jpegs
only loaded, the page loaded normally, the other two times camino crashed.  i am
using verion 0.7

Reproducible: Always

Steps to Reproduce:
1.  load http://sjrsimac.mine.nu/westcoast10.html/
2.  watch camino 0.7 crash
3.

Actual Results:  
the application crashed and talkback began to work

Expected Results:  
loaded the page correctly and fully, treating bitmaps as it does jpegs

the windows bitmap photos began to load from the bottom up, whereas jpegs load
from the top down.

Comment 1

[Chris Casciano]

I'm seeing this crash in Mozilla OS X/2003-08-08-03 trunk & Camino 08-12-02... 

This may have something to do with the resizing of the images via html as they
all seemed to load indiviually outside of an html doc without a crash. 

Adding qawanted: A trimmed down testcase w/ just one image would be really nice

ugly stack.. here's the tail end of it. I'll attach a full log in a second

Date/Time:  2003-08-16 22:41:02 -0400
OS Version: 10.2.6 (Build 6L60)
Host:       pnhTiObject.local.

Command:    mozilla-bin
PID:        1030

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x06a74000

Thread 0 Crashed:
 #0   0x91a95d2c in Average32
 #1   0x91a5e0a0 in Merge32Src
 #2   0x91a54a9c in StretchBlt
 #3   0x91a5436c in Stretch
 #4   0x91a5f168 in OneSrcOneDst
 #5   0x91a59a90 in BitsDevLoop
 #6   0x91a53868 in CommonBits
 #7   0x91a583d0 in StdBits
 #8   0x91a53814 in CommonBits
 #9   0x91a59c88 in CopyBits
 #10  0x0158b028 in nsImageMac::CopyBitsWithMask(BitMap const*, BitMap const*,
short, BitMap const*, Rect const&, Rect const&, Rect const&, int)
 #11  0x0158a68c in nsImageMac::Draw(nsIRenderingContext&, void*, int, int, int,
int, int, int, int, int)
 #12  0x0159eb94 in nsRenderingContextImpl::DrawScaledImage(imgIContainer*,
nsRect const*, nsRect const*)
 #13  0x00ed6374 in nsImageFrame::Paint(nsIPresContext*, nsIRenderingContext&,
nsRect const&, nsFramePaintLayer, unsigned)
 #14  0x00ebb7cc in nsContainerFrame::PaintChild(nsIPresContext*,
nsIRenderingContext&, nsRect const&, nsIFrame*, nsFramePaintLayer, unsigned)
 #15  0x00ebb66c in nsContainerFrame::PaintChildren(nsIPresContext*,
nsIRenderingContext&, nsRect const&, nsFramePaintLayer, unsigned)

Comment 2

[Chris Casciano]

Attachment: full seamonkey crash log

This is the full text of one of the Mozilla 08-08-03 crashes... Camino stack
looks almost identical

Comment 3

[Olivier Cahagne]

wfm using 2003081805 on Linux x86.

CC'ing biesi, the original developer of the BMP decoder, may enlighten a
possible big endian only issue ? (eventhough it does not crash within the BMP
decoder).

Anyone on MacOSX, is this a regression ? Did it used to work with Chimera 0.5 or
0.4 ?
This function appears to have been heavily modified with patch from bug 137295.

Comment 4

[Chris Casciano]

Some wuick OS X testing...

1.0.2: WFM (which if i'm reading things correctly may eliminate that bug/patch
as the cause)

1.2.1: WFM
1.3: these BMPs images are broken... on viewing along get "The image
“http://sjrsimac.mine.nu/westcoastpics10/1.bmp” cannot be displayed, because it
contains errors."
1.3.1: ditto
1.4: crash

Unfortunately my archives of nightlies died in a HDD crash a few weeks ago so
tracking things down with more granularity will take some time (I'll see what I
can do by grabbing camino builds off the ftp site)

Comment 5

[Stefan [:stefanh]]

Camino 2003081810 loads the image http://sjrsimac.mine.nu/westcoastpics10/1.bmp
fine without crashing.

I get a 404 at http://sjrsimac.mine.nu/westcoast10.html. 

Comment 6

[Olivier Cahagne]

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

Comment 7

[Gulliver]

Unfortunately the test-page is not available anymore! Probably Bug 231241 should
be reopened.

Comment 8

[Gulliver]

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

Comment 9

[Gulliver]

Confirmed with Mozilla 1.6 on MacOS X 10.3.2.
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6)
Gecko/20040113

Comment 10

[Bruce Davidson]

Note that I suspect this was confirmed using the URL from bug 231241
(http://www.pm-host.de/pokemonspiele/komplettloesung/komplett_rs2.htm) as the
URL in this bug is no longer available.

Comment 11

[Stefan [:stefanh]]

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

Comment 12

[Stefan [:stefanh]]

URL from the dupe: http://fidlerontheroof.blogspot.com/2004/09/ok-dudes.html

My talkback ID from crashing at the above URL: TB735791W

Comment 13

[Ben Fowler]

Attachment: Backtrace for crash at nsImageMac::CopyBitsWithMask( )

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041203
Firefox/1.0+

I am seeing a crash in this function, nsImageMac::CopyBitsWithMask( ),
with a similar stack trace on the URL 
http://www.aceldama.com/~tomr/media/dalek/

Kindly note that there was no crash on this page if I just open it in
my standard build (so I have been able to review the page source), the
crash occurs in a debug build that I made a few days ago.

The image files appear to be:

<img src="../../_aux_/titles/tomr.gif" width="108" height="32" alt="TomR's ">
<img src="../../_aux_/titles/media.gif" width="256" height="32" alt=" Media
Creations">
<a href="dalek-3h.jpg"><img align="right" src="dalek-3q.gif" alt="[Dalek #3 -
blasting you!]" width="110" height="115" border="0"></a>
<a href="stills0.map"><img usemap="#stills0" ismap src="stills0.gif" alt=""
width="512" height="256" border="0"></a><br>
<a href="dalek-10.jpg"><img align="right" src="dalek-10.gif" alt="[Dalek #10 -
well lit!]" width="192" height="128" border="1"></a>

so this is not a BMP file, neither am I going through 
nsRenderingContextImpl::DrawScaledImage( ),
so this may be different defect (or gif files may be susceptible
as well).

I looked at the relevant frame with gdb, and found infeasible dimensions
for the source rect, so I can see where some spackle might help:

(gdb) p aSrcRect
$1 = (const nsRect &) @0x85d36b0: {
  x = 140167464, 
  y = 140167060, 
  width = 140167236, 
  height = 140167868
}

Comment 14

[Ben Fowler]

(In reply to comment #13)
> ... crash at nsImageMac::CopyBitsWithMask( )

May be intermittent, or depend on something in addition to the above.

Comment 15

[Ben Fowler]

(In reply to comment #13)
> I am seeing a crash in this function, nsImageMac::CopyBitsWithMask( ),
> with a similar stack trace on the URL 
> http://www.aceldama.com/~tomr/media/dalek/
> 
> Kindly note that there was no crash on this page if I just open it in
> my standard build (so I have been able to review the page source), the
> crash occurs in a debug build that I made a few days ago.

It happened today in a build using standard methods. I have been able
to evince it fairly reliably by "View source" or "Save As", but so far
never whilst running in a debugger.

I also once had this happen whilst opening the saved page in Camino 

Comment 16

[Ben Fowler]

Attachment: Stack trace

I was on Bug 277368 and reviewing the screenshots. I clicked with the zoom
tool on either the second or third attachment (didn't note which), and 
then clicked the scroll bar: Firefox crashed with the attached stack trace
that seems identical to the others on this bug.

Will try to reproduce.

Comment 17

[Ben Fowler]

(In reply to comment #16)
> Created an attachment (id=170532) [edit]
> Stack trace
> 
> Will try to reproduce.

Easily reproducible. Go to Bug 277368 and open Attachment 1 [details] [diff] , click with the 
magnifying glass. Scroll up by clicking on the scroll bar. When you scroll
down by clicking on the scroll bar, Firefox crashes.

FVIW this can be considered to invalidate my earlier stacktrace. I will try
to catch this in a debugger some time over the weekend.

Comment 18

[Ben Fowler]

Using a debug build and following my receipe I did mot get a crash.
Will keep on trying.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Would be nice to get some traction on this....

Comment 20

[Jo Hermans]

bug 275120, bug 262549, bug 253286 and bug 207553 might be dupes (they have the
same stacktrace)

I encountered this crash yesterday in the latest Firefox trunk build :
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20050109
Firefox/1.0+

I found it while testing the url in bug 277674 :
<http://www.emsc-csem.org/favicon.ico> . It's a very large BMP-image (I have
resizing on), which is common theme among these bugs.

Comment 21

[Jo Hermans]

The testcase in comment 17 doesn't crashes for me.

But the url I mentioned before <http://www.emsc-csem.org/favicon.ico>, crashes
consistently on my iBook with a 800x600 screen and Mac OS X 10.2.8. No need to
click or scroll, just open the url.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20050109
Firefox/1.0+

Comment 22

[Ben Fowler]

(In reply to comment #21)
> The testcase in comment 17 doesn't crash for me.
> 

See also comment 18

I agree that the crash cannot be reproduced at will.

I have just compiled Firefox using standard methods and this mozconfig:


. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_OBJDIR=/Users/bfowler/build/The_birds

ac_add_options --enable-extensions=default,-venkman

#ac_add_options --enable-application=browser
mk_add_options MOZ_CO_PROJECT=browser,mail

#mk_add_options MOZ_CO_LOCALES=en-GB
#ac_add_options --enable-ui-locale=en-GB

and the recipe in comment 17 followed to the letter, crashes for me.
I am on Mac OS 10.2.6, Darwin Kernel Version 6.6: Thu May  1 21:48:54 PDT 2003;
root:xnu/xnu-344.34.obj~1/RELEASE_PPC  


I am downloading the nightly at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-01-10-07-trunk/firefox-1.0+.en-US.mac.dmg.gz
and will try with that edition.

Comment 23

[Ben Fowler]

(In reply to comment #22)
> I am downloading the nightly at: ...

No crash, as per comment 21

buildconfig: 
--enable-application=browser --enable-optimize=-O2 --disable-debug
--disable-tests --enable-static --disable-shared --enable-official-branding
--enable-prebinding --with-macos-sdk=/Developer/SDKs/MacOSX10.2.8.sdk

Grateful for advice/instructions

Comment 24

[Simon Fraser [no longer active]]

The crash might depend on your screen depth. Try Thousands.

Comment 25

[Uri Bernstein]

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

Comment 26

[GavinS]

(In reply to comment #25)
> *** Bug 275120 has been marked as a duplicate of this bug. ***

The attchment on that last dupe will easily reproduce the problem, for me at
least...

https://bugzilla.mozilla.org/attachment.cgi?id=169033

Comment 27

[Jo Hermans]

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

Comment 28

[Jo Hermans]

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

Comment 29

[Simon Fraser [no longer active]]

Can someone verify if this crash depends on your screen depth?

Comment 30

[Benjamin Mucci]

I can't reproduce at all with
https://bugzilla.mozilla.org/attachment.cgi?id=169033 but at
http://www3.telus.net/excel/PDA/schedule.htm (See Bug 253286) Mozilla
(Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5)
Gecko/20041217) always crashes in any screen depth (256 / Thousands / Millions) 

Comment 31

[Uri Bernstein]

I can reproduce it on https://bugzilla.mozilla.org/attachment.cgi?id=169033 with
all three color depths.

Comment 32

[Hiro]

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

Comment 33

[Ben Fowler]

Attachment: Data from gdb

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050125

Further to comment 22 , I have great difficulty in reproducing this crash
at will, though today I did catch it in the debugger whilst I do not have
my sources mounted.

It is possible that the rect (width) of the scrBits is wrong, or perhaps
we are trying to draw where there is no memory; or perhaps this is a red
herring.

Comment 34

[chief nerd]

FWIW:

I encounted the bug at the www.alarms-r-us.com shopping site and it took me down
5-6 times before I gave up.

Comment 35

[Asa Dotzler [:asa]]

moving to a 1.8b nomination. Jay, can you tell us how high on the Mac topcrash
list this crash is?

Comment 36

[Simon Fraser [no longer active]]

The best fix for this would be to take the quartz image patch (bug 245407),
currently under review by me.

Comment 37

[Matthias Versen [:Matti]]

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

Comment 38

[Simon Fraser [no longer active]]

This will have been fixed by the fix for bug 245407.

Comment 39

[Nicolaus Hepler]

(In reply to comment #38)
> This will have been fixed by the fix for bug 245407.

I hate to be so annoying, but in Camino 0.8.3 and Firefox 1.0.2 for Mac OS X, this bug still seems to 
still be a problem.  (try http://www.life.umd.edu/CBMG/faculty/asmith/BSCI223/infospring.html) It 
seems whatever fix that was implemented hasn't made it into the applications yet, or the fix didn't 
repair this problem.

Nicolaus Lance Hepler

Comment 40

[Jo Hermans]

(In reply to comment #39)
> (In reply to comment #38)
> > This will have been fixed by the fix for bug 245407.
> 
> I hate to be so annoying, but in Camino 0.8.3 and Firefox 1.0.2 for Mac OS X,
this bug still seems to 
> still be a problem.

Bug 245507 was checked in on the trunk, which will be the future Firefox 1.1.
It's not fixed on the branch, which was used for FF 1.0.2 or Camino.

Comment 41

[chief nerd]

err...

http://alarms-r-us.com/catalog/default.php

is crashing Mozilla 1.7.5 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7.5) Gecko/20041217

again/still

Comment 42

[Ben Fowler]

(In reply to comment #41)
> http://alarms-r-us.com/catalog/default.php
> 
> is crashing Mozilla 1.7.5 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; 
> en-US; rv:1.7.5) Gecko/20041217
> 
> again/still

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050813
Firefox/1.0+

Your URL WFM. Assuming that this is the same crash, its being present in a 
Gecko dated 2004 is NOT unexpected, as the fix was checked in around 20050219 .

If you want to double check, you could try with a recent lizard.