As per  issue 666748 , assigning to mmoroz@. Max, could you please take a look?
Thank you.

That's an interesting testcase. It uses 1,125 MB with ASan. I guess we can harden some other limits to shrink it...

00000000  aa 53 45 4c 45 43 54 20  20 2a 2c 2a 2c 2a 46 52  |.SELECT  *,*,*FR|
00000010  4f 4d 20 28 53 45 4c 45  43 54 3a 65 72 6f 62 6c  |OM (SELECT:erobl|
00000020  6f 62 28 36 35 32 39 34  34 38 32 29 2c 22 a8 c5  |ob(65294482),"..|
00000030  ac 9d 45 4c 45 43 20 d4  24 0f 22 22 22 2c 20 7a  |..ELEC .$.""", z|
00000040  65 72 6f 62 6c 6f 62 28  33 32 36 34 37 32 34 31  |eroblob(32647241|
00000050  29 2c 22 61 2c 41 4c 54  45 52 22 2c 22 22 22 61  |),"a,ALTER","""a|
00000060  22 2c 22 22 2c 20 7a 65  72 6f 62 6c 6f 62 28 36  |","", zeroblob(6|
00000070  35 32 39 34 34 38 31 29  2c 22 61 2c 41 4c 54 45  |5294481),"a,ALTE|
00000080  52 e7 e7 e7 e7 e7 e7 e7  e7 e7 e7 e7 e7 e7 e7 e7  |R...............|
00000090  e7 e7 e7 e7 da e7 e7 e7  e7 e7 6c 65 76 65 6c 2c  |..........level,|
000000a0  22 2c 22 22 22 61 22 2c  22 62 22 22 22 2c 20 22  |","""a","b""", "|
000000b0  61 22 2c 22 24 0f 22 22  22 2c 20 7a 65 72 6f 62  |a","$.""", zerob|
000000c0  6c 6f 62 28 38 34 32 39  30 34 35 38 29 2c 22 61  |lob(84290458),"a|
000000d0  2c 41 4c 54 45 52 22 22  22 22 2c 61 2c 22 22 22  |,ALTER"""",a,"""|
000000e0  2c 20 7a 65 72 6f 62 6c  6f 62 28 35 33 37 31 32  |, zeroblob(53712|
000000f0  38 35 35 29 2c 22 61 2c  41 4c 54 45 52 22 2c 22  |855),"a,ALTER","|
00000100  22 22 61 22 2c 22 61 3a  53 62 45 4c 45 43 20 d4  |""a","a:SbELEC .|
00000110  24 0f 22 22 22 2c 20 7a  65 72 6f 62 6c 6f 62 28  |$.""", zeroblob(|
00000120  36 35 32 39 34 34 38 32  29 2c 22 61 2c 41 4c 20  |65294482),"a,AL |
00000130  45 52 22 2c 22 22 22 61  22 2c 22 22 2c 20 7a 65  |ER","""a","", ze|
00000140  72 6f 62 6c 6f 62 28 36  35 32 34 37 32 33 31 29  |roblob(65247231)|
00000150  2c 22 61 ff ff ff ff ff  2a ff ff ff ff ff ff ff  |,"a.....*.......|
00000160  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000180  ff ff ff ff ff 3b ff 2c  6e 22 22 22 2c 20 22 36  |.....;.,n""", "6|
00000190  22 2c 30 31 39 30 30 2c  31 29                    |",01900,1)|
0000019a

Should this be non-deterministic?  It doesn't always happen for me even when I use a fixed -seed=N.

:eroblob(65294482) is being interpreted as "The named parameter eroblob(65294482)", per
    https://www.sqlite.org/c3ref/bind_blob.html
The $ are all inside quotes, so they are not interpreted that way.

Aaaand, that's not it (I was thinking it was binding to something random in memory), as s/:/ z/ still gets the OOM.

Actually ... now the OOM is pretty reliable.  Adding all of the zeroblob() parameters together only gets 431,781,230, that seems pretty far from 2048MB, even if there are copies stored.  Though that number *5 is only half a percent above 2^31, so maybe it is just "Here's what you asked for".

Well ... that's basically it:

SELECT * FROM (SELECT 1, 2, 3);
1|2|3

SELECT *,* FROM (SELECT 1, 2, 3);
1|2|3|1|2|3

This query is the original one with the s/:/ z/ change, plus I removed all the strings and integers:
SELECT  *,*,* FROM (SELECT zeroblob(65294482), zeroblob(32647241), zeroblob(65294481), zeroblob(84290458), zeroblob(53712855), zeroblob(65294482), zeroblob(65247231))
It reliably repros the OOM.  I could three copies in the outer select, plus a fourth copy in the inner select.  I don't really think I need to dig any further to assume there's a fifth copy in there.

Is there a way to suppress this class of issue without destroying the utility of fuzzing it?

Thank you Scott for the thorough analysis here.

I think we can harden SQLITE_MAX_LENGTH limit (and SQLITE_MAX_SQL_LENGTH as well, as it cannot be greater than SQLITE_MAX_LENGTH): https://cs.chromium.org/chromium/src/third_party/sqlite/BUILD.gn?l=134

Or we can add some filtering against sequences like *,*,* in https://cs.chromium.org/chromium/src/third_party/sqlite/fuzz/sqlite3_prepare_v2_fuzzer.cc?sq=package:chromium&l=19

but I really don't like this idea. Hardening max length to ~10 MBs sounds better for me.

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

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