463306 - crash on loading PNG or JPEG image [@ cmsAllocMatShaper ]

Status: VERIFIED FIXED

Description

[Tarmo Järvalt]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081105 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081105 Minefield/3.1b2pre

crashes on loading image

Reproducible: Always

Steps to Reproduce:
1. http://imgs.xkcd.com/comics/going_west.png
2. crash

1. http://www.motomaania.ee/wp-content/uploads/bmw_f800r.jpg
2. crash
Actual Results:  
crashes

Expected Results:  
shows image

SeaMonkey is affected too. Regression about month+ back sometime.

Comment 1

[Tarmo Järvalt]

Created attachment 346546 [details]
PNG crash with Gecko/20081105

Comment 2

[Dave Garrett]

I can't reproduce this with latest nightly on either Linux or Windows XP. The two files in comment 0 show fine and attachment 346546 [details] says it has errors, but no crashes. Please post crash report ID or stack trace.
http://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report

Comment 3

[Tarmo Järvalt]

Indeed crashes on only one machine:
PNG http://crash-stats.mozilla.com/report/index/b7aefa57-ab93-11dd-b1e7-001cc45a2c28
JPEG http://crash-stats.mozilla.com/report/index/d036d37a-ab93-11dd-b779-001cc4e2bf68

Crashes with javascript.options.jit.chrome|content on/off and clean or old profile.

Comment 4

[Dave Garrett]

bp-d036d37a-ab93-11dd-b779-001cc4e2bf68
0  	xul.dll  	cmsAllocMatShaper  	 modules/lcms/src/cmsmatsh.c:202
1 	xul.dll 	cmsBuildOutputMatrixShaper 	modules/lcms/src/cmsxform.c:1027
2 	xul.dll 	xul.dll@0x29634c 	
3 	xul.dll 	cmsCreateTransform 	modules/lcms/src/cmsxform.c:1927
4 	xul.dll 	nsJPEGDecoder::ProcessData 	modules/libpr0n/decoders/jpeg/nsJPEGDecoder.cpp:421
5 	xul.dll 	ReadDataOut 	modules/libpr0n/decoders/jpeg/nsJPEGDecoder.cpp:248
6 	xul.dll 	nsInputStreamTee::WriteSegmentFun 	xpcom/io/nsInputStreamTee.cpp:102
7 	xul.dll 	nsPipeInputStream::ReadSegments 	xpcom/io/nsPipe3.cpp:799
8 	xul.dll 	nsInputStreamTee::ReadSegments 	xpcom/io/nsInputStreamTee.cpp:156
9 	xul.dll 	nsJPEGDecoder::WriteFrom 	modules/libpr0n/decoders/jpeg/nsJPEGDecoder.cpp:266
10 	xul.dll 	imgRequest::OnDataAvailable 	modules/libpr0n/src/imgRequest.cpp:893
11 	xul.dll 	ProxyListener::OnDataAvailable 	modules/libpr0n/src/imgLoader.cpp:1402
12 	xul.dll 	nsMediaDocumentStreamListener::OnDataAvailable 	content/html/document/src/nsMediaDocument.cpp:115
13 	xul.dll 	nsDocumentOpenInfo::OnDataAvailable 	uriloader/base/nsURILoader.cpp:306
14 	xul.dll 	nsStreamListenerTee::OnDataAvailable 	netwerk/base/src/nsStreamListenerTee.cpp:97
15 	xul.dll 	nsHttpChannel::OnDataAvailable 	netwerk/protocol/http/src/nsHttpChannel.cpp:4886
16 	xul.dll 	nsInputStreamPump::OnStateTransfer 	netwerk/base/src/nsInputStreamPump.cpp:508
17 	nspr4.dll 	_MD_CURRENT_THREAD 	nsprpub/pr/src/md/windows/w95thred.c:298
18 	nspr4.dll 	PR_Lock 	nsprpub/pr/src/threads/combined/prulock.c:239
19 	xul.dll 	nsInputStreamReadyEvent::Run 	xpcom/io/nsStreamUtils.cpp:111
20 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:510
21 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:170
22 	nspr4.dll 	PR_GetEnv 	
23 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:87
24 	firefox.exe 	firefox.exe@0x2197 	
25 	kernel32.dll 	kernel32.dll@0x17066

Comment 5

[timeless]

http://mxr.mozilla.org/mozilla-central/source/modules/lcms/src/cmsio1.c?mark=1848-1849#1830
cmsReadICCGammaReversed can return null

cmsBuildOutputMatrixShaper just uses its result and calls cmsAllocMatShaper:
http://mxr.mozilla.org/mozilla-central/source/modules/lcms/src/cmsxform.c?mark=1023-1025,1027#1002

