Hello,
I am noticing a strange effect in php-4.3.5RC1 while using
dba_open("name", "c", "db4") -- this used to work in php-4.3.3
(I have both libphp4.so versions and can switch between them)
but it fails in php-4.3.5RC1 with the error message:
Warning: dba_open(...,c):
Driver initialization failed for handler: db4: Unable to establish lock
(no matter if I use "c", "cd" or "ct" for the flags). The only
possibility to get it working is by using "c-" for $flags.
Note that in ext/dba/dba_db4.c, I see some clues about a
db4-internal locking:
--snip--dba_db4.c::DBA_OPEN_FUNC(db4)
#ifdef DB_FCNTL_LOCKING
gmode |= DB_FCNTL_LOCKING;
#endif
--snip--
so I tried to change the handler[] for db4 to:
--snip--dba.c::handler[]
#if DBA_DB4
#ifdef DB_FCNTL_LOCKING
DBA_HND(db4, DBA_LOCK_EXT) /* Locking done in library if set /
#else
DBA_HND(db4, DBA_LOCK_ALL) / No lock in lib */
#endif
#endif
--snip--
but that doesn't change the observed behaviour.
Is it my error, or is something really broken in php-4.3.5RC1?
Martin
Martin.Kraemer@Fujitsu-Siemens.com | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Hello Martin,
Thursday, January 15, 2004, 6:08:31 PM, you wrote:
Hello,
I am noticing a strange effect in php-4.3.5RC1 while using
dba_open("name", "c", "db4") -- this used to work in php-4.3.3
(I have both libphp4.so versions and can switch between them)
but it fails in php-4.3.5RC1 with the error message:
Warning: dba_open(...,c):
Driver initialization failed for handler: db4: Unable to establish lock
(no matter if I use "c", "cd" or "ct" for the flags). The only
possibility to get it working is by using "c-" for $flags.
Note that in ext/dba/dba_db4.c, I see some clues about a
db4-internal locking:
--snip--dba_db4.c::DBA_OPEN_FUNC(db4)
#ifdef DB_FCNTL_LOCKING
gmode |= DB_FCNTL_LOCKING;
#endif
--snip--
so I tried to change the handler[] for db4 to:
--snip--dba.c::handler[]
#if DBA_DB4
#ifdef DB_FCNTL_LOCKING
DBA_HND(db4, DBA_LOCK_EXT) /* Locking done in library if set /
#else
DBA_HND(db4, DBA_LOCK_ALL) / No lock in lib */
#endif
#endif
--snip--
but that doesn't change the observed behaviour.
Is it my error, or is something really broken in php-4.3.5RC1?
Nice idea but DB_FCNTL_LOCKING has a different meaning. It says go use the
lock that is already set from the process. And it does not mean do create a
lock.
What version of db4 do you have? Is it compiled by your own? are you using a
dba.so? Are you testing on a standard linux fs (extfs3) or what?
--
Best regards,
Marcus mailto:helly@php.net
Is it my error [..]?
Nice idea but DB_FCNTL_LOCKING has a different meaning. It says go use the
lock that is already set from the process. And it does not mean do create a
lock.
Thanks for the hint.
What version of db4 do you have? Is it compiled by your own? are you using a
dba.so? Are you testing on a standard linux fs (extfs3) or what?
I am using libdb 4.0.14 (compiled statically, linked with Apache, so
libphp4.so (both version) use the same lib).
dba is linked into the libphp4.so, so no more dynamic loading is involved.
I did a "cvs annotate" of the dba.c code and saw no changes since 2002
around the place where the error is reported. I'll have to redo that
for dba_db4.c because it looks like the same error is happening with
php-5.0.0b2 (I am currently configuring...).
Well, about the machine, it's an EBCDIC-based mainframe on which I am
currently porting the EBCDIC changes which were present in php3 but
got lost in php4, so it may of course be related to that.
Strange to me is the fact that 4.3.3 behaves so much differenty from
4.3.5RC1++ -- but as I said, I'll have a glimpse at "cvs ann".
I'll report when I found anything.
Martin
Martin.Kraemer@Fujitsu-Siemens.com | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Hello Martin,
Thursday, January 15, 2004, 9:19:01 PM, you wrote:
Is it my error [..]?
Nice idea but DB_FCNTL_LOCKING has a different meaning. It says go use the
lock that is already set from the process. And it does not mean do create a
lock.
Thanks for the hint.
What version of db4 do you have? Is it compiled by your own? are you using a
dba.so? Are you testing on a standard linux fs (extfs3) or what?
I am using libdb 4.0.14 (compiled statically, linked with Apache, so
libphp4.so (both version) use the same lib).
dba is linked into the libphp4.so, so no more dynamic loading is involved.
I did a "cvs annotate" of the dba.c code and saw no changes since 2002
around the place where the error is reported. I'll have to redo that
for dba_db4.c because it looks like the same error is happening with
php-5.0.0b2 (I am currently configuring...).
Well, about the machine, it's an EBCDIC-based mainframe on which I am
currently porting the EBCDIC changes which were present in php3 but
got lost in php4, so it may of course be related to that.
Strange to me is the fact that 4.3.3 behaves so much differenty from
4.3.5RC1++ -- but as I said, I'll have a glimpse at "cvs ann".
I'll report when I found anything.
Could you please update your php to current cvs version (PHP4.3.5RC1-dev and
PHP5-dev). Also if that doesn't help you could update db4 to db4>=4.1.25 and
test with db3 or db2 version. And what is the output of
"php run-tests.php ext/dba"?
--
Best regards,
Marcus mailto:helly@php.net
I'll report when I found anything.
Could you please update your php to current cvs version (PHP4.3.5RC1-dev and
PHP5-dev). Also if that doesn't help you could update db4 to db4>=4.1.25 and
test with db3 or db2 version. And what is the output of
"php run-tests.php ext/dba"?
I have upgraded to db4.1.25 and now the locking problems have vanished.
The output of php run-tests.php ext/dba follows:
env TEST_PHP_EXECUTABLE=$cwd/sapi/cli/php sapi/cli/php run-tests.php ext/dba
=====================================================================
CWD : /home/openis/cache/tmp/php-4.3.5RC1
PHP : /home/martin/SRC/plusCD/work/php-4.3.5RC1/sapi/cli/php
PHP_SAPI : cli
PHP_VERSION : 4.3.5RC1
ZEND_VERSION: 1.3.0
PHP_OS : POSIX-BC - POSIX-BC S130he12.mch.fsc.net 04.0A A35 BS2000
INI actual :
More .INIs :
Extra dirs :
Running selected tests.
PASS DBA CDB handler test [ext/dba/tests/dba_cdb.phpt] (info: CDB does not support replace or delete)
FAIL DBA CDB_MAKE handler test [ext/dba/tests/dba_cdb_make.phpt] (info: CDB_MAKE does not support reading)
FAIL DBA CDB handler test (read only) [ext/dba/tests/dba_cdb_read.phpt]
SKIP DBA DBM handler test [ext/dba/tests/dba_dbm.phpt] (reason: DBM handler not available)
SKIP DBA DB2 handler test [ext/dba/tests/dba_db2.phpt] (reason: DB2 handler not available)
SKIP DBA DB3 handler test [ext/dba/tests/dba_db3.phpt] (reason: DB3 handler not available)
PASS DBA DB4 handler test [ext/dba/tests/dba_db4.phpt]
PASS DBA FlatFile handler test [ext/dba/tests/dba_flatfile.phpt]
PASS DBA GDBM handler test [ext/dba/tests/dba_gdbm.phpt]
PASS DBA INIFILE handler test [ext/dba/tests/dba_inifile.phpt]
SKIP DBA NDBM handler test [ext/dba/tests/dba_ndbm.phpt] (reason: NDBM handler not available)
PASS DBA File Creation Test [ext/dba/tests/dba001.phpt] (info: FLATFILE handler used)
PASS DBA Insert/Fetch Test [ext/dba/tests/dba002.phpt] (info: FLATFILE handler used)
PASS DBA Insert/Replace/Fetch Test [ext/dba/tests/dba003.phpt] (info: FLATFILE handler used)
PASS DBA Multiple Insert/Fetch Test [ext/dba/tests/dba004.phpt] (info: FLATFILE handler used)
PASS DBA FirstKey/NextKey Loop Test With 5 Items [ext/dba/tests/dba005.phpt] (info: FLATFILE handler used)
PASS DBA FirstKey/NextKey with 2 deletes [ext/dba/tests/dba006.phpt] (info: FLATFILE handler used)
PASS DBA Multiple File Creation Test [ext/dba/tests/dba007.phpt] (info: FLATFILE handler used)
PASS DBA magic_quotes_runtime Test [ext/dba/tests/dba008.phpt] (info: FLATFILE handler used)
PASS DBA dba_popen Test [ext/dba/tests/dba009.phpt] (info: FLATFILE handler used)
So, as I understand it, the problem went away by replacing db-4.0.14
by db-4.1.25. But isn't it going to bite other db4 users?
Strange however that php-4.3.3 did not experience these problems.
Martin
Martin.Kraemer@Fujitsu-Siemens.com | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Hello Martin,
thanks for prooving my thoughts. What should i say other than the module is
far too complex and allows far too many combinations so that as a
consequence a lot of them don't work. Most of the non working combinations
are inherent problems we cannot solve. The most common is the problem of
name clashes in the external libs. And i don't want to search for all
failing combinations that would be an endless story. Does this make you feel
more comfortable in any way?
marcus
Friday, January 23, 2004, 10:16:37 AM, you wrote:
I'll report when I found anything.
Could you please update your php to current cvs version (PHP4.3.5RC1-dev and
PHP5-dev). Also if that doesn't help you could update db4 to db4>=4.1.25 and
test with db3 or db2 version. And what is the output of
"php run-tests.php ext/dba"?
I have upgraded to db4.1.25 and now the locking problems have vanished.
The output of php run-tests.php ext/dba follows:
env TEST_PHP_EXECUTABLE=$cwd/sapi/cli/php sapi/cli/php run-tests.php ext/dba
=====================================================================
CWD : /home/openis/cache/tmp/php-4.3.5RC1
PHP : /home/martin/SRC/plusCD/work/php-4.3.5RC1/sapi/cli/php
PHP_SAPI: cli
PHP_VERSION: 4.3.5RC1
ZEND_VERSION: 1.3.0
PHP_OS: POSIX-BC - POSIX-BC S130he12.mch.fsc.net 04.0A A35 BS2000
INI actual :
More .INIs :
Extra dirs :Running selected tests.
PASS DBA CDB handler test [ext/dba/tests/dba_cdb.phpt] (info: CDB does not support replace or delete)
FAIL DBA CDB_MAKE handler test [ext/dba/tests/dba_cdb_make.phpt] (info: CDB_MAKE does not support reading)
FAIL DBA CDB handler test (read only) [ext/dba/tests/dba_cdb_read.phpt]
SKIP DBA DBM handler test [ext/dba/tests/dba_dbm.phpt] (reason: DBM handler not available)
SKIP DBA DB2 handler test [ext/dba/tests/dba_db2.phpt] (reason: DB2 handler not available)
SKIP DBA DB3 handler test [ext/dba/tests/dba_db3.phpt] (reason: DB3 handler not available)
PASS DBA DB4 handler test [ext/dba/tests/dba_db4.phpt]
PASS DBA FlatFile handler test [ext/dba/tests/dba_flatfile.phpt]
PASS DBA GDBM handler test [ext/dba/tests/dba_gdbm.phpt]
PASS DBA INIFILE handler test [ext/dba/tests/dba_inifile.phpt]
SKIP DBA NDBM handler test [ext/dba/tests/dba_ndbm.phpt] (reason: NDBM handler not available)
PASS DBA File Creation Test [ext/dba/tests/dba001.phpt] (info: FLATFILE handler used)
PASS DBA Insert/Fetch Test [ext/dba/tests/dba002.phpt] (info: FLATFILE handler used)
PASS DBA Insert/Replace/Fetch Test [ext/dba/tests/dba003.phpt] (info: FLATFILE handler used)
PASS DBA Multiple Insert/Fetch Test [ext/dba/tests/dba004.phpt] (info: FLATFILE handler used)
PASS DBA FirstKey/NextKey Loop Test With 5 Items
[ext/dba/tests/dba005.phpt] (info: FLATFILE handler used)
PASS DBA FirstKey/NextKey with 2 deletes [ext/dba/tests/dba006.phpt] (info: FLATFILE handler used)
PASS DBA Multiple File Creation Test [ext/dba/tests/dba007.phpt] (info: FLATFILE handler used)
PASS DBA magic_quotes_runtime Test [ext/dba/tests/dba008.phpt] (info: FLATFILE handler used)
PASS DBA dba_popen Test [ext/dba/tests/dba009.phpt] (info: FLATFILE handler used)
So, as I understand it, the problem went away by replacing db-4.0.14
by db-4.1.25. But isn't it going to bite other db4 users?
Strange however that php-4.3.3 did not experience these problems.
Martin
--
Best regards,
Marcus mailto:helly@php.net
Hello Martin,
thanks for prooving my thoughts. What should i say other than the module is
far too complex and allows far too many combinations so that as a
consequence a lot of them don't work. Most of the non working combinations
are inherent problems we cannot solve. [...]
So, as I understand it, the problem went away by replacing db-4.0.14
by db-4.1.25. But isn't it going to bite other db4 users?
Maybe it could be added to a README somewhere...?!
Martin
Martin.Kraemer@Fujitsu-Siemens.com | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany