Bug #20201 Segmentation fault on maxdb_query in PHP
Submitted: 1 Jun 2006 13:17 Modified: 22 Nov 2006 8:38
Reporter: [ name withheld ] Email Updates:
Status: No Feedback Impact on me:
None 
Category:MaxDB Severity:S1 (Critical)
Version:7.6.00.27 OS:Linux (Linux)
Assigned to: CPU Architecture:Any

[1 Jun 2006 13:17] [ name withheld ]
Description:
Hello!

I have troubles with your MaxDB SQLDBC library. PHP segfaults on maxdb_query, but not on all queries. Most of all queries are executed fine.

PHP 5.1.4

backtrace

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1082918144 (LWP 22263)]
0x401cc47a in IFR_ErrorHndl::clear () from /opt/sdb/programs/lib/libSQLDBC_C.so
(gdb) bt
#0  0x401cc47a in IFR_ErrorHndl::clear () from /opt/sdb/programs/lib/libSQLDBC_C.so
#1  0x4017e47a in IFR_ResultSet::close () from /opt/sdb/programs/lib/libSQLDBC_C.so
#2  0x40112da2 in SQLDBC::SQLDBC_ResultSet::close () from /opt/sdb/programs/lib/libSQLDBC_C.so
#3  0x4010f4dd in SQLDBC_ResultSet_close () from /opt/sdb/programs/lib/libSQLDBC_C.so
#4  0x08133ba0 in zif_maxdb_free_result (ht=1, return_value=0x87a88d4, return_value_ptr=0x0,
    this_ptr=0x0, return_value_used=0) at /tmp/php-5.1.4/ext/maxdb/php_maxdb.c:5413
#5  0x0829016b in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffc9e0)
    at zend_vm_execute.h:200
#6  0x0828fa49 in execute (op_array=0x87a38dc) at zend_vm_execute.h:92
#7  0x0828ff63 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffcab0)
    at zend_vm_execute.h:234
#8  0x0828fa49 in execute (op_array=0x87a376c) at zend_vm_execute.h:92
#9  0x0826eaa1 in zend_call_function (fci=0xbfffcc00, fci_cache=0xbfffcbe0)
    at /tmp/php-5.1.4/Zend/zend_execute_API.c:938
#10 0x08287754 in zend_call_method (object_pp=0xbfffcc8c, obj_ce=0x87a873c, fn_proxy=0x87a882c,
    function_name=0x849a8ac "__destruct", function_name_len=10, retval_ptr_ptr=0x0,
    param_count=142038348, arg1=0x0, arg2=0x0) at /tmp/php-5.1.4/Zend/zend_interfaces.c:88
#11 0x0828b904 in zend_objects_destroy_object (object=0x8789184, handle=142038348)
    at /tmp/php-5.1.4/Zend/zend_objects.c:98
#12 0x0828e1ef in zend_objects_store_del_ref (zobject=0x87a2c1c)
    at /tmp/php-5.1.4/Zend/zend_objects_API.c:166
#13 0x0827720f in _zval_dtor_func (zvalue=0x87a2c1c) at /tmp/php-5.1.4/Zend/zend_variables.c:52
#14 0x0826dd89 in _zval_ptr_dtor (zval_ptr=0x8789118) at zend_variables.h:35
#15 0x0827fd79 in zend_hash_clean (ht=0x87752b4) at /tmp/php-5.1.4/Zend/zend_hash.c:547
#16 0x0828fff6 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffd320)
    at zend_vm_execute.h:255
#17 0x0828fa49 in execute (op_array=0x8770fdc) at zend_vm_execute.h:92
#18 0x08278b4a in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /tmp/php-5.1.4/Zend/zend.c:1109
#19 0x08242dfd in php_execute_script (primary_file=0xbffff720) at /tmp/php-5.1.4/main/main.c:1732
#20 0x082da4c9 in main (argc=2, argv=0xbffff7f4) at /tmp/php-5.1.4/sapi/cli/php_cli.c:1092

How to repeat:
Try to use maxdb_query with different queries.
In most of cases it works fine, but in some case it segfaults.
Maybe it's a buggy combinations of requests or something else. 

I've used it within php-class. Maybe it helps.
[1 Jun 2006 17:24] C.J. Adams-Collier
Hey there!

Can you start by giving me the query you are issuing?  It would be great if you could create a very simple .php script to exercise the bug.  Just enough to cause the segfault.

Thanks!

C.J.
[2 Jun 2006 11:38] [ name withheld ]
Try to use maxdb_free_result 2 times and one of them should be in class destructor. For ex.:

class A
{
  private $res;

  function __destruct()
  {
    $this->do_something();
  }

  function do_something()
  {
    if ($this->res)
       maxdb_free_result($res);
  }
}

$b = new A();
$b->do_something();

We fixed this by adding   $this->res = null  after maxdb_free_result();
[22 Oct 2006 8:38] Valeriy Kravchuk
Please, try to repeat with a newer version, 7.6.00.34, and inform about the results.
[23 Nov 2006 0:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".