Ralf Junker <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I am using SQLite compiled with SQLITE_ENABLE_MEMORY_MANAGEMENT on Win32.
>
Why? What do you hope to accomplish by using MEMORY_MANAGEMENT on
Win32? MM is designed for use on embedded devices with very tight
memory restrictions. It is not intended for use on workstations,
which is why it is off by default.
> I execute the following psydocode, all with same DB handle:
>
> * In application's main thread: sqlite3_open
> * Create a new thread
> * In new thread: sqlite3_close
When SQLITE_ENABLE_MEMORY_MANAGEMENT is turned on, it is an error
to move a database connection from one thread to another.
>
> This creates an access violation in pager.c, lines 2065 to 2076:
>
> #ifdef SQLITE_ENABLE_MEMORY_MANAGEMENT
> /* Remove the pager from the linked list of pagers starting at
> ** ThreadData.pPager if memory-management is enabled.
> */
> if( pPager==pTsd->pPager ){
> pTsd->pPager = pPager->pNext;
> }else{
> Pager *pTmp;
> for(pTmp = pTsd->pPager; pTmp->pNext!=pPager; pTmp=pTmp->pNext);
> pTmp->pNext = pPager->pNext;
> }
> #endif
And here is one reason why it is an error: When MM is enabled,
SQLite keeps a linked list of every pager structure used in each
thread. (It has to do this in order to support some features of MM.)
When you close a connection it must unlink that pager from the
linked list. But it can only do so if the connection is closed
from the same thread in which it was created.
>
> While I understand from the FAQ that it might be problematic to use more than
> one thread with SQLITE_ENABLE_MEMORY_MANAGEMENT, I wonder if SQLite should
> cause an AV in this case?
Yes it should.
>
> I even found that other SQL instructions, like INSERT, work fine when called
> from the 2nd thread.
You were lucky.
