Segmentation fault in function isLikeOrGlob()
We found a testcase causing a SQLite crash exception:
CREATE TABLE t0(a PRIMARY KEY,b CHAR(30) AS(1) UNIQUE) WITHOUT ROWID; SELECT * FROM t0 JOIN t0 AS ra0 ON unlikely(ra0.a=t0.a) AND t0.b='iii' WHERE ra0.a=false OR t0.b LIKE '.' AND t0.a=ra0.b;
We simply analyzed the cause of the crash, locating it in the function isLikeOrGlob().
In this line:
|| IsVirtual(pLeft->y.pTab) /* Value might be numeric */
pLeft->y.pTab is a NULL pointer, and the use of macro:
# define IsVirtual(X) ((X)->eTabType==TABTYP_VTAB)
triggers the segmentation fault.
Bisecting shows the problem may be related to check-in b99d570131.
Thanks for the bug report. Should now be fixed on trunk.
Thanks for the quick fix!
I can't think of a less productive way for you to spend your time than answering this, but I am curious how much simpler the query could have been and still trigger the fault.
The best I could do is shown in the test case that is included with the fix.
CREATE TABLE t0(a PRIMARY KEY,b TEXT AS ('2') UNIQUE); SELECT * FROM t0 AS x JOIN t0 AS y WHERE x.b='2' AND (y.a=2 OR (x.b LIKE '2*' AND y.a=x.b));
So I was able to take off the "WITHOUT ROWID" from the table definition, and remove the "likely()" term from the WHERE clause. I wasn't able to simplify beyond that.
The problem arose for a tricky and unlikely interaction between:
- The LIKE optimizer
- The OR optimizer
- Generated columns
Just out of curiosity.... Do you have an estimate of how man CPU-hours your fuzzer took to find this bug?
Well, it's really hard to estimate the cost of CPU-hours.
Our fuzzer is running on a single CPU core, and it took about 1-10 hours from start to when we first found the testcase (I didn't monitor the fuzzing progress during that time so I don't know the exact cost).
In fact, I think the initial seed matters a lot. When we use another input seed (looks completely different from this testcase, which triggers other crash, while we have not yet found a testcase suitable for reporting), within less than an hour a testcase was generated that could cause this bug.
Just wanted to praise this report.
- Test the right version of the source code: source tree, not amalgamation, current version.
- Find a genuine crash.
- Find how to reproduce the crash with 100% reliability.
- (optional) find suspicious lines of source code
- (optional) bisect previous versions to find which version introduced bug
- Send a polite and informative message to the correct forum including the above.
I've been receiving and submitting bug reports for the last 40 years and wish they were all this good. Apologies for interrupting your scheduled technical discussions.
Thanks for the praise.
Actually, we could do better by simplifying the test case as Dr. Hipp did.
We will continue to find potential bugs in SQLite to help improve the reliability of the software.
Richard does have extensive knowledge of the SQLite innards. I'm not saying you shouldn't try simplifying, or that it is right for him to do the work, but I'm sure he is orders of magnitude faster at it because of said knowledge.
i.e: Do not feel bad for it, finding that bug is already a job well done.
We have reported several bugs before, and in the process, we continue to accumulate experience and think about how we can reduce the work of developers so that the problem can be fixed as soon as possible.
So my previous reply was just to sum up this experience, and I didn't feel bad.
Anyway, thanks for your encouragement.
, and I didn't feel bad.
Yeah sorry, I think there is a large cultural gap between our phrasing.
I did not actually think you were feeling bad. Perhaps my reply was a wordier version of simply saying:
"That's nothing, great job mate!"
or if I was Australian:
"No worries mate, great job!"
or maybe as an English gangster:
"Relax Gov, 's all good."
or maybe an American one:
"Chill mother(bleep)er, we cool."
or perhaps just as myself:
"All good, Keep up the good work!"