Libprotobuf-mutator-based SQLite fuzzer |
||||||
Issue descriptionWe should create a grammar-based (LPM) fuzzer for sqlite instead of just using raw libfuzzer, since SQL queries are highly structured data. We'll be able to hit quite a bit more code coverage, I'm sure, and more easily support new sqlite features or extensions. This will also allow us to generate whichever sql queries we want (for example, just CREATE TABLE and INSERT), if we have a need to do so--such as creating new databases for corruption, in order to test sqlite's resiliency to corruption. There's probably room for a good testcase minimizer as well.
,
Nov 29
Very cool!
,
Nov 29
I like this idea. One reason in particular is because SQL is pretty standardized, so effort spent here can (mostly) be reused to fuzz other SQL databases (e.g. postgres or mysql if desired. Also the fuzzer will never go obsolete because of formats changing.
,
Nov 30
Here's my problem: it's fairly difficult for LPM to actually find some parts of the grammar.
For example, I have a
message SQLQueries {
repeated SQLQuery query = 1;
}
And I ran it for an hour on 36 cores, and it rarely, if ever, was generating multiple queries. I'm concerned that even with many more days, it wouldn't be generating many multiple-line SQLQueries because coverage might not increase even when adding another line. For example CREATE TABLE table1; CREATE TABLE table2; (that's probably incorrect syntax <-) wouldn't be stored to any corpus as the second statement wouldn't add any coverage, even though it's useful.
I tried
message SQLQueries {
required SQLQuery q1 = 1;
required SQLQuery q2 = 2;
// ...
required SQLQuery q10 = 10;
repeated SQLQuery extra_queries = 11;
}
And nothing changed, except it took a lot longer to start generating any queries at all because libfuzzer had to find out how to fill in all the required fields first (I believe).
My current idea for fixing this is:
1. Manually write a bunch of protobuf-formatted SQL queries (and SQL expressions, etc.)
2. Serialize them.
3. Add the serialized representations to a libfuzzer dictionary.
4. Hope libfuzzer starts adding these at the right spots.
Note if I added them to the corpus instead, then libfuzzer would use them as a starting point but might never add them into the middle of the protobuf (I assume this is a mutation that libfuzzer performs??). For example if I had an expression in the dictionary 1 - (1 + 1), then we might be able to modify some SQL statement
SELECT * FROM table0 WHERE col0=1
to
SELECT * FROM table0 WHERE col0=1 - (1 + 1)
(Presumably this is why the dictionary file exists in the first place!)
The problems with this are that (a) it's difficult and time-consuming (b) I'm not sure it will even work, and (c) libfuzzer is still constrained to the SQL queries I add to the dictionary and won't find any parts of the grammar I haven't manually covered.
The only things I can think that fix this problem more generally are writing some sort of custom protobuf mutators, or somehow making libfuzzer more aware how it can modify protobufs. Optimally it would be able to generate something as random looking as Domato could, but with the advantage of coverage-guided optimizations, customizability, etc. that libfuzzer+LPM provides.
Thoughts?
,
Nov 30
>For example CREATE TABLE table1; CREATE TABLE table2; (that's probably incorrect syntax <-) wouldn't be stored to any corpus as the second statement wouldn't add any coverage, even though it's useful. I think I get what your saying in the general case. But in this particular one, I think the two line would get added to the corpus because it (probably?) increases hit counts on an edge(s). LF actually adds things to the corpus based on differences in hit counts: https://cs.chromium.org/chromium/src/third_party/libFuzzer/src/FuzzerTracePC.h?q=bucket+file:%5Esrc/third_party/libFuzzer/src/+package:%5Echromium$&g=0&l=226 (though it does some bucketing so that 32 hits of an edge and 33 hits are considered the same). >And nothing changed, except it took a lot longer to start generating any queries at all because libfuzzer had to find out how to fill in all the required fields first (I believe). Does running with len_control=0 help? LF uses a heuristic to prevent corpus sizes from growing too large by trying to exhaust what it can find with an input of a certain size before allowing the size to grow. I think the heuristic conflicts with LPM though I haven't had the chance to actually verify this, so setting len_control=0 turns it off. >My current idea for fixing this is: >1. Manually write a bunch of protobuf-formatted SQL queries (and SQL expressions, etc.) >2. Serialize them. >3. Add the serialized representations to a libfuzzer dictionary. >4. Hope libfuzzer starts adding these at the right spots. I'm not sure if I understand this correctly, but I don't see how this works. Putting tokens in a dictionary when using LPM means that LF might insert them in a proto string field. >Note if I added them to the corpus instead, then libfuzzer would use them as a starting point but might never add them into the middle of the protobuf (I assume this is a mutation that libfuzzer performs??). There's a mutation called CrossOver (for my own sake: https://cs.chromium.org/chromium/src/third_party/libprotobuf-mutator/src/src/mutator.cc?l=509) that LPM performs which combines two protos together. It should do what you are describing. >For example if I had an expression in the dictionary 1 - (1 + 1), then we might be able to modify >some SQL statement >SELECT * FROM table0 WHERE col0=1 >to >SELECT * FROM table0 WHERE col0=1 - (1 + 1) Only if "1" is a string field. >(Presumably this is why the dictionary file exists in the first place!) Dictionaries predate LPM and they don't exactly work super well with it in the case of grammar based fuzzing. >The problems with this are that (a) it's difficult and time-consuming (b) I'm not sure it will even work, and (c) libfuzzer is still constrained to the SQL queries I add to the dictionary and won't find any parts of the grammar I haven't manually covered. Sorry about this. Maybe run the fuzzer again without len_control and for a longer period of time (a day lets say), or submit to ClusterFuzz so you can get a better idea of what it can generate. We could also meet to discuss this. >The only things I can think that fix this problem more generally are writing some sort of custom protobuf mutators I think LPM supports this functionality but I haven't used it since it is relatively new, I can look into it though and put you in touch with the person who created this feature if you want. >or somehow making libfuzzer more aware how it can modify protobufs. KCC will almost certainly reject this unfortunately.
,
Nov 30
Ah okay, most of the entire problem was len_control. It wasn't documented in the libfuzzer docs so I assumed it wasn't supported anymore, is it something chrome-specific?
I think I was assuming libfuzzer + LPM was much more primitive than it is. It seems to be working much better, though still has some trouble generating really complicated examples.
Anyway some more samples of the grammar after running it for ~15 seconds:
VALUES (1) ;
CREATE TEMP TABLE Table0 (Col0 ) ;
VALUES (1, x'4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c') ;
CREATE TEMP TABLE Table0 (Col0 DEFAULT (1) ) WITHOUT ROWID ;
VALUES (1) ORDER BY 1 ;
CREATE TEMP TABLE Table0 (Col0 DEFAULT 'VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV' ) ;
VALUES (1, x'4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c') ORDER BY 1 ;
SELECT DISTINCT * (Schema0.Table8 ) GROUP BY 1 HAVING (VALUES (1) ) UNION VALUES (1), (1, 1 + 1) ;
WITH RECURSIVE Table0(Col0) AS (VALUES (1) ) DELETE FROM Table0 ;
SELECT DISTINCT * (Schema4.Table0 ) GROUP BY 0 HAVING 1 ;
VALUES (0) UNION VALUES (1), (TRUE) ORDER BY 1 COLLATE NOCASE ;
VALUES (1) UNION VALUES (1), (1, EXISTS (VALUES (1) ) ) ;
SELECT DISTINCT * WHERE Col0 || 1 LIKE 1 ISNULL GROUP BY 1 HAVING 1 LIKE 1 ORDER BY 1 ;
VALUES (1) ;
WITH RECURSIVE Table0 AS (VALUES (1) ) DELETE FROM Table0 ;
WITH RECURSIVE Table0 AS (VALUES (1, (VALUES (1) ) ) ) DELETE FROM Table0 ;
VALUES (1) UNION VALUES ('PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP') LIMIT 'NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN' ;
SELECT DISTINCT * GROUP BY 1 HAVING 1 ;
VALUES (0) ;
SELECT DISTINCT * (table_fn_dummy() Table8 , Table0 ) GROUP BY 1 HAVING 1 ;
VALUES (1, x'4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c') ;
SELECT DISTINCT * ((VALUES (1) ) Table8 ) GROUP BY 1 HAVING 1 ;
CREATE TEMP TABLE Table0 (Col0 , CONSTRAINT TableConstraint4 CHECK(1) , CONSTRAINT TableConstraint4 CHECK(1) ) ;
CREATE TEMP TABLE Table0 (Col0 , Col0 , CONSTRAINT TableConstraint4 CHECK(1) ) ;
SELECT DISTINCT * GROUP BY 1 HAVING 1 LIMIT 1 , x'64656c657465' ;
CREATE TEMP TABLE Table0 (Col0 ) ;
CREATE TEMP TABLE Table8 (Col0 ) ;
SELECT DISTINCT * (Table0 ) GROUP BY 1 HAVING 1 ;
,
Nov 30
We should be able to disable len_control for a particular target via "libfuzzer_optiong" GN attribute, if necessary.
,
Nov 30
Re: #7 I'm pretty tempted to do this automatically on ClusterFuzz (ie: look for fuzzers that are LPM and always disable len_control for them). CCing some libFuzzer devs who might be interested in seeing a case where len_control hurts LPM.
,
Nov 30
> disable len_control Another option, that is useful by itself, is to make sure that a seed corpus has at least one input of a decent size.
,
Dec 11
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7d3def8575ecd2e5e2e7ab7f585961206007bd25 commit 7d3def8575ecd2e5e2e7ab7f585961206007bd25 Author: Matthew Denton <mpdenton@chromium.org> Date: Tue Dec 11 00:04:51 2018 Adds LPM-based SQLite fuzzer This adds a grammar-based SQLite fuzzer based on libprotobuf-mutator. This includes fuzzing for general SQL statements, FTS3, SQL expressions, and SQLite's printf and strftime functions. R=metzman@chromium.org, pwnall@chromium.org Bug: 909886 Change-Id: I2ccd4c868f9349f63b76666206ea6c5bdf78aef5 Reviewed-on: https://chromium-review.googlesource.com/c/1366875 Commit-Queue: Matthew Denton <mpdenton@chromium.org> Commit-Queue: Max Moroz <mmoroz@chromium.org> Reviewed-by: Max Moroz <mmoroz@chromium.org> Reviewed-by: Jonathan Metzman <metzman@chromium.org> Reviewed-by: Victor Costan <pwnall@chromium.org> Cr-Commit-Position: refs/heads/master@{#615339} [modify] https://crrev.com/7d3def8575ecd2e5e2e7ab7f585961206007bd25/third_party/sqlite/BUILD.gn [add] https://crrev.com/7d3def8575ecd2e5e2e7ab7f585961206007bd25/third_party/sqlite/fuzz/DEPS [add] https://crrev.com/7d3def8575ecd2e5e2e7ab7f585961206007bd25/third_party/sqlite/fuzz/icu_codes.proto [add] https://crrev.com/7d3def8575ecd2e5e2e7ab7f585961206007bd25/third_party/sqlite/fuzz/sql_expr_fuzzer.cc [add] https://crrev.com/7d3def8575ecd2e5e2e7ab7f585961206007bd25/third_party/sqlite/fuzz/sql_fuzzer.cc [add] https://crrev.com/7d3def8575ecd2e5e2e7ab7f585961206007bd25/third_party/sqlite/fuzz/sql_multithreaded_fuzzer.cc [add] https://crrev.com/7d3def8575ecd2e5e2e7ab7f585961206007bd25/third_party/sqlite/fuzz/sql_printf_fuzzer.cc [add] https://crrev.com/7d3def8575ecd2e5e2e7ab7f585961206007bd25/third_party/sqlite/fuzz/sql_queries.proto [add] https://crrev.com/7d3def8575ecd2e5e2e7ab7f585961206007bd25/third_party/sqlite/fuzz/sql_query_grammar.proto [add] https://crrev.com/7d3def8575ecd2e5e2e7ab7f585961206007bd25/third_party/sqlite/fuzz/sql_query_proto_to_string.cc [add] https://crrev.com/7d3def8575ecd2e5e2e7ab7f585961206007bd25/third_party/sqlite/fuzz/sql_query_proto_to_string.h [add] https://crrev.com/7d3def8575ecd2e5e2e7ab7f585961206007bd25/third_party/sqlite/fuzz/sql_run_queries.cc [add] https://crrev.com/7d3def8575ecd2e5e2e7ab7f585961206007bd25/third_party/sqlite/fuzz/sql_run_queries.h [add] https://crrev.com/7d3def8575ecd2e5e2e7ab7f585961206007bd25/third_party/sqlite/fuzz/sql_strftime_fuzzer.cc
,
Dec 11
,
Dec 11
Was directly inspired by https://twitter.com/NedWilliamson/status/1064792156861169664. :)
,
Dec 11
Wonderful! You've done a really good job here from a first glance. I planned to attempt this at some point and it looks like you got there first, so kudos. My hope is that all security critical code is tested in this fashion.
,
Dec 13
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8865bae0bc54955fb85c5deb4ae1bc5978124b55 commit 8865bae0bc54955fb85c5deb4ae1bc5978124b55 Author: Matthew Denton <mpdenton@chromium.org> Date: Thu Dec 13 20:14:53 2018 Updated SQLite LPM Fuzzer Fixed two bugs (missed the word "FROM" in SELECT statements, which stops the fuzzer from doing much of anything in SELECT, and one incorrect type name). Also added NumericLiteral to LiteralValue, so we can hit code handling floating point numbers. Bug: 909886 Change-Id: I5d5825bd7b4e0277beb6e47d58b09d0fb12eeece Reviewed-on: https://chromium-review.googlesource.com/c/1374913 Reviewed-by: Victor Costan <pwnall@chromium.org> Reviewed-by: Jonathan Metzman <metzman@chromium.org> Commit-Queue: Matthew Denton <mpdenton@chromium.org> Cr-Commit-Position: refs/heads/master@{#616415} [modify] https://crrev.com/8865bae0bc54955fb85c5deb4ae1bc5978124b55/third_party/sqlite/fuzz/sql_query_grammar.proto [modify] https://crrev.com/8865bae0bc54955fb85c5deb4ae1bc5978124b55/third_party/sqlite/fuzz/sql_query_proto_to_string.cc
,
Dec 20
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b880687775ccc1a24323912f75efb50d21d98685 commit b880687775ccc1a24323912f75efb50d21d98685 Author: Matthew Denton <mpdenton@chromium.org> Date: Thu Dec 20 03:30:51 2018 Add well-formed SQLite LPM fuzzer seed corpus The SQLite fuzzer needs a seed corpus full of well-formed SQL queries that it can mess around with. This adds the seed corpus, as well as an executable for the corpus generator. Also fixes a few bugs in the protobuf-to-string converter, and adds timeouts to individual queries in the fuzzer so uninteresting queries (from the fuzzer standpoint) don't take up all the time. Bug: 909886 Change-Id: I4af84d44bd748bda0489149523c2924eef2f73fe Reviewed-on: https://chromium-review.googlesource.com/c/1379306 Reviewed-by: Jonathan Metzman <metzman@chromium.org> Reviewed-by: Victor Costan <pwnall@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Peter Kasting <pkasting@chromium.org> Commit-Queue: Matthew Denton <mpdenton@chromium.org> Cr-Commit-Position: refs/heads/master@{#618098} [modify] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/protobuf/BUILD.gn [modify] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/BUILD.gn [modify] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/DEPS [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries0 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries1 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries10 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries11 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries12 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries13 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries14 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries15 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries16 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries17 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries18 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries19 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries2 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries3 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries4 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries5 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries6 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries7 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries8 [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/lpm_fuzzer_seed_corpus/corpus_queries9 [modify] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/sql_fuzzer.cc [add] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/sql_generate_corpus.cc [modify] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/sql_query_grammar.proto [modify] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/sql_query_proto_to_string.cc [modify] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/sql_query_proto_to_string.h [modify] https://crrev.com/b880687775ccc1a24323912f75efb50d21d98685/third_party/sqlite/fuzz/sql_run_queries.cc
,
Dec 20
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1df00428ecd6bd17c56fe5b8ab626f5389dd4b1d commit 1df00428ecd6bd17c56fe5b8ab626f5389dd4b1d Author: Matthew Denton <mpdenton@chromium.org> Date: Thu Dec 20 03:56:33 2018 Add missing space in SQLite LPM fuzzer The missing space screwed up all the ALTER TABLE statements. R=metzman@chromium.org, pwnall@chromium.org Bug: 909886 Change-Id: I7cb6d53d8286c79dc37a43f84a94ab1016a2a21e Reviewed-on: https://chromium-review.googlesource.com/c/1385885 Reviewed-by: Jonathan Metzman <metzman@chromium.org> Reviewed-by: Victor Costan <pwnall@chromium.org> Commit-Queue: Victor Costan <pwnall@chromium.org> Cr-Commit-Position: refs/heads/master@{#618103} [modify] https://crrev.com/1df00428ecd6bd17c56fe5b8ab626f5389dd4b1d/third_party/sqlite/fuzz/sql_query_proto_to_string.cc
,
Dec 20
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4b8e8fb7f02a0c1190bd4ecb633b63828f84c288 commit 4b8e8fb7f02a0c1190bd4ecb633b63828f84c288 Author: Matthew Denton <mpdenton@chromium.org> Date: Thu Dec 20 23:41:12 2018 Added missing space in SQLite LPM fuzzer This missing space may have screwed up WHERE statements when creating indexes (or might not have, since I don't see any errors. Adding anyway) R=metzman@chromium.org, pwnall@chromium.org Bug: 909886 Change-Id: Idd322f43a2b715d1d282546df4c504148a5014a4 Reviewed-on: https://chromium-review.googlesource.com/c/1387837 Commit-Queue: Victor Costan <pwnall@chromium.org> Reviewed-by: Jonathan Metzman <metzman@chromium.org> Reviewed-by: Victor Costan <pwnall@chromium.org> Cr-Commit-Position: refs/heads/master@{#618376} [modify] https://crrev.com/4b8e8fb7f02a0c1190bd4ecb633b63828f84c288/third_party/sqlite/fuzz/sql_query_proto_to_string.cc
,
Jan 7
The Storage team monitors Internals>Storage. The Internals>Services>Storage label will be deprecated & removed.
,
Jan 9
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/55a46db4d17608aca41a7016557d5cea064ae126 commit 55a46db4d17608aca41a7016557d5cea064ae126 Author: Matthew Denton <mpdenton@chromium.org> Date: Wed Jan 09 01:46:00 2019 Easier minimization for SQLite LPM Fuzzer Adds support for turning off specific queries with an environment variable; makes it very easy to rule out a ton of irrelevant queries in a very short amount of time when minimizing a test case. R=metzman@chromium.org, pwnall@chromium.org Bug: 909886 Change-Id: Ia785a8d89cad415f791fd28cd498244358437898 Reviewed-on: https://chromium-review.googlesource.com/c/1388035 Reviewed-by: Jonathan Metzman <metzman@chromium.org> Reviewed-by: Victor Costan <pwnall@chromium.org> Commit-Queue: Matthew Denton <mpdenton@chromium.org> Cr-Commit-Position: refs/heads/master@{#620992} [modify] https://crrev.com/55a46db4d17608aca41a7016557d5cea064ae126/third_party/sqlite/BUILD.gn [add] https://crrev.com/55a46db4d17608aca41a7016557d5cea064ae126/third_party/sqlite/fuzz/disabled_queries_parser.cc [add] https://crrev.com/55a46db4d17608aca41a7016557d5cea064ae126/third_party/sqlite/fuzz/disabled_queries_parser.h [modify] https://crrev.com/55a46db4d17608aca41a7016557d5cea064ae126/third_party/sqlite/fuzz/sql_fuzzer.cc [modify] https://crrev.com/55a46db4d17608aca41a7016557d5cea064ae126/third_party/sqlite/fuzz/sql_multithreaded_fuzzer.cc [modify] https://crrev.com/55a46db4d17608aca41a7016557d5cea064ae126/third_party/sqlite/fuzz/sql_query_proto_to_string.cc [modify] https://crrev.com/55a46db4d17608aca41a7016557d5cea064ae126/third_party/sqlite/fuzz/sql_query_proto_to_string.h
,
Jan 9
Next steps would be to upstream this to sqlite itself. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by mpdenton@chromium.org
, Nov 29