which crashes:
http://mxr.mozilla.org/mozilla-central/source/modules/lcms/src/cmsmatsh.c?mark=201-202#163

Comment 6

[timeless]

Created attachment 346686 [details] [diff] [review]
null ch
eck

Comment 7

[Joe Drew (not getting mail)]

Comment on attachment 346686 [details] [diff] [review]
null ch
eck

Looks alright. Vlad, thoughts?

Comment 8

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

Comment on attachment 346686 [details] [diff] [review]
null ch
eck

Looks fine, but let's let bholley take a look at it -- he knows this code best.

Comment 9

[Bobby Holley (:bholley)]

Comment on attachment 346686 [details] [diff] [review]
null ch
eck

Looks good. It appears that the forward gamma reads already do this.

I'm mailing a link to the upstream maintainer, since presumably they'd be interested in this as well.

Comment 10

[Glenn Randers-Pehrson]

Does the setting of color_management.mode affect this?
The file contains iCCP and valid gAMA and cHRM chunks.
I don't know if the iCCP chunk is OK or not.  The
gAMA and cHRM chunks seem to be describing the sRGB
colorspace.  The image data is actually 8-bit grayscale.

pngcheck -v says:
File: going_west.png (38379 bytes)
  chunk IHDR at offset 0x0000c, length 13
    740 x 238 image, 8-bit grayscale, non-interlaced
  chunk pHYs at offset 0x00025, length 9: 2835x2835 pixels/meter (72 dpi)
  chunk iCCP at offset 0x0003a, length 792
    profile name = Photoshop ICC profile, compression method = 0 (deflate)
    compressed profile = 769 bytes
  chunk gAMA at offset 0x0035e, length 4: 0.45454
  chunk cHRM at offset 0x0036e, length 32
    White x = 0.31269 y = 0.32899,  Red x = 0.63999 y = 0.33001
    Green x = 0.3 y = 0.6,  Blue x = 0.15 y = 0.05999
  chunk IDAT at offset 0x0039a, length 37437
    zlib:  deflated, 32K window, maximum compression
  chunk IEND at offset 0x095e3, length 0
No errors detected in going_west.png (78.2% compression).

Comment 11

[Tarmo Järvalt]

For what it's worth: when I removed the monitor color profile "driver" then it doesn't crash Gecko/20081105 anymore.

GPU: nVidia GeForce4 Ti 4280 using the 93.71 WHQL drivers
Monitor: Hyundai DeluxScan HL-5870B (aka 15G+) CRT.

Comment 12

[Bobby Holley (:bholley)]

Whoa, I almost forgot about this bug - did it ever land in MC? If not, we need to land this in 1.9.1 as well.

Comment 13

[timeless]

I'm no longer landing things to m-c because it's absolutely impossible to find a window. i have dozens of patches that have various sets of approvals.

someone should please try to land as many as possible.
please use '[e-mail]' as my complete commit name.

Comment 14

[Bobby Holley (:bholley)]

Comment on attachment 346686 [details] [diff] [review]
null ch
eck

Requesting 191 approval. this is a crasher, and should obviously go in 191.

Comment 15

[Bobby Holley (:bholley)]

pushed to mc in b638481767be.

I'll push to 191 once we get approval.

Comment 16

[Tarmo Järvalt]

> Comment #10 From  Glenn Randers-Pehrson
> Does the setting of color_management.mode affect this?

Setting the gfx.color_management.mode to 0 prevents crashing, setting it to 1 or 2 crashes.

Tested with nightly rv:1.9.1b3pre Gecko/20081204 SeaMonkey/2.0a3pre.

Comment 17

[Justin Wood (:Callek)]

Fixed per c#15

Comment 18

[Bobby Holley (:bholley)]

pushed to releases/mozilla-1.9.1 in 18398e0350cd

Comment 19

[Tarmo Järvalt]

Confirming that those images doesn't crash anymore with with "rv:1.9.1b3pre Gecko/20081210 SeaMonkey/2.0a3pre" or "rv:1.9.1b3pre Gecko/20081210 Shiretoko/3.1b3pre".

Comment 20

[Marcia Knous [:marcia - needinfo? me]]

verified fixed on the 1.9.1 branch using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081229 Shiretoko/3.1b3pre. No crashes with either image in Comment 0.

Comment 21

[Tony Chung [:tchung]]

sorry for the inconvenience.  i meant to detect any bugs before the branch merge that were still RESO fixed, but had a verified1.9.1 keyword next to them.

Comment 22

[Tony Chung [:tchung]]

Verified fix on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090115 Minefield/3.2a1pre