In fact those test suites being so large is possibly part of the problem. Sounds like they are being overly prescriptive in their testing, which is why it's so damn fussy about the order commands are executed without causing it to leak memory left right and center.
You're going to have to justify that a bit more, that would not be the overwhelming experience around these parts.
Not to say its perfect but its the weight of evidence is in SQLites favour here.
On a fairly regular basis. Google gives:About 57,400 results
So I'm definitely not the only one.
Transactions are particularly bad. One bug I ran into earlier in the year would gobble up 12gb of system ram trying to search and insert a few 10s of mb of text, just because it was leaving prepared statements laying around without telling me.
... thanks for reporting it.
(https://www.sqlite.org/malloc.html)
"No memory leaks. The application is responsible for destroying any objects it allocates."
"Robust against allocation failures. If a memory allocation ever fails (that is to say, if malloc() or realloc() ever return NULL) then SQLite will recover gracefully."
And I see plenty of reported examples and work arounds. Even yum has been suffering from it for years.
http://forums.fedoraforum.org/showthread.php?t=260195
http://www.pvangsgaard.com/2016/03/16/yum-error-database-dis...
All I said is the databases are temperamental. If you do anything "unexpected" it breaks. Numerous ways and often. Most of the bugs I've seen would be easily picked up with non deterministic testing. (Leaking result sets and prepared statements for example) - which is how I found them.
The testing codebase can only be that huge if they are all deterministic tests.
Trouble with deterministic tests is they miss all the edge cases and bugs persist for a long long time.
The transaction stuff is particularly bad. Gobbles memory without a care in the world till it either runs out and performance drops to near zero or fails and corrupts the database.
So everyone is forced to break transactions they would prefer to be atomic into multiple smaller ones.
These aren't things that should need a specific test case making in c, and many of the problems are horrific optimisation problems rather than show stoppers.
My point is. For all those kloc of testing, the sqlite code is definitely not what I would call robust.
How long has sqlite been reporting "out of memory" just because a database failed to open for some reason?
The biggest problem seems to be right here:
OOM testing is accomplished by simulating OOM errors.
I.e. not simulated in a real way. Which is silly when it is so easy to generate them.
"The application is responsible for destroying any objects it allocates"
...smells like user error to me.
e.g. "the application must use sqlite3_finalize() on every prepared statement and sqlite3_close() on every database connection "
I suggest that if you want to continue to assert that SQLite is not robust, you have to show us your code.
Because the number of cases where finalize doesn't destroy them or calling finalize on a closed prepared statement (supposed to be a harmless noop) crashing it completely seems fairly common. Yum is open source. A big chunk of the sqlite tests are not. With plenty of examples of yum sqlite databases becoming corrupt and needing to be rebuilt from scratch why would you need my code. Yum is infinately more important to those millions of users than anything I write.
So yeah, great when it works, but testing nothing to be proud of is definitely my experience.
Pay for this: TH3 is free to SQLite Consortium members and is available by license to others.
No chance.
That default encryption is locked behind walls doesn't inspire cooperation either.
rather than: for 1 to 1000 testCommand(random 1 to 6)
6 lines instead of 2, and less robust testing.