Automatically adding ccs based on OWNERS file / target commit history.

If this is incorrect, please add ClusterFuzz-Wrong label.

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

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

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/5cb3a6cd8648c1585a8bd47c8333c5e406476527 (Fixed sqlite fuzzer to use upstream version).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

Should this be reported upstream?

ClusterFuzz testcase 5753425020846080 appears to be flaky, updating reproducibility label.

Please ignore the last comment about testcase being unreproducible. The testcase is still reproducible. This happened due to a code refactoring on ClusterFuzz side, and the underlying root cause is now fixed. Resetting the label back to Reproducible. Sorry about the inconvenience caused from these incorrect notifications.

Interesting. Totally forgot about this bug trying to write the LPM fuzzer. Dr. Hipp, this is an UBSAN failure. Can you take a look?

Deleted: clusterfuzz-testcase-minimized-sqlite3_ossfuzz_fuzzer-5753425020846080 915 bytes

clusterfuzz-testcase-minimized-sqlite3_ossfuzz_fuzzer-5753425020846080 915 bytes View Download

Unable to repro using -fsanitize=undefined,address.  Do you have a stack trace I can look at?  Or the UBSAN error message?

Thank you very much for looking into this, Richard!

This is the stack trace from the bot:

../../third_party/sqlite/amalgamation/sqlite3.c:158459:3: runtime error: left shift of negative value -64
    #0 0x5577bd2343a7 in sqlite3Fts3GetVarint32 third_party/sqlite/amalgamation/sqlite3.c:158459:3
    #1 0x5577bd235a02 in fts3SegReaderNext third_party/sqlite/amalgamation/sqlite3.c:169576:12
    #2 0x5577bd235281 in fts3SegReaderStart third_party/sqlite/amalgamation/sqlite3.c:170906:16
    #3 0x5577bd251cba in fts3SegmentMerge third_party/sqlite/amalgamation/sqlite3.c:171405:8
    #4 0x5577bd25223c in fts3AllocateSegdirIdx third_party/sqlite/amalgamation/sqlite3.c:169330:12
    #5 0x5577bd251bf2 in fts3SegmentMerge third_party/sqlite/amalgamation/sqlite3.c:171392:10
    #6 0x5577bd25c827 in sqlite3Fts3PendingTermsFlush third_party/sqlite/amalgamation/sqlite3.c:171445:10
    #7 0x5577bd23f63d in fts3SyncMethod third_party/sqlite/amalgamation/sqlite3.c:161506:8
    #8 0x5577bd158045 in sqlite3VtabSync third_party/sqlite/amalgamation/sqlite3.c:134560:12
    #9 0x5577bd156223 in vdbeCommit third_party/sqlite/amalgamation/sqlite3.c:78307:8
    #10 0x5577bd155ad3 in sqlite3VdbeHalt third_party/sqlite/amalgamation/sqlite3.c:78772:16
    #11 0x5577bd16de79 in sqlite3VdbeExec third_party/sqlite/amalgamation/sqlite3.c:84101:8
    #12 0x5577bd122581 in sqlite3Step third_party/sqlite/amalgamation/sqlite3.c:81444:10
    #13 0x5577bd11d02a in chrome_sqlite3_step third_party/sqlite/amalgamation/sqlite3.c:81507:16
    #14 0x5577bd127642 in chrome_sqlite3_exec third_party/sqlite/amalgamation/sqlite3.c:118092:12
    #15 0x5577bd033dab in LLVMFuzzerTestOneInput third_party/sqlite/src/test/ossfuzz.c:175:3

Locally (with a couple of backports applied), I'm getting "runtime error: left shift of negative value -83". This only happens in release builds (assert are off, optimizations are on).

mpdenton@: Is optimize_for_fuzzing (GN argument) supposed to introduce behavior changes?

I get "runtime error: left shift of negative value -64" when I set optimize_for_fuzzing to false in my args.gn. When I set it to true (matching the settings in the clusterfuzz report), I get "runtime error: left shift of negative value -83".

Richard you might want to try -fsanitize=shift, since this is an undefined shift. As far as I can remember lots of UBSAN checks are off by default.

Victor, yes I'm pretty sure that UBSAN will be very affected by the optimizations. Things like ASAN and even MSAN probably don't get very affected by optimization since things like heap overflows and uses of uninitialized values mostly would still happen in an optimized build; on the other hand, UBSAN seems like a grab bag of other undefined behavior and is probably heavily affected by optimizations--since an undefined shift is undefined behavior, the compiler can assume it doesn't happen and generate different code. I have no idea how a value could change from -64 to -83, but it doesn't seem impossible. :)

Maybe kcc@ can clarify.

I got it to fail, and was able to bisect, but the bisect landed on a check-in that does not affect any code that is part of the reproducer case.  The reproducer uses the FTS3 extension, but bisect landed on a change to RTREE:

https://sqlite.org/src/timeline?bid=y835e2cc55fnbf8c1b2b7ay11d4682d2encc42dd1510y48438bb35bnddf06db702n085667180bndee3ae9001nda587d1857yb39bf4356e

I double-checked, and this result is reproducible.

UBSAN is telling me the negative left-shift (-84) is on this line of code:

https://sqlite.org/src/artifact/65b8489e35da23b1?ln=388

The GETVARINT_STEP macro is defined just above, on line 340 of the same file. As you can see, the left-shift is by a *constant* value of 7.  All this suggests a tooling problem to me.  I did the initial bisect using clang 3.8.0-2ubuntu4 but I verified the results using clang 6.0.0-1ubuntu2~16.04.1.

Maybe I'll have a better idea in the morning....

Interesting that it bisects to the same change on both versions of clang! I would have told you it was just an artifact of compilation randomness. Oh well.

This particular error is that it is undefined behavior in C to left shift a negative value. To get this warning to go away you can just cast to unsigned and back to int later. This stackoverflow post gives a decent explanation: https://stackoverflow.com/a/29710927

In any case, compilers almost definitely compile this correctly, but it's best not to rely on undefined behavior in case some seemingly unrelated compiler change screws up the codegen for this.

pwnall@ I don't believe we'll need to backport any fix here.

Ah.  I misread the error, understanding that the shift amount was negative, not the value being shifted.  I'll check in a cast fix shortly.  I agree that I don't think you need to backport this.