Assigning to concern owner from Predator results --
The result is a list of CLs that change the crashed files. 

Author: Scott Hess
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/0270407c0555655d204235d1fa39c86d453cb809
Time: Mon Mar 20 19:38:21 2017
Lines 79764, 166946-166947, 166972-166978, 166984-166985 of file sqlite3.c which potentially caused crash are changed in this cl (frame #0, "icuLikeCompare"; frame #1, "icuLikeCompare"; frame #3, "sqlite3VdbeExec").
Minimum distance from crash line to modified line: 0. (file: sqlite3.c, crashed on: 166946, modified: 166946).

@Scott Hess -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

jungshik, looping you in because I think this is not actionable.  My SQLite import replaces your patch to  issue 575205  with the SQLite core team's patch to the issue.  The code is calling this macro:

#define SQLITE_ICU_READ_UTF8(zIn, c)                       \
  c = *(zIn++);                                            \
  if( c>=0xc0 ){                                           \
    c = icuUtf8Trans1[c-0xc0];                             \
    while( (*zIn & 0xc0)==0x80 ){                          \
      c = (c<<6) + (0x3f & *(zIn++));                      \
    }                                                      \
  }

If the UTF-8 is not well-formed, this will yield a busted code point, but it won't overflow the buffer (which is what  issue 575205  is about).  IMHO your fix was a preferred fix from the ICU point of view, but I'm not sure how important it is to get in and contest the fix they decided on, given that we're just arguing about different ways to handle invalid data.

 Issue 704768  has been merged into this issue.

Found an old email from Dan Kennedy indicating that their first order of business was not crashing.  Beyond that, some other solutions were discarded because they caused problems against some versions of ICU.  So they may prefer sticking with their version.

ClusterFuzz testcase 6244514907029504 is flaky and no longer reproduces, so closing issue.

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

ClusterFuzz testcase 6479261176430592 is still reproducing on tip-of-tree build (trunk).

If this testcase was not reproducible locally or unworkable, ignore this notification and we will file another bug soon with hopefully a better and workable testcase.

Otherwise, if this is not intended to be fixed (e.g. this is an intentional crash), please add ClusterFuzz-Ignore label to prevent future bug filing with similar crash stacktrace.