Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Regression range is bogus. This is Skia calling into the image decoder, so all this is happening on the back end in the raster pipeline, I presume.

The decode is getting triggered from skia. Since the image is in a picture shader, which we don't decode in cc.

#0 0x7f410dbee00b in memcpy-ssse3-back.S:1658 /build/glibc-Cl5G7W/glibc-2.23/sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1658
#1 0x563126b65b4c in CopyPixels third_party/blink/renderer/platform/graphics/image_frame_generator.cc:47:5
#2 0x563126b65b4c in blink::ImageFrameGenerator::DecodeAndScale(blink::SegmentReader*, bool, unsigned long, SkImageInfo const&, void*, unsigned long, blink::ImageDecoder::AlphaOption) third_party/blink/renderer/platform/graphics/image_frame_generator.cc:182
#3 0x563126b2986c in blink::DecodingImageGenerator::GetPixels(SkImageInfo const&, void*, unsigned long, unsigned long, unsigned int) third_party/blink/renderer/platform/graphics/decoding_image_generator.cc:153:42
#4 0x56311451b248 in SkImageGenerator::getPixels(SkImageInfo const&, void*, unsigned long, SkImageGenerator::Options const*) third_party/skia/src/core/SkImageGenerator.cpp:33:18
#5 0x5631147c1ad9 in generate_pixels third_party/skia/src/image/SkImage_Lazy.cpp:487:15
#6 0x5631147c1ad9 in SkImage_Lazy::lockAsBitmap(SkBitmap*, SkImage::CachingHint, SkImageCacherator::CachedFormat, SkImageInfo const&, SkTransferFunctionBehavior) const third_party/skia/src/image/SkImage_Lazy.cpp:527
#7 0x5631147c3181 in SkImage_Lazy::getROPixels(SkBitmap*, SkColorSpace*, SkImage::CachingHint) const third_party/skia/src/image/SkImage_Lazy.cpp:586:18
#8 0x5631144968bd in SkBaseDevice::drawImageRect(SkImage const*, SkRect const*, SkRect const&, SkPaint const&, SkCanvas::SrcRectConstraint) third_party/skia/src/core/SkDevice.cpp:194:23
#9 0x56311442788e in SkCanvas::onDrawImageRect(SkImage const*, SkRect const*, SkRect const&, SkPaint const*, SkCanvas::SrcRectConstraint) third_party/skia/src/core/SkCanvas.cpp:2258:23
#10 0x563114418fae in SkCanvas::drawImageRect(SkImage const*, SkRect const&, SkRect const&, SkPaint const*, SkCanvas::SrcRectConstraint) third_party/skia/src/core/SkCanvas.cpp:1731:11
#11 0x56311447c53e in SkColorSpaceXformCanvas::onDrawImageRect(SkImage const*, SkRect const*, SkRect const&, SkPaint const*, SkCanvas::SrcRectConstraint) third_party/skia/src/core/SkColorSpaceXformCanvas.cpp:151:22
#12 0x563114418fae in SkCanvas::drawImageRect(SkImage const*, SkRect const&, SkRect const&, SkPaint const*, SkCanvas::SrcRectConstraint) third_party/skia/src/core/SkCanvas.cpp:1731:11
#13 0x56311441e084 in SkCanvas::legacy_drawImageRect(SkImage const*, SkRect const*, SkRect const&, SkPaint const*, SkCanvas::SrcRectConstraint) third_party/skia/src/core/SkCanvas.cpp:1899:15
#14 0x56311467b008 in draw<SkRecords::DrawImageRect> third_party/skia/src/core/SkRecordDraw.cpp:110:1
#15 0x56311467b008 in operator()<SkRecords::DrawImageRect> third_party/skia/src/core/SkRecordDraw.h:62
#16 0x56311467b008 in decltype(fp((SkRecords::NoOp)())) SkRecord::Record::visit<SkRecords::Draw&>(SkRecords::Draw&&&) const third_party/skia/src/core/SkRecord.h:165
#17 0x563114678f6a in visit<SkRecords::Draw &> third_party/skia/src/core/SkRecord.h:42:28
#18 0x563114678f6a in SkRecordDraw(SkRecord const&, SkCanvas*, SkPicture const* const*, SkDrawable* const*, int, SkBBoxHierarchy const*, SkPicture::AbortCallback*) third_party/skia/src/core/SkRecordDraw.cpp:52
#19 0x563114397d2b in SkBigPicture::playback(SkCanvas*, SkPicture::AbortCallback*) const third_party/skia/src/core/SkBigPicture.cpp:33:5
#20 0x563114435ecf in SkCanvas::drawPicture(SkPicture const*, SkMatrix const*, SkPaint const*) third_party/skia/src/core/SkCanvas.cpp:2775:18
#21 0x563114637334 in drawPicture third_party/skia/include/core/SkCanvas.h:2118:15
#22 0x563114637334 in SkPictureImageGenerator::onGetPixels(SkImageInfo const&, void*, unsigned long, SkImageGenerator::Options const&) third_party/skia/src/core/SkPictureImageGenerator.cpp:78
#23 0x56311451b248 in SkImageGenerator::getPixels(SkImageInfo const&, void*, unsigned long, SkImageGenerator::Options const*) third_party/skia/src/core/SkImageGenerator.cpp:33:18
#24 0x5631147c1ad9 in generate_pixels third_party/skia/src/image/SkImage_Lazy.cpp:487:15
#25 0x5631147c1ad9 in SkImage_Lazy::lockAsBitmap(SkBitmap*, SkImage::CachingHint, SkImageCacherator::CachedFormat, SkImageInfo const&, SkTransferFunctionBehavior) const third_party/skia/src/image/SkImage_Lazy.cpp:527
#26 0x5631147c3181 in SkImage_Lazy::getROPixels(SkBitmap*, SkColorSpace*, SkImage::CachingHint) const third_party/skia/src/image/SkImage_Lazy.cpp:586:18
#27 0x5631143a550f in SkDefaultBitmapControllerState::SkDefaultBitmapControllerState(SkBitmapProvider const&, SkMatrix const&, SkFilterQuality) third_party/skia/src/core/SkBitmapController.cpp:0:24
#28 0x5631143a573c in SkDefaultBitmapController::onRequestBitmap(SkBitmapProvider const&, SkMatrix const&, SkFilterQuality, void*, unsigned long) third_party/skia/include/private/SkTemplates.h:0:38
#29 0x5631143a4863 in SkBitmapController::requestBitmap(SkBitmapProvider const&, SkMatrix const&, SkFilterQuality, void*, unsigned long) third_party/skia/src/core/SkBitmapController.cpp:22:26
#30 0x5631143b5581 in SkBitmapProcInfo::init(SkMatrix const&, SkPaint const&) third_party/skia/src/core/SkBitmapProcState.cpp:89:27
#31 0x5631147ea80b in setup third_party/skia/src/core/SkBitmapProcState.h:61:22
#32 0x5631147ea80b in SkBitmapProcLegacyShader::MakeContext(SkShaderBase const&, SkShader::TileMode, SkShader::TileMode, SkBitmapProvider const&, SkShaderBase::ContextRec const&, SkArenaAlloc*) third_party/skia/src/shaders/SkBitmapProcShader.cpp:107
#33 0x5631147f463d in SkImageShader::onMakeContext(SkShaderBase::ContextRec const&, SkArenaAlloc*) const third_party/skia/src/shaders/SkImageShader.cpp:119:12
#34 0x5631148038f8 in SkShaderBase::makeContext(SkShaderBase::ContextRec const&, SkArenaAlloc*) const third_party/skia/src/shaders/SkShader.cpp:113:18
#35 0x56311480111c in PictureShaderContext third_party/skia/src/shaders/SkPictureShader.cpp:327:50
#36 0x56311480111c in make<SkPictureShader::PictureShaderContext, const SkPictureShader &, SkShaderBase::ContextRec &, sk_sp<SkShader>, SkArenaAlloc *&> third_party/skia/include/private/SkArenaAlloc.h:103
#37 0x56311480111c in SkPictureShader::onMakeContext(SkShaderBase::ContextRec const&, SkArenaAlloc*) const third_party/skia/src/shaders/SkPictureShader.cpp:302
#38 0x5631148038f8 in SkShaderBase::makeContext(SkShaderBase::ContextRec const&, SkArenaAlloc*) const third_party/skia/src/shaders/SkShader.cpp:113:18
#39 0x5631143cfcb0 in SkBlitter::Choose(SkPixmap const&, SkMatrix const&, SkPaint const&, SkArenaAlloc*, bool) third_party/skia/src/core/SkBlitter.cpp:1103:33

