Issue 659812 #c6 regression range same as this issue.
brucedawson@: Could you please take a look into this and dupe if its the same.

All four calls to FXSYS_round in AdobeCMYK_to_sRGB can trigger this bug, and all four were fixed by crrev.com/2466203002

Let's not dup an unsolved bug into a solved one.

 Issue 699339  has been merged into this issue.

I don't think this is an unsolved bug. The assert occurred in the same revision range as for 659812. Here is a summary of the three bugs:

699459: k1 == FXSYS_round(k * 255), 402692:402822
659812: c1 == FXSYS_round(c * 255), 402692:402822
699339: m1 == FXSYS_round(m * 255), 455091:455226

When I optimized the float-to-int conversion I added four asserts to verify the results. The three bugs represent three of those asserts firing, all for the same reason. After my fix I tested all floats from 0.0 to 1.0 to confirm that the new code gives the exact same result as FXSYS_round. So, 699459 (this bug) and 659812 are definitely the same bug and should both be fixed now - is that not the case?

699339 is more of a mystery because it shows up in a different regression range. Is that assert still firing?

It sounds like this bug should be duped to 659812 but perhaps 699339 should be left open. The main question for  bug 699339  will be what value of 'm' triggered the assert.

Looking more carefully, all 3 bugs you mention have the same root cause, but none were fixed, even the one you marked as Fixed. The root cause is that the in parameters for AdobeCMYK_to_sRGB do not satisfy the expected constraint of being between 0.0 and 1.0. Clusterfuzz was crazy on March 8 and thought 659812 was fixed, for no good reason. They should all be fixed after https://pdfium-review.googlesource.com/c/2954/ lands.

The following revision refers to this bug:
  https://pdfium.googlesource.com/pdfium/+/6791295a4e8c99097e6d75870871e128284f8cb5

commit 6791295a4e8c99097e6d75870871e128284f8cb5
Author: Nicolas Pena <npm@chromium.org>
Date: Fri Mar 10 20:46:14 2017

Normalize channels when transforming CMYK to RGB

PDF spec, section 'DeviceCMYK Color Space' states that:
'Each component is specified by a number in the range 0.0 to 1.0'

BUG= chromium:699459 

Change-Id: Ie476bbe8740c7b1b33c80be3e3dc4207df5e6e28
Reviewed-on: https://pdfium-review.googlesource.com/2954
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>

[modify] https://crrev.com/6791295a4e8c99097e6d75870871e128284f8cb5/BUILD.gn
[modify] https://crrev.com/6791295a4e8c99097e6d75870871e128284f8cb5/core/fpdfapi/page/fpdf_page_colors.cpp
[add] https://crrev.com/6791295a4e8c99097e6d75870871e128284f8cb5/core/fpdfapi/page/cpdf_devicecs_unittest.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/48c92d825cbd761300c4463cec1f09b2ef479b66

commit 48c92d825cbd761300c4463cec1f09b2ef479b66
Author: pdfium-deps-roller <pdfium-deps-roller@chromium.org>
Date: Fri Mar 10 22:24:41 2017

Roll src/third_party/pdfium/ 5c1961dfa..6791295a4 (1 commit)

https://pdfium.googlesource.com/pdfium.git/+log/5c1961dfa0b1..6791295a4e8c

$ git log 5c1961dfa..6791295a4 --date=short --no-merges --format='%ad %ae %s'
2017-03-10 npm Normalize channels when transforming CMYK to RGB

Created with:
  roll-dep src/third_party/pdfium
BUG= 699459 

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, see:
http://www.chromium.org/developers/tree-sheriffs/sheriff-details-chromium#TOC-Failures-due-to-DEPS-rolls

TBR=dsinclair@chromium.org

Review-Url: https://codereview.chromium.org/2746613002
Cr-Commit-Position: refs/heads/master@{#456187}

[modify] https://crrev.com/48c92d825cbd761300c4463cec1f09b2ef479b66/DEPS