php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #51278 Crash when using reopened persistent connection after one resource closed
Submitted: 2010-03-12 01:17 UTC Modified: 2013-05-16 19:02 UTC
Votes:5
Avg. Score:3.4 ± 0.8
Reproduced:5 of 5 (100.0%)
Same Version:1 (20.0%)
Same OS:4 (80.0%)
From: christopher dot jones at oraclel dot com Assigned:
Status: Duplicate Package: DBM/DBA related
PHP Version: 5.3SVN-2010-03-12 (SVN) OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: christopher dot jones at oraclel dot com
New email:
PHP Version: OS:

 

 [2010-03-12 01:17 UTC] christopher dot jones at oraclel dot com 
Description:
------------
Do two dba_popen() calls using the same file.  Close one resource with 
dba_close(). Then do a dba_fetch on the still open resource.  This results in a 
crash in flatfile_findkey() with a NULL dba pointer.

Program received signal SIGSEGV, Segmentation fault.
0x0817c3b4 in flatfile_findkey (dba=0x0, key_datum=...) at 
/home/cjones/phpsrc/php/php-
src/branches/PHP_5_3/ext/dba/libflatfile/flatfile.c:173
(gdb) bt
#0  0x0817c3b4 in flatfile_findkey (dba=0x0, key_datum=...) at 
/home/cjones/phpsrc/php/php-
src/branches/PHP_5_3/ext/dba/libflatfile/flatfile.c:173
#1  0x0817bfaa in flatfile_fetch (dba=0x0, key_datum=...) at 
/home/cjones/phpsrc/php/php-
src/branches/PHP_5_3/ext/dba/libflatfile/flatfile.c:91
#2  0x0817a671 in dba_fetch_flatfile (info=0x89abb20, key=0x897b2bc "key1", 
keylen=4, skip=0, newlen=0xbfffd348) at /home/cjones/phpsrc/php/php-
src/branches/PHP_5_3/ext/dba/dba_flatfile.c:70
#3  0x0817871b in zif_dba_fetch (ht=2, return_value=0x897a638, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at 
/home/cjones/phpsrc/php/php-src/branches/PHP_5_3/ext/dba/dba.c:1025
#4  0x0844ccf0 in zend_do_fcall_common_helper_SPEC (execute_data=0x89abcc8) at 
/home/cjones/phpsrc/php/php-src/branches/PHP_5_3/Zend/zend_vm_execute.h:313
#5  0x084507ae in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x89abcc8) at 
/home/cjones/phpsrc/php/php-src/branches/PHP_5_3/Zend/zend_vm_execute.h:1603
#6  0x0844c38d in execute (op_array=0x897ac98) at /home/cjones/phpsrc/php/php-
src/branches/PHP_5_3/Zend/zend_vm_execute.h:104
#7  0x0841ff12 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at 
/home/cjones/phpsrc/php/php-src/branches/PHP_5_3/Zend/zend.c:1194
#8  0x083b6c16 in php_execute_script (primary_file=0xbffff7c4) at 
/home/cjones/phpsrc/php/php-src/branches/PHP_5_3/main/main.c:2260
#9  0x084dd733 in main (argc=2, argv=0xbffff954) at /home/cjones/phpsrc/php/php-
src/branches/PHP_5_3/sapi/cli/php_cli.c:1192

Test script:
---------------
See ext/dba/tests/dba015.phpt

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-05-06 23:32 UTC] cjashfor at linux dot vnet dot ibm dot com 
Shouldn't someone at least be assigned to fix this bug?  I reported what appears to be an identical bug - 61390 - and it was closed after just a small amount of discussion from the developers, followed by inactivity.
 [2013-05-16 19:02 UTC] aharvey@php.net
-Status: Open +Status: Duplicate
 [2013-05-16 19:02 UTC] aharvey@php.net 
I'll close this in favour of bug #61390, since it has more detail. I'll reopen that one momentarily.

I don't see assigning a bug to someone at random as being particularly helpful (as #61390 shows, in fact): what's really needed here is a patch or pull request. If someone with php-src karma knowledgeable about dba had time to fix this, I'm sure they would.
 [2013-05-16 19:02 UTC] aharvey@php.net 
Related To: Bug #61390
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Nov 24 01:01:29 2024 UTC