php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #24824 dba_ routines with ndbm crash
Submitted: 2003-07-26 20:40 UTC Modified: 2003-11-25 18:53 UTC
Votes:2
Avg. Score:4.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: php at johnlevine dot com Assigned: helly (profile)
Status: Wont fix Package: DBM/DBA related
PHP Version: 4.3.4 OS: BSD/OS 4.3.1
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: php at johnlevine dot com
New email:
PHP Version: OS:

 

 [2003-07-26 20:40 UTC] php at johnlevine dot com
Description:
------------
This program prints Resource handle #5, and then crashes.
It works OK in 4.2.2, crashes in a version of 4.3.0 I had
lying around.  It crashes in the Apache module, which is
where I first noticed it.

There also seems to be a change since 4.2 that it used to append .db to the file name but doesn't any more.

It's compiled --with-mysql --with-apxs --with-ndbm

(I know that ndbm is old and tired, but it's distributed
with BSD/OS and I have a lot of existing ndbm files that
I'm using.)


Reproduce code:
---------------
   $a = dba_popen("test.db", "r", "ndbm");
    print "handle is $a\n"; // prints Resource #5

    $k = dba_firstkey($a);
    print "key is $k\n"; // segfaults, see trace below


Expected result:
----------------
should print first key in db file


Actual result:
--------------
Segmentation violation:
#0  0x481b5f1d in dbm_firstkey () from /shlib/libc.so.2
#1  0x806486f in dba_firstkey_ndbm (info=0x81bdf00, newlen=0x8046070)
    at /home/src/php-4.3.2/ext/dba/dba_ndbm.c:126
#2  0x8063a74 in zif_dba_firstkey (ht=1, return_value=0x81bc68c, this_ptr=0x0, 
    return_value_used=1) at /home/src/php-4.3.2/ext/dba/dba.c:704
#3  0x8139bf3 in execute (op_array=0x81bb88c)
    at /home/src/php-4.3.2/Zend/zend_execute.c:1608
#4  0x812821e in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /home/src/php-4.3.2/Zend/zend.c:869
#5  0x8100275 in php_execute_script (primary_file=0x8047a94)
    at /home/src/php-4.3.2/main/main.c:1671
#6  0x814188e in main (argc=2, argv=0x8047afc)
    at /home/src/php-4.3.2/sapi/cli/php_cli.c:806
#7  0x8061843 in __start ()


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-07-27 10:10 UTC] iliaa@php.net
could you please provide the sample db, I am unabled to replicate the problem using a ndbm database that I have.
 [2003-07-27 11:22 UTC] php at johnlevine dot com
On my system, it crashes with any dbm file, even one with no
entries.
 [2003-07-27 11:27 UTC] helly@php.net
Please provide the outputs of the following two commands using CLI or CGI version of php:
1) php run-tests.php ext/dba
2) ldd php
 [2003-07-27 11:41 UTC] php at johnlevine dot com
tom:johnl:php-4.3.2$ TEST_PHP_EXECUTABLE=/usr/local/bin/php php run-tests.php ext/dba

