[PHP-BUG] Bug #61079 [NEW]: mysqli crashes when var_dump'ed while not connected
From: Operating system: Linux PHP version: 5.3SVN-2012-02-13 (SVN) Package: MySQLi related Bug Type: Bug Bug description:mysqli crashes when var_dump'ed while not connected Description: This creates a segfault: export USE_ZEND_ALLOC=0 php -n -r '$c = mysqli_init(); var_dump($c);' Backtrace: 0x76b0303e in mysql_stat () from /usr/lib/libmysqlclient.so.16 (gdb) bt #0 0x76b0303e in mysql_stat () from /usr/lib/libmysqlclient.so.16 #1 0x006a78a4 in link_stat_read (obj=0x148fc80, retval=0x7fffda98) at /home/derick/dev/php/php-src/branches/PHP_5_3/ext/mysqli/mysqli_prop.c:226 #2 0x0069567c in mysqli_read_property (object=0x148cf30, member=0x7fffdb30, type=3) at /home/derick/dev/php/php-src/branches/PHP_5_3/ext/mysqli/mysqli.c:339 #3 0x00695be6 in mysqli_object_get_debug_info (object=0x148cf30, is_temp=0x7fffdbc0) at /home/derick/dev/php/php-src/branches/PHP_5_3/ext/mysqli/mysqli.c:468 #4 0x0088f895 in php_var_dump (struc=0x77ea6148, level=1) at /home/derick/dev/php/php-src/branches/PHP_5_3/ext/standard/var.c:129 #5 0x0088fc32 in zif_var_dump (ht=1, return_value=0x148fcb0, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /home/derick/dev/php/php-src/branches/PHP_5_3/ext/standard/var.c:181 #6 0x0099a026 in zend_do_fcall_common_helper_SPEC (execute_data=0x77ea6030) at /home/derick/dev/php/php-src/branches/PHP_5_3/Zend/zend_vm_execute.h:320 #7 0x0099e4cf in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x77ea6030) at /home/derick/dev/php/php-src/branches/PHP_5_3/Zend/zend_vm_execute.h:1640 #8 0x009994ff in execute (op_array=0x148d8c0) at /home/derick/dev/php/php-src/branches/PHP_5_3/Zend/zend_vm_execute.h:107 #9 0x00956e22 in zend_eval_stringl (str=0x7fffe643 "$c = mysqli_init(); var_dump($c);", str_len=33, retval_ptr=0x0, string_name=0xf62b34 "Command line code") at /home/derick/dev/php/php-src/branches/PHP_5_3/Zend/zend_execute_API.c:1198 #10 0x00957060 in zend_eval_stringl_ex (str=0x7fffe643 "$c = mysqli_init(); var_dump($c);", str_len=33, retval_ptr=0x0, string_name=0xf62b34 "Command line code", handle_exceptions=1) at /home/derick/dev/php/php-src/branches/PHP_5_3/Zend/zend_execute_API.c:1240 #11 0x009570ef in zend_eval_string_ex (str=0x7fffe643 "$c = mysqli_init(); var_dump($c);", retval_ptr=0x0, string_name=0xf62b34 "Command line code", handle_exceptions=1) at /home/derick/dev/php/php-src/branches/PHP_5_3/Zend/zend_execute_API.c:1251 #12 0x00a48018 in main (argc=4, argv=0x7fffe358) at /home/derick/dev/php/php-src/branches/PHP_5_3/sapi/cli/php_cli.c:1223 Valgrind tracE: derick@whisky:~/dev/php/xdebug$ valgrind php -n -r '$c = mysqli_init(); var_dump($c);' ==26602== Memcheck, a memory error detector ==26602== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==26602== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==26602== Command: php -n -r $c\ =\ mysqli_init();\ var_dump($c); ==26602== Warning: var_dump(): Property access is not allowed yet in Command line code on line 1 Warning: var_dump(): Property access is not allowed yet in Command line code on line 1 Warning: var_dump(): Property access is not allowed yet in Command line code on line 1 Warning: var_dump(): Property access is not allowed yet in Command line code on line 1 Warning: var_dump(): Property access is not allowed yet in Command line code on line 1 Warning: var_dump(): Property access is not allowed yet in Command line code on line 1 Warning: var_dump(): Property access is not allowed yet in Command line code on line 1 ==26602== Invalid read of size 8 ==26602==at 0x5DA603E: mysql_stat (in /usr/lib/libmysqlclient.so.16.0.0) ==26602==by 0x6A78A3: link_stat_read (mysqli_prop.c:226) ==26602==by 0x69567B: mysqli_read_property (mysqli.c:339) ==26602==by 0x695BE5: mysqli_object_get_debug_info (mysqli.c:468) ==26602==by 0x88F894: php_var_dump (var.c:129) ==26602==by 0x88FC31: zif_var_dump (var.c:181) ==26602==by 0x99A025: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:320) ==26602==by 0x99E4CE: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1640) ==26602==by 0x9994FE: execute (zend_vm_execute.h:107) ==26602==by 0x956E21: zend_eval_stringl (zend_execute_API.c:1198) ==26602==by 0x95705F: zend_eval_stringl_ex (zend_execute_API.c:1240) ==26602==by 0x9570EE: zend_eval_string_ex (zend_execute_API.c:1251) ==26602== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==26602== ==26602== ==26602== Process terminating with default action of signal 11 (SIGSEGV) ==26602== Access not within mapped region at address 0x8 ==26602==at 0x5DA603E: mysql_stat (in /usr/lib/libmysqlclient.so.16.0.0) ==26602==by 0x6A78A3: link_stat_read (mysqli_prop.c:226) ==26602==by 0x69567B: mysqli_read_property (mysqli.c:339) ==2
Bug #64258 [PATCH]: --with-mcrypt causes bad linking (with --with-libxml-dir). Reason: -lltdl flag
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 Patch added by: der...@php.net Reported by:spamik at yum dot pl Summary:--with-mcrypt causes bad linking (with --with-libxml-dir). Reason: -lltdl flag Status: Open Type: Bug Package:*Compile Issues PHP Version:5.4.16 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: mcrypt-config-20130613 Revision: 1371113762 URL: https://bugs.php.net/patch-display.php?bug=64258&patch=mcrypt-config-20130613&revision=1371113762 Previous Comments: [2013-06-13 08:55:32] der...@php.net It's a linker helper library as used by gnu libtool. I have no idea why it messes the libxml include though, and as far as I know, that library is no longer needed since libmcrypt 2.5.4. So unless your version is that old, -lltdl should not be part of your Makefile. If I manually remove -lltdl from the Makefile, PHP still compiles and links, so I would recommend you try the following: cat /usr/include/mutils/mcrypt.h | grep VER And let me know what it says. Secondly, apply the attached patch to ext/mcrypt/config.m4 and then run: make clean ./buildconf --force ./config.nice make and see which libxml it now links too. [2013-06-13 00:57:01] spamik at yum dot pl root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 && make root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml libxml2.so.2 => /usr/libxml2-2.9.0/lib/libxml2.so.2 (0x7f6b2c098000) root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 -- with-mcrypt && make root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x7f1478692000) When configured with mcrypt Makefile has EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lmcrypt -lltdl -lrt -lm -ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt - lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt when configured without mcrypt Makefile has EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm - lxml2 -lz -lm -lxml2 -lz -lm -lcrypt problem seems to be caused by flag -lltdl. When removed manualy, libxml2 is liked ok. What is this flag? [2013-06-12 20:58:07] spamik at yum dot pl or better I'll put in into to compile issues... [2013-06-12 20:56:32] spamik at yum dot pl changing to mcrypt package. Maybe more devs there will be more active. [2013-06-12 20:53:47] spamik at yum dot pl Problem is still not addressed. root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml libxml2.so.2 => /usr/libxml2-2.9.0/lib/libxml2.so.2 (0x7f6b2c098000) root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 -- with-mcrypt root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php:
[PHP-BUG] Bug #1 [Com]: Apache 1.3b3 + mod_php3 is slow
Edit report at http://bugs-beta.php.net//bug.php?id=1&edit=1 ID: 1 Comment by: der...@php.net Reported by: rasmus at lerdorf dot on dot ca Summary: Apache 1.3b3 + mod_php3 is slow Status: Closed Type: Bug Package: Performance problem Operating System: Solaris 2.5.1 PHP Version: 3.0b3 New Comment: testing II Previous Comments: [2010-03-01 20:20:57] der...@php.net testing. [2009-05-22 09:27:28] j...@php.net test [1998-01-25 11:06:03] rasmus at lerdorf dot on dot ca When PHP3 is linked into Apache 1.3b3 on Solaris 2.5.1 the web server becomes extremely sluggish or won't answer requests at all. -- Edit this bug report at http://bugs-beta.php.net//bug.php?id=1&edit=1
[PHP-BUG] Bug #55673 [NEW]: Compiler creates (unused) compiled variables for self::$foo
From: derick Operating system: * PHP version: 5.3SVN-2011-09-12 (SVN) Package: Scripting Engine problem Bug Type: Bug Bug description:Compiler creates (unused) compiled variables for self::$foo Description: When having the following code: The compiler generates compiled variable !0 for $bar, even though it's a class variable: derick@whisky:/tmp$ php -dvld.active=1 -r 'class foo { function bar() { self::$bar = 42; } }' Finding entry points Branch analysis from position: 0 Return found filename: Command line code function name: (null) number of ops: 2 compiled vars: none line # * op fetch ext return operands - 1 0 > NOP 1> RETURN null branch: # 0; line: 1-1; sop: 0; eop: 1 path #1: 0, Class foo: Function bar: Finding entry points Branch analysis from position: 0 Return found filename: Command line code function name: bar number of ops: 4 compiled vars: !0 = $bar line # * op fetch ext return operands - 0 > ZEND_FETCH_CLASS 1 1 FETCH_W static member $1 'bar' 2 ASSIGN $1, 42 3> RETURN null branch: # 0; line: 1-1; sop: 0; eop: 3 path #1: 0, End of function bar. End of class foo. 14:41 <@Derick> dmitry: I am wondering why self::$foo creates a compiled variable. Any idea? 14:42 <@Derick> dmitry: it creates it, but it's never used 14:44 <@dmitry> I see. It's probably because od simple one-pass compiler that first interpret $foo as local variable and only then as a class variable :) 14:44 <@Derick> dmitry: any way we can fix that perhaps? 14:44 <@dmitry> Derick: could you please create a bug and assign it to me 14:44 <@Derick> yes, sure -- Edit bug report at https://bugs.php.net/bug.php?id=55673&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55673&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55673&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55673&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55673&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55673&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55673&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55673&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55673&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55673&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55673&r=support Expected behavior: https://bugs.php.net/fix.php?id=55673&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55673&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55673&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55673&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55673&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55673&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55673&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55673&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55673&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55673&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55673&r=mysqlcfg
[PHP-BUG] Bug #63486 [NEW]: mysqli_free_result leave the resource variable in a messy state
From: der...@php.net Operating system: PHP version: 5.4.8 Package: MySQLi related Bug Type: Bug Bug description:mysqli_free_result leave the resource variable in a messy state Description: An Xdebug user filed the following report: http://bugs.xdebug.org/view.php?id=900 I've just investigated this, and found out that this is something I can't fix in Xdebug. mysqli_free_result() destroys the internal object, but leaves the resource (in your case, $rs) in a silly state. All Xdebug does internally is basically a var_dump( $rs ), and after it is freed with mysqli_free_result(), that throws exactly the same error (without Xdebug). This can however, easily be fixed in the MySQLi extension with the attached patch. The patch applies to PHP 5.4, but this also a problem in master and PHP 5.3. It is also possible, that other mysqli_free_* functions can benefit from a similar construct. Test script: --- Expected result: The expected result is perhaps something like "NULL" (which my patch makes it do). Actual result: -- hi mom Warning: var_dump(): Couldn't fetch mysqli_result in /home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10 Call Stack: 0.0002 662616 1. {main}() /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0 0.0032 672792 2. var_dump(class mysqli_result { public $current_field = NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows = NULL; public $type = NULL }) /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10 Warning: var_dump(): Couldn't fetch mysqli_result in /home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10 Call Stack: 0.0002 662616 1. {main}() /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0 0.0032 672792 2. var_dump(class mysqli_result { public $current_field = NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows = NULL; public $type = NULL }) /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10 Warning: var_dump(): Property access is not allowed yet in /home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10 Call Stack: 0.0002 662616 1. {main}() /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0 0.0032 672792 2. var_dump(class mysqli_result { public $current_field = NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows = NULL; public $type = NULL }) /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10 Warning: var_dump(): Couldn't fetch mysqli_result in /home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10 Call Stack: 0.0002 662616 1. {main}() /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0 0.0032 672792 2. var_dump(class mysqli_result { public $current_field = NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows = NULL; public $type = NULL }) /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10 Warning: var_dump(): Property access is not allowed yet in /home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10 Call Stack: 0.0002 662616 1. {main}() /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0 0.0032 672792 2. var_dump(class mysqli_result { public $current_field = NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows = NULL; public $type = NULL }) /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10 class mysqli_result#2 (5) { public $current_field => NULL public $field_count => NULL public $lengths => NULL public $num_rows => NULL public $type => NULL } -- Edit bug report at https://bugs.php.net/bug.php?id=63486&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63486&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63486&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63486&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63486&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63486&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63486&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63486&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63486&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63486&r=support Expected behavior: https://bugs.php.net/fix.php?id=63486&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63486&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63486&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63486&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63486&r=php4 Daylight Savings:
Bug #63486 [PATCH]: mysqli_free_result leave the resource variable in a messy state
Edit report at https://bugs.php.net/bug.php?id=63486&edit=1 ID: 63486 Patch added by: der...@php.net Reported by: der...@php.net Summary:mysqli_free_result leave the resource variable in a messy state Status: Open Type: Bug Package:MySQLi related PHP Version:5.4.8 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: mysqli-clear-result-cleanup Revision: 1352638381 URL: https://bugs.php.net/patch-display.php?bug=63486&patch=mysqli-clear-result-cleanup&revision=1352638381 Previous Comments: [2012-11-11 12:52:02] der...@php.net Description: An Xdebug user filed the following report: http://bugs.xdebug.org/view.php?id=900 I've just investigated this, and found out that this is something I can't fix in Xdebug. mysqli_free_result() destroys the internal object, but leaves the resource (in your case, $rs) in a silly state. All Xdebug does internally is basically a var_dump( $rs ), and after it is freed with mysqli_free_result(), that throws exactly the same error (without Xdebug). This can however, easily be fixed in the MySQLi extension with the attached patch. The patch applies to PHP 5.4, but this also a problem in master and PHP 5.3. It is also possible, that other mysqli_free_* functions can benefit from a similar construct. Test script: --- Expected result: The expected result is perhaps something like "NULL" (which my patch makes it do). Actual result: -- hi mom Warning: var_dump(): Couldn't fetch mysqli_result in /home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10 Call Stack: 0.0002 662616 1. {main}() /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0 0.0032 672792 2. var_dump(class mysqli_result { public $current_field = NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows = NULL; public $type = NULL }) /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10 Warning: var_dump(): Couldn't fetch mysqli_result in /home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10 Call Stack: 0.0002 662616 1. {main}() /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0 0.0032 672792 2. var_dump(class mysqli_result { public $current_field = NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows = NULL; public $type = NULL }) /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10 Warning: var_dump(): Property access is not allowed yet in /home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10 Call Stack: 0.0002 662616 1. {main}() /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0 0.0032 672792 2. var_dump(class mysqli_result { public $current_field = NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows = NULL; public $type = NULL }) /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10 Warning: var_dump(): Couldn't fetch mysqli_result in /home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10 Call Stack: 0.0002 662616 1. {main}() /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0 0.0032 672792 2. var_dump(class mysqli_result { public $current_field = NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows = NULL; public $type = NULL }) /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10 Warning: var_dump(): Property access is not allowed yet in /home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10 Call Stack: 0.0002 662616 1. {main}() /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0 0.0032 672792 2. var_dump(class mysqli_result { public $current_field = NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows = NULL; public $type = NULL }) /home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10 class mysqli_result#2 (5) { public $current_field => NULL public $field_count => NULL public $lengths => NULL public $num_rows => NULL public $type => NULL } -- Edit this bug report at https://bugs.php.net/bug.php?id=63486&edit=1