RE: [sqlite] SQLite 3.5.2 - Unix - Memory issue?

2007-11-26 Thread Mark Brown
Ah, yes.  My mistake.  Thanks.

> 
> The locking style has absolutely nothing to do with
> threads.  Locking style is what kind of file locks
> are used to prevent separate processes from updating
> the same database as the same time.  SQLite uses
> posix advisory locks by default.  Not all systems
> support posix advisory locks correctly, which is the
> reason for providing alternatives.
> --
> D. Richard Hipp <[EMAIL PROTECTED]>



-
To unsubscribe, send email to [EMAIL PROTECTED]
-



Re: [sqlite] SQLite 3.5.2 - Unix - Memory issue?

2007-11-21 Thread drh
"Mark Brown" <[EMAIL PROTECTED]> wrote:
> I was using the noLocking style.  Is that essentially what you get with
> SQLITE_THREADSAFE = 0?
> 

The locking style has absolutely nothing to do with
threads.  Locking style is what kind of file locks
are used to prevent separate processes from updating
the same database as the same time.  SQLite uses
posix advisory locks by default.  Not all systems
support posix advisory locks correctly, which is the
reason for providing alternatives.
--
D. Richard Hipp <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-



RE: [sqlite] SQLite 3.5.2 - Unix - Memory issue?

2007-11-21 Thread Mark Brown
I was using the noLocking style.  Is that essentially what you get with
SQLITE_THREADSAFE = 0?

Thanks,
Mark


> 
> I recommend that you *not* use LOCKING_STYLE.  It is
> disabled by default.  Dan and I have a note to go back
> and get the LOCKING_STYLE stuff working, but we have not
> gotten around to that yet, being distracted by more
> pressing issues.



-
To unsubscribe, send email to [EMAIL PROTECTED]
-



Re: [sqlite] SQLite 3.5.2 - Unix - Memory issue?

2007-11-21 Thread drh
"Mark Brown" <[EMAIL PROTECTED]> wrote:
> Hi-
> 
> I am currently migrating over from 3.4 to 3.5.2.  I am creating a custom
> VFS, but it is essentially the same as unix.
> 
> As I was going through the code, there was a particular section that =
> made me
> think that it may not have been migrated correctly.
> 
> In the fillInUnixFile() method (and assuming that
> SQLITE_ENABLE_LOCKING_STYLE is defined), 

I recommend that you *not* use LOCKING_STYLE.  It is
disabled by default.  Dan and I have a note to go back
and get the LOCKING_STYLE stuff working, but we have not
gotten around to that yet, being distracted by more
pressing issues.

--
D. Richard Hipp <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-



[sqlite] SQLite 3.5.2 - Unix - Memory issue?

2007-11-21 Thread Mark Brown
Hi-

I am currently migrating over from 3.4 to 3.5.2.  I am creating a custom
VFS, but it is essentially the same as unix.

As I was going through the code, there was a particular section that made me
think that it may not have been migrated correctly.

In the fillInUnixFile() method (and assuming that
SQLITE_ENABLE_LOCKING_STYLE is defined), my concern is at line 2196:

  pNew = sqlite3_malloc( sizeof(unixFile) );

(in context, the surrounding code is:)

  pNew->dirfd = -1;
  pNew->h = h;
  SET_THREADID(pNew);
  pNew = sqlite3_malloc( sizeof(unixFile) );  /* <--- This line */
  if( pNew==0 ){
close(h);
enterMutex();
releaseLockInfo(pNew->pLock);
releaseOpenCnt(pNew->pOpen);
leaveMutex();
return SQLITE_NOMEM;
  }else{
switch(lockingStyle) {

It seems like the allocation will wipe out previous set values and cause a
memory leak.  Could someone verify?

Thanks,
Mark



-
To unsubscribe, send email to [EMAIL PROTECTED]
-