Proposed fix:
--- os_win.old 2009-04-09 20:41:18.000000000 +0200
+++ os_win.c 2009-04-17 16:33:47.904710700 +0200
@@ -1317,7 +1317,7 @@
}else{
dwCreationDisposition = OPEN_EXISTING;
}
- if( flags & SQLITE_OPEN_MAIN_DB ){
+ if( !(flags & SQLITE_OPEN_EXCLUSIVE) ){
dwShareMode = FILE_SHARE_READ | FILE_SHARE_WRITE;
}else{
dwShareMode = 0;
Best regards,
Filip Navara
On Fri, Apr 17, 2009 at 3:30 PM, Filip Navara <filip.nav...@gmail.com> wrote:
> Hi again,
>
> the bug was introduced in revision 1.573 of pager.c.
>
> Best regards,
> Filip Navara
>
> On Fri, Apr 17, 2009 at 2:26 PM, Filip Navara <filip.nav...@gmail.com> wrote:
>>
>> Hello,
>>
>> today I tried to upgrade our software from SQLite version 3.6.3 to version
>> 3.6.13 and I am hitting a race condition that I believe is a bug in the
>> library. The library is compiled as thread-safe (and it's reproducible even
>> with the precompiled DLL). Sometimes sqlite3_step fails with SQLITE_CANTOPEN
>> error. I traced it with Process Monitor and each time the error happened,
>> this could be seen in the log:
>>
>> (time / process / PID / function name / file name / result of the call /
>> parameters / thread ID)
>> 12:27:55.1443678 PM eM Client.vshost.exe 3308 LockFile folders.dat SUCCESS
>> Exclusive: True, Offset: 1,073,741,825, Length: 1, Fail Immediately: True
>> 5052
>> 12:27:55.1443826 PM eM Client.vshost.exe 3308 UnlockFileSingle folders.dat
>> SUCCESS Offset: 1,073,741,825, Length: 1 5052
>> 12:27:55.1443944 PM eM Client.vshost.exe 3308 QueryStandardInformationFile
>> folders.dat SUCCESS AllocationSize: 32,768, EndOfFile: 21,504,
>> NumberOfLinks: 1, DeletePending: False, Directory: False 5052
>> 12:27:55.1445976 PM eM Client.vshost.exe 3308 CreateFile folders.dat-journal
>> SUCCESS Desired Access: Generic Read, Disposition: Open, Options:
>> Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode:
>> None, AllocationSize: n/a, OpenResult: Opened 5052
>> 12:27:55.1447616 PM eM Client.vshost.exe 3308 CreateFile folders.dat-journal
>> SHARING VIOLATION Desired Access: Generic Read, Disposition: Open, Options:
>> Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode:
>> None, AllocationSize: n/a 5804
>> 12:27:55.1447930 PM eM Client.vshost.exe 3308 ReadFile folders.dat-journal
>> SUCCESS Offset: 0, Length: 1, Priority: Normal 5052
>> 12:27:55.1448185 PM eM Client.vshost.exe 3308 UnlockFileSingle folders.dat
>> SUCCESS Offset: 1,073,741,826, Length: 510 5804
>> 12:27:55.1448268 PM eM Client.vshost.exe 3308 CloseFile folders.dat-journal
>> SUCCESS 5052
>> There are two threads accessing the folders.dat database at the same time,
>> the first one (5052) succeeds, while the other one (5804) fails when
>> checking for hot journal. Here are the stack traces of the two threads
>> during the CreateFile calls (both against the sqlite3.c 3.6.13 amalgamation).
>>
>> Thread 5052:
>> 14 sqlite3.dll winOpen + 0x139, sqlite3.c(27454) 0x100067d6
>> 15 sqlite3.dll sqlite3OsOpen + 0x19, sqlite3.c(11655) 0x100095ed
>> 16 sqlite3.dll hasHotJournal + 0xce, sqlite3.c(33360) 0x1000ac42
>> 17 sqlite3.dll pagerSharedLock + 0x102, sqlite3.c(33499) 0x100093c0
>> 18 sqlite3.dll sqlite3PagerAcquire + 0x41, sqlite3.c(33732) 0x10008c21
>> 19 sqlite3.dll sqlite3BtreeGetPage + 0x19, sqlite3.c(37419) 0x1000c92a
>> 20 sqlite3.dll lockBtree + 0x16, sqlite3.c(38097) 0x1000c6ee
>> 21 sqlite3.dll sqlite3BtreeBeginTrans + 0xe5,sqlite3.c(38366) 0x1000c434
>> 22 sqlite3.dll sqlite3VdbeExec + 0x2e59, sqlite3.c(52191) 0x10019223
>> 23 sqlite3.dll sqlite3Step + 0x161,sqlite3.c(48601) 0x10014d9d
>> 24 sqlite3.dll sqlite3_step + 0x3d, sqlite3.c(48675) 0x10014aaf
>> Thread 5804:
>> 14 sqlite3.dll winOpen + 0x139, sqlite3.c(27454) 0x100067d6
>> 15 sqlite3.dll sqlite3OsOpen + 0x19, sqlite3.c(11655) 0x100095ed
>> 16 sqlite3.dll hasHotJournal + 0xce, sqlite3.c(33360) 0x1000ac42
>> 17 sqlite3.dll pagerSharedLock + 0x102, sqlite3.c(33499) 0x100093c0
>> 18 sqlite3.dll sqlite3PagerAcquire + 0x41, sqlite3.c(33732) 0x10008c21
>> 19 sqlite3.dll sqlite3BtreeGetMeta + 0x6e, sqlite3.c(42972) 0x1000ed7e
>> 20 sqlite3.dll sqlite3VdbeExec + 0x2f05, sqlite3.c(52230) 0x100192cf
>> 21 sqlite3.dll sqlite3Step + 0x161, sqlite3.c(48601) 0x10014d9d
>> 22 sqlite3.dll sqlite3_step + 0x3d, sqlite3.c(48675) 0x10014aaf
>> I believe it's incorrect behavior to return SQLITE_CANTOPEN to the
>> application in that case. I'm not sure what would be the correct solution
>> (setting sharing mode in winOpen?). Anyone can help or offer any insight?
>> Thanks,
>> Filip Navara
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
