#48052 [Opn->Asn]: SPLStack::setIteratorMode() throw exception on keep/delete flag

2009-04-26 Thread colder
 ID:   48052
 Updated by:   col...@php.net
 Reported By:  ralph at smashlabs dot com
-Status:   Open
+Status:   Assigned
 Bug Type: SPL related
 Operating System: OSX
 PHP Version:  5.3.0RC1
-Assigned To:  
+Assigned To:  colder


Previous Comments:


[2009-04-22 16:50:24] ralph at smashlabs dot com

Description:

Attempting to change the IteratorMode throws an exception.

The is probably due to the code that changes the LIFO/FIFO ordering
that is also settable via the inherited method of
SplDoublyLinkedList::setIteratorMode().



Reproduce code:
---
setIteratorMode(SplDoublyLinkedList::IT_MODE_DELETE);

Expected result:

Do not throw exception on the following use cases:

->setIteratorMode(SplDoublyLinkedList::IT_MODE_DELETE)
->setIteratorMode(SplDoublyLinkedList::IT_MODE_KEEP)

Actual result:
--
PHP Fatal error:  Uncaught exception 'RuntimeException' with message
'Iterators' LIFO/FIFO modes for SplStack/SplQueue objects are frozen' in
path/to/test-splstack.php:4
Stack trace:
#0 path/to/test-splstack.php(4):
SplDoublyLinkedList->setIteratorMode(1)
#1 {main}
  thrown in path/to/test-splstack.php on line 4





-- 
Edit this bug report at http://bugs.php.net/?id=48052&edit=1



#48082 [Fbk->Ver]: mysql_connect not work with named pipes

2009-04-26 Thread mattwil
 ID:   48082
 Updated by:   matt...@php.net
 Reported By:  andrew dot answer at gmail dot com
-Status:   Feedback
+Status:   Verified
 Bug Type: MySQL related
 Operating System: Windows XP
 PHP Version:  5.3.0RC1


Previous Comments:


[2009-04-27 00:04:04] matt...@php.net

No it's not Jani. :-)

Confirmed. Looks like it's with the VC9 binaries -- is that what you
are using (not VC6)? Another difference related to getaddrinfo...

