Closed Bug 463306 Opened 14 years ago Closed 14 years ago

crash on loading PNG or JPEG image [@ cmsAllocMatShaper ]


(Core :: GFX: Color Management, defect)

Windows XP
Not set





(Reporter: tar, Assigned: timeless)




(Keywords: crash, verified1.9.1)

Crash Data


(2 files)

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:
2. crash

2. crash
Actual Results:  

Expected Results:  
shows image

SeaMonkey is affected too. Regression about month+ back sometime.
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.
Version: unspecified → Trunk
Indeed crashes on only one machine:

Crashes with|content on/off and clean or old profile.
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
Summary: crash on loading PNG or JPEG image → crash on loading PNG or JPEG image [@ cmsAllocMatShaper ]
cmsReadICCGammaReversed can return null

cmsBuildOutputMatrixShaper just uses its result and calls cmsAllocMatShaper:,1027#1002

which crashes:
Component: General → GFX
Keywords: crash
Product: Firefox → Core
Attached patch null ch eckSplinter Review
Assignee: nobody → timeless
Ever confirmed: true
Attachment #346686 - Flags: superreview?(pavlov)
Attachment #346686 - Flags: review?
Attachment #346686 - Flags: review? → review?(tor)
QA Contact: general → general
Attachment #346686 - Attachment description: null check → null ch eck
Attachment #346686 - Flags: superreview?(pavlov)
Attachment #346686 - Flags: review?(tor)
Attachment #346686 - Flags: review?(joe)
Comment on attachment 346686 [details] [diff] [review]
null ch

Looks alright. Vlad, thoughts?
Attachment #346686 - Flags: superreview?(vladimir)
Attachment #346686 - Flags: review?(joe) → review+
Comment on attachment 346686 [details] [diff] [review]
null ch

Looks fine, but let's let bholley take a look at it -- he knows this code best.
Attachment #346686 - Flags: superreview?(vladimir)
Attachment #346686 - Flags: superreview+
Attachment #346686 - Flags: review?(bholley)
Attachment #346686 - Flags: review?(bholley) → review+
Comment on attachment 346686 [details] [diff] [review]
null ch

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.
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).
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.
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.
Blocks: 455056
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 '' as my complete commit name.
Comment on attachment 346686 [details] [diff] [review]
null ch

Requesting 191 approval. this is a crasher, and should obviously go in 191.
Attachment #346686 - Flags: approval1.9.1?
pushed to mc in b638481767be.

I'll push to 191 once we get approval.
> 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.
Component: GFX → GFX: Color Management
QA Contact: general → color-management
Fixed per c#15
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [needs 191 landing]
Attachment #346686 - Flags: approval1.9.1? → approval1.9.1+
pushed to releases/mozilla-1.9.1 in 18398e0350cd
Whiteboard: [needs 191 landing]
Keywords: fixed1.9.1
Target Milestone: --- → mozilla1.9.1b3
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".
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.
Keywords: verified1.9.1
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.
Keywords: verified1.9.1
Verified fix on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090115 Minefield/3.2a1pre
Crash Signature: [@ cmsAllocMatShaper ]
You need to log in before you can comment on or make changes to this bug.