=====================================================================
CWD         : /home/src/php-4.3.2
PHP         : /usr/local/bin/php 
PHP_SAPI    : cli
PHP_VERSION : 4.3.2
ZEND_VERSION: 1.3.0
PHP_OS      : BSD/OS
INI actual  : /usr/local/lib/php.ini
More .INIs  : 
Extra dirs  : 
=====================================================================
Running selected tests.
FAIL DBA File Creation Test [ext/dba/tests/dba001.phpt]
FAIL DBA Insert/Fetch Test [ext/dba/tests/dba002.phpt]
FAIL DBA Insert/Replace/Fetch Test [ext/dba/tests/dba003.phpt]
FAIL DBA Multiple Insert/Fetch Test [ext/dba/tests/dba004.phpt]
FAIL DBA FirstKey/NextKey Loop Test With 5 Items [ext/dba/tests/dba005.phpt]
FAIL DBA FirstKey/NextKey with 2 deletes [ext/dba/tests/dba006.phpt]
FAIL DBA Multiple File Creation Test [ext/dba/tests/dba007.phpt]
FAIL DBA magic_quotes_runtime Test [ext/dba/tests/dba008.phpt]
FAIL DBA dba_popen Test [ext/dba/tests/dba009.phpt]
FAIL DBA CDB handler test [ext/dba/tests/dba_cdb.phpt]
FAIL DBA CDB_MAKE handler test [ext/dba/tests/dba_cdb_make.phpt]
PASS DBA CDB handler test (read only) [ext/dba/tests/dba_cdb_read.phpt]
FAIL DBA DB2 handler test [ext/dba/tests/dba_db2.phpt]
FAIL DBA DB3 handler test [ext/dba/tests/dba_db3.phpt]
FAIL DBA DB4 handler test [ext/dba/tests/dba_db4.phpt]
FAIL DBA DBM handler test [ext/dba/tests/dba_dbm.phpt]
FAIL DBA FlatFile handler test [ext/dba/tests/dba_flatfile.phpt]
FAIL DBA GDBM handler test [ext/dba/tests/dba_gdbm.phpt]
FAIL DBA NDBM handler test [ext/dba/tests/dba_ndbm.phpt]
tom:johnl:php-4.3.2$ ldd /usr/local/bin/php                          
        libm.so => /shlib/libm.so.0.0 (0x48171000)
        libdl.so => /shlib/libdl.so (0x48182000)
        libgcc.so.1 => /shlib/libgcc.so.1 (0x48185000)
        libc.so.2 => /shlib/libc.so.2 (0x48191000)
 [2003-07-27 12:33 UTC] helly@php.net
The result should be impossible with normal builds. Did you compile your own libc or something like that?

Please execute: php -r 'echo print_r(dba_handlers());'

You could also provide me with your config.log per email but stick to the list for the rest.
 [2003-07-27 14:05 UTC] php at johnlevine dot com
All the system libraries are the standard ones.  We may have an arcane difference between BSD/OS and other BSDs, assuming we know this works on other BSDs.  I could try it on FreeBSD 4.8.

tom:johnl:php-4.3.2$ php -r 'echo print_r(dba_handlers());'
Array
(
    [0] => ndbm
    [1] => cdb
    [2] => cdb_make
    [3] => flatfile
)
 [2003-08-05 19:56 UTC] php at johnlevine dot com
It turns out on my system the ndbm is really a wrapper around the more recent Berkeley db that uses dbopen().

The problem seems to be that the ndbm library appends .db to file name, so if you open "foo", it really opens "foo.db".  There's a bunch of code in php_dba_open that distrusts ndbm's locking and tries to open the file and lock it, but that code doesn't know that the file is really called foo.db and gets confused.

The locking code is a mess.  If it's written down anywhere what it's supposed to do, I can probably come up with a simple patch or rewrite that will work anywhere.  The obvious question is why it tries to do its own lockf rather than use the one built into ndbm.
 [2003-08-06 02:40 UTC] helly@php.net
Because ndbm is a mess erm i mean sometimes a wrapper to this sometimes to that! So there's no reliable easy solution. And Berkley DB locking would involve an 'environment' which i don't want to create.

Feel free to find a solution your self. What ext/dba does is quite simple. It either locks the database file itself or a log file according to the flag given in dba_open(). And it does this reliable on all supported platforms.
 [2003-11-25 18:53 UTC] php at johnlevine dot com
I have a reasonably clean fix for my ndbm problem.  As far as I can tell, nobody uses ndbm any more, just the ndbm compatible interface to Berkeley DB (the original non
shareware version.) So I redid dba_ndbm.c so that if at compile time it can tell it's the compat version, which is easy to test by #ifdef, it calls the DB routines directly.
Otherwise it uses the old ndbm code.  I've tested it some, but since the calls to DB are almost the same as DB2 and DB3 only simpler, I expect that it will work the same as they do.
See http://www.iecc.com/php_ndbm.c for the updated source file.  The build process is the same, the #ifdef is entirely in this one file.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Sat Nov 28 14:01:23 2020 UTC