Hi again,
sorry, but it looks that the problem was on my side...
An error printf that I added to trace the condition causes
the crash and not the sqlite... sorry sorry, I'm getting old...
Marcus
Marcus Grimm wrote:
> Hi Ken,
>
> thanks for the code, but I guess it will still crash:
>
> Ken wrote:
>> Marcus try something like this pseudo code:
>>
>> local_Exec( exec_Str) {
>> *pStmt = NULL;
>>
>> rc = prepare_v2 (exec_Str)
>> if (rc != SQLITE_OK) goto exec_err
>
> ok, but this usually works without a BUSY state. so no problem here.
>
>> rc = step ( );
>
> This may now generate a BUSY or LOCKED state and fails.
> Same as in my code except that the loop is outside.
>
>
>> if (rc != SQLITE_OK or SQLITE_DONE ) goto exec_err
>>
>> rc = finalize( )
>> if rc != SQLITE_OK ) goto exec_err
>>
>> return SQLITE_OK;
>> :exec_err
>
> if I come here from the step() error, I still have the same problem,
> and I'm sure it will still crash in sqlite_finalize. Or do you think
> it is a problem that I call Step multible times in case it returns a
> busy state ?
>
> Maybe the Step() call allready frees the pStmt because it was
> trying to do an exclusive transaction, maybe a special handling for this
> SQL statement ?
> If nobody else has an explanation it seems that I'll have to run it in
> a debugger to see where it actually crashes inside finalize... ;)
>
> Thanks for the reply
>
> Marcus
>
>> if (pStmt) sqlite_finalize;
>> return rc ;
>> }
>>
>> ==============================
>> code to lock:
>>
>> do
>> {
>> rc = local_exec(db, "BEGIN EXCLUSIVE TRANSACTION;", -1, 0);
>>
>> if( (rc == SQLITE_BUSY) || (rc == SQLITE_LOCKED) )
>> {
>> n++;
>> Sleep(SQLTM_TIME);
>> }
>> }while( (n < SQLTM_COUNT) && ((rc == SQLITE_BUSY)
>> || (rc == SQLITE_LOCKED)));
>>
>> ==============================================================
>>
>>
>>
>> --- On Wed, 12/3/08, Marcus Grimm <[EMAIL PROTECTED]> wrote:
>>
>>> From: Marcus Grimm <[EMAIL PROTECTED]>
>>> Subject: [sqlite] Transaction Timeout and crash
>>> To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org>
>>> Date: Wednesday, December 3, 2008, 4:15 AM
>>> Hi all,
>>>
>>> while doing a stress test on my embedded server application
>>> I'm noting a crash in sqlite3_finalize that I don't
>>> understand,
>>> and I'm wondering if I'm doing the right error
>>> handling.
>>>
>>> Background: In order to encapsulate writings to the tables
>>> I'm using
>>> BEGIN EXCLUSIVE TRANSACTION to block all other threads from
>>> reading and writing. Of course this requires a timeout and
>>> busy
>>> handling when trying to acquire the exclusive lock.
>>>
>>> So the code looks like:
>>>
>>> ---------------------------------------
>>> /** Obtain exclusive lock **/
>>> n = 0;
>>> do
>>> {
>>> rc = sqlite3_prepare_v2(db, "BEGIN EXCLUSIVE
>>> TRANSACTION;", -1, &stmt, 0);
>>>
>>> if( (rc == SQLITE_BUSY) || (rc == SQLITE_LOCKED) )
>>> {
>>> n++;
>>> Sleep(SQLTM_TIME);
>>> }
>>> }while( (n < SQLTM_COUNT) && ((rc ==
>>> SQLITE_BUSY) || (rc == SQLITE_LOCKED)));
>>>
>>> if( n == SQLTM_COUNT )
>>> return(TIMEOUT_ERROR); /** --> Timeout during
>>> prepare, never happends so far **/
>>>
>>> n = 0;
>>> do
>>> {
>>> rc = sqlite3_step(stmt);
>>> if( (rc == SQLITE_BUSY) || (rc == SQLITE_LOCKED) )
>>> {
>>> Sleep(SQLTM_TIME);
>>> n++;
>>> }
>>> }while( (n < SQLTM_COUNT) && ((rc ==
>>> SQLITE_BUSY) || (rc == SQLITE_LOCKED)));
>>>
>>> /** we are done **/
>>> sqlite3_finalize(stmt); /** <<- crash if timeout
>>> occurs **/
>>>
>>> if( n == SQLTM_COUNT )
>>> return(TIMEOUT_ERROR);
>>>
>>> ------------------------
>>>
>>> The problem is that it crashes in the sqlite3_finalize
>>> function in case the
>>> sqlite3_step doesn't actually did something and the
>>> timeout condition
>>> becames true.
>>> My feeling is that it occurs only when trying to get the
>>> exclusive transaction;
>>> A simple "SELECT *" that runs into a timeout
>>> doesn't crash when using sqlite3_finalize.
>>>
>>> Before starting to deeper debugging this, I would like to
>>> ask if there
>>> is an advice or known issue concerning the sqlite3_finalize
>>> when a
>>> step was not successful due to busy or locking state.
>>> It is not allowed to call this function in this case ?
>>> But then: How to free the statement, succesfully created by
>>> sqlite3_prepare_v2 ?
>>>
>>> I'm using sqlite 3.6.6.2, compiled using MSVS 2008, and
>>> of course threadsafe.
>>> I'm not using any timeout callback or timeout value
>>> settings since I'm handling
>>> this by my selve like in the code above.
>>>
>>> Thank you in advance.
>>>
>>> Marcus
>>>
>>>
>>>
>>> _______________________________________________
>>> sqlite-users mailing list
>>> sqlite-users@sqlite.org
>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
