hi,

OK, the value of p->magic is 519C2973 (VDBE_MAGIC_HALT)

that should mean that "VDBE has completed execution"...

I don't know... in that case I should get a SQLITE_DONE
when stepping throu the result set, right ?

Just some additional info:
It is the last sqlite version, threadsafe is true and all
db connections are opened using SQLITE_OPEN_READWRITE|SQLITE_OPEN_FULLMUTEX in 
the flags
for sqlite3_open_v2, it is a dual core PC.

kind regards

Marcus

D. Richard Hipp wrote:
> On Mar 4, 2009, at 8:31 AM, Marcus Grimm wrote:
> 
>> Richard,
>> Thanks for looking into this.
>>
>> I've placed some debug output in the sqlite2_step function
>> and I found that it returns SQLITE_MISUSE here:
>>
>> --
>>   static int sqlite3Step(Vdbe *p){
>>   sqlite3 *db;
>>   int rc;
>>
>>   assert(p);
>>   if( p->magic!=VDBE_MAGIC_RUN )
>>   {
>>     return SQLITE_MISUSE;
>>   }
>> --
> 
> What is the value of p->magic at the point of failure?  (In hex, please)
> 
>>
>> I have no idea what this MAGIC_RUN means.
>>
>> Does it indicate that infact I'm using an allready released  
>> statement ?
>>
>> Please note that I'm not able to reproduce the problem when
>> I switch the shared cache off.
>>
>> Thank you
>>
>> Kind regards
>>
>> Marcus Grimm
>>
>>
>> D. Richard Hipp wrote:
>>> On Mar 4, 2009, at 5:19 AM, Marcus Grimm wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm doing a little stress test on a server application and run into
>>>> a problem when two threads are trying to access the database.
>>>> Here is the background:
>>>> 1. shared cache is enabled prior open any DB connection.
>>>> 2. Each thread then opens a DB connection.
>>>> 3. Thread A just reads table entries continuosly by
>>>>   doing sqlite3_prepare_v2 and followed by some sqlite3_step to
>>>> parse the result set.
>>>>   He then uses sqlite3_finalize and after a few ms he repeats
>>>> everything.
>>>> 4. Thread B is triggered to update or insert some a new values
>>>>   in some tables.
>>>>   To do so I obtain an EXCLUSIVE transaction, do the insert/update
>>>> and COMIT.
>>>>
>>>> Now, a problem arises occasionally that thread A gets an
>>>> SQLITE_MISUSE when
>>>> trying to call sqlite3_step, most likely because thread B currently
>>>> writes into
>>>> the DB, I guess.
>>>>
>>>> Now, my question:
>>>>
>>>> How to handle the SQLITE_MISUSE ?
>>> My guess is that the SQLITE_MISUSE is being returned because you are
>>> calling sqlite3_step() with a statement that has already been
>>> destroyed by sqlite3_finalize().
>>>
>>>
>>> D. Richard Hipp
>>> d...@hwaci.com
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
> 
> D. Richard Hipp
> d...@hwaci.com
> 
> 
> 
> _______________________________________________
> 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

Reply via email to