I've instrumented the SQLite source and have found that the error is
occurring at the fcntl call near the end of function unixLock (in
SQLite version 3.7.0.1, this is line 23592 of sqlite3.c). The
relevant code snippet is below. fnctl is returning -1, and errno=2
(ENOENT). From my reading of the fcntl man page, it wouldn't seem to
be possible for fcntl to even return ENOENT.
SQLite is being used from a multi-threaded application in my case, and
I don't know if it's a possibility that some other thread is
overwriting errno. But then, if that's even a possibility, wouldn't
that seem to preclude using SQLite in a multithreaded application at
all?
}else{
/* The request was for a RESERVED or EXCLUSIVE lock. It is
** assumed that there is a SHARED or greater lock on the file
** already.
*/
assert( 0!=pFile->eFileLock );
lock.l_type = F_WRLCK;
switch( eFileLock ){
case RESERVED_LOCK:
lock.l_start = RESERVED_BYTE;
break;
case EXCLUSIVE_LOCK:
lock.l_start = SHARED_FIRST;
lock.l_len = SHARED_SIZE;
break;
default:
assert(0);
}
s = fcntl(pFile->h, F_SETLK, &lock);
if( s==(-1) ){
tErrno = errno;
rc = sqliteErrorFromPosixError(tErrno, SQLITE_IOERR_LOCK);
if( IS_LOCK_ERROR(rc) ){
pFile->lastErrno = tErrno;
}
}
}
On Feb 26, 2013, at 9:13 AM, Dan Kennedy wrote:
On 02/27/2013 12:00 AM, Greg Janée wrote:
errno=2 (ENOENT)
What could not be existing?
Strange. Could the value of errno have been clobbered before you
read it?
What can you see if you run the app under "truss -tfcntl"?
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
