Closed
Bug 463306
Opened 14 years ago
Closed 14 years ago
crash on loading PNG or JPEG image [@ cmsAllocMatShaper ]
Categories
(Core :: GFX: Color Management, defect)
Tracking
()
VERIFIED
FIXED
mozilla1.9.1b3
People
(Reporter: tar, Assigned: timeless)
References
()
Details
(Keywords: crash, verified1.9.1)
Crash Data
Attachments
(2 files)
37.48 KB,
image/png
|
Details | |
1.12 KB,
patch
|
joe
:
review+
bholley
:
review+
vlad
:
superreview+
vlad
:
approval1.9.1+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•14 years ago
|
||
Comment 2•14 years ago
|
||
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
Version: unspecified → Trunk
Reporter | ||
Comment 3•14 years ago
|
||
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•14 years ago
|
||
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
Summary: crash on loading PNG or JPEG image → crash on loading PNG or JPEG image [@ cmsAllocMatShaper ]
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
Assignee: nobody → timeless
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #346686 -
Flags: superreview?(pavlov)
Attachment #346686 -
Flags: review?
Attachment #346686 -
Flags: review? → review?(tor)
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 7•14 years ago
|
||
Comment on attachment 346686 [details] [diff] [review] null ch eck Looks alright. Vlad, thoughts?
Attachment #346686 -
Flags: superreview?(vladimir)
Updated•14 years ago
|
Attachment #346686 -
Flags: review?(joe) → review+
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.
Attachment #346686 -
Flags: superreview?(vladimir)
Attachment #346686 -
Flags: superreview+
Attachment #346686 -
Flags: review?(bholley)
Updated•14 years ago
|
Attachment #346686 -
Flags: review?(bholley) → review+
Comment 9•14 years ago
|
||
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•14 years ago
|
||
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).
Reporter | ||
Comment 11•14 years ago
|
||
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•14 years ago
|
||
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
Assignee | ||
Comment 13•14 years ago
|
||
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 'timeless@mozdev.org' as my complete commit name.
Comment 14•14 years ago
|
||
Comment on attachment 346686 [details] [diff] [review] null ch eck Requesting 191 approval. this is a crasher, and should obviously go in 191.
Attachment #346686 -
Flags: approval1.9.1?
Comment 15•14 years ago
|
||
pushed to mc in b638481767be. I'll push to 191 once we get approval.
Reporter | ||
Comment 16•14 years ago
|
||
> 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
Comment 17•14 years ago
|
||
Fixed per c#15
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
Whiteboard: [needs 191 landing]
Attachment #346686 -
Flags: approval1.9.1? → approval1.9.1+
Comment 18•14 years ago
|
||
pushed to releases/mozilla-1.9.1 in 18398e0350cd
Whiteboard: [needs 191 landing]
Updated•14 years ago
|
Keywords: fixed1.9.1
Target Milestone: --- → mozilla1.9.1b3
Reporter | ||
Comment 19•14 years ago
|
||
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•14 years ago
|
||
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: fixed1.9.1 → verified1.9.1
Updated•14 years ago
|
Keywords: verified1.9.1
Comment 21•14 years ago
|
||
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
Comment 22•14 years ago
|
||
Verified fix on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090115 Minefield/3.2a1pre
Status: RESOLVED → VERIFIED
Updated•11 years ago
|
Crash Signature: [@ cmsAllocMatShaper ]
You need to log in
before you can comment on or make changes to this bug.
Description
•