Re: [sqlite] Problem with SQLite FastCGI module "malformed database schema"
On Fri, Aug 03, 2007 at 11:38:57AM -0700, Joe Wilson wrote: > > Of course I'm not. The PHP4 module uses sqlite2.x, and - besides - it > > :-) > > "Of course"? That's rich. "Of course" - just because I haven't any possibility to do that. > > OK, I'll try to ask maintainers about that. > > Good luck. Sent a comment about that - we'll see. -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem with SQLite FastCGI module "malformed database schema"
--- Zbigniew Baniewski <[EMAIL PROTECTED]> wrote: > On Fri, Aug 03, 2007 at 09:27:22AM -0700, Joe Wilson wrote: > > > You are not checking the return code of the sqlite3 connection close. > > Of course I'm not. The PHP4 module uses sqlite2.x, and - besides - it :-) "Of course"? That's rich. I don't know whether you're running PHP version 3, 4, 99 or PI^2 and what version of sqlite it uses. > OK, I'll try to ask maintainers about that. Good luck. I fear I've learned too much about PHP already. Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem with SQLite FastCGI module "malformed database schema"
On Fri, Aug 03, 2007 at 09:27:22AM -0700, Joe Wilson wrote: > You are not checking the return code of the sqlite3 connection close. Of course I'm not. The PHP4 module uses sqlite2.x, and - besides - it doesn't return any value when using sqlite_close. > I have no idea if the PHP sqlite3 wrapper propogates these errors, No, it isn't. http://hostprogressive.com/support/php_5_docs/function.sqlite-close.html void sqlite_close ( resource dbhandle ) ! > as the return code of sqlite3_close is not examined (see PHP wrapper below). > Perhaps PHP somehow calls sqlite3_errcode() - who knows. It's a question > for the PHP people. OK, I'll try to ask maintainers about that. -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem with SQLite FastCGI module "malformed database schema"
--- Zbigniew Baniewski <[EMAIL PROTECTED]> wrote:
> > Your trace seems to indicate it has 20 or so open
> > connections to the same database file in the same process.
>
> I think, at last I've traced the problem:
>
> One of the scripts doesn't make use out of database contents at all. But at
> the beginning there was a simple check for database file presence, just to
> let the user know, if there (from any reason) could be dbfile missing:
>
> if ($dbhandle = sqlite_open("/path/to/database/dbfile.db", 0666,
> $sqliteerror)) {
> $result = sqlite_unbuffered_query($dbhandle, 'select something from
> some_table');
> sqlite_close($dbhandle);
> } else {
> die($sqliteerror);
> }
>
>
> Yes, the "$result = ..." line can be omitted (it is now, anyway...), because
> a successfull opening a database file is enough to check, whether the file
> is present, or not (although without SELECT it may be any other database
> file, with quite different tables).
>
> My problem was caused by the fact, that there was a "SELECT" query, but
> $result handle hasn't been processed any further. After commenting out the
> "$result = ..." line there are no more "persistent" open database connections.
>
>
> And the question: is it normal behaviour - or is it a bug in PHP-module?
> I've got a feeling, that after "sqlite_close($dbhandle)" there should be
> assumption, that the script will not use database anymore (until ev. next
> "sqlite_open"), so all ev. other handles related to database contents should
> be immediately removed.
You are not checking the return code of the sqlite3 connection close.
sqlite3_close can fail with:
SQLITE_MISUSE
SQLITE_BUSY -> "Unable to close due to unfinalised statements"
SQLITE_ERROR
see http://sqlite.org/capi3ref.html#sqlite3_close
I have no idea if the PHP sqlite3 wrapper propogates these errors, as
the return code of sqlite3_close is not examined (see PHP wrapper below).
Perhaps PHP somehow calls sqlite3_errcode() - who knows. It's a question
for the PHP people.
static int sqlite_handle_closer(pdo_dbh_t *dbh TSRMLS_DC) /* {{{ */
{
pdo_sqlite_db_handle *H = (pdo_sqlite_db_handle *)dbh->driver_data;
if (H) {
pdo_sqlite_error_info *einfo = >einfo;
pdo_sqlite_cleanup_callbacks(H TSRMLS_CC);
if (H->db) {
sqlite3_close(H->db);
H->db = NULL;
}
if (einfo->errmsg) {
pefree(einfo->errmsg, dbh->is_persistent);
einfo->errmsg = NULL;
}
pefree(H, dbh->is_persistent);
dbh->driver_data = NULL;
}
return 0;
}
Be a better Globetrotter. Get better travel answers from someone who knows.
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list=396545469
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] Problem with SQLite FastCGI module "malformed database schema"
--- Zbigniew Baniewski <[EMAIL PROTECTED]> wrote: > On Wed, Aug 01, 2007 at 03:04:35PM -0700, Joe Wilson wrote: > > > Maybe the php wrapper is not closing sqlite connections correctly > > (or at all). > > > > See if you can get the stack traces of all threads in the php process > > 162 via pstack, lsstack or by attaching gdb to it at runtime. > > Before I'll make it: does there exist any possibility, that I made some > mistake in PHP-scripts? If I correctly recall, even ev. omitting of > "sqlite_close" function can't make any problem, because the connection is > always closed even without this, just when end of script has been reached. > > Are any script-related (not bugs in PHP-module) reasons possible? Anything's possible when you're dealing with so many unrelated libraries. Why do you think that the sqlite connection closes itself automatically? Did you examine the PHP wrapper code to verify it closes each connection in a timely fashion? Your trace seems to indicate it has 20 or so open connections to the same database file in the same process. Maybe there's a state the PHP wrapper can get into where the close is not issued. Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list=396545433 - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem with SQLite FastCGI module "malformed database schema"
On Wed, Aug 01, 2007 at 03:04:35PM -0700, Joe Wilson wrote: > Maybe the php wrapper is not closing sqlite connections correctly > (or at all). > > See if you can get the stack traces of all threads in the php process > 162 via pstack, lsstack or by attaching gdb to it at runtime. Before I'll make it: does there exist any possibility, that I made some mistake in PHP-scripts? If I correctly recall, even ev. omitting of "sqlite_close" function can't make any problem, because the connection is always closed even without this, just when end of script has been reached. Are any script-related (not bugs in PHP-module) reasons possible? -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem with SQLite FastCGI module "malformed database schema"
Maybe the php wrapper is not closing sqlite connections correctly (or at all). See if you can get the stack traces of all threads in the php process 162 via pstack, lsstack or by attaching gdb to it at runtime. > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > php 162 root5uVREG0,0 613376 338233 > /usr/local/db/databasefile.db > php 162 root6uVREG0,0 0 92290 / > (/dev/wd0a) > php 162 root7uVREG0,0 613376 338233 > /usr/local/db/databasefile.db > php 162 root8uVREG0,0 0 92318 / > (/dev/wd0a) > php 162 root9uVREG0,0 613376 338233 > /usr/local/db/databasefile.db > php 162 root 10uVREG0,0 0 92319 / > (/dev/wd0a) > php 162 root 11uVREG0,0 613376 338233 > /usr/local/db/databasefile.db > php 162 root 12uVREG0,0 0 92317 / > (/dev/wd0a) Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/ - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem with SQLite FastCGI module "malformed database schema"
On Thu, Jul 26, 2007 at 04:26:41PM -0700, [EMAIL PROTECTED] wrote: > If it works and then later stops working, it's much more likely that > you're having a problem with some file descriptor that is not closed > properly (on the temp db most likely). > If it dies after let's say a week, you can check after a few days using > lsof if the process is keeping files open in /tmp After several days (no error until today) I made a check using lsof, and I've found something looking a bit suspicious (a fragment of lsof-output below) - what do you think about it? The www-service wasn't used by anybody when I used lsof. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME php 162 root5uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root6uVREG0,0 0 92290 / (/dev/wd0a) php 162 root7uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root8uVREG0,0 0 92318 / (/dev/wd0a) php 162 root9uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 10uVREG0,0 0 92319 / (/dev/wd0a) php 162 root 11uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 12uVREG0,0 0 92317 / (/dev/wd0a) php 162 root 13uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 14uVREG0,0 0 92321 / (/dev/wd0a) php 162 root 15uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 16uVREG0,0 0 92331 / (/dev/wd0a) php 162 root 17uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 18uVREG0,0 0 91348 / (/dev/wd0a) php 162 root 19uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 20uVREG0,0 0 92328 / (/dev/wd0a) php 162 root 21uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 22uVREG0,0 0 92332 / (/dev/wd0a) php 162 root 23uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 24uVREG0,0 0 92322 / (/dev/wd0a) php 162 root 25uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 26uVREG0,0 0 92334 / (/dev/wd0a) php 162 root 27uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 28uVREG0,0 0 92333 / (/dev/wd0a) php 162 root 29uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 30uVREG0,0 0 92198 / (/dev/wd0a) php 162 root 31uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 32uVREG0,0 0 92337 / (/dev/wd0a) php 162 root 33uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 34uVREG0,0 0 92336 / (/dev/wd0a) php 162 root 35uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 36uVREG0,0 0 92267 / (/dev/wd0a) php 162 root 37uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 38uVREG0,0 0 92349 / (/dev/wd0a) php 162 root 39uVREG0,0 613376 338233 /usr/local/db/databasefile.db php 162 root 40uVREG0,0 0 92350 / (/dev/wd0a) php 165 root cwd VDIR0,0512 317929 / (/dev/wd0a) php 165 root txt VREG0,01122496 319019 / (/dev/wd0a) -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem with SQLite FastCGI module "malformed database schema"
--- Zbigniew Baniewski <[EMAIL PROTECTED]> wrote: > Starting from 101st it just keeps reporting "malformed..." error everytime, > when one tries to access the database using any of PHP-scripts. Until I > "manually" restart lighttpd server. I have no idea about the architecture of lighttpd and its relationship to PHP and SQLite. Something in the various layers of bindings might be wrong. If the database is reporting it is malformed, then something may be fundamentally broken. Either fnctl locking is not working, or there's some memory corruption somewhere, or there's some multithreading or fork() issue. Good luck with that. Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/ - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem with SQLite FastCGI module "malformed database schema"
On Thu, Jul 26, 2007 at 05:29:15PM -0700, Joe Wilson wrote: > What happens on the 102nd time? Starting from 101st it just keeps reporting "malformed..." error everytime, when one tries to access the database using any of PHP-scripts. Until I "manually" restart lighttpd server. > If it fails, then it's easy enough to debug. > Just put some debugging code in sqlite3UnixTempFileName() > and find out what the problem is. > [..] > See also: > > http://sqlite.org/capi3ref.html#sqlite3_extended_result_codes Thanks. Indeed, it's a way to obtain much more information. -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem with SQLite FastCGI module "malformed database schema"
On Thu, Jul 26, 2007 at 04:26:41PM -0700, [EMAIL PROTECTED] wrote: > If it works and then later stops working, it's much more likely that > you're having a problem with some file descriptor that is not closed > properly (on the temp db most likely). > If it dies after let's say a week, you can check after a few days using > lsof if the process is keeping files open in /tmp Thanks, I'll check it. What can be a reason to leave such descriptor still open? In my particular case it can't be - as I think - anything from PHP-script contents, because it has nothing to do with that temporary files. It's one of SQLite's internals rather. So, most likely it'll be kind of bug in the php-sqlite module? As example: one of my scripts is doing VACUUM on the database file, after opening it (I noticed in error log several "malformed..." - reports when running that script). Not sure: were there any similar problems (file descriptors left open) while doing VACUUM? Or is it accident? -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem with SQLite FastCGI module "malformed database schema"
-- Zbigniew Baniewski <[EMAIL PROTECTED]> wrote: > The problem is, that the error message actually gives not any clue. It just > tells, that "there was problem while truing to open temporary database file" > - but there (considering the above) shouldn't be any problem. /var/tmp has > rwxrwxrwx privileges. Even worse: it's working without any problems most of > the time - and then, after f.e. a week, it refuses to work any further, > without any particular reason. It did open that temporary files 100 times > before - and it can't open it at 101. time. What happens on the 102nd time? If it fails, then it's easy enough to debug. Just put some debugging code in sqlite3UnixTempFileName() and find out what the problem is. > Perhaps there are other possible reasons, not just wrong permissions for > "temp" sub-dir? > > I think, that the error code should be more communicative, and there should > be something like "wrong permissions", "directory not found" or at least kind > of numerical error code added, to allow the reason of the problem be found. See also: http://sqlite.org/capi3ref.html#sqlite3_extended_result_codes Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem with SQLite FastCGI module "malformed database schema"
> > - Original Message > From: Zbigniew Baniewski <[EMAIL PROTECTED]> > To: sqlite-users@sqlite.org > Sent: Thursday, July 26, 2007 4:12:00 PM > Subject: Re: [sqlite] Problem with SQLite FastCGI module "malformed database > schema" > > > On Thu, Jul 26, 2007 at 12:59:45PM -0700, Joe Wilson wrote: > > > /var on my machine is drwxr-xr-x, and I don't have any issues with sqlite > > reading and writing temp files to /var/tmp/. Even if the permissions of /var > > were d--x--x--x, it would also be fine. As long as /var/tmp is rwx for > > the sqlite process, it will work. > > > > Just make sure the the first accessible temp dir has enough disk space > > for the temporary files. > > Of course. It's a little 5 GB HDD - but filled only to 1/3 of it's capacity. > There's just one big partition (beside swap). > > The problem is, that the error message actually gives not any clue. It just > tells, that "there was problem while truing to open temporary database file" > - but there (considering the above) shouldn't be any problem. /var/tmp has > rwxrwxrwx privileges. Even worse: it's working without any problems most of > the time - and then, after f.e. a week, it refuses to work any further, > without any particular reason. It did open that temporary files 100 times > before - and it can't open it at 101. time. > If it works and then later stops working, it's much more likely that you're having a problem with some file descriptor that is not closed properly (on the temp db most likely). If it dies after let's say a week, you can check after a few days using lsof if the process is keeping files open in /tmp Good luck Nicolas
Re: [sqlite] Problem with SQLite FastCGI module "malformed database schema"
On Thu, Jul 26, 2007 at 12:59:45PM -0700, Joe Wilson wrote: > /var on my machine is drwxr-xr-x, and I don't have any issues with sqlite > reading and writing temp files to /var/tmp/. Even if the permissions of /var > were d--x--x--x, it would also be fine. As long as /var/tmp is rwx for > the sqlite process, it will work. > > Just make sure the the first accessible temp dir has enough disk space > for the temporary files. Of course. It's a little 5 GB HDD - but filled only to 1/3 of it's capacity. There's just one big partition (beside swap). The problem is, that the error message actually gives not any clue. It just tells, that "there was problem while truing to open temporary database file" - but there (considering the above) shouldn't be any problem. /var/tmp has rwxrwxrwx privileges. Even worse: it's working without any problems most of the time - and then, after f.e. a week, it refuses to work any further, without any particular reason. It did open that temporary files 100 times before - and it can't open it at 101. time. Perhaps there are other possible reasons, not just wrong permissions for "temp" sub-dir? I think, that the error code should be more communicative, and there should be something like "wrong permissions", "directory not found" or at least kind of numerical error code added, to allow the reason of the problem be found. -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem with SQLite FastCGI module "malformed database schema"
On Thu, Jul 26, 2007 at 08:11:22AM -0700, Joe Wilson wrote: > Try > > PRAGMA temp_store_directory = 'directory-name'; > > Otherwise, the temp file location order for UNIX is: > > "/var/tmp", > "/usr/tmp", > "/tmp", > ".", Thanks, I'll try to. Although is rather temporar workaround than solution, because there's a need to set it at every database connection. As I can see, the order, in which sqlite is searching the "temp" directories, is like the above. Someone from other list wrote, that sqlite doesn't like, when "any directory in the database path isn't writeable" (is it true?) - perhaps the same thing is related to any "temp" directory? Under NetBSD there are /var/tmp and /tmp directories - but, of course, /var doesn't have 777 (both /var/tmp and /tmp do). Perhaps this can make a problem? If so - shouldn't be much more logical, to change the order of search to: 1. /tmp 2. /var/tmp 3. /usr/tmp 4. . In such way, on the first place could be the only one directory, which is always (if it does exist at all) both world-writeable and hasn't any parent-dir, which can be not set to 777. Wouldn't it be a "final solution" of the problem? -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem with SQLite FastCGI module "malformed database schema"
--- Zbigniew Baniewski <[EMAIL PROTECTED]> wrote: > > While using SQLite as FastCGI module from within PHP-scripts, sometimes I'm > getting error messages, like: > > (mod_fastcgi.c.2551) FastCGI-stderr: PHP Warning: > sqlite_open() [function.sqlite-open > malformed database schema - unable to open a temporary database file > for storing temporary tables in /usr/local/www/index.php on line 25 > > Yes, I've found several "recipes", how to fix it, like: > > http://hostprogressive.com/support/php_5_docs/ref.sqlite.html > > "On Windows operating systems, unprivileged accounts don't have the TMP > environment variable set by default. This will make sqlite create temporary > files in the windows directory, which is not desirable. So, you should set > the TMP environment variable for the web server" > > or f.e.: > > http://www.bacula.org/dev-manual/Installin_Configuri_SQLite.html > > "this is most likely caused by the fact that some versions of SQLite attempt > to create a temporary file in the current directory" > > > ...but the problem is, that: > > 1. This isn't any Windows-based installation - it's NetBSD. > > 2. The error message didn't tell, WHERE exactly it's trying to "open a >temporary database file" - but under NetBSD, lighttpd is working with >root privileges (the privileges seem not to be dropped, because I can >see, that the files sent via http form are saved with root.wheel owner). >So, even if it's trying to create any temporary file, it's able to create >it anywhere. In /tmp or anywhere else. > > 3. The problem isn't occuring in regular manner - f.e. once in two weeks >(while the PHP scripts, which are calling SQLite are used each day). >So, currently no idea, what is causing that. > > Any clues? Try PRAGMA temp_store_directory = 'directory-name'; Otherwise, the temp file location order for UNIX is: "/var/tmp", "/usr/tmp", "/tmp", ".", If NetBSD has some equivalent to truss or strace you could determine the temp file location using that. Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC - To unsubscribe, send email to [EMAIL PROTECTED] -