'' (empty string) and 'localhost' work. BTW localhost is actually using
TCP/IP, contrary to what the manual says. Also (even in 5.2), the empty
string is also changing to localhost -- I'm not sure when the behavior
changed (or if it's MySQL server-related), but that used to use a named
pipe without needing to specify '.' :-/



[2009-04-26 21:07:14] j...@php.net

What if you pass proper parameters? "." as host is quite invalid..



[2009-04-26 18:31:40] andrew dot answer at gmail dot com

Description:

When mysql server setting up on WinXP machine with named pipe, 
mysql_connect called with '.' as host parameter anyway connect via 
tcp:// protocol.






Reproduce code:
---
When mysql server setting up on WinXP machine with options
[client]
pipe
socket=mysql

[mysqld]
skip-networking
enable-named-pipe
socket=mysql

php code like this:

$link = mysql_connect('.','user','password');
if (!$link) {
die('Could not connect: ' . mysql_error());
} else echo 'Connected successfully';

mysql_close($link);

should connect via named pipes. But it's fail.


Expected result:

Connected successfully

Actual result:
--
Could not connect: php_network_getaddresses: getaddrinfo failed: Ýòîò 
õîñò íåèçâåñòåí.

php errorlog:
[27-Apr-2009 01:28:06] PHP Warning:  mysql_connect(): 
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñòåí.  
in C:\sites\www\php.php on line 10

[27-Apr-2009 01:28:06] PHP Warning:  mysql_connect(): [2002] 
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñò 
(trying to connect via tcp://.:3306) in C:\sites\www\php.php on line 
10

[27-Apr-2009 01:28:06] PHP Warning:  mysql_connect(): 
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñòåí.  
in C:\sites\www\php.php on line 10









-- 
Edit this bug report at http://bugs.php.net/?id=48082&edit=1



#48082 [Fbk]: mysql_connect not work with named pipes

2009-04-26 Thread mattwil
 ID:   48082
 Updated by:   matt...@php.net
 Reported By:  andrew dot answer at gmail dot com
 Status:   Feedback
 Bug Type: MySQL related
 Operating System: Windows XP
 PHP Version:  5.3.0RC1
 New Comment:

No it's not Jani. :-)

Confirmed. Looks like it's with the VC9 binaries -- is that what you
are using (not VC6)? Another difference related to getaddrinfo...

'' (empty string) and 'localhost' work. BTW localhost is actually using
TCP/IP, contrary to what the manual says. Also (even in 5.2), the empty
string is also changing to localhost -- I'm not sure when the behavior
changed (or if it's MySQL server-related), but that used to use a named
pipe without needing to specify '.' :-/


Previous Comments:


[2009-04-26 21:07:14] j...@php.net

What if you pass proper parameters? "." as host is quite invalid..



[2009-04-26 18:31:40] andrew dot answer at gmail dot com

Description:

When mysql server setting up on WinXP machine with named pipe, 
mysql_connect called with '.' as host parameter anyway connect via 
tcp:// protocol.






Reproduce code:
---
When mysql server setting up on WinXP machine with options
[client]
pipe
socket=mysql

[mysqld]
skip-networking
enable-named-pipe
socket=mysql

php code like this:

$link = mysql_connect('.','user','password');
if (!$link) {
die('Could not connect: ' . mysql_error());
} else echo 'Connected successfully';

mysql_close($link);

should connect via named pipes. But it's fail.


Expected result:

Connected successfully

Actual result:
--
Could not connect: php_network_getaddresses: getaddrinfo failed: Ýòîò 
õîñò íåèçâåñòåí.

php errorlog:
[27-Apr-2009 01:28:06] PHP Warning:  mysql_connect(): 
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñòåí.  
in C:\sites\www\php.php on line 10

[27-Apr-2009 01:28:06] PHP Warning:  mysql_connect(): [2002] 
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñò 
(trying to connect via tcp://.:3306) in C:\sites\www\php.php on line 
10

[27-Apr-2009 01:28:06] PHP Warning:  mysql_connect(): 
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñòåí.  
in C:\sites\www\php.php on line 10









-- 
Edit this bug report at http://bugs.php.net/?id=48082&edit=1



#48082 [Opn->Fbk]: mysql_connect not work with named pipes

2009-04-26 Thread jani
 ID:   48082
 Updated by:   j...@php.net
 Reported By:  andrew dot answer at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: MySQL related
 Operating System: Windows XP
 PHP Version:  5.3.0RC1
 New Comment:

What if you pass proper parameters? "." as host is quite invalid..


Previous Comments:


[2009-04-26 18:31:40] andrew dot answer at gmail dot com

Description:

When mysql server setting up on WinXP machine with named pipe, 
mysql_connect called with '.' as host parameter anyway connect via 
tcp:// protocol.






Reproduce code:
---
When mysql server setting up on WinXP machine with options
[client]
pipe
socket=mysql

[mysqld]
skip-networking
enable-named-pipe
socket=mysql

php code like this:

$link = mysql_connect('.','user','password');
if (!$link) {
die('Could not connect: ' . mysql_error());
} else echo 'Connected successfully';

mysql_close($link);

should connect via named pipes. But it's fail.


Expected result:

Connected successfully

Actual result:
--
Could not connect: php_network_getaddresses: getaddrinfo failed: Ýòîò 
õîñò íåèçâåñòåí.

php errorlog:
[27-Apr-2009 01:28:06] PHP Warning:  mysql_connect(): 
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñòåí.  
in C:\sites\www\php.php on line 10

[27-Apr-2009 01:28:06] PHP Warning:  mysql_connect(): [2002] 
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñò 
(trying to connect via tcp://.:3306) in C:\sites\www\php.php on line 
10

[27-Apr-2009 01:28:06] PHP Warning:  mysql_connect(): 
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñòåí.  
in C:\sites\www\php.php on line 10









-- 
Edit this bug report at http://bugs.php.net/?id=48082&edit=1



#48081 [Fbk->Bgs]: stream_socket_client with SSL causes SEGFAULT

2009-04-26 Thread pajoye
 ID:   48081
 Updated by:   paj...@php.net
 Reported By:  alexander at wright-family dot me dot uk
-Status:   Feedback
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: Gentoo Linux
 PHP Version:  5.2.9
 Assigned To:  pajoye
 New Comment:

missed the last comment, no php bug then > bogus.


Previous Comments:


[2009-04-26 20:39:32] paj...@php.net

Which openssl version do you use?

Can you try to compile PHP yourself and see if you can reproduce this
problem?



[2009-04-26 20:02:44] alexander at wright-family dot me dot uk

Further information:

Buggy PHP compiled with x86_64-pc-linux-gnu-3.4.6

I compiled the same version of PHP on another AMD64 machine with
x86_64-pc-linux-gnu-4.2.4 and this works correctly (with suhosin
enabled).



[2009-04-26 19:09:15] alexander at wright-family dot me dot uk

Also available here:
http://www.wright-family.me.uk/shared/phpgdb.txt



[2009-04-26 19:06:07] alexander at wright-family dot me dot uk

Suhosin removed. Is this enough debug info?

Cheers.

(gdb) bt
#0  0xff70085e in ?? ()
#1  0x6ad6211f47f2 in gettimeofday ()
#2  0x6ad619e3e2ba in gettimeofday () from /lib/libc.so.6
#3  0x004934ff in php_openssl_enable_crypto (stream=0x12ce7e8,
sslsock=0x12ce730, cparam=0x740fac178940, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/openssl/xp_ssl.c:417
#4  0x00492ddf in php_openssl_sockop_set_option
(stream=0x12ce7e8, option=8, value=0, ptrparam=0x740fac178940,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/openssl/xp_ssl.c:669
#5  0x008346e0 in _php_stream_set_option (stream=0x12ce7e8,
option=8, value=0, ptrparam=0x740fac178940, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/streams.c:1155
#6  0x008464cf in php_stream_xport_crypto_enable
(stream=0x12ce7e8, activate=1, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/transports.c:371
#7  0x00492e9b in php_openssl_sockop_set_option
(stream=0x12ce7e8, option=7, value=0, ptrparam=0x740fac178b00,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/openssl/xp_ssl.c:689
#8  0x008346e0 in _php_stream_set_option (stream=0x12ce7e8,
option=7, value=0, ptrparam=0x740fac178b00, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/streams.c:1155
#9  0x00845f28 in php_stream_xport_connect (stream=0x12ce7e8,
name=0x12cd8ce "www.google.com:443", namelen=18, asynchronous=0,
timeout=0x740fac178e60, error_text=0x740fac178d08,
error_code=0x740fac178e4c, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/transports.c:230
#10 0x00845a39 in _php_stream_xport_create (name=0x12cd8ce
"www.google.com:443", namelen=18, options=12, flags=2,
persistent_id=0x0,
timeout=0x740fac178e60, context=0x12c2d20,
error_string=0x740fac178e38, error_code=0x740fac178e4c,
__php_stream_call_depth=0,
__zend_filename=0xc04480
"/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/standard/streamsfuncs.c",
__zend_lineno=129,
__zend_orig_filename=0x0, __zend_orig_lineno=0, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/transports.c:143
#11 0x007d21a6 in zif_stream_socket_client (ht=6,
return_value=0x12cda30, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1,
tsrm_ls=0xfad400) at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/standard/streamsfuncs.c:126
#12 0x008c285d in execute_internal
(execute_data_ptr=0x740fac179460, return_value_used=1,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_execute.c:1373
#13 0x6ad61978a5dd in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#14 0x008c337f in zend_do_fcall_common_helper_SPEC
(execute_data=0x740fac179460, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_vm_execute.h:202
#15 0x008cb2fa in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x740fac179460, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_vm_execute.h:1729
#16 0x008c2c98 in execute (op_array=0x12cb8c0,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_vm_execute.h:92
#17 0x6ad6197876eb in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#18 0x6ad619787785 in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.

#48081 [Opn->Fbk]: stream_socket_client with SSL causes SEGFAULT

2009-04-26 Thread pajoye
 ID:   48081
 Updated by:   paj...@php.net
 Reported By:  alexander at wright-family dot me dot uk
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Gentoo Linux
 PHP Version:  5.2.9
-Assigned To:  
+Assigned To:  pajoye
 New Comment:

Which openssl version do you use?

Can you try to compile PHP yourself and see if you can reproduce this
problem?


Previous Comments:


[2009-04-26 20:02:44] alexander at wright-family dot me dot uk

Further information:

Buggy PHP compiled with x86_64-pc-linux-gnu-3.4.6

I compiled the same version of PHP on another AMD64 machine with
x86_64-pc-linux-gnu-4.2.4 and this works correctly (with suhosin
enabled).



[2009-04-26 19:09:15] alexander at wright-family dot me dot uk

Also available here:
http://www.wright-family.me.uk/shared/phpgdb.txt



[2009-04-26 19:06:07] alexander at wright-family dot me dot uk

Suhosin removed. Is this enough debug info?

Cheers.

(gdb) bt
#0  0xff70085e in ?? ()
#1  0x6ad6211f47f2 in gettimeofday ()
#2  0x6ad619e3e2ba in gettimeofday () from /lib/libc.so.6
#3  0x004934ff in php_openssl_enable_crypto (stream=0x12ce7e8,
sslsock=0x12ce730, cparam=0x740fac178940, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/openssl/xp_ssl.c:417
#4  0x00492ddf in php_openssl_sockop_set_option
(stream=0x12ce7e8, option=8, value=0, ptrparam=0x740fac178940,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/openssl/xp_ssl.c:669
#5  0x008346e0 in _php_stream_set_option (stream=0x12ce7e8,
option=8, value=0, ptrparam=0x740fac178940, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/streams.c:1155
#6  0x008464cf in php_stream_xport_crypto_enable
(stream=0x12ce7e8, activate=1, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/transports.c:371
#7  0x00492e9b in php_openssl_sockop_set_option
(stream=0x12ce7e8, option=7, value=0, ptrparam=0x740fac178b00,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/openssl/xp_ssl.c:689
#8  0x008346e0 in _php_stream_set_option (stream=0x12ce7e8,
option=7, value=0, ptrparam=0x740fac178b00, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/streams.c:1155
#9  0x00845f28 in php_stream_xport_connect (stream=0x12ce7e8,
name=0x12cd8ce "www.google.com:443", namelen=18, asynchronous=0,
timeout=0x740fac178e60, error_text=0x740fac178d08,
error_code=0x740fac178e4c, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/transports.c:230
#10 0x00845a39 in _php_stream_xport_create (name=0x12cd8ce
"www.google.com:443", namelen=18, options=12, flags=2,
persistent_id=0x0,
timeout=0x740fac178e60, context=0x12c2d20,
error_string=0x740fac178e38, error_code=0x740fac178e4c,
__php_stream_call_depth=0,
__zend_filename=0xc04480
"/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/standard/streamsfuncs.c",
__zend_lineno=129,
__zend_orig_filename=0x0, __zend_orig_lineno=0, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/transports.c:143
#11 0x007d21a6 in zif_stream_socket_client (ht=6,
return_value=0x12cda30, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1,
tsrm_ls=0xfad400) at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/standard/streamsfuncs.c:126
#12 0x008c285d in execute_internal
(execute_data_ptr=0x740fac179460, return_value_used=1,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_execute.c:1373
#13 0x6ad61978a5dd in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#14 0x008c337f in zend_do_fcall_common_helper_SPEC
(execute_data=0x740fac179460, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_vm_execute.h:202
#15 0x008cb2fa in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x740fac179460, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_vm_execute.h:1729
#16 0x008c2c98 in execute (op_array=0x12cb8c0,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_vm_execute.h:92
#17 0x6ad6197876eb in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#18 0x6ad619787785 in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#19 0x0088ffcc in zend_execute_scripts (type=8,
tsrm_ls=0xfad400, retval=0x0, file_count=3)
at
/var/tmp/portage/dev-lang/php-5.2.

#48081 [Opn]: stream_socket_client with SSL causes SEGFAULT

2009-04-26 Thread alexander at wright-family dot me dot uk
 ID:   48081
 User updated by:  alexander at wright-family dot me dot uk
 Reported By:  alexander at wright-family dot me dot uk
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Gentoo Linux
 PHP Version:  5.2.9
 New Comment:

Further information:

Buggy PHP compiled with x86_64-pc-linux-gnu-3.4.6

I compiled the same version of PHP on another AMD64 machine with
x86_64-pc-linux-gnu-4.2.4 and this works correctly (with suhosin
enabled).


Previous Comments:


[2009-04-26 19:09:15] alexander at wright-family dot me dot uk

Also available here:
http://www.wright-family.me.uk/shared/phpgdb.txt



[2009-04-26 19:06:07] alexander at wright-family dot me dot uk

Suhosin removed. Is this enough debug info?

Cheers.

(gdb) bt
#0  0xff70085e in ?? ()
#1  0x6ad6211f47f2 in gettimeofday ()
#2  0x6ad619e3e2ba in gettimeofday () from /lib/libc.so.6
#3  0x004934ff in php_openssl_enable_crypto (stream=0x12ce7e8,
sslsock=0x12ce730, cparam=0x740fac178940, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/openssl/xp_ssl.c:417
#4  0x00492ddf in php_openssl_sockop_set_option
(stream=0x12ce7e8, option=8, value=0, ptrparam=0x740fac178940,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/openssl/xp_ssl.c:669
#5  0x008346e0 in _php_stream_set_option (stream=0x12ce7e8,
option=8, value=0, ptrparam=0x740fac178940, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/streams.c:1155
#6  0x008464cf in php_stream_xport_crypto_enable
(stream=0x12ce7e8, activate=1, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/transports.c:371
#7  0x00492e9b in php_openssl_sockop_set_option
(stream=0x12ce7e8, option=7, value=0, ptrparam=0x740fac178b00,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/openssl/xp_ssl.c:689
#8  0x008346e0 in _php_stream_set_option (stream=0x12ce7e8,
option=7, value=0, ptrparam=0x740fac178b00, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/streams.c:1155
#9  0x00845f28 in php_stream_xport_connect (stream=0x12ce7e8,
name=0x12cd8ce "www.google.com:443", namelen=18, asynchronous=0,
timeout=0x740fac178e60, error_text=0x740fac178d08,
error_code=0x740fac178e4c, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/transports.c:230
#10 0x00845a39 in _php_stream_xport_create (name=0x12cd8ce
"www.google.com:443", namelen=18, options=12, flags=2,
persistent_id=0x0,
timeout=0x740fac178e60, context=0x12c2d20,
error_string=0x740fac178e38, error_code=0x740fac178e4c,
__php_stream_call_depth=0,
__zend_filename=0xc04480
"/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/standard/streamsfuncs.c",
__zend_lineno=129,
__zend_orig_filename=0x0, __zend_orig_lineno=0, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/transports.c:143
#11 0x007d21a6 in zif_stream_socket_client (ht=6,
return_value=0x12cda30, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1,
tsrm_ls=0xfad400) at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/standard/streamsfuncs.c:126
#12 0x008c285d in execute_internal
(execute_data_ptr=0x740fac179460, return_value_used=1,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_execute.c:1373
#13 0x6ad61978a5dd in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#14 0x008c337f in zend_do_fcall_common_helper_SPEC
(execute_data=0x740fac179460, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_vm_execute.h:202
#15 0x008cb2fa in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x740fac179460, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_vm_execute.h:1729
#16 0x008c2c98 in execute (op_array=0x12cb8c0,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_vm_execute.h:92
#17 0x6ad6197876eb in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#18 0x6ad619787785 in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#19 0x0088ffcc in zend_execute_scripts (type=8,
tsrm_ls=0xfad400, retval=0x0, file_count=3)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend.c:1134
#20 0x008126c7 in php_execute_script
(primary_file=0x740fac17bc00, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/main.c:2023
#21 0x0093e561 in main (argc=2, argv=0x740fac17bec8) at
/var/tmp/portage/dev-lang/php

#48081 [Opn]: stream_socket_client with SSL causes SEGFAULT

2009-04-26 Thread alexander at wright-family dot me dot uk
 ID:   48081
 User updated by:  alexander at wright-family dot me dot uk
 Reported By:  alexander at wright-family dot me dot uk
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Gentoo Linux
 PHP Version:  5.2.9
 New Comment:

Also available here:
http://www.wright-family.me.uk/shared/phpgdb.txt


Previous Comments:


[2009-04-26 19:06:07] alexander at wright-family dot me dot uk

Suhosin removed. Is this enough debug info?

Cheers.

(gdb) bt
#0  0xff70085e in ?? ()
#1  0x6ad6211f47f2 in gettimeofday ()
#2  0x6ad619e3e2ba in gettimeofday () from /lib/libc.so.6
#3  0x004934ff in php_openssl_enable_crypto (stream=0x12ce7e8,
sslsock=0x12ce730, cparam=0x740fac178940, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/openssl/xp_ssl.c:417
#4  0x00492ddf in php_openssl_sockop_set_option
(stream=0x12ce7e8, option=8, value=0, ptrparam=0x740fac178940,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/openssl/xp_ssl.c:669
#5  0x008346e0 in _php_stream_set_option (stream=0x12ce7e8,
option=8, value=0, ptrparam=0x740fac178940, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/streams.c:1155
#6  0x008464cf in php_stream_xport_crypto_enable
(stream=0x12ce7e8, activate=1, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/transports.c:371
#7  0x00492e9b in php_openssl_sockop_set_option
(stream=0x12ce7e8, option=7, value=0, ptrparam=0x740fac178b00,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/openssl/xp_ssl.c:689
#8  0x008346e0 in _php_stream_set_option (stream=0x12ce7e8,
option=7, value=0, ptrparam=0x740fac178b00, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/streams.c:1155
#9  0x00845f28 in php_stream_xport_connect (stream=0x12ce7e8,
name=0x12cd8ce "www.google.com:443", namelen=18, asynchronous=0,
timeout=0x740fac178e60, error_text=0x740fac178d08,
error_code=0x740fac178e4c, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/transports.c:230
#10 0x00845a39 in _php_stream_xport_create (name=0x12cd8ce
"www.google.com:443", namelen=18, options=12, flags=2,
persistent_id=0x0,
timeout=0x740fac178e60, context=0x12c2d20,
error_string=0x740fac178e38, error_code=0x740fac178e4c,
__php_stream_call_depth=0,
__zend_filename=0xc04480
"/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/standard/streamsfuncs.c",
__zend_lineno=129,
__zend_orig_filename=0x0, __zend_orig_lineno=0, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/transports.c:143
#11 0x007d21a6 in zif_stream_socket_client (ht=6,
return_value=0x12cda30, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1,
tsrm_ls=0xfad400) at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/standard/streamsfuncs.c:126
#12 0x008c285d in execute_internal
(execute_data_ptr=0x740fac179460, return_value_used=1,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_execute.c:1373
#13 0x6ad61978a5dd in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#14 0x008c337f in zend_do_fcall_common_helper_SPEC
(execute_data=0x740fac179460, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_vm_execute.h:202
#15 0x008cb2fa in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x740fac179460, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_vm_execute.h:1729
#16 0x008c2c98 in execute (op_array=0x12cb8c0,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_vm_execute.h:92
#17 0x6ad6197876eb in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#18 0x6ad619787785 in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#19 0x0088ffcc in zend_execute_scripts (type=8,
tsrm_ls=0xfad400, retval=0x0, file_count=3)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend.c:1134
#20 0x008126c7 in php_execute_script
(primary_file=0x740fac17bc00, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/main.c:2023
#21 0x0093e561 in main (argc=2, argv=0x740fac17bec8) at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/sapi/cli/php_cli.c:1133
(gdb)



[2009-04-26 18:28:02] scott...@php.net

Can you remove sushosin and get debug symbols for the rest of the php
binary.

I can't reproduce this on 5.2.10-dev or 5.3.0-dev


Output is:
Warning: stream_socket_client(): unable 

#48081 [Fbk->Opn]: stream_socket_client with SSL causes SEGFAULT

2009-04-26 Thread alexander at wright-family dot me dot uk
 ID:   48081
 User updated by:  alexander at wright-family dot me dot uk
 Reported By:  alexander at wright-family dot me dot uk
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Gentoo Linux
 PHP Version:  5.2.9
 New Comment:

Suhosin removed. Is this enough debug info?

Cheers.

(gdb) bt
#0  0xff70085e in ?? ()
#1  0x6ad6211f47f2 in gettimeofday ()
#2  0x6ad619e3e2ba in gettimeofday () from /lib/libc.so.6
#3  0x004934ff in php_openssl_enable_crypto (stream=0x12ce7e8,
sslsock=0x12ce730, cparam=0x740fac178940, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/openssl/xp_ssl.c:417
#4  0x00492ddf in php_openssl_sockop_set_option
(stream=0x12ce7e8, option=8, value=0, ptrparam=0x740fac178940,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/openssl/xp_ssl.c:669
#5  0x008346e0 in _php_stream_set_option (stream=0x12ce7e8,
option=8, value=0, ptrparam=0x740fac178940, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/streams.c:1155
#6  0x008464cf in php_stream_xport_crypto_enable
(stream=0x12ce7e8, activate=1, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/transports.c:371
#7  0x00492e9b in php_openssl_sockop_set_option
(stream=0x12ce7e8, option=7, value=0, ptrparam=0x740fac178b00,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/openssl/xp_ssl.c:689
#8  0x008346e0 in _php_stream_set_option (stream=0x12ce7e8,
option=7, value=0, ptrparam=0x740fac178b00, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/streams.c:1155
#9  0x00845f28 in php_stream_xport_connect (stream=0x12ce7e8,
name=0x12cd8ce "www.google.com:443", namelen=18, asynchronous=0,
timeout=0x740fac178e60, error_text=0x740fac178d08,
error_code=0x740fac178e4c, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/transports.c:230
#10 0x00845a39 in _php_stream_xport_create (name=0x12cd8ce
"www.google.com:443", namelen=18, options=12, flags=2,
persistent_id=0x0,
timeout=0x740fac178e60, context=0x12c2d20,
error_string=0x740fac178e38, error_code=0x740fac178e4c,
__php_stream_call_depth=0,
__zend_filename=0xc04480
"/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/standard/streamsfuncs.c",
__zend_lineno=129,
__zend_orig_filename=0x0, __zend_orig_lineno=0, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/streams/transports.c:143
#11 0x007d21a6 in zif_stream_socket_client (ht=6,
return_value=0x12cda30, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1,
tsrm_ls=0xfad400) at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/standard/streamsfuncs.c:126
#12 0x008c285d in execute_internal
(execute_data_ptr=0x740fac179460, return_value_used=1,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_execute.c:1373
#13 0x6ad61978a5dd in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#14 0x008c337f in zend_do_fcall_common_helper_SPEC
(execute_data=0x740fac179460, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_vm_execute.h:202
#15 0x008cb2fa in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x740fac179460, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_vm_execute.h:1729
#16 0x008c2c98 in execute (op_array=0x12cb8c0,
tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend_vm_execute.h:92
#17 0x6ad6197876eb in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#18 0x6ad619787785 in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#19 0x0088ffcc in zend_execute_scripts (type=8,
tsrm_ls=0xfad400, retval=0x0, file_count=3)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/Zend/zend.c:1134
#20 0x008126c7 in php_execute_script
(primary_file=0x740fac17bc00, tsrm_ls=0xfad400)
at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/main/main.c:2023
#21 0x0093e561 in main (argc=2, argv=0x740fac17bec8) at
/var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/sapi/cli/php_cli.c:1133
(gdb)


Previous Comments:


[2009-04-26 18:28:02] scott...@php.net

Can you remove sushosin and get debug symbols for the rest of the php
binary.

I can't reproduce this on 5.2.10-dev or 5.3.0-dev


Output is:
Warning: stream_socket_client(): unable to connect to
ssl://www.google.com:443 (Operation now in progress) in
/private/tmp/test.php on line 7

Error:36: Operation now in progress


Headers:




---

#48082 [NEW]: mysql_connect not work with named pipes

2009-04-26 Thread andrew dot answer at gmail dot com
From: andrew dot answer at gmail dot com
Operating system: Windows XP
PHP version:  5.3.0RC1
PHP Bug Type: MySQL related
Bug description:  mysql_connect not work with named pipes

Description:

When mysql server setting up on WinXP machine with named pipe, 
mysql_connect called with '.' as host parameter anyway connect via 
tcp:// protocol.






Reproduce code:
---
When mysql server setting up on WinXP machine with options
[client]
pipe
socket=mysql

[mysqld]
skip-networking
enable-named-pipe
socket=mysql

php code like this:

$link = mysql_connect('.','user','password');
if (!$link) {
die('Could not connect: ' . mysql_error());
} else echo 'Connected successfully';

mysql_close($link);

should connect via named pipes. But it's fail.


Expected result:

Connected successfully

Actual result:
--
Could not connect: php_network_getaddresses: getaddrinfo failed: Ýòîò 
õîñò íåèçâåñòåí.

php errorlog:
[27-Apr-2009 01:28:06] PHP Warning:  mysql_connect(): 
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñòåí.  
in C:\sites\www\php.php on line 10

[27-Apr-2009 01:28:06] PHP Warning:  mysql_connect(): [2002] 
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñò 
(trying to connect via tcp://.:3306) in C:\sites\www\php.php on line 
10

[27-Apr-2009 01:28:06] PHP Warning:  mysql_connect(): 
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñòåí.  
in C:\sites\www\php.php on line 10





-- 
Edit bug report at http://bugs.php.net/?id=48082&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48082&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48082&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48082&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48082&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48082&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48082&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48082&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48082&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48082&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48082&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48082&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48082&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48082&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48082&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48082&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48082&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48082&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48082&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48082&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48082&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48082&r=mysqlcfg



#41027 [Fbk->Opn]: Executing prepared statement changes type of bound parameters to string

2009-04-26 Thread martin at bangaroo dot net
 ID:   41027
 User updated by:  martin at bangaroo dot net
 Reported By:  martin at bangaroo dot net
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: Gentoo Linux
 PHP Version:  5.2.1
 Assigned To:  wez
 New Comment:

I just checked with the snapshot php5.2-200904261630.

Unfortunately the bug still exists.


Previous Comments:


[2009-04-25 14:44:51] j...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





[2007-04-09 14:31:34] martin at bangaroo dot net

Description:

Executing a prepared statement changes the type of bound parameters 
to string (Tested only with pgsql driver).

This bite me when I wanted to execute an insert statement only when 
the double value to be inserted actually changed, NULL being a 
possible value. Unfortunatly, comparing the new value with the old 
value with the !== operator didn't work, because the type-change 
made the test always evaluate to TRUE.


Reproduce code:
---
query("CREATE TABLE test_table ( val REAL )");
  $qry = $db->prepare("INSERT INTO test_table VALUES (:val)");
  $qry->bindParam(":val",$bound_val);

  $bound_val = 5.2;
  echo "Type before execute(): ".gettype($bound_val)."\n";
  $qry->execute();
  echo "Type after execute(): ".gettype($bound_val)."\n";

  $db->query("DROP TABLE test");
?>

Expected result:

Type before execute(): double
Type after execute(): double


Actual result:
--
Type before execute(): double
Type after execute(): string






-- 
Edit this bug report at http://bugs.php.net/?id=41027&edit=1



#48081 [Opn->Fbk]: stream_socket_client with SSL causes SEGFAULT

2009-04-26 Thread scottmac
 ID:   48081
 Updated by:   scott...@php.net
 Reported By:  alexander at wright-family dot me dot uk
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Gentoo Linux
 PHP Version:  5.2.9


Previous Comments:


[2009-04-26 18:28:02] scott...@php.net

Can you remove sushosin and get debug symbols for the rest of the php
binary.

I can't reproduce this on 5.2.10-dev or 5.3.0-dev


Output is:
Warning: stream_socket_client(): unable to connect to
ssl://www.google.com:443 (Operation now in progress) in
/private/tmp/test.php on line 7

Error:36: Operation now in progress


Headers:






[2009-04-26 17:26:12] alexander at wright-family dot me dot uk

Description:

PHPInfo located here:
http://www.wright-family.me.uk/shared/phpinfo.txt

Using hardened profile Gentoo Linux:
Linux beth 2.6.25-hardened-r11 #6 SMP Tue Dec 23 08:37:01 GMT 2008
x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD
GNU/Linux

Attached code causes a segfault when executing the
stream_socket_client() function.

Using TCP rather than SSL works correctly (i.e. without a segfault).

Reproduce code:
---



Expected result:

Code should connect to google, and attempt to read some data.

Actual result:
--
Backtrace:


#0  0xff70085e in ?? ()
#1  0x6f972c5797f2 in gettimeofday ()
#2  0x6f97251c32ba in gettimeofday () from /lib/libc.so.6
#3  0x05b28362a9f0 in ?? () from /usr/lib64/php5/bin/php
#4  0x05b28362a2a5 in ?? () from /usr/lib64/php5/bin/php
#5  0x05b2839cec4f in _php_stream_set_option () from
/usr/lib64/php5/bin/php
#6  0x05b2839e0cbf in php_stream_xport_crypto_enable () from
/usr/lib64/php5/bin/php
#7  0x05b28362a361 in ?? () from /usr/lib64/php5/bin/php
#8  0x05b2839cec4f in _php_stream_set_option () from
/usr/lib64/php5/bin/php
#9  0x05b2839e0718 in php_stream_xport_connect () from
/usr/lib64/php5/bin/php
#10 0x05b2839e0229 in _php_stream_xport_create () from
/usr/lib64/php5/bin/php
#11 0x05b28396a9e3 in zif_stream_socket_client () from
/usr/lib64/php5/bin/php
#12 0x05b283a5f371 in execute_internal () from
/usr/lib64/php5/bin/php
#13 0x6f9724b0f5dd in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#14 0x05b283a5fe93 in ?? () from /usr/lib64/php5/bin/php
#15 0x05b283a67e4c in ?? () from /usr/lib64/php5/bin/php
#16 0x05b283a5f7ac in execute () from /usr/lib64/php5/bin/php
#17 0x6f9724b0c6eb in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#18 0x6f9724b0c785 in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#19 0x05b283a2c0fe in zend_execute_scripts () from
/usr/lib64/php5/bin/php
#20 0x05b2839ab8ed in php_execute_script () from
/usr/lib64/php5/bin/php
#21 0x05b283adb1a3 in main () from /usr/lib64/php5/bin/php






-- 
Edit this bug report at http://bugs.php.net/?id=48081&edit=1



#48081 [Opn]: stream_socket_client with SSL causes SEGFAULT

2009-04-26 Thread scottmac
 ID:   48081
 Updated by:   scott...@php.net
 Reported By:  alexander at wright-family dot me dot uk
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Gentoo Linux
 PHP Version:  5.2.9
 New Comment:

Can you remove sushosin and get debug symbols for the rest of the php
binary.

I can't reproduce this on 5.2.10-dev or 5.3.0-dev


Output is:
Warning: stream_socket_client(): unable to connect to
ssl://www.google.com:443 (Operation now in progress) in
/private/tmp/test.php on line 7

Error:36: Operation now in progress


Headers:





Previous Comments:


[2009-04-26 17:26:12] alexander at wright-family dot me dot uk

Description:

PHPInfo located here:
http://www.wright-family.me.uk/shared/phpinfo.txt

Using hardened profile Gentoo Linux:
Linux beth 2.6.25-hardened-r11 #6 SMP Tue Dec 23 08:37:01 GMT 2008
x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD
GNU/Linux

Attached code causes a segfault when executing the
stream_socket_client() function.

Using TCP rather than SSL works correctly (i.e. without a segfault).

Reproduce code:
---



Expected result:

Code should connect to google, and attempt to read some data.

Actual result:
--
Backtrace:


#0  0xff70085e in ?? ()
#1  0x6f972c5797f2 in gettimeofday ()
#2  0x6f97251c32ba in gettimeofday () from /lib/libc.so.6
#3  0x05b28362a9f0 in ?? () from /usr/lib64/php5/bin/php
#4  0x05b28362a2a5 in ?? () from /usr/lib64/php5/bin/php
#5  0x05b2839cec4f in _php_stream_set_option () from
/usr/lib64/php5/bin/php
#6  0x05b2839e0cbf in php_stream_xport_crypto_enable () from
/usr/lib64/php5/bin/php
#7  0x05b28362a361 in ?? () from /usr/lib64/php5/bin/php
#8  0x05b2839cec4f in _php_stream_set_option () from
/usr/lib64/php5/bin/php
#9  0x05b2839e0718 in php_stream_xport_connect () from
/usr/lib64/php5/bin/php
#10 0x05b2839e0229 in _php_stream_xport_create () from
/usr/lib64/php5/bin/php
#11 0x05b28396a9e3 in zif_stream_socket_client () from
/usr/lib64/php5/bin/php
#12 0x05b283a5f371 in execute_internal () from
/usr/lib64/php5/bin/php
#13 0x6f9724b0f5dd in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#14 0x05b283a5fe93 in ?? () from /usr/lib64/php5/bin/php
#15 0x05b283a67e4c in ?? () from /usr/lib64/php5/bin/php
#16 0x05b283a5f7ac in execute () from /usr/lib64/php5/bin/php
#17 0x6f9724b0c6eb in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#18 0x6f9724b0c785 in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#19 0x05b283a2c0fe in zend_execute_scripts () from
/usr/lib64/php5/bin/php
#20 0x05b2839ab8ed in php_execute_script () from
/usr/lib64/php5/bin/php
#21 0x05b283adb1a3 in main () from /usr/lib64/php5/bin/php






-- 
Edit this bug report at http://bugs.php.net/?id=48081&edit=1



#48081 [NEW]: stream_socket_client with SSL causes SEGFAULT

2009-04-26 Thread alexander at wright-family dot me dot uk
From: alexander at wright-family dot me dot uk
Operating system: Gentoo Linux
PHP version:  5.2.9
PHP Bug Type: Reproducible crash
Bug description:  stream_socket_client with SSL causes SEGFAULT

Description:

PHPInfo located here: http://www.wright-family.me.uk/shared/phpinfo.txt

Using hardened profile Gentoo Linux:
Linux beth 2.6.25-hardened-r11 #6 SMP Tue Dec 23 08:37:01 GMT 2008 x86_64
AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux

Attached code causes a segfault when executing the stream_socket_client()
function.

Using TCP rather than SSL works correctly (i.e. without a segfault).

Reproduce code:
---



Expected result:

Code should connect to google, and attempt to read some data.

Actual result:
--
Backtrace:


#0  0xff70085e in ?? ()
#1  0x6f972c5797f2 in gettimeofday ()
#2  0x6f97251c32ba in gettimeofday () from /lib/libc.so.6
#3  0x05b28362a9f0 in ?? () from /usr/lib64/php5/bin/php
#4  0x05b28362a2a5 in ?? () from /usr/lib64/php5/bin/php
#5  0x05b2839cec4f in _php_stream_set_option () from
/usr/lib64/php5/bin/php
#6  0x05b2839e0cbf in php_stream_xport_crypto_enable () from
/usr/lib64/php5/bin/php
#7  0x05b28362a361 in ?? () from /usr/lib64/php5/bin/php
#8  0x05b2839cec4f in _php_stream_set_option () from
/usr/lib64/php5/bin/php
#9  0x05b2839e0718 in php_stream_xport_connect () from
/usr/lib64/php5/bin/php
#10 0x05b2839e0229 in _php_stream_xport_create () from
/usr/lib64/php5/bin/php
#11 0x05b28396a9e3 in zif_stream_socket_client () from
/usr/lib64/php5/bin/php
#12 0x05b283a5f371 in execute_internal () from
/usr/lib64/php5/bin/php
#13 0x6f9724b0f5dd in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#14 0x05b283a5fe93 in ?? () from /usr/lib64/php5/bin/php
#15 0x05b283a67e4c in ?? () from /usr/lib64/php5/bin/php
#16 0x05b283a5f7ac in execute () from /usr/lib64/php5/bin/php
#17 0x6f9724b0c6eb in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#18 0x6f9724b0c785 in ?? () from
/usr/lib64/php5/lib/php/extensions/debug-zts-20060613/suhosin.so
#19 0x05b283a2c0fe in zend_execute_scripts () from
/usr/lib64/php5/bin/php
#20 0x05b2839ab8ed in php_execute_script () from
/usr/lib64/php5/bin/php
#21 0x05b283adb1a3 in main () from /usr/lib64/php5/bin/php


-- 
Edit bug report at http://bugs.php.net/?id=48081&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48081&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48081&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48081&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48081&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48081&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48081&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48081&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48081&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48081&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48081&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48081&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48081&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48081&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48081&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48081&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48081&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48081&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48081&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48081&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48081&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48081&r=mysqlcfg



#48080 [NEW]: Add support for forcing DOM to validate a DOMDocument with a DTD

2009-04-26 Thread jose dot rob dot jr at gmail dot com
From: jose dot rob dot jr at gmail dot com
Operating system: 
PHP version:  5.2.9
PHP Bug Type: Feature/Change Request
Bug description:  Add support for forcing DOM to validate a DOMDocument with a 
DTD

Description:

I need to validate XML files before loading them, then I created a DTD and
hosted it.

With python I can distribute the DTD file with the program and validate
the XML file locally.
A python example:
---
from lxml import etree
from StringIO import StringIO

xmlstart="""
http://example.com/mydtd.dtd'>"""

xmlok=xmlstart+"The XML file";
xmlinvalid=xmlstart+"testThe XML file";

dtddata="";

f=StringIO(dtddata);
dtd=etree.DTD(f);

print "Valid XML:";
xml1=etree.XML(xmlok);
validation=dtd.validate(xml1);
print validation;
print dtd.error_log.filter_from_errors();

print "Invalid XML:";
xml2=etree.XML(xmlinvalid);
validation=dtd.validate(xml2);
print validation;
print dtd.error_log.filter_from_errors();

The only way I find to port this stript is using DOMDocument::validate()
but this method will get the DTD from http://example.com/mydtd.dtd and be
slower, generate traffic, and fail when example.com is off-line...

I suggest adding an attribute like DOMDocument::validate($source) where
$source is a string with DTD source to avoid situations like this...

Reproduce code:
---

http://example.com/mydtd.dtd'>
XML;

$xmlok=$xmlstart."The XML file";
$xmlinvalid=$xmlstart."testThe XML file";
$dtddata="";

print "Valid XML:";
$xml1=DOMDocument::loadXML($xmlok);
$validation=(int)$xml1->validate($dtddata); //Example that would work
print "$validation";
print "Invalid XML:";
$xml1=DOMDocument::loadXML($xmlinvalid);
$validation=(int)$xml1->validate($dtddata); //Example that would work
print "$validation";
?>

Expected result:

Valid XML:

1

Invalid XML:

Warning: DOMDocument::validate() [function.DOMDocument-validate]: Element
example was declared #PCDATA but contains non text nodes in
/script/path/xml.php on line 19

Warning: DOMDocument::validate() [function.DOMDocument-validate]: No
declaration for element a in /script/path/xml.php on line 19

0

Actual result:
--
When no argument is passed to validate and DTD server is off-line:

Valid XML:

Warning: DOMDocument::validate(http://example.com/mydtd.dtd)
[function.DOMDocument-validate]: failed to open stream: HTTP request
failed! HTTP/1.1 404 Not Found in /script/path/xml.php on line 14

Warning: DOMDocument::validate() [function.DOMDocument-validate]: I/O
warning : failed to load external entity "http://example.com/mydtd.dtd"; in
/script/path/xml.php on line 14

Warning: DOMDocument::validate() [function.DOMDocument-validate]: Could
not load the external subset "http://example.com/mydtd.dtd"; in
/script/path/xml.php on line 14

0

Invalid XML:

Warning: DOMDocument::validate(http://example.com/mydtd.dtd)
[function.DOMDocument-validate]: failed to open stream: HTTP request
failed! HTTP/1.1 404 Not Found in /script/path/xml.php on line 19

Warning: DOMDocument::validate() [function.DOMDocument-validate]: I/O
warning : failed to load external entity "http://example.com/mydtd.dtd"; in
/script/path/xml.php on line 19

Warning: DOMDocument::validate() [function.DOMDocument-validate]: Could
not load the external subset "http://example.com/mydtd.dtd"; in
/script/path/xml.php on line 19

0

-- 
Edit bug report at http://bugs.php.net/?id=48080&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48080&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48080&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48080&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48080&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48080&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48080&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48080&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48080&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48080&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48080&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48080&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48080&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48080&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48080&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48080&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48080&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48080&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48080&r=gnused
Floa

#47782 [Bgs]: Anomalous results from stored procedure with a PREPAREd statement

2009-04-26 Thread phpbug at smithii dot com
 ID:   47782
 User updated by:  phpbug at smithii dot com
 Reported By:  phpbug at smithii dot com
 Status:   Bogus
 Bug Type: MySQLi related
 Operating System: Linux, Windows
 PHP Version:  5.2.9, 5.3.0RC2
 New Comment:

j...@php.net: I can call stored procedures just fine with
execute()/bind_result()/fetch(). This is the method the Zend Framework
uses, and I don't want to rewrite their classes. I'm sure there are many
other PHP frameworks that use these functions as well.

Also, the mysqli_multi_query() function does not allow me to prepare()
a statement once, and then execute() it multiple times.

The only problem I'm having, and it's still a problem with PHP 5.3 and
MySQL 5.1, is that if the stored procedure contains a PREPAREd
statement, then the fetch() function is returning corrupted data.

This sure seems to me to be an actual bug, and not just that I'm using
the wrong function call.

Therefore, please mark this bug as open.

I will attempt to fix this myself. Can you point me to any
documentation or IRC channel, that would help me to get started?

Thanks for any assistance,

Ross


Previous Comments:


[2009-04-26 15:41:48] j...@php.net

For calling stored procedures you have to use mysqli_multi_query.



[2009-04-15 10:09:31] phpbug at smithii dot com

The following script produces errors on 5.2.9 and 5.3.0RC2, on both
Linux and Windows:

 $sql) {
$mysqli->query("DROP PROCEDURE IF EXISTS echo$i");
$mysqli->query($sql) || die($mysqli->error);
$sql = "CALL echo$i(?)";
printf("Executing: %s with '%s'\n", $sql, $inp);
$s = $mysqli->prepare($sql);
if (!$s) die($mysqli->error);
printf("inp=%s (%s)\n", $inp, bin2hex($inp));
$s->bind_param('s', $inp) || die($mysqli->error);
$s->execute() || die($mysqli->error);
$s->bind_result($out) || die($mysqli->error);
while ($s->fetch()) {
   printf("out=%s (%s)\n", $out, bin2hex($out));
}
$s->close();
}

Here's the script's output:

Executing: CALL echo0(?) with '1234'
inp=1234 (31323334)
out=1234 (31323334)
Executing: CALL echo1(?) with '1234'
inp=1234 (31323334)
out=34
(3334)
Executing: CALL echo2(?) with '1234'
inp=1234 (31323334)
out=34
(3334)
Executing: CALL echo3(?) with '1234'
inp=1234 (31323334)
out=3420978 (33343230393738)



[2009-03-26 00:08:39] phpbug at smithii dot com

Description:

Using MySQL 5.0.77, and calling a stored procedure with a PREPAREd
statement, execute()/bind_result()/fetch() return anomalous results.


Reproduce code:
---
Using MySQL 5.0.77, and calling any stored procedure with a PREPAREd
statement, such as:

DROP PROCEDURE IF EXISTS echo;
DELIMITER //
CREATE PROCEDURE echo(p VARCHAR(255))
BEGIN
SET @sql = CONCAT('SELECT ',QUOTE(p));
PREPARE stmt FROM @sql;
EXECUTE stmt;
DROP PREPARE stmt;
END;
//
DELIMITER ;

via this script:

prepare($sql);
$i = $argv[1];
printf("i=%s\n", $i);
$s->bind_param('s', $i);
$s->execute();
$s->bind_result($o);
while ($s->fetch()) {
   printf("o=%s (%s)\n", $o, bin2hex($o));
}
$s->close();

produces anomalous results at least 50% of the time. For example:

$ php echo.php abcd
i=abcd
o=cd  ♦ (636404)

If I remove the PREPAREd statement:

DROP PROCEDURE IF EXISTS echo;
DELIMITER //
CREATE PROCEDURE echo(p VARCHAR(255))
BEGIN
SELECT p;
END;
//
DELIMITER ;

everything works fine.

Replacing execute()/bind_result()/fetch(), with query()/fetch_assoc()
also fixes the issue.

Other details:

mysqli_get_client_info=5.0.51a
mysqli_get_client_version=50051
mysqli_get_server_info=5.0.77-community-nt
mysqli_get_server_version=50077
mysqli_get_host_info=localhost via TCP/IP
mysqli_get_proto_info=10


Expected result:

$ php echo.php abcd
i=abcd
o=abcd (63646566)


Actual result:
--
$ php echo.php abcd
i=abcd
o=cd  ♦ (636404)





-- 
Edit this bug report at http://bugs.php.net/?id=47782&edit=1



#47870 [Opn->Fbk]: array() returns NULL (works in PHP_5_2!)

2009-04-26 Thread jani
 ID:   47870
 Updated by:   j...@php.net
 Reported By:  mbecc...@php.net
-Status:   Open
+Status:   Feedback
 Bug Type: Arrays related
 Operating System: FreeBSD 6.2
 PHP Version:  5.3CVS-2009-04-01 (CVS)
 New Comment:

Try latest CVS just in case that GCC optimizer bugfix was the cause for

this bug as well.


Previous Comments:


[2009-04-06 13:05:25] mbecc...@php.net

Nope. Latest 5.1 and 5.2 work perfectly fine.



[2009-04-06 12:59:18] j...@php.net

Can you reproduce this with PHP_5_2 branch?



[2009-04-02 09:11:25] mbecc...@php.net

I've tried to reduce the affected test to a smaller test case with no
luck. As soon as I remove something from it. It suddenly starts to pass
with no segfault.



[2009-04-02 00:36:03] mbecc...@php.net

mat...@phenom-ubuntu:~/OX-trunk/tests$ valgrind --tool=memcheck
--num-callers=30 --log-file=php.log /usr/local/bin/php run.php
--type=unit --level=file --layer=dal --folder=lib/OA/Dal/Maintenance
--file=Priority_getZoneImpressionForecasts.dal.test.php --format=text
--host=test Priority_getZoneImpressionForecasts.dal.test.php
Segmentation fault
mat...@phenom-ubuntu:~/OX-trunk/tests$ cat php.log
==11808== Memcheck, a memory error detector.
==11808== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et
al.
==11808== Using LibVEX rev 1854, a library for dynamic binary
translation.
==11808== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==11808== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation
framework.
==11808== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et
al.
==11808== For more details, rerun with: -v
==11808== 
==11808== My PID = 11808, parent PID = 10101.  Prog and args are:
==11808==/usr/local/bin/php
==11808==run.php
==11808==--type=unit
==11808==--level=file
==11808==--layer=dal
==11808==--folder=lib/OA/Dal/Maintenance
==11808==--file=Priority_getZoneImpressionForecasts.dal.test.php
==11808==--format=text
==11808==--host=test
==11808==Priority_getZoneImpressionForecasts.dal.test.php
==11808== 
==11808== Conditional jump or move depends on uninitialised value(s)
==11808==at 0x7FF79D: _zval_ptr_dtor (zend_execute_API.c:430)
==11808==by 0x824537: zend_hash_clean (zend_hash.c:552)
==11808==by 0x849231: zend_leave_helper_SPEC
(zend_vm_execute.h:208)
==11808==by 0x8DC019: ZEND_RETURN_SPEC_CV_HANDLER
(zend_vm_execute.h:22098)
==11808==by 0x848774: execute (zend_vm_execute.h:104)
==11808==by 0x814198: zend_execute_scripts (zend.c:1188)
==11808==by 0x768884: php_execute_script (main.c:2157)
==11808==by 0x9125CE: main (php_cli.c:1159)
==11808== 
==11808== Conditional jump or move depends on uninitialised value(s)
==11808==at 0x7FF861: _zval_ptr_dtor (zend_execute_API.c:441)
==11808==by 0x824537: zend_hash_clean (zend_hash.c:552)
==11808==by 0x849231: zend_leave_helper_SPEC
(zend_vm_execute.h:208)
==11808==by 0x8DC019: ZEND_RETURN_SPEC_CV_HANDLER
(zend_vm_execute.h:22098)
==11808==by 0x848774: execute (zend_vm_execute.h:104)
==11808==by 0x814198: zend_execute_scripts (zend.c:1188)
==11808==by 0x768884: php_execute_script (main.c:2157)
==11808==by 0x9125CE: main (php_cli.c:1159)
==11808== 
==11808== Conditional jump or move depends on uninitialised value(s)
==11808==at 0x881939: zend_assign_to_variable (zend_execute.c:664)
==11808==by 0x8FCC90: ZEND_ASSIGN_SPEC_CV_VAR_HANDLER
(zend_vm_execute.h:27359)
==11808==by 0x848774: execute (zend_vm_execute.h:104)
==11808==by 0x814198: zend_execute_scripts (zend.c:1188)
==11808==by 0x768884: php_execute_script (main.c:2157)
==11808==by 0x9125CE: main (php_cli.c:1159)
==11808== 
==11808== Conditional jump or move depends on uninitialised value(s)
==11808==at 0x881991: zend_assign_to_variable (zend_execute.c:669)
==11808==by 0x8FCC90: ZEND_ASSIGN_SPEC_CV_VAR_HANDLER
(zend_vm_execute.h:27359)
==11808==by 0x848774: execute (zend_vm_execute.h:104)
==11808==by 0x814198: zend_execute_scripts (zend.c:1188)
==11808==by 0x768884: php_execute_script (main.c:2157)
==11808==by 0x9125CE: main (php_cli.c:1159)
==11808== 
==11808== Conditional jump or move depends on uninitialised value(s)
==11808==at 0x881A77: zend_assign_to_variable (zend_execute.c:684)
==11808==by 0x8FCC90: ZEND_ASSIGN_SPEC_CV_VAR_HANDLER
(zend_vm_execute.h:27359)
==11808==by 0x848774: execute (zend_vm_execute.h:104)
==11808==by 0x814198: zend_execute_scripts (zend.c:1188)
==11808==by 0x768884: php_execute_script (main.c:2157)
==11808==by 0x9125CE: main (php_cli.c:1159)
==11808== 
==11808== Conditional jump or move depends on uninitialis

#47782 [Opn->Bgs]: Anomalous results from stored procedure with a PREPAREd statement

2009-04-26 Thread jani
 ID:   47782
 Updated by:   j...@php.net
 Reported By:  phpbug at smithii dot com
-Status:   Open
+Status:   Bogus
 Bug Type: MySQLi related
 Operating System: Linux, Windows
 PHP Version:  5.2.9, 5.3.0RC2
 New Comment:

For calling stored procedures you have to use mysqli_multi_query.


Previous Comments:


[2009-04-15 10:09:31] phpbug at smithii dot com

The following script produces errors on 5.2.9 and 5.3.0RC2, on both
Linux and Windows:

 $sql) {
$mysqli->query("DROP PROCEDURE IF EXISTS echo$i");
$mysqli->query($sql) || die($mysqli->error);
$sql = "CALL echo$i(?)";
printf("Executing: %s with '%s'\n", $sql, $inp);
$s = $mysqli->prepare($sql);
if (!$s) die($mysqli->error);
printf("inp=%s (%s)\n", $inp, bin2hex($inp));
$s->bind_param('s', $inp) || die($mysqli->error);
$s->execute() || die($mysqli->error);
$s->bind_result($out) || die($mysqli->error);
while ($s->fetch()) {
   printf("out=%s (%s)\n", $out, bin2hex($out));
}
$s->close();
}

Here's the script's output:

Executing: CALL echo0(?) with '1234'
inp=1234 (31323334)
out=1234 (31323334)
Executing: CALL echo1(?) with '1234'
inp=1234 (31323334)
out=34
(3334)
Executing: CALL echo2(?) with '1234'
inp=1234 (31323334)
out=34
(3334)
Executing: CALL echo3(?) with '1234'
inp=1234 (31323334)
out=3420978 (33343230393738)



[2009-03-26 00:08:39] phpbug at smithii dot com

Description:

Using MySQL 5.0.77, and calling a stored procedure with a PREPAREd
statement, execute()/bind_result()/fetch() return anomalous results.


Reproduce code:
---
Using MySQL 5.0.77, and calling any stored procedure with a PREPAREd
statement, such as:

DROP PROCEDURE IF EXISTS echo;
DELIMITER //
CREATE PROCEDURE echo(p VARCHAR(255))
BEGIN
SET @sql = CONCAT('SELECT ',QUOTE(p));
PREPARE stmt FROM @sql;
EXECUTE stmt;
DROP PREPARE stmt;
END;
//
DELIMITER ;

via this script:

prepare($sql);
$i = $argv[1];
printf("i=%s\n", $i);
$s->bind_param('s', $i);
$s->execute();
$s->bind_result($o);
while ($s->fetch()) {
   printf("o=%s (%s)\n", $o, bin2hex($o));
}
$s->close();

produces anomalous results at least 50% of the time. For example:

$ php echo.php abcd
i=abcd
o=cd  ♦ (636404)

If I remove the PREPAREd statement:

DROP PROCEDURE IF EXISTS echo;
DELIMITER //
CREATE PROCEDURE echo(p VARCHAR(255))
BEGIN
SELECT p;
END;
//
DELIMITER ;

everything works fine.

Replacing execute()/bind_result()/fetch(), with query()/fetch_assoc()
also fixes the issue.

Other details:

mysqli_get_client_info=5.0.51a
mysqli_get_client_version=50051
mysqli_get_server_info=5.0.77-community-nt
mysqli_get_server_version=50077
mysqli_get_host_info=localhost via TCP/IP
mysqli_get_proto_info=10


Expected result:

$ php echo.php abcd
i=abcd
o=abcd (63646566)


Actual result:
--
$ php echo.php abcd
i=abcd
o=cd  ♦ (636404)





-- 
Edit this bug report at http://bugs.php.net/?id=47782&edit=1



#45468 [NoF->Asn]: Using mysqlnd defaults to using unix socket instead of localhost:port

2009-04-26 Thread jani
 ID:   45468
 Updated by:   j...@php.net
-Summary:  socket file problem when mysqlnd is enabled
 Reported By:  michael dot kofler at gmx dot com
-Status:   No Feedback
+Status:   Assigned
-Bug Type: MySQLi related
+Bug Type: MySQL related
-Operating System: *
+Operating System: * (not win32)
-PHP Version:  5.3.0alpha1
+PHP Version:  5.3CVS, 6CVS (2009-04-25)
-Assigned To:  mysql
+Assigned To:  johannes
 New Comment:

This is clearly a bug:

# sapi/cli/php -n -r 'mysql_connect("localhost:3306");'

Output with --with-mysql=mysqlnd:

Warning: mysql_connect(): [2002] No such file or directory (trying to 
connect via unix:///tmp/mysql.sock) in Command line code on line 1

# sapi/cli/php -n -r 'mysql_connect("localhost:3306");'

No output (error) --with-mysql (without mysqlnd) -> connection works.

The problem is with code in ext/mysqlnd/mysqlnd.c:537-543 which forces

using the socket in this case.

Note: Same happens with mysqli. This bug also makes all mysql(i) tests 

fail unless one uses some environment variables while running them.



Previous Comments:


[2009-02-03 11:59:28] and...@php.net

 Hi,
it was a problem, the Unix path, in the extensions, not mysqlnd. Yes,
mysqlnd uses /tmp/mysql.sock, but actually there are no configure
options for mysqlnd. --with-mysql-sock is actually an option of
ext/mysql . It wasn't used in the past, as far as I recall, but current
5_3 and HEAD do use it to set default value for the socket path, which
can be overwritten by the user. Both for ext/mysql and mysqli.
This if from ext/mysql/php_mysql.c :
#ifdef MYSQL_UNIX_ADDR
STD_PHP_INI_ENTRY("mysql.default_socket",   
MYSQL_UNIX_ADDR,PHP_INI_ALL,OnUpdateStringUnempty,  default_socket, 
zend_mysql_globals, mysql_globals)
#else
STD_PHP_INI_ENTRY("mysql.default_socket",   NULL,   
PHP_INI_ALL,OnUpdateStringUnempty,  default_socket, 
zend_mysql_globals, mysql_globals)
#endif


This is from ext/mysqli/mysql.c :
#ifdef PHP_MYSQL_UNIX_SOCK_ADDR
STD_PHP_INI_ENTRY("mysqli.default_socket",  
MYSQL_UNIX_ADDR,PHP_INI_ALL,OnUpdateStringUnempty,  default_socket, 
zend_mysqli_globals,mysqli_globals)
#else
STD_PHP_INI_ENTRY("mysqli.default_socket",  NULL,   
PHP_INI_ALL,OnUpdateStringUnempty,  default_socket, 
zend_mysqli_globals,mysqli_globals)
#endif

MYSQL_UNIX_ADDR is a macro, for PHP_MYSQL_UNIX_ADDR, which is defined
by the configure script if --with-mysql-sock is used.

In this regard, PDO doesn't use --with-mysql-sock. PDO_MYSQL used
mysql_config to find the socket, but for mysqln defaults to
/tmp/mysql.sock , which seems like bug, because of inconsistency.
This is something for Johannes

Best,
Andrey



[2009-02-03 11:43:38] johan...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

--with-mysql-sock should work now properly



[2008-08-07 08:01:44] michael dot kofler at gmx dot com

re-tested on Linux with alpha1, compiled with this configuration:

configure --with-mysqli=mysqlnd \
--with-mysql=mysqlnd \
--with-mysql-sock=/var/run/mysqld/mysqld.sock \
--enable-pdo \
--with-pdo-mysql=mysqlnd \
--with-apxs2=/usr/bin/apxs2 \
--with-zlib \
--with-gd \
--with-config-file-scan-dir=/etc/php5/apache2 \
--with-jpeg-dir=/usr/lib \
--enable-exif \
--libdir=/usr/lib \
--enable-mbstring  

also tried

--with-mysql-sock=/var/run/mysqld \

result: mysql, mysqli and PDO/mysql, all using mysqlnd, still look for
the socket file /tmp/mysql.sock and ignore --with-mysql-sock

if I compile without mysqlnd and without the --with-mysql-sock option,
PHP automatically finds the right socket file, probably because libmysql
reads the [client] settings in /etc/mysql/my.cnf

my solution for now: I changed all socket options in /etc/mysql/my.cnf
and /etc/mysql/debian.cnf

it would be better either to provide a working configure option for PHP
(--mysqlnd-sock=...) or to evaluate my.cnf within mysqlnd

--

PS: as to mysqlnd not supporting old MySQL authentication: perfectly
fine for me, but *do document* it in some PHP 5.3 update advisory;
otherwise I am pretty sure the update to PHP 5.3 will cause trouble for
many MySQL users



[2008-07-23 11:37:26] u...@php.net

>From the begin on mysqlnd has been described as MySQL 4.1+. We won't
make it work with any MySQL <4.1. See also the MySQL Lifecycle Policy.

Those distributions that use old_passwords=1 have two choices: use a
different config

#48078 [Opn->Bgs]: SimpleXML allows white spaces as attribute names

2009-04-26 Thread iliaa
 ID:   48078
 Updated by:   il...@php.net
 Reported By:  ifegh...@php.net
-Status:   Open
+Status:   Bogus
 Bug Type: SimpleXML related
 Operating System: Mac OS X
 PHP Version:  5.3.0RC1
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

I think its more along the lines of a libxml2 bug then PHP's since 
attribute creation is done by simply calling the libxml API. PHP cannot

perform validation on XML.


Previous Comments:


[2009-04-26 12:18:27] ifegh...@php.net

Description:

SimpleXML allows the creation of attributes containing white spaces in
the name. This violates the XML specs [1].

* reported by Thiago Toledo during PHP Test Fest 2009 (Rio UG).

[1] http://www.w3.org/TR/2006/REC-xml11-20060816/#NT-NameChar

Reproduce code:
---
";
$myXML = new SimpleXMLElement($xmlExample);
$myXML->addAttribute('Basic Attribute','Basic Attribute Content');
echo $myXML->asXML();
?>

Expected result:

Warning: Wrong character for XML attribute name

Actual result:
--







-- 
Edit this bug report at http://bugs.php.net/?id=48078&edit=1



#48079 [NEW]: Provide a way to serialize classes to include files

2009-04-26 Thread php at prog dot hu
From: php at prog dot hu
Operating system: 
PHP version:  5.3.0RC1
PHP Bug Type: Feature/Change Request
Bug description:  Provide a way to serialize classes to include files

Description:

This entry is about a feature request for a way to serialize/export
complete class structures to include files. 

The purpose of this extensions would be to enable template systems,
configuration intensive frameworks, etc. to use a persistent object storage
which can take advantage of present opcode accelerators (eAccelerator,
mmcache, etc), and thus avoid the overhead of classical parsing of
serialized objects.

Classical serialize()/unserialize() gets very slow when the serialized
state grows large (>100KB), and is also a waste of CPU with mostly static
serialized objects, as it forces PHP to parse the serialized string over
and over (even when it's more effective than direct PHP source parsing).
The solution to this problem could be to provide a way to export complete
objects and object structures (also including circular or back+forth
references) to PHP include files, which then in turn - when stored in the
file system - could be easily re-instantiated at any point without the need
of a re-parse if an accelerator is present in the system. (Even if an
accelerator isn't present, the overhead of parsing a var_export-style
object-construction shouldn't be lot worser than parsing the output of
serialize(), and shouldn't result in significantly larger output).

Currently PHP provides no integral means to to such an export
(var_export() fails on circular references and too deep object nesting),
and even though this can be circumvented from custom PHP code (with a lot
of tricks, like casting an object to an array to be able to enumerate all
it's members, including hidden ones, and usage of reflection API to get the
actual value of hidden member fields), there's practically no way to
re-instantiate the class in/from the generated source (include), as the
standard constructor can't be avoided/circumvented when re-instantiating an
object, making it impossible to load an object state directly back into
memory.

To solve the problem PHP should provide a way to statically instantiate a
class with predefined member field values (much like the __set_state()
magic method, but _without the need of define this method in each classes_,
and also without the method calling the "normal" constructor used for
in-code instantiation, which defeats the purpose of serialization). This
method the could be used in the generated include files to re-instantiate
the class and restore it's state as it was when it was serialized. Circular
references can be easily resolved with late-binding in the include, so
practically the var_export() style can be preserved (with extra fixup code
added after the basic construction of the object-hierarchy skeleton, to
resolve the circular references). 

The extra method wouldn't open up any new security vulnerabilities and
affect the object integrity (by avoiding the standard constructor and thus
theorethically enabling to set all kind of inconsistent values in member
fields accross the objects), as the input of unserialize() can be
manipulated too anyway, so construction of possibly invalid object states
and creation of objects with arbitrary member field values is already
possible even without this special method/function I'm asking for.


-- 
Edit bug report at http://bugs.php.net/?id=48079&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48079&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48079&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48079&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48079&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48079&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48079&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48079&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48079&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48079&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48079&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48079&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48079&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48079&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48079&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48079&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48079&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48079&r=isapi
Install GNU Sed:  

#48078 [NEW]: SimpleXML allows white spaces as attribute names

2009-04-26 Thread ifegh...@php.net
From: ifegh...@php.net
Operating system: Mac OS X
PHP version:  5.3.0RC1
PHP Bug Type: SimpleXML related
Bug description:  SimpleXML allows white spaces as attribute names

Description:

SimpleXML allows the creation of attributes containing white spaces in the
name. This violates the XML specs [1].

* reported by Thiago Toledo during PHP Test Fest 2009 (Rio UG).

[1] http://www.w3.org/TR/2006/REC-xml11-20060816/#NT-NameChar

Reproduce code:
---
";
$myXML = new SimpleXMLElement($xmlExample);
$myXML->addAttribute('Basic Attribute','Basic Attribute Content');
echo $myXML->asXML();
?>

Expected result:

Warning: Wrong character for XML attribute name

Actual result:
--



-- 
Edit bug report at http://bugs.php.net/?id=48078&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48078&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48078&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48078&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48078&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48078&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48078&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48078&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48078&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48078&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48078&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48078&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48078&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48078&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48078&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48078&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48078&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48078&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48078&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48078&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48078&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48078&r=mysqlcfg



#48070 [Opn]: PDO_OCI Segfault when using persistent connection

2009-04-26 Thread jarismar dot php at gmail dot com
 ID:   48070
 User updated by:  jarismar dot php at gmail dot com
 Reported By:  jarismar dot php at gmail dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: *
 PHP Version:  5.2CVS-2009-04-24 (CVS)
 New Comment:

This seems to fix these two bugs also,

Bug #42075  pdo_oci crash (with persistent connection) when couldn't
connect to db
Bug #44560  Apache crashes with PDO_OCI and both persistent and
non-persistent connections.


Previous Comments:


[2009-04-24 14:11:13] jarismar dot php at gmail dot com

I think, this happens because error messages are being created with
pestrdup and later destructed with efree.

I've changed the pdo_oci extension to use pefree when appropriate, it
seems to solve the problem.

This is the patch against PHP_5_2 tip.

cvs diff - u >
Index: oci_driver.c
===
RCS file: /repository/php-src/ext/pdo_oci/oci_driver.c,v
retrieving revision 1.24.2.4.2.11
diff -u -u -p -r1.24.2.4.2.11 oci_driver.c
--- oci_driver.c31 Dec 2008 11:17:42 -  1.24.2.4.2.11
+++ oci_driver.c24 Apr 2009 10:47:29 -
@@ -70,16 +70,15 @@ ub4 _oci_error(OCIError *err, pdo_dbh_t 
S = (pdo_oci_stmt*)stmt->driver_data;
einfo = &S->einfo;
pdo_err = &stmt->error_code;
-   if (einfo->errmsg) {
-   efree(einfo->errmsg);
-   }
}
else {
einfo = &H->einfo;
-   if (einfo->errmsg) {
-   pefree(einfo->errmsg, dbh->is_persistent);
-   }
}
+   
+   if (einfo->errmsg) {
+   pefree(einfo->errmsg, dbh->is_persistent);
+   }
+
 
einfo->errmsg = NULL;
einfo->errcode = 0;
Index: oci_statement.c
===
RCS file: /repository/php-src/ext/pdo_oci/oci_statement.c,v
retrieving revision 1.16.2.10.2.9
diff -u -u -p -r1.16.2.10.2.9 oci_statement.c
--- oci_statement.c 31 Dec 2008 11:17:42 -  1.16.2.10.2.9
+++ oci_statement.c 24 Apr 2009 10:47:30 -
@@ -54,6 +54,7 @@ static php_stream *oci_create_lob_stream
 static int oci_stmt_dtor(pdo_stmt_t *stmt TSRMLS_DC) /* {{{ */
 {
pdo_oci_stmt *S = (pdo_oci_stmt*)stmt->driver_data;
+   pdo_dbh_t *dbh = stmt->dbh;
HashTable *BC = stmt->bound_columns;
HashTable *BP = stmt->bound_params;
 
@@ -87,7 +88,7 @@ static int oci_stmt_dtor(pdo_stmt_t *stm
}
 
if (S->einfo.errmsg) {
-   efree(S->einfo.errmsg);
+   pefree(S->einfo.errmsg, dbh->is_persistent);
S->einfo.errmsg = NULL;
}



[2009-04-24 14:09:13] jarismar dot php at gmail dot com

Description:

When using persistent connections apache segfaults at end of the
request.
The segfault only happens if some statment has got error.

Reproduced on Windows (XP) and Linux (debian 2.6.29-1-686).



Reproduce code:
---
$sDSN = 'oci:dbname=//webreport:1521/adplabs';
$sUserName = 'rpttest82';
$sPassword = 'rpttest82';

$oPDO = new PDO($sDSN, $sUserName, $sPassword,
array(PDO::ATTR_PERSISTENT => true));
$oPDO->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
try {
  $oStatement = $oPDO->prepare('Select x from no_table');
  $oStatement->execute();
} catch (Exception $oException) {
  print $oException->getMessage()."\n";
}

Expected result:

SQLSTATE[HY000]: General error: 942 OCIStmtExecute: ORA-00942: table or
view does not exist
 (/home/jaris/php-latest/ext/pdo_oci/oci_statement.c:147)

Actual result:
--
Windows :

Unhandled exception at 0x0088ad16 (php5ts.dll) in Apache.exe:
0xC005: Access violation reading location 0x002c5cc4.

Debian :
segmentation fault
ALERT - canary mismatch on efree() - heap overflow detected (attacker
'REMOTE_ADDR not set', file 'unknown')





-- 
Edit this bug report at http://bugs.php.net/?id=48070&edit=1