Everything

php

Home » Project » Newsgroups » php.internals » Re: PHP 4.3.5RC1 and dba(db4) »

Re: PHP 4.3.5RC1 and dba(db4)

php.internals

Martin Kraemer

22 years ago

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

Marcus Börger

22 years ago

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

Martin Kraemer

22 years ago

On Thu, Jan 15, 2004 at 08:39:58PM +0100, Marcus Boerger 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.

Martin

--
<Martin.Kraemer@Fujitsu-Siemens.com>         |     Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730  Munich,  Germany

Marcus Börger

22 years ago

Hello Martin,

Thursday, January 15, 2004, 9:19:01 PM, you wrote:

> On Thu, Jan 15, 2004 at 08:39:58PM +0100, Marcus Boerger 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

Martin Kraemer

22 years ago

On Thu, Jan 15, 2004 at 10:33:38PM +0100, Marcus Boerger 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

--
<Martin.Kraemer@Fujitsu-Siemens.com>         |     Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730  Munich,  Germany

Marcus Börger

22 years ago

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:

> On Thu, Jan 15, 2004 at 10:33:38PM +0100, Marcus Boerger 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

Martin Kraemer

22 years ago

On Fri, Jan 23, 2004 at 07:18:33PM +0100, Marcus Boerger wrote:

> 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