weird parser crash

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

weird parser crash

Shields, Daniel
I have a process that consistently crashes preparing a fairly innocuous statement.
Has anyone seen anything similar? Any suggestions for a fix/workaround? The stack
trace of the problem follows.

Thanks,

Daniel.

        t@7 (l@3) terminated by signal SEGV (no mapping at the fault address)
        Current function is nameResolverStep
         1039     if( ExprHasAnyProperty(pExpr, EP_Resolved) ) return 1;
        (dbx 1) where
        current thread: t@7
        =>[1] nameResolverStep(pArg = 0xfda0b5ec, pExpr = 0x70), line 1039 in "expr.c"
          [2] walkExprTree(pExpr = 0x70, xFunc = 0xff2b6a48 = &`libsqlite3.so.0`expr.c`nameResolverStep(void *pArg, struct Expr *pExpr), pArg = 0xfda0b5ec), line 615 in "expr.c"
          [3] walkExprList(p = 0x675610, xFunc = 0xff2b6a48 = &`libsqlite3.so.0`expr.c`nameResolverStep(void *pArg, struct Expr *pExpr), pArg = 0xfda0b5ec), line 632 in "expr.c"
          [4] walkExprTree(pExpr = 0x67c538, xFunc = 0xff2b6a48 = &`libsqlite3.so.0`expr.c`nameResolverStep(void *pArg, struct Expr *pExpr), pArg = 0xfda0b5ec), line 619 in "expr.c"
          [5] nameResolverStep(pArg = 0xfda0b5ec, pExpr = 0x685df0), line 1136 in "expr.c"
          [6] walkExprTree(pExpr = 0x685df0, xFunc = 0xff2b6a48 = &`libsqlite3.so.0`expr.c`nameResolverStep(void *pArg, struct Expr *pExpr), pArg = 0xfda0b5ec), line 615 in "expr.c"
          [7] sqlite3ExprResolveNames(pNC = 0xfda0b5ec, pExpr = 0x685df0), line 1188 in "expr.c"
          [8] sqlite3Update(pParse = 0xfda0b898, pTabList = 0x67a4f0, pChanges = 0x67a2c0, pWhere = 0x685ec8, onError = 99), line 165 in "update.c"
          [9] yy_reduce(yypParser = 0x6855c0, yyruleno = 158), line 549 in "parse.y"
          [10] sqlite3Parser(yyp = 0x6855c0, yymajor = 10, yyminor = RECORD, pParse = 0xfda0b898), line 3270 in "parse.c"
          [11] sqlite3RunParser(pParse = 0xfda0b898, zSql = 0xfda0b9f8 "UPDATE SDDSTORE SET SDD = ?, TIMESTAMP = DATETIME('NOW','LOCALTIME') WHERE ECORDERID = ?", pzErrMsg = 0xfda0b894), line 399 in "tokenize.c"
          [12] sqlite3_prepare(db = 0x10a590, zSql = 0xfda0b9f8 "UPDATE SDDSTORE SET SDD = ?, TIMESTAMP = DATETIME('NOW','LOCALTIME') WHERE ECORDERID = ?", nBytes = -1, ppStmt = 0xfda0bd28, pzTail = (nil)), line 435 in "prepare.c"
          [13] 0xfeb9ea88(0xfec45cf8, 0xfda0bd20, 0x67f0f0, 0xfec45c98, 0x3000, 0xfec45c80), at 0xfeb9ea87
          [14] 0xfeb9d4fc(0x0, 0xfec45d30, 0xffffffff, 0x67f0f0, 0xfec45cc0, 0x1), at 0xfeb9d4fb


Daniel Shields        
+44(0)207 888 9248  
[hidden email]
CREDIT | FIRST
SUISSE | BOSTON


==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:

http://www.csfb.com/legal_terms/disclaimer_external_email.shtml

==============================================================================

Reply | Threaded
Open this post in threaded view
|

Re: weird parser crash

D. Richard Hipp
"Shields, Daniel" <[hidden email]> wrote:
> I have a process that consistently crashes preparing a fairly innocuous statement.
> Has anyone seen anything similar? Any suggestions for a fix/workaround? The stack
> trace of the problem follows.
>

You are, it seems, the person who posted ticket #1557.

A stack trace is of little to no help in fixing a problem
like this.  What is needed is a script that when feed into
the "sqlite" command-line shell will reproduce the problem.
Send in such a script (or added it to ticket #1557) and you
will find the problem will get addressed *much* faster.
--
D. Richard Hipp <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

RE: weird parser crash

Shields, Daniel
In reply to this post by Shields, Daniel
> You are, it seems, the person who posted ticket #1557.
>
> A stack trace is of little to no help in fixing a problem
> like this.  What is needed is a script that when feed into
> the "sqlite" command-line shell will reproduce the problem.
> Send in such a script (or added it to ticket #1557) and you
> will find the problem will get addressed *much* faster.
>

I will try and provide a script to reproduce the problem but
I can't see how to script a prepare/step construct when it is
not available in the SQL syntax.

Daniel.

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:

http://www.csfb.com/legal_terms/disclaimer_external_email.shtml

==============================================================================

Reply | Threaded
Open this post in threaded view
|

Re: weird parser crash

D. Richard Hipp
In reply to this post by Shields, Daniel
"Shields, Daniel" <[hidden email]> wrote:
>
> I will try and provide a script to reproduce the problem but
> I can't see how to script a prepare/step construct when it is
> not available in the SQL syntax.
>

If you would just submit the particular query that is causing
the problem, that would be an enormous help.  If you can also
include the schema for your database, so much the better.
--
D. Richard Hipp <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

RE: weird parser crash

Shields, Daniel
In reply to this post by Shields, Daniel
> If you would just submit the particular query that is causing
> the problem, that would be an enormous help.  If you can also
> include the schema for your database, so much the better.

Statement failing in sqlite3_prepare is:
"UPDATE SDDSTORE SET SDD = ?, TIMESTAMP = DATETIME('NOW','LOCALTIME') WHERE ECORDERID = ?"

Schema is:
CREATE TABLE AMENDS (KEY VARCHAR PRIMARY KEY, VALUE INTEGER);
CREATE TABLE EXECID (KEY VARCHAR PRIMARY KEY, VALUE INTEGER);
CREATE TABLE PERSISTEDID (NAME VARCHAR, VALUE VARCHAR);
CREATE TABLE QUOTES (KEY VARCHAR PRIMARY KEY, VALUE INTEGER);
CREATE TABLE SDDSTORE (ECORDERID VARCHAR PRIMARY KEY, TIMESTAMP DATE, SDD BLOB);

I've added these to ticket 1557.

Strangely this only occurs the first time the statement is prepared. When the process
crashes and re-starts, subsequent prepares/steps are fine. I'm guessing its thread related
so I'll try it with a debug version of the sqlite3 library.

Thanks,

Daniel.

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:

http://www.csfb.com/legal_terms/disclaimer_external_email.shtml

==============================================================================