|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #25099 DBA extension with DB2 handler crashing Apache
Submitted: 2003-08-15 12:37 UTC Modified: 2003-08-17 05:10 UTC
From: nathan at inimit dot com Assigned: helly (profile)
Status: Wont fix Package: DBM/DBA related
PHP Version: 4.3.2 OS: RedHat 7.2
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: nathan at inimit dot com
New email:
PHP Version: OS:


 [2003-08-15 12:37 UTC] nathan at inimit dot com
When running the code below which uses the DBA extension and the DB2 handler, I have run across a problem which is replicable using the code below that causes a segfault in Apache. When I run the script via CLI, the code seems to work fine and no errors are produced. I have added the "-" on the last part of the flag due to the file locking mechanism described in a previous bug.

Server version: Apache/1.3.27 (Unix)  (Red-Hat/Linux)
Server built:   Oct 23 2002 14:52:50
Server's Module Magic Number: 19990320:13
Server compiled with....
 -D EAPI_MM_CORE_PATH="/var/run/"
 -D HTTPD_ROOT="/etc/httpd"
 -D SUEXEC_BIN="/usr/sbin/suexec"
 -D DEFAULT_PIDLOG="/var/run/"
 -D DEFAULT_SCOREBOARD="/var/run/httpd.scoreboard"
 -D DEFAULT_LOCKFILE="/var/run/httpd.lock"
 -D DEFAULT_ERRORLOG="/var/log/httpd/error_log"
 -D TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"
 -D ACCESS_CONFIG_FILE="conf/access.conf"
 -D RESOURCE_CONFIG_FILE="conf/srm.conf"

PHP 4.3.2 Configure Options:

ldd /usr/src/redhat/SOURCES/php-4.3.2/sapi/cli/php => /lib/ (0x4001b000) => /lib/ (0x40049000) => /usr/lib/ (0x4005e000) => /usr/lib/ (0x4007d000) => /usr/lib/ (0x40082000) => /usr/lib/ (0x4009c000) => /usr/lib/ (0x400a3000) => /usr/lib/ (0x400a6000) => /lib/i686/ (0x400e9000) => /lib/i686/ (0x42000000) => /usr/lib/ (0x4010b000) => /usr/lib/ (0x4010f000) => /usr/lib/ (0x4014d000) => /usr/lib/ (0x40176000) => /usr/lib/ (0x40198000) => /usr/lib/ (0x401a6000) => /usr/lib/ (0x401c4000) => /usr/lib/ (0x40200000) => /lib/ (0x40210000) => /lib/ (0x4023e000) => /lib/ (0x40302000) => /lib/ (0x40313000) => /usr/lib/ (0x40316000)
        /lib/ => /lib/ (0x40000000)

Reproduce code:
$file = '/tmp/dba_open.test';

// check to see whether to create the file or update
$flag = (file_exists($file)) ? 'w-' : 'c-';

$dba = dba_open($file, $flag, 'db2');

if (!$dba) {
        die('no connection');
} else {
	dba_insert('key-'.substr(time(), -3), 'test-'.time(), $dba);

Expected result:
When running the code above there is no expected output, but rather a new file to be created in the /tmp directory based on the DB2 handler and if the file exists from a previous execution then new row to be inserted .

Actual result:
When ran via CLI, the code above works perfectly fine. When the script is attempted to be loaded in Apache, the child proc dies.

> gdb /usr/sbin/httpd
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x4036b642 in __db_calloc () from /usr/lib/
#2  0x4036481d in db_open () from /usr/lib/
#3  0x40583b84 in dba_open_db2 (info=0x810bfd4, error=0xbfffc944) at 
#4  0x40582941 in php_dba_open (ht=3, return_value=0x819466c, this_ptr=0x0, return_value_used=1, persistent=0)
    at /usr/src/redhat/SOURCES/php-4.3.2/ext/dba/dba.c:606
#5  0x40582ae5 in zif_dba_open (ht=3, return_value=0x819466c, this_ptr=0x0, return_value_used=1)
    at /usr/src/redhat/SOURCES/php-4.3.2/ext/dba/dba.c:648
#6  0x4065fab8 in execute (op_array=0x815727c) at /usr/src/redhat/SOURCES/php-4.3.2/Zend/zend_execute.c:1606
#7  0x4064d5c4 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at 
#8  0x40626b4c in php_execute_script (primary_file=0xbffff640) at /usr/src/redhat/SOURCES/php-4.3.2/main/main.c:1671
#9  0x40667066 in apache_php_module_main (r=0x80fd818, display_source_mode=0)
    at /usr/src/redhat/SOURCES/php-4.3.2/sapi/apache/sapi_apache.c:54
#10 0x40667c42 in send_php (r=0x80fd818, display_source_mode=0, filename=0x0)
    at /usr/src/redhat/SOURCES/php-4.3.2/sapi/apache/mod_php4.c:617
#11 0x40667c96 in send_parsed_php (r=0x80fd818) at /usr/src/redhat/SOURCES/php-4.3.2/sapi/apache/mod_php4.c:632
#12 0x080547cd in ap_invoke_handler ()
#13 0x0806769c in process_request_internal ()
#14 0x08067713 in ap_process_request ()
#15 0x0805f867 in child_main ()
#16 0x0805fa0a in make_child ()
#17 0x0805fb4d in startup_children ()
#18 0x080601a0 in standalone_main ()
#19 0x08060aa3 in main ()
#20 0x42017589 in __libc_start_main () from /lib/i686/


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-08-17 00:44 UTC]
Note: there is also another crash when you have both gdbm and ndbm handlers enabled and you use the ndbm handler in the above mentioned script. Backtrace as follows:

0x40d9a6c8 in gdbm_store () from /usr/lib/
(gdb) bt
#0  0x40d9a6c8 in gdbm_store () from /usr/lib/
#1  0x40d99bcf in dbm_store () from /usr/lib/
#2  0x80d1b4f in dba_update_ndbm (info=0x874f8b4, key=0x874fad4 "key-020", keylen=7, val=0x874f874 "test-1061099020", 
    vallen=15, mode=1) at /usr/src/web/php/php4_3/ext/dba/dba_ndbm.c:99
#3  0x80ce28f in php_dba_update (ht=3, return_value=0x874fb0c, this_ptr=0x0, return_value_used=0, mode=1)
    at /usr/src/web/php/php4_3/ext/dba/dba.c:480
#4  0x80d012c in zif_dba_insert (ht=3, return_value=0x874fb0c, this_ptr=0x0, return_value_used=0)
    at /usr/src/web/php/php4_3/ext/dba/dba.c:945

Some conflict with gdbm vs. ndbm funcs..

 [2003-08-17 05:10 UTC]
To even make it harder db2 comes into this conflict, too. Mandrake is a nice platform where all works fine, so it's clearly a problem of how the libs where build on those platforms and not our problem or a problem we could solve.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Sun May 28 16:03:40 2023 UTC