On Wed, 2007-06-06 at 13:38 +0200, [EMAIL PROTECTED] wrote: > > There have been some recent changes to try to address this > > by placing various limits on number of columns, length of > > SQL expressions, length of SQL statements etc. See: > > > > http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/limits.h&v=1.6 > > Nice. Limit is much better than a crash. But I hope that I will always remain > configurable and will be possible to specify really large values. > > > But so that we can check, can you post the database schema > > and the actual SQL statement that caused the crash in the > > sqlite shell? Or mail it to me off-list if it's too large or > > something. > > Below is a simple C programme that causes a crash with default stack size > (tested with MSVC i cygwin's gcc): > > #include <stdio.h> > #include <string.h> > #include <malloc.h> > #include "sqlite3.h" > > int main(int argc, char **argv){ > sqlite3 *db; > char *str = (char *) malloc(1000000); > int rc, i; > > strcpy(str, "select * from (select 1"); > for (i = 0; i < 5000; ++i) { > strcat(str, " union select 1"); > } > strcat(str, ")"); > > rc = sqlite3_open("test.db3", &db); > printf("rc: %d\n", rc); > rc = sqlite3_exec(db, str, NULL, 0, NULL); > printf("rc: %d\n", rc); > rc = sqlite3_close(db); > printf("rc: %d\n", rc); > > return 0; > } > > If you still want the big query let me know, but it basically does the same - > it doesn't even need any table.
Change the 5000 to 50000 and it crashes here on linux too. Maybe we need to limit the number of SELECT statements that can be combined in a compound. Another case (haven't tested it though): SELECT * FROM (SELECT * FROM (SELECT * FROM ...))) probably overflows the stack too. > I was thinking about sqlite based solution (other solutions are: don't make > such query or increase stack limit). I guess the best way is: > -include multiSelect in sqlite3Select - that's the easy part > -instead of recursive calls to sqlite3Select use gotos with self written > stack created on the heap - unfortunatelly it requires to keep track of all > created variables. They are mostly in front of the function but still it's > annoying to have to remember all of them. > > Using MSVC it's easy prevent a crash: __try, __except and _resetstkoflw. > I have no idea yet hot to do this with gcc. Signal can be caught, but I > wasn't able to do anything more with demaged stack. Even if it worked it would leak resources and maybe leave SQLite's internals in an inconsistent state. Dan. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
