ID: 19077
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
