#19077 [Bgs->Ana]: dba_open fails

From: Date: Mon, 09 Sep 2002 22:20:34 +0000
Subject: #19077 [Bgs->Ana]: dba_open fails
References: 1  Groups: php.bugs php.doc 
Request: Send a blank email to php-bugs+get-18868@lists.php.net to get a copy of this message
ID: 19077 Updated by: sniper@php.net Reported By: wboring@qualys.com -Status: Bogus +Status: Analyzed -Bug Type: DBM/DBA related +Bug Type: Documentation problem Operating System: Redhat 6.2 kernel 2.2.10 PHP Version: 4.2.2 New Comment: Yes, that's true..reclassified as documentation problem. Previous Comments: ------------------------------------------------------------------------ [2002-09-09 17:17:20] wboring@qualys.com If its not a bug in php, someone should not this anomaly in the php docs, so other don't make the same mistake. There is no info on any of the docs that say you need to "manually" semaphore access to the db file. I guess this means that only 1 script can access the db at 1 time, which means slow. *sigh* I wish I could use a real DB. ------------------------------------------------------------------------ [2002-09-09 17:12:39] sniper@php.net There can only be one writer at the time. This really isn't bug in PHP..just do what Wez proposed. (use the semaphores) ------------------------------------------------------------------------ [2002-09-09 15:10:24] wboring@qualys.com Ok So I modified the dba_gdbm.c's dba_open call to output a little debugging information if(dbf) { info->dbf = malloc(sizeof(dba_gdbm_data)); memset(info->dbf, 0, sizeof(dba_gdbm_data)); ((dba_gdbm_data *) info->dbf)->dbf = dbf; php_error(E_WARNING, "gdbm_open worked, %s\n", gdbm_strerror(gdbm_errno)); return SUCCESS; } else { php_error(E_WARNING, "gdbm_open failed %s\n", gdbm_strerror(gdbm_errno)); return FAILURE; } The error I am always getting is PHP Warning: gdbm_open failed Can't be writer from the gdbm_open call. ------------------------------------------------------------------------ [2002-09-09 14:55:10] wez@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. If PHP really is bailing out when dba_open fails, we need a backtrace to be able to determine the cause. However, from what you describe, I don't think that this crash is actually the cause of your problem - it's a side-effect... dba works by passing the calls through to your dbm style library. Since the default for gdbm is to open the db in locking mode (and that's what we're using), it sounds like this is either an issue with gdbm itself or perhaps even with your kernel. It's doesn't say anywhere in the docs for gdbm that multiple writers will block when accessing the database, so I would expect to get those intermittent errors you reported. (not a bug). So it seems that you need to manually ensure that writers will block - rather than use flock to protect your db, try using a semaphore from the sysvsem extension (much more reliable). Other things to try are upgrading (or perhaps downgrading) your gdbm installation and see if that makes a difference. (See if there are any known issues with gdbm too). --Wez. ------------------------------------------------------------------------ [2002-09-09 12:24:59] wboring@qualys.com I just did a diff on ext/dba_gdbm.c between php 4.2.2 and php 4.2.3 and php in cvs, and there is no difference. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19077 -- Edit this bug report at http://bugs.php.net/?id=19077&edit=1

« previous php.bugs (#18868) next »