Looks like its happening when we are copying into the pixel buffer passed to the generator. fmalita@, could you help triage this in skia?

The decode is triggered in Skia, but handled in Blink.  I cannot repro the ASAN crash locally -- the only hint I'm getting is this (in regular release/debug builds):

tcmalloc: large alloc 2045935616 bytes == 0x135b680a7000 @  0x7fea3930289c 0x7fea392ffd96 0x7fea39303c0a 0x7fea39300c7b 0x7fea39303933 0x7fea3932ec55 0x7fea392bdc0d 0x7fea392bcfea 0x7fea390f3079 0x7fea3812e8d9 0x7fea3812e7ab 0x7fea387d4ec7 0x7fea387d50c8 0x7fea387d518b 0x7fea386ee181 0x7fea386eda08 0x7fea1eac9b06 0x7fea1eac5499 0x7fea1eab60e7 0x7fea1eab9518 0x7fea1eab6a1a 0x7fea1eac46c3 0x7fea1ea358d7 0x7fea1ea3384a 0x7fea1ea32e56 0x7fea1e87e02d 0x7fea2fe70a2c 0x7fea387c3532 0x7fea389a3961 0x7fea389a32ab 0x7fea389a3f9e

Looks like we're trying to decode a huge (22616 x 22616) frame, which requires > 2GB.  That's close enough to INT_MAX that I wouldn't be shocked if it's overflowing some calculation on 32bit.  Is there any way to tell if the CF/ASAN build is 32 or 64 bit?

I'm not sure where that huge frame is coming from, the image should be much smaller:

file cf/image-surku-236.6774.1527947865001.7149.gif
cf/image-surku-236.6774.1527947865001.7149.gif: GIF image data, version 89a, 20 x 22


<image xlink:href="image-surku-236.6774.1527947865001.7149.gif" width="400" height="300"/>

@scroggo, any ideas?

Although the header says its 20 x 22, Chromium makes the image bigger to account for the first frame*. In this case, the first frame starts at (11308, 11308), and its rectangle is 11308 x 11308, so we expand the image to the huge size you're seeing.

fmalita@, what calculation do you think might be overflowing? 2045935616 (the size of the allocation) is still within the size of a 32 bit int.

Since we are in CopyPixels, this means that we successfully decoded the image (well, we at least zero'ed its pixels and decoded what's there; the file is truncated), and the problem is copying it into memory provided by the generator. I think that's discardable memory. Passing to reveman@ in case there's a discardable problem, but my guess is this is overcommit, as we've seen in other bugs (e.g.  issue 847805 , issue 820889, issue 813489).

(* I don't know how we settled on this behavior. It's somewhat arbitrary, given that the input data doesn't make sense. https://github.com/google/wuffs/blob/master/test/data/artificial/gif-frame-out-of-bounds.gif.make-artificial.txt has a list of how we could choose to deal with it, and a partial list of how it is handled by different viewers. Notice that FireFox makes a different decision.)

@scroggo I don't have a particular overflow in mind, just hand-waving since the number is "big".  The overcommit explanation also seems plausible, and I see the symptoms match those other bugs.

@khushalsagar Do you think Skia triggering the decode is a significant distinction here?  IOW, would CC decoding do something different/smarter to limit the size of this allocation?  If so, then maybe we can look at adopting the same strategy.

re #6, I'm pretty sure we would hit the same case even if the decode was being triggered in cc. We don't do anything to limit the size of the allocation either.

> Is there any way to tell if the CF/ASAN build is 32 or 64 bit?

The Bus line appears to include an x86_64 version of memcpy. Does that tell us it's 64 bit, or does that just mean the machine is 64 bit?

ClusterFuzz has detected this issue as fixed in range 573184:573185.

Detailed report: https://clusterfuzz.com/testcase?key=5552798436163584

Fuzzer: noel-image-surku
Job Type: linux_asan_chrome_mp
Platform Id: linux

Crash Type: Bus
Crash Address: 0x7f41ae688ff0
Crash State:
  blink::ImageFrameGenerator::DecodeAndScale
  blink::DecodingImageGenerator::GetPixels
  SkImageGenerator::getPixels
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=524901:524903
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=573184:573185

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5552798436163584

See https://github.com/google/clusterfuzz-tools for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 5552798436163584 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.