[PHP-BUG] Bug #61079 [NEW]: mysqli crashes when var_dump'ed while not connected

2012-02-13 Thread der...@php.net
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

2013-06-13 Thread der...@php.net
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

2010-03-01 Thread der...@php.net
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

2011-09-12 Thread der...@php.net
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

2012-11-11 Thread der...@php.net
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

2012-11-11 Thread der...@php.net
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