Whoops, didn't update the images correctly. Here's an updated example with local SVG images. 

Deleted: bug 2.zip 3.6 KB

bug 2.zip 3.6 KB Download

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=4623261135798272.

I was able to trace the issue to invalid IDs in the `antenna-icon.svg` file. Still looks like this is a bug in Chrome that it blows up the way it does, and I'm still not sure if this would allow an attacker to exploit the issue or not (that's beyond my knowledge).

Looks like a DoS only; TerminateBecauseOutOfMemory when Skia tries an allocation.

On Windows, the renderer process with runaway allocations terminates at around 3gb of Private Working Set (the Windows Job sandbox is capped at 4gb).

Indeed, just a DoS, plus I don't think this repros on Canary. After a quick search, I don't see a bug to dupe this into but it does look like it was already fixed.

This repros for me in Canary on Windows, but not in Chrome 52. Bisecting now.

Oddly, bisecting points at a revert as the source of the problem.

You are probably looking for a change made after 467496 (known good), but no later than 467497 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/145b24f9355dc8a7c59bfb93f3634eef1d555784..afc38d533169c0fb576d2def6f5a37943784100f

warx@, can you please analyze the impact on current M60 stable? Seems like the issue exists on current stable#60.0.3112.90 (Base Revision# 474897) as well.

I am not the right owner for this. When I revert it, it is because it was breaking chrome pfq. But the reverted CL is landed again in 60.0.3088.0. So bisecting result is a bit of confusing.

assigned to enne first or triage if possible

Looks like this is related to GPU raster.  I can repro this on Linux ToT with --enable-gpu-rasterization (but without gpu raster the page appears fine).

I feel like I've seen similar issues from the paint_op_buffer_fuzzer.

Received signal 6
#0 0x7f7aa3a6d07d base::debug::StackTrace::StackTrace()
#1 0x7f7aa3a6b44c base::debug::StackTrace::StackTrace()
#2 0x7f7aa3a6ca35 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#3 0x7f7aa40ce330 <unknown>
#4 0x7f7a8ae63c37 gsignal
#5 0x7f7a8ae67028 abort
#6 0x7f7aa3a68446 base::debug::(anonymous namespace)::DebugBreak()
#7 0x7f7aa3a68428 base::debug::BreakDebugger()
#8 0x7f7aa3afc5a6 logging::LogMessage::~LogMessage()
#9 0x7f7aa3bc0e4e base::(anonymous namespace)::OnNoMemorySize()
#10 0x7f7aa3bc047d base::(anonymous namespace)::OnNoMemory()
#11 0x7f7aa3da9a0a (anonymous namespace)::CallNewHandler()
#12 0x7f7aa3da9c11 ShimMalloc
#13 0x7f7aa3da9629 malloc
#14 0x7f7aa3fdae28 operator new()
#15 0x7f7aa3fdaf35 operator new[]()
#16 0x7f7aa2c4bcef SkArenaAlloc::ensureSpace()
#17 0x7f7aa2bd2447 SkArenaAlloc::allocObject()
#18 0x7f7aa3043807 _ZN12SkArenaAlloc4makeIN12_GLOBAL__N_14EdgeEJRPNS1_6VertexES5_RiRNS2_4TypeEEEEPT_DpOT0_
#19 0x7f7aa3045353 (anonymous namespace)::split_edge()
#20 0x7f7aa30456fd (anonymous namespace)::check_for_intersection()
#21 0x7f7aa3042075 (anonymous namespace)::simplify()
#22 0x7f7aa304085d (anonymous namespace)::contours_to_polys()
#23 0x7f7aa303fbc5 (anonymous namespace)::path_to_polys()
#24 0x7f7aa303f5a2 GrTessellator::PathToTriangles()
#25 0x7f7aa30c53f9 (anonymous namespace)::TessellatingPathOp::draw()
#26 0x7f7aa30c4c4f (anonymous namespace)::TessellatingPathOp::onPrepareDraws()
#27 0x7f7aa3091e58 GrMeshDrawOp::onPrepare()
#28 0x7f7aa30240ef GrOp::prepare()
#29 0x7f7aa30214b6 GrRenderTargetOpList::prepareOps()
#30 0x7f7aa2fc87d6 GrDrawingManager::internalFlush()
#31 0x7f7aa2fbd2ff GrDrawingManager::flush()
#32 0x7f7aa2fc8d06 GrDrawingManager::prepareSurfaceForExternalIO()
#33 0x7f7aa301b019 GrRenderTargetContext::prepareForExternalIO()
#34 0x7f7aa31fdf1f SkGpuDevice::flushAndSignalSemaphores()
#35 0x7f7aa320fc22 SkSurface_Gpu::onFlush()
#36 0x7f7aa2db8f6c SkSurface::flush()
#37 0x7f7aa2db8f35 SkSurface::prepareForExternalIO()
#38 0x7f7a9b72d435 cc::ResourceProvider::ScopedSkSurfaceProvider::~ScopedSkSurfaceProvider()
#39 0x7f7a9b6d82ad cc::(anonymous namespace)::RasterizeSource()
#40 0x7f7a9b6d6a1a cc::GpuRasterBufferProvider::PlaybackOnWorkerThread()

Thanks for the test case.

Note to self: Skia reduction is attached. Repro with SampleApp --slide GM:thinconcavepaths --pr tess --msaa 4

Deleted: skia-753867-repro.patch 2.0 KB

skia-753867-repro.patch 2.0 KB Download

Reduced repro (3 triangles, 9 verts).

Deleted: skia-753867-repro-reduced.patch 1.7 KB

skia-753867-repro-reduced.patch 1.7 KB Download

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/3f5301b284f195305371657801b1fc167a7f2671

commit 3f5301b284f195305371657801b1fc167a7f2671
Author: Stephen White <senorblanco@chromium.org>
Date: Wed Aug 16 13:52:48 2017

GrTessellator: fix for collinear out-of-range intersections.

Change 3b5a3fa8b1c11d4bd4499b040311f4c3553ebf8c introduced support
for out-of-range intersections, which is necessary when the top and
bottom vertices of an edge differ by only one ULP in the primary sort
order and can't be split in-order.

However, some out-of-range intersections produce edges which cancel
each other out on splitting, in particular when the intersection is
collinear with the newly-computed edge. This undoes the effect of the
split.  The tessellator then rewinds, re-detects the intersection, resplits,
an infinite loop.

The fix is to check for out-of-range intersections which are also
collinear, and ignore them. This is ok, because these are not
the cases we care about it change 3b5a3f above, which are
never collinear.

Bug:  753867 
Change-Id: I590231e0e6f19c98f1ccf46cb7acc8a63ba35a9d
Reviewed-on: https://skia-review.googlesource.com/34925
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>

[modify] https://crrev.com/3f5301b284f195305371657801b1fc167a7f2671/tests/TessellatingPathRendererTests.cpp
[modify] https://crrev.com/3f5301b284f195305371657801b1fc167a7f2671/src/gpu/GrTessellator.cpp

Fix in #14 should take care of it; let's see if ClusterFuzz agrees.

RE #15: I don't think Clusterfuzz was able to reproduce a problem with the original repro files. I can certainly retry my repro in Canary tomorrow.