#48052 [Opn->Asn]: SPLStack::setIteratorMode() throw exception on keep/delete flag
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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!)
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
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
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
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
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
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
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