343192 - Crash with huge image - uncaught c++ exception from new (bad_alloc)

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Brian Polidoro]

My cairo build crashes trying to view this huge image.  Non-cairo does not display the image but doesn't crash.  

I found this out from a talkback I came across:
http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=19827038

When I crash I get less useful talkbacks:
http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB20422529W

I can't tell much about this to know if there's already a bug that covers this.  And I'm assuming this isn't a regression.  I'm assuming this is a problem that hasn't been encountered yet.  

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060629 Minefield/3.0a1 ID:2006062910 [cairo]

Comment 1

[Brian Polidoro]

The more useful talkback:
Stack Signature	 kernel32.dll + 0x1eb33 (0x7c81eb33) 3b8e5560
Product ID	FirefoxTrunk
Build ID	2006061205
Trigger Time	2006-06-13 08:29:58.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	kernel32.dll + (0001eb33)
URL visited	http://veimages.gsfc.nasa.gov/1438/nightearth.gif
User Comments	
Since Last Crash	47631 sec
Total Uptime	75322 sec
Trigger Reason	Microsoft C++ exception
Source File, Line No.	N/A
Stack Trace 	
kernel32.dll + 0x1eb33 (0x7c81eb33)
MSVCR80.dll + 0x28dd3 (0x78158dd3)
MSVCR80.dll + 0x30e59 (0x78160e59)
gfxImageSurface::gfxImageSurface   nsThebesImage::Init   nsJPEGDecoder::WriteFrom   imgRequest::OnDataAvailable   g_TOKEN_Directories
0x0012fbd0

Comment 2

[timeless]

this is our general "we crash when new fails to alloc because we switched from new.h to new and from compilers that could return null [vc6..71] to vc8 which wants to throw unless you ask it very nicely"

Comment 3

[Brian Polidoro]

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

Comment 4

[Stuart Parmenter]

Attachment: avoid super large images

this won't really fix it in all cases but will avoid the potential overflow.  we have similar code in old gfx

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 230017 [details] [diff] [review]
avoid super large images

Do the > k64KLimit checks first before the multiply/divide checks

Comment 6

[Stuart Parmenter]

checked in.  i think we should mark this fixed and open another bug on the whole exceptions thing as that is more tree-wide.

Comment 7

[Daniel Veditz [:dveditz]]

we've already got at least bug 324005 on the new exceptions, but I'm fairly sure we must have an older bug on it. At one point biesi replaced most of the 'new' calls in the GIF decoder with mallocs just to work around this problem (which didn't help anywhere else, of course).

Comment 8

[Ian Neal]

Would TB26555683X be related to this or a similar issue?