This was covered a few days ago...the error handling is not thread safe
apparently(why not???) so you need to wrap the call and error check with a
mutex.
int rc=SQLITE_OK;
char *errmsg=NULL;
sqlite3_mutex_enter(sqlite_db_mutex(db));
rc=sqlite3_blobopen(.....);
if(rc!=SQLITE_OK) {
rc=sqlite3_extended_errcode(db);
errmsg=strdup(sqlite3_errmsg(db);
}
sqlite3_mutex_leave(sqlite_db_mutex(db));
// now you can safely use rc and errmsg
-----Original Message-----
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Greg Janée
Sent: Tuesday, February 26, 2013 11:50 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] locked database returning SQLITE_IOERR, not
SQLITE_BUSY
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
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
