New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 5415 link

Starred by 2 users

Issue metadata

Status: Fixed
Last visit 28 days ago
Closed: Oct 2016
Area: ----
NextAction: ----
Priority: Medium
Type: Defect

Sign in to add a comment

Possible pointer overflow in SkPathRef::Iter::setPathRef.

Reported by, Jun 10 2016

Issue description

What steps will reproduce the problem?
1. Go to web page with chromium (

What is the expected output? What do you see instead?

Expected output in shell - nothing.
Seen output in shell: 
../../third_party/skia/src/core/SkPath.cpp:1951:53: runtime error: unsigned integer overflow: 0 - 4 cannot be represented in type 'sizetype'

What version of the product are you using? On what operating system?

Skia version: 553
Target platform: arm-linux-gnueabi
Please provide any additional information below.


when testing my home-made unsigned integer overflow tool (based on UBSan) on chromium, I noticed such a strange warning:

../../third_party/skia/src/core/SkPath.cpp:1951:53: runtime error: unsigned integer overflow: 0 - 4 cannot be represented in type 'sizetype'

Looking to the source code, I see:

void SkPath::RawIter::setPath(const SkPath& path) {
    fPts = path.fPathRef->points();
    fVerbs = path.fPathRef->verbs();
    fVerbStop = path.fPathRef->verbsMemBegin();
    fConicWeights = path.fPathRef->conicWeights() - 1; // begin one behind

Here, if path.fPathRef->conicWeights() == nullptr, we actually have a pointer wrapping to (-4) for fConicWeights and this looks quite scary to me (UB?). Is this intentional? If so, sorry for a noise.

Comment 1 by, Jun 14 2016

And one can I see, this code is still present in trunk Skia version, it was just moved to src/core/SkPathRef.cpp:

void SkPathRef::Iter::setPathRef(const SkPathRef& path) {
    fPts = path.points();
    fVerbs = path.verbs();
    fVerbStop = path.verbsMemBegin();
    fConicWeights = path.conicWeights() - 1; // begin one behind

Project Member

Comment 2 by, Jun 14 2016

Cary, can you chime in here?
Project Member

Comment 3 by, Jun 14 2016

Your homemade unsigned integer overflow tool? will correct the warning, but I am confused why you think this is a bug. Does this fail to create the correct output on some platform? Does it crash? Does it create a performance concern? Does it generate a warning on a mainstream tool?
Project Member

Comment 4 by, Jun 15 2016

Status: Unconfirmed (was: New)

Comment 5 by, Jun 15 2016

> Your homemade unsigned integer overflow tool?

Just like -fsanitize=unsigned-integer-overflow, but extended for pointer plus expressions.

I don't see any observable bugs right now, but using invalid pointer later may cause undefined behavior (say, compiler may optimize some range checks such as
Project Member

Comment 6 by, Oct 4 2016

Status: Started (was: Unconfirmed)
Project Member

Comment 7 by, Oct 4 2016

The following revision refers to this bug:

commit 6942442ef7cc018ac136dd379ad6a30902a060e5
Author: caryclark <>
Date: Tue Oct 04 20:06:17 2016

disallow -4 pointer

A user's homegrown unsigned integer overflow tool
complains if a nullptr is decremented.
The conicWeight pointer likes to predecrement
before walking, but this is unnecessary if
its value is nullptr.
BUG= skia:5415 



Project Member

Comment 8 by, Oct 4 2016

Status: Fixed (was: Started)

Sign in to add a comment