Bug #64267 [Opn->Fbk]: ldap_bind crash for ldaps://
Edit report at https://bugs.php.net/bug.php?id=64267&edit=1 ID: 64267 Updated by: paj...@php.net Reported by:andrew+bugsphp at wimpyprogrammer dot com Summary:ldap_bind crash for ldaps:// -Status: Open +Status: Feedback Type: Bug Package:LDAP related Operating System: Windows Server 2008 R2 x64 PHP Version:5.4.12 Block user comment: N Private report: N New Comment: PHP is loading openssl 1.0.0 while it is built and requires 0.9.x series. That's the cause of the crash (openssl is very sensible and break ABI between these versions). Snapshots are available here: http://windows.php.net/downloads/snaps/php-5.4/ Please try again and be sure to only have openssl 0.9.x (bundled with the release) in the PATH used by the PHP processes. Previous Comments: [2013-02-21 20:58:37] andrew+bugsphp at wimpyprogrammer dot com Here's the backtrace. I hope I captured it correctly. I struggled to find a debug file for libeay32.dll and ended up using http://www.orangefs.org/trac/orangefs/browser/branches/windows-client/openssl- windows/bin64/debug?rev=8844. Thanks! - Thread 0 - System ID 3660 Entry point php_cgi!mainCRTStartup Create time 2/21/2013 3:07:58 PM Time spent in user mode 0 Days 0:0:0.656 Time spent in kernel mode 0 Days 0:0:0.312 Full Call Stack Function Arg 1 Arg 2 Arg 3 Arg 4 Source libeay32!OPENSSL_showfatal+c0 0001 0064 01bf1b48 0024b80c g:\root\pvfsdev\windows\openssl-1.0.0d\crypto\cryptlib.c @ 831 + f libeay32!bn_mul_high+75f 01c798b4 01c798a4 01bf1b48 0025e0ee g:\root\pvfsdev\windows\openssl-1.0.0d\crypto\bn\bn_mul.c @ 890 + 1e ssleay32!SSLv3_client_method+18c 01bf1b48 01c41d38 72096bb8 01bf1b48 ssleay32!SSL_free+19e 01bf1b48 01c41d38 720a659b 01c41d38 php_ldap!ldap_search_s+1c8 01c41d38 01c41d18 01c41b78 720a6907 php_ldap!ber_sockbuf_remove_io+7b 01c41b78 720b52e8 0014 70f52dec php_ldap!ber_int_sb_destroy+57 01c41b78 01c41b78 014ba128 php_ldap!ber_sockbuf_free+44 01c41b78 014ba128 7209b949 php_ldap!ldap_ld_free+1ad 014ba128 0001 php_ldap!ldap_unbind_ext+59 014ba128 720a9f80 php_ldap!ldap_unbind_s+e 014ba128 0002 6ec4cd63 008ecb68 php_ldap!_close_ldap_link+f 008ecb68 6ec60b97 008ecb68 0126f068 c:\php-sdk\php54dev\vc9\x86\php-5.4.12\ext\ldap\ldap.c @ 103 php5!list_entry_destructor+43 008edc54 009d1410 0126f1dc 6ecaf59d c:\php-sdk\php54dev\vc9\x86\php-5.4.12\zend\zend_list.c @ 178 + 2 php5!zend_hash_apply_deleter+6c 01c44480 6f1b5330 6ec3cd06 6f1b5b78 c:\php-sdk\php54dev\vc9\x86\php-5.4.12\zend\zend_hash.c @ 650 + 5 php5!zend_hash_graceful_reverse_destroy+d 6f1b5b78 6f1b5a60 6ee7cd24 01c44480 c:\php-sdk\php54dev\vc9\x86\php-5.4.12\zend\zend_hash.c @ 688 php5!shutdown_executor+46 01c8f450 008ed678 c:\php-sdk\php54dev\vc9\x86\php-5.4.12\zend\zend_execute_api.c @ 247 + a php5!zend_deactivate+49 0001 004800c4 c:\php-sdk\php54dev\vc9\x86\php-5.4.12\zend\zend.c @ 940 php5!php_request_shutdown+198 00a6d500 0001 c:\php-sdk\php54dev\vc9\x86\php-5.4.12\main\main.c @ 1803 php_cgi!main+3db 0003 009d2f80 009d1bf8 21c90fe5 c:\php- sdk\php54dev\vc9\x86\php-5.4.12\sapi\cgi\cgi_main.c @ 2498 + 7 php_cgi!__tmainCRTStartup+10f 7efde000 0126f84c 776d9ed2 7efde000 f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 586 + 17 kernel32!BaseThreadInitThunk+12 7efde000 1083a766 ntdll!RtlInitializeExceptionChain+63 00a63a39 7efde000 777672ff ntdll!RtlInitializeExceptionChain+36 00a63a39 7efde000 Exception Information LIBEAY32!OPENSSL_SHOWFATAL+C0In php- cgi__PID__3152__Date__02_21_2013__Time_03_08_05PM__37__Second_Chance_Exception_C 005.dmp the assembly instruction at libeay32!OPENSSL_showfatal+c0 in C:\Program Files (x86)\PHP\PHP_5_4_12_NTS_x86\libeay32.dll from The OpenSSL Project, http://www.openssl.org/ has caused an access violation exception (0xC005) when trying to write to memory location 0x0001 on thread 0 Module Information Image Name: C:\Program Files (x86)\PHP\PHP_5_4_12_NTS_x86\libeay32.dll Symbol Type: PDB Base address: 0x00905a4d Time Stamp: Wed Feb 13 05:36:27 2013 Checksum: 0x65006200 Comments: COM DLL: False Company Name: The OpenSSL Project, http://www.openssl.org/ ISAPIExtension: False File De
Bug #64258 [Opn]: XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet)
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet) Status: Open Type: Bug Package:XML Reader PHP Version:5.4.11 Block user comment: N Private report: N New Comment: I would guess that mere presence of --with-mcrypt on configure breaks linking to custom libxml2 directory (--with-libxml-dir=/usr/libxml2-2.9.0/) and it defaults to system /usr/lib64 (and there is distro standard old libxml2 there which break things). Previous Comments: [2013-02-22 01:38:34] spamik at yum dot pl also during make install (php) i see ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) I did not linked to usr/lib64/libxml2.so.2 !! Some error in linking (but only when mcrypt is present) [2013-02-22 01:23:02] spamik at yum dot pl >>Problem appears when compiling with mcrypt and extension (and libxml2 2.9)<< Package libmcrypt-devel-2.5.8-4.el5.centos.x86_64 already installed and latest version ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install datadata'; $xml->XML($xmldata); ?> /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup I've also tried compiling libmcrypt from source - no changes. ./configure --prefix=/usr/libmcrypt-2.5.8 --disable-posix-threads make install ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt=/usr/libmcrypt-2.5.8' sill does not work (it works with libxml2 2.6.x for some reason) [2013-02-22 00:28:10] spamik at yum dot pl I've tested with ONLY --with-libxml-dir=/usr/libxml2-2.9.0 and it does work. Some other extension (on my normal configure) must be interfering. I will try to determine which one with trial and error and soon let you know. [2013-02-21 15:33:00] r...@php.net Cannot reproduce. php 5.4.11 and 5.4.12 build against libxml2 and work as expected. ---
Bug #64258 [Opn]: XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet)
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet) Status: Open Type: Bug Package:XML Reader PHP Version:5.4.11 Block user comment: N Private report: N New Comment: also during make install (php) i see ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) I did not linked to usr/lib64/libxml2.so.2 !! Some error in linking (but only when mcrypt is present) Previous Comments: [2013-02-22 01:23:02] spamik at yum dot pl >>Problem appears when compiling with mcrypt and extension (and libxml2 2.9)<< Package libmcrypt-devel-2.5.8-4.el5.centos.x86_64 already installed and latest version ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install datadata'; $xml->XML($xmldata); ?> /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup I've also tried compiling libmcrypt from source - no changes. ./configure --prefix=/usr/libmcrypt-2.5.8 --disable-posix-threads make install ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt=/usr/libmcrypt-2.5.8' sill does not work (it works with libxml2 2.6.x for some reason) [2013-02-22 00:28:10] spamik at yum dot pl I've tested with ONLY --with-libxml-dir=/usr/libxml2-2.9.0 and it does work. Some other extension (on my normal configure) must be interfering. I will try to determine which one with trial and error and soon let you know. [2013-02-21 15:33:00] r...@php.net Cannot reproduce. php 5.4.11 and 5.4.12 build against libxml2 and work as expected. [2013-02-21 00:01:56] spamik at yum dot pl Description: datadata'; $xml->XML($xmldata); ?> php 5.4.11 compiled with libxml2 2.9.0 /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup It works when php is compiled against libxml2 2.6.26 XMLReader is not compatibile with new libxml2 vers
Bug #64258 [Opn]: XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet)
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet) Status: Open Type: Bug Package:XML Reader PHP Version:5.4.11 Block user comment: N Private report: N New Comment: >>Problem appears when compiling with mcrypt and extension (and libxml2 2.9)<< Package libmcrypt-devel-2.5.8-4.el5.centos.x86_64 already installed and latest version ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install datadata'; $xml->XML($xmldata); ?> /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup I've also tried compiling libmcrypt from source - no changes. ./configure --prefix=/usr/libmcrypt-2.5.8 --disable-posix-threads make install ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt=/usr/libmcrypt-2.5.8' sill does not work (it works with libxml2 2.6.x for some reason) Previous Comments: [2013-02-22 00:28:10] spamik at yum dot pl I've tested with ONLY --with-libxml-dir=/usr/libxml2-2.9.0 and it does work. Some other extension (on my normal configure) must be interfering. I will try to determine which one with trial and error and soon let you know. [2013-02-21 15:33:00] r...@php.net Cannot reproduce. php 5.4.11 and 5.4.12 build against libxml2 and work as expected. [2013-02-21 00:01:56] spamik at yum dot pl Description: datadata'; $xml->XML($xmldata); ?> php 5.4.11 compiled with libxml2 2.9.0 /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup It works when php is compiled against libxml2 2.6.26 XMLReader is not compatibile with new libxml2 version. -- Edit this bug report at https://bugs.php.net/bug.php?id=64258&edit=1
Bug #64253 [Opn]: alpha 5 does not load extensions
Edit report at https://bugs.php.net/bug.php?id=64253&edit=1 ID: 64253 Updated by: szar...@php.net Reported by:bugzilla77 at gmail dot com Summary:alpha 5 does not load extensions Status: Open Type: Bug Package:Dynamic loading Operating System: win 7 32 PHP Version:5.5.0alpha4 Block user comment: N Private report: N New Comment: Thanks for reporting this. We narrowed this down to a build issue with the ZTS build of PHP-5.5.0alpha5. I have fixed the issue and updated the build and checksum on http://windows.php.net/qa. Can you please test the new build and let me know if it fixes the issue? Thanks, Steve Previous Comments: [2013-02-20 19:57:36] bugzilla77 at gmail dot com I have TS and: ;extension=php_bz2.dll extension=php_com_dotnet.dll ;extension=php_curl.dll ;extension=php_fileinfo.dll extension=php_gd2.dll ;extension=php_gettext.dll ;extension=php_gmp.dll ;extension=php_intl.dll ;extension=php_imap.dll ;extension=php_interbase.dll ;extension=php_ldap.dll extension=php_mbstring.dll ;extension=php_exif.dll ; Must be after mbstring as it depends on it ;extension=php_mysql.dll ;extension=php_mysqli.dll ;extension=php_oci8.dll ; Use with Oracle 10gR2 Instant Client ;extension=php_oci8_11g.dll ; Use with Oracle 11gR2 Instant Client ;extension=php_openssl.dll ;extension=php_pdo_firebird.dll ;extension=php_pdo_mysql.dll ;extension=php_pdo_oci.dll ;extension=php_pdo_odbc.dll ;extension=php_pdo_pgsql.dll ;extension=php_pdo_sqlite.dll ;extension=php_pgsql.dll ;extension=php_pspell.dll ;extension=php_shmop.dll ; The MIBS data available in the PHP distribution must be installed. ; See http://www.php.net/manual/en/snmp.installation.php ;extension=php_snmp.dll ;extension=php_soap.dll ;extension=php_sockets.dll ;extension=php_sqlite3.dll ;extension=php_sybase_ct.dll ;extension=php_tidy.dll ;extension=php_xmlrpc.dll ;extension=php_xsl.dll ;extension=php_zip.dll and a have not loaded php_com_dotnet.dll, php_mbstring.dll etc On php 5.5 aplpha 4 is ok with the same php.ini [2013-02-20 19:34:05] mattfic...@php.net Extensions are fine for me with 5.5.0a5-NTS on Windows7, but the following extensions are missing on 5.5.0a5-TS: bz2 exif fileinfo gd gettext imap intl mysql mysqli pdo_mysql pdo_pgsql pgsql openssl soap wddx xmlrpc The TS and NTS builds of 5.4.12 and 5.3.22 all have all the extensions though (so its only a 5.5.0a5-TS problem). [2013-02-20 16:57:01] bugzilla77 at gmail dot com Description: alpha 5 does not load extensions Expected result: alpha 4 loads extensions on the same php.ini Actual result: -- alpha 5 does not load extensions -- Edit this bug report at https://bugs.php.net/bug.php?id=64253&edit=1
Bug #64258 [Opn]: XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet)
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet) Status: Open Type: Bug Package:XML Reader PHP Version:5.4.11 Block user comment: N Private report: N New Comment: I've tested with ONLY --with-libxml-dir=/usr/libxml2-2.9.0 and it does work. Some other extension (on my normal configure) must be interfering. I will try to determine which one with trial and error and soon let you know. Previous Comments: [2013-02-21 15:33:00] r...@php.net Cannot reproduce. php 5.4.11 and 5.4.12 build against libxml2 and work as expected. [2013-02-21 00:01:56] spamik at yum dot pl Description: datadata'; $xml->XML($xmldata); ?> php 5.4.11 compiled with libxml2 2.9.0 /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup It works when php is compiled against libxml2 2.6.26 XMLReader is not compatibile with new libxml2 version. -- Edit this bug report at https://bugs.php.net/bug.php?id=64258&edit=1
Bug #63378 [Nab]: xmlreader libxml2 2.9.0 undefined symbol: xmlTextReaderSetup
Edit report at https://bugs.php.net/bug.php?id=63378&edit=1 ID: 63378 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:xmlreader libxml2 2.9.0 undefined symbol: xmlTextReaderSetup Status: Not a bug Type: Bug Package:XML Reader PHP Version:5.4.8 Block user comment: N Private report: N New Comment: I never said it does not build! /usr/bin/php: undefined symbol: xmlTextReaderSetup is obviosly runtime crash not a build problem (which does not happen when build against very old libxml2 2.6.26) I always do clean build. Previous Comments: [2013-02-21 12:36:14] paj...@php.net @spamik at yum dot pl What Felipe said is correct. It builds just fine using 2.9.0 (be unix or windows). Try again using a clean build (read: either download 5.4.x again or do a buildconf, configure, etc.). [2013-02-20 23:58:13] spamik at yum dot pl Not an answer. Not related to the question. Yes a bug in libxml extension which is not compatibile with new libxml2 libs. [2012-10-29 15:25:36] fel...@php.net 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. Not a PHP problem. Try a clean PHP build on your system again. [2012-10-28 21:29:03] spamik at yum dot pl Description: datadata'; $xml->XML($xmldata); ?> php 5.4.8 compiled with libxml2 2.9.0 /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup It works when php is compiled against libxml2 2.6.26 -- Edit this bug report at https://bugs.php.net/bug.php?id=63378&edit=1
Bug #63983 [Com]: enabling FPM borks compile
Edit report at https://bugs.php.net/bug.php?id=63983&edit=1 ID: 63983 Comment by: phpfpm1 at gmail dot com Reported by:jhein_98 at swbell dot net Summary:enabling FPM borks compile Status: Open Type: Bug Package:Compile Failure Operating System: FreeBSD 9.1 PHP Version:5.4.10 Block user comment: N Private report: N New Comment: Any new on this? It's still not fixed. Patch submitted works fine. Previous Comments: [2013-01-14 05:39:01] jhein_98 at swbell dot net After doing some research, I think I may have found a fix. I'm testing it now Fix: just replace in file fpm_sockets.c : 1)info.tcpi_sacked => info.__tcpi_sacked 2)info.tcpi_unacked => info.__tcpi_unacked Hopefully this works and helps someone else. [2013-01-14 04:53:03] jhein_98 at swbell dot net Description: Running the configure script with --enable-fpm causes make to fail with the following errors: /usr/local/src/php-5.4.10/sapi/fpm/fpm/fpm_sockets.c -o sapi/fpm/fpm/fpm_sockets.lo /usr/local/src/php-5.4.10/sapi/fpm/fpm/fpm_sockets.c: In function 'fpm_socket_get_listening_queue': /usr/local/src/php-5.4.10/sapi/fpm/fpm/fpm_sockets.c:404: error: 'struct tcp_info' has no member named 'tcpi_sacked' /usr/local/src/php-5.4.10/sapi/fpm/fpm/fpm_sockets.c:409: error: 'struct tcp_info' has no member named 'tcpi_unacked' /usr/local/src/php-5.4.10/sapi/fpm/fpm/fpm_sockets.c:413: error: 'struct tcp_info' has no member named 'tcpi_sacked' *** [sapi/fpm/fpm/fpm_sockets.lo] Error code 1 Stop in /usr/local/src/php-5.4.10. The specific options I passed to the configure script was: ./configure --prefix=/usr/local/software/php --mandir=/usr/local/man --enable-cgi --enable-fpm --with-mysql=/usr/local/software/mysql --with-openssl-dir=/usr/local/software/openssl -- Edit this bug report at https://bugs.php.net/bug.php?id=63983&edit=1
Bug #64070 [Com]: Inheritance with Traits failed with error
Edit report at https://bugs.php.net/bug.php?id=64070&edit=1 ID: 64070 Comment by: alexander at mailinator dot net Reported by:denny dot reeh at gmail dot com Summary:Inheritance with Traits failed with error Status: Closed Type: Bug Package:Scripting Engine problem PHP Version:5.4.11 Assigned To:dmitry Block user comment: N Private report: N New Comment: Problem has not solved yet. Test snapshot http://windows.php.net/downloads/snaps/php-5.4/r86c1a26/ and bug still present in it. Previous Comments: [2013-02-18 12:37:45] dmi...@php.net The fix for this bug has been committed. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2013-02-18 12:36:39] dmi...@php.net Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=42437dd870de28eee6c9127f4c7e7c78ba8e0152 Log: Fixed bug #64070 (Inheritance with Traits failed with error) [2013-02-18 10:41:18] inefedor at gmail dot com Hi, I checked this problem with the master branch and yes, I was wrong, here's PR I attached to this bug, it solves the problem, but it won't work with xdebug extension. I'm not familiar with code of xdebug, I will contact with Derick about it. [2013-02-17 12:05:25] denny dot reeh at gmail dot com That can not be the solution. I've reproduced that issue in 5.4.11, but it was working in 5.4.10 [2013-02-17 11:11:22] inefedor at gmail dot com I can't find exact commit, but it works at least on 5.4.9 ( http://codepad.viper-7.com/GOqBix ). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64070 -- Edit this bug report at https://bugs.php.net/bug.php?id=64070&edit=1
[PHP-BUG] Bug #64271 [NEW]: imap_search has a bug
From: rixsta at hotmail dot com Operating system: Cent OS PHP version: Irrelevant Package: IMAP related Bug Type: Bug Bug description:imap_search has a bug Description: --- >From manual page: http://www.php.net/function.imap-search#refsect1- function.imap-search-description --- The following example should highlight this bug clearly: $newCount = count(imap_search($imap_stream, 'UNSEEN')); We use the function above to count the number of 'UNSEEN' messages in the mailbox folders. It works fine until we have read all messages and in this case we would expect the $newCount to be 0. However it remains at 1! We have been able to work around this bug with the following fix/function (see test script) This returns the count as we would expect. If you do address this bug we would appreciate a quick email and advise on the version of PHP it will be included in. Many thanks. Test script: --- $newCount = $this->count_unread_email($imap_stream); function count_unread_email($imap_stream) { $count = 0; if (!$imap_stream) { echo "Error"; } else { $headers = imap_headers($imap_stream); foreach ($headers as $mail) { $flags = substr($mail, 0, 4); $isunr = (strpos($flags, "U") !== false); if ($isunr) $count++; } } return $count; } Expected result: We expect the function to return 0 when there are no remaining 'UNSEEN' messages, not 1. Actual result: -- We receive a 1 even though there are 0 'UNSEEN' messages remaining in our mailbox folder. -- Edit bug report at https://bugs.php.net/bug.php?id=64271&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64271&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64271&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64271&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64271&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64271&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64271&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64271&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64271&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64271&r=support Expected behavior: https://bugs.php.net/fix.php?id=64271&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64271&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64271&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64271&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64271&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64271&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64271&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64271&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64271&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64271&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64271&r=mysqlcfg
Bug #64267 [Fbk->Opn]: ldap_bind crash for ldaps://
Edit report at https://bugs.php.net/bug.php?id=64267&edit=1 ID: 64267 User updated by:andrew+bugsphp at wimpyprogrammer dot com Reported by:andrew+bugsphp at wimpyprogrammer dot com Summary:ldap_bind crash for ldaps:// -Status: Feedback +Status: Open Type: Bug Package:LDAP related Operating System: Windows Server 2008 R2 x64 -PHP Version:5.4Git-2013-02-21 (snap) +PHP Version:5.4.12 Block user comment: N Private report: N New Comment: Here's the backtrace. I hope I captured it correctly. I struggled to find a debug file for libeay32.dll and ended up using http://www.orangefs.org/trac/orangefs/browser/branches/windows-client/openssl- windows/bin64/debug?rev=8844. Thanks! - Thread 0 - System ID 3660 Entry point php_cgi!mainCRTStartup Create time 2/21/2013 3:07:58 PM Time spent in user mode 0 Days 0:0:0.656 Time spent in kernel mode 0 Days 0:0:0.312 Full Call Stack Function Arg 1 Arg 2 Arg 3 Arg 4 Source libeay32!OPENSSL_showfatal+c0 0001 0064 01bf1b48 0024b80c g:\root\pvfsdev\windows\openssl-1.0.0d\crypto\cryptlib.c @ 831 + f libeay32!bn_mul_high+75f 01c798b4 01c798a4 01bf1b48 0025e0ee g:\root\pvfsdev\windows\openssl-1.0.0d\crypto\bn\bn_mul.c @ 890 + 1e ssleay32!SSLv3_client_method+18c 01bf1b48 01c41d38 72096bb8 01bf1b48 ssleay32!SSL_free+19e 01bf1b48 01c41d38 720a659b 01c41d38 php_ldap!ldap_search_s+1c8 01c41d38 01c41d18 01c41b78 720a6907 php_ldap!ber_sockbuf_remove_io+7b 01c41b78 720b52e8 0014 70f52dec php_ldap!ber_int_sb_destroy+57 01c41b78 01c41b78 014ba128 php_ldap!ber_sockbuf_free+44 01c41b78 014ba128 7209b949 php_ldap!ldap_ld_free+1ad 014ba128 0001 php_ldap!ldap_unbind_ext+59 014ba128 720a9f80 php_ldap!ldap_unbind_s+e 014ba128 0002 6ec4cd63 008ecb68 php_ldap!_close_ldap_link+f 008ecb68 6ec60b97 008ecb68 0126f068 c:\php-sdk\php54dev\vc9\x86\php-5.4.12\ext\ldap\ldap.c @ 103 php5!list_entry_destructor+43 008edc54 009d1410 0126f1dc 6ecaf59d c:\php-sdk\php54dev\vc9\x86\php-5.4.12\zend\zend_list.c @ 178 + 2 php5!zend_hash_apply_deleter+6c 01c44480 6f1b5330 6ec3cd06 6f1b5b78 c:\php-sdk\php54dev\vc9\x86\php-5.4.12\zend\zend_hash.c @ 650 + 5 php5!zend_hash_graceful_reverse_destroy+d 6f1b5b78 6f1b5a60 6ee7cd24 01c44480 c:\php-sdk\php54dev\vc9\x86\php-5.4.12\zend\zend_hash.c @ 688 php5!shutdown_executor+46 01c8f450 008ed678 c:\php-sdk\php54dev\vc9\x86\php-5.4.12\zend\zend_execute_api.c @ 247 + a php5!zend_deactivate+49 0001 004800c4 c:\php-sdk\php54dev\vc9\x86\php-5.4.12\zend\zend.c @ 940 php5!php_request_shutdown+198 00a6d500 0001 c:\php-sdk\php54dev\vc9\x86\php-5.4.12\main\main.c @ 1803 php_cgi!main+3db 0003 009d2f80 009d1bf8 21c90fe5 c:\php- sdk\php54dev\vc9\x86\php-5.4.12\sapi\cgi\cgi_main.c @ 2498 + 7 php_cgi!__tmainCRTStartup+10f 7efde000 0126f84c 776d9ed2 7efde000 f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 586 + 17 kernel32!BaseThreadInitThunk+12 7efde000 1083a766 ntdll!RtlInitializeExceptionChain+63 00a63a39 7efde000 777672ff ntdll!RtlInitializeExceptionChain+36 00a63a39 7efde000 Exception Information LIBEAY32!OPENSSL_SHOWFATAL+C0In php- cgi__PID__3152__Date__02_21_2013__Time_03_08_05PM__37__Second_Chance_Exception_C 005.dmp the assembly instruction at libeay32!OPENSSL_showfatal+c0 in C:\Program Files (x86)\PHP\PHP_5_4_12_NTS_x86\libeay32.dll from The OpenSSL Project, http://www.openssl.org/ has caused an access violation exception (0xC005) when trying to write to memory location 0x0001 on thread 0 Module Information Image Name: C:\Program Files (x86)\PHP\PHP_5_4_12_NTS_x86\libeay32.dll Symbol Type: PDB Base address: 0x00905a4d Time Stamp: Wed Feb 13 05:36:27 2013 Checksum: 0x65006200 Comments: COM DLL: False Company Name: The OpenSSL Project, http://www.openssl.org/ ISAPIExtension: False File Description: OpenSSL Shared Library ISAPIFilter: False File Version: 0.9.8y Managed DLL: False Internal Name: libeay32 VB DLL: False Legal Copyright: Copyright © 1998-2007 The OpenSSL Project. Copyright © 1995-1998 Eric A. Young, Tim J. Hudson. All rights reserved. Loaded Image Name: libeay32.dll Legal Trademarks: Mapped Image Name: Original filename: libeay32.dll Module name: libeay32 Private Build: Single Threaded: False
Bug #64268 [Csd->Nab]: crypt() outputting *0 for unknown reason
Edit report at https://bugs.php.net/bug.php?id=64268&edit=1 ID: 64268 Updated by: ras...@php.net Reported by:sarciszewski at knights dot ucf dot edu Summary:crypt() outputting *0 for unknown reason -Status: Closed +Status: Not a bug Type: Bug Package:*Encryption and hash functions Operating System: Ubuntu 12.04 kernel 3.2.0 PHP Version:5.4.11 Block user comment: N Private report: N Previous Comments: [2013-02-21 18:30:57] sarciszewski at knights dot ucf dot edu After all that concern of an unknown buffer overflow or disallowed character, I forgot to end the salt with a $ character :( [2013-02-21 18:19:13] sarciszewski at knights dot ucf dot edu Description: crypt() seems to be breaking for some reason with this password and salt combination I've not read anything about limitations on the characters supplied to crypt() in the PHP documentation Test script: --- Expected result: $2a$10$CqenGirJlEl6sCA2/w2a (followed by hashed data) Actual result: -- *0 -- Edit this bug report at https://bugs.php.net/bug.php?id=64268&edit=1
Bug #64268 [Opn->Csd]: crypt() outputting *0 for unknown reason
Edit report at https://bugs.php.net/bug.php?id=64268&edit=1 ID: 64268 User updated by:sarciszewski at knights dot ucf dot edu Reported by:sarciszewski at knights dot ucf dot edu Summary:crypt() outputting *0 for unknown reason -Status: Open +Status: Closed Type: Bug Package:*Encryption and hash functions Operating System: Ubuntu 12.04 kernel 3.2.0 PHP Version:5.4.11 Block user comment: N Private report: N New Comment: After all that concern of an unknown buffer overflow or disallowed character, I forgot to end the salt with a $ character :( Previous Comments: [2013-02-21 18:19:13] sarciszewski at knights dot ucf dot edu Description: crypt() seems to be breaking for some reason with this password and salt combination I've not read anything about limitations on the characters supplied to crypt() in the PHP documentation Test script: --- Expected result: $2a$10$CqenGirJlEl6sCA2/w2a (followed by hashed data) Actual result: -- *0 -- Edit this bug report at https://bugs.php.net/bug.php?id=64268&edit=1
[PHP-BUG] Bug #64269 [NEW]: Reading conf files takes 30minutes
From: phpfpm1 at gmail dot com Operating system: CentOS 5.8 PHP version: 5.3.21 Package: FPM related Bug Type: Bug Bug description:Reading conf files takes 30minutes Description: Hello, we have a lot of users on the system and reading php-fpm conf files is a bit "weird". Why is it reading every byte? Checking every char looks like a bug. Test script: --- strace /usr/local/php53/sbin/php-fpm53 --fpm-config /usr/local/php53/etc/php-fpm.conf Expected result: Reading whole lines. Actual result: -- open("/usr/local/directadmin/data/users/test83/php/php-fpm53.conf", O_RDONLY) = 4 read(4, "\n", 1)= 1 read(4, "\n", 1)= 1 read(4, "\n", 1)= 1 read(4, "\n", 1)= 1 read(4, "\n", 1)= 1 read(4, "\n", 1)= 1 read(4, "[", 1) = 1 read(4, "t", 1) = 1 read(4, "e", 1) = 1 read(4, "s", 1) = 1 read(4, "t", 1) = 1 read(4, "8", 1) = 1 read(4, "3", 1) = 1 read(4, "]", 1) = 1 read(4, "\n", 1)= 1 read(4, "u", 1) = 1 read(4, "s", 1) = 1 read(4, "e", 1) = 1 read(4, "r", 1) = 1 read(4, " ", 1) = 1 read(4, "=", 1) = 1 read(4, " ", 1) = 1 read(4, "$", 1) = 1 read(4, "p", 1) = 1 read(4, "o", 1) = 1 read(4, "o", 1) = 1 read(4, "l", 1) = 1 read(4, "\n", 1)= 1 read(4, "g", 1) = 1 read(4, "r", 1) = 1 read(4, "o", 1) = 1 read(4, "u", 1) = 1 read(4, "p", 1) = 1 read(4, " ", 1) = 1 read(4, "=", 1) = 1 read(4, " ", 1) = 1 read(4, "$", 1) = 1 read(4, "p", 1) = 1 read(4, "o", 1) = 1 read(4, "o", 1) = 1 read(4, "l", 1) = 1 read(4, "\n", 1)= 1 read(4, "\n", 1)= 1 read(4, "l", 1) = 1 read(4, "i", 1) = 1 read(4, "s", 1) = 1 read(4, "t", 1) = 1 read(4, "e", 1) = 1 read(4, "n", 1) = 1 read(4, " ", 1) = 1 read(4, "=", 1) = 1 read(4, " ", 1) = 1 read(4, "/", 1) = 1 read(4, "t", 1) = 1 read(4, "m", 1) = 1 read(4, "p", 1) = 1 read(4, "/", 1) = 1 read(4, "f", 1) = 1 read(4, "p", 1) = 1 read(4, "m", 1) = 1 read(4, "5", 1) = 1 read(4, "3", 1) = 1 read(4, "/", 1) = 1 read(4, "$", 1) = 1 read(4, "p", 1) = 1 read(4, "o", 1) = 1 read(4, "o", 1) = 1 read(4, "l", 1) = 1 read(4, ".", 1) = 1 read(4, "s", 1) = 1 read(4, "o", 1) = 1 read(4, "c", 1) = 1 read(4, "k", 1) = 1 read(4, "\n", 1)= 1 read(4, "\n", 1)= 1 read(4, "p", 1) = 1 read(4, "m", 1) = 1 read(4, " ", 1) = 1 read(4, "=", 1) = 1 read(4, " ", 1) = 1 read(4, "d", 1) = 1 read(4, "y", 1) = 1 read(4, "n", 1) = 1 read(4, "a", 1) = 1 read(4, "m", 1) = 1 read(4, "i", 1) = 1 read(4, "c", 1) = 1 read(4, "\n", 1)= 1 read(4, "p", 1) = 1 read(4, "m", 1) = 1 read(4, ".", 1) = 1 read(4, "m", 1) = 1 read(4, "a", 1) = 1 read(4, "x", 1) = 1 read(4, "_", 1) = 1 read(4, "c", 1) = 1 read(4, "h", 1) = 1 read(4, "i", 1) = 1 read(4, "l"
Bug #64267 [Opn->Fbk]: ldap_bind crash for ldaps://
Edit report at https://bugs.php.net/bug.php?id=64267&edit=1 ID: 64267 Updated by: paj...@php.net Reported by:andrew+bugsphp at wimpyprogrammer dot com Summary:ldap_bind crash for ldaps:// -Status: Open +Status: Feedback Type: Bug Package:LDAP related Operating System: Windows Server 2008 R2 x64 PHP Version:5.4Git-2013-02-21 (snap) Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2013-02-21 17:38:48] andrew+bugsphp at wimpyprogrammer dot com Description: (I am using PHP 5.4.12 NTS, but it's not an option in the version menu. I tried grabbing a Windows snapshot but the 5.4 links on http://windows.php.net/snapshots/ are broken.) Calling ldap_bind() with an ldaps:// resource causes PHP via FastCGI to crash: HTTP Error 500.0 - Internal Server Error C:\PROGRA~2\PHP\PHP_5_4_12_NTS_x86\php-cgi.exe - The FastCGI process exited unexpectedly If the resource is ldap://, the connection succeeds. If I change my PHP version to 5.4.11 with the same PHP INI, both methods succeed. Test script: --- http://php.net/manual/en/function.ldap-bind.php#example-4224. $ldaprdn = 'uname'; $ldappass = 'password'; // connect to ldap server $ldapconn = ldap_connect("ldaps://ldap.example.com") or die("Could not connect to LDAP server."); if ($ldapconn) { $ldapbind = ldap_bind($ldapconn, $ldaprdn, $ldappass); if ($ldapbind) { echo "LDAP bind successful..."; } else { echo "LDAP bind failed..."; } } Expected result: LDAP bind successful... Actual result: -- Error Summary HTTP Error 500.0 - Internal Server Error C:\PROGRA~2\PHP\PHP_5_4_12_NTS_x86\php-cgi.exe - The FastCGI process exited unexpectedly Detailed Error Information Module FastCgiModule Notification ExecuteRequestHandler Handler PHP 5.4.12 NTS x86 via FastCGI Error Code 0x00ff Requested URL [Redacted] Physical Path [Redacted] Logon Method Anonymous Logon User Anonymous -- Edit this bug report at https://bugs.php.net/bug.php?id=64267&edit=1
[PHP-BUG] Bug #64268 [NEW]: crypt() outputting *0 for unknown reason
From: sarciszewski at knights dot ucf dot edu Operating system: Ubuntu 12.04 kernel 3.2.0 PHP version: 5.4.11 Package: *Encryption and hash functions Bug Type: Bug Bug description:crypt() outputting *0 for unknown reason Description: crypt() seems to be breaking for some reason with this password and salt combination I've not read anything about limitations on the characters supplied to crypt() in the PHP documentation Test script: --- Expected result: $2a$10$CqenGirJlEl6sCA2/w2a (followed by hashed data) Actual result: -- *0 -- Edit bug report at https://bugs.php.net/bug.php?id=64268&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64268&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64268&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64268&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64268&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64268&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64268&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64268&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64268&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64268&r=support Expected behavior: https://bugs.php.net/fix.php?id=64268&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64268&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64268&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64268&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64268&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64268&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64268&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64268&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64268&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64268&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64268&r=mysqlcfg
[PHP-BUG] Bug #64267 [NEW]: ldap_bind crash for ldaps://
From: andrew+bugsphp at wimpyprogrammer dot com Operating system: Windows Server 2008 R2 x64 PHP version: 5.4Git-2013-02-21 (snap) Package: LDAP related Bug Type: Bug Bug description:ldap_bind crash for ldaps:// Description: (I am using PHP 5.4.12 NTS, but it's not an option in the version menu. I tried grabbing a Windows snapshot but the 5.4 links on http://windows.php.net/snapshots/ are broken.) Calling ldap_bind() with an ldaps:// resource causes PHP via FastCGI to crash: HTTP Error 500.0 - Internal Server Error C:\PROGRA~2\PHP\PHP_5_4_12_NTS_x86\php-cgi.exe - The FastCGI process exited unexpectedly If the resource is ldap://, the connection succeeds. If I change my PHP version to 5.4.11 with the same PHP INI, both methods succeed. Test script: --- http://php.net/manual/en/function.ldap-bind.php#example-4224. $ldaprdn = 'uname'; $ldappass = 'password'; // connect to ldap server $ldapconn = ldap_connect("ldaps://ldap.example.com") or die("Could not connect to LDAP server."); if ($ldapconn) { $ldapbind = ldap_bind($ldapconn, $ldaprdn, $ldappass); if ($ldapbind) { echo "LDAP bind successful..."; } else { echo "LDAP bind failed..."; } } Expected result: LDAP bind successful... Actual result: -- Error Summary HTTP Error 500.0 - Internal Server Error C:\PROGRA~2\PHP\PHP_5_4_12_NTS_x86\php-cgi.exe - The FastCGI process exited unexpectedly Detailed Error Information Module FastCgiModule Notification ExecuteRequestHandler Handler PHP 5.4.12 NTS x86 via FastCGI Error Code 0x00ff Requested URL [Redacted] Physical Path [Redacted] Logon Method Anonymous Logon User Anonymous -- Edit bug report at https://bugs.php.net/bug.php?id=64267&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64267&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64267&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64267&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64267&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64267&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64267&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64267&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64267&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64267&r=support Expected behavior: https://bugs.php.net/fix.php?id=64267&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64267&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64267&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64267&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64267&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64267&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64267&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64267&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64267&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64267&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64267&r=mysqlcfg
Bug #60840 [Asn->Csd]: undefined symbol: mysqlnd_debug_std_no_trace_funcs
Edit report at https://bugs.php.net/bug.php?id=60840&edit=1 ID: 60840 Updated by: johan...@php.net Reported by:public at grik dot net Summary:undefined symbol: mysqlnd_debug_std_no_trace_funcs -Status: Assigned +Status: Closed Type: Bug Package:PDO related Operating System: linux PHP Version:5.4SVN-2012-01-22 (snap) Assigned To:mysql Block user comment: N Private report: N New Comment: Automatic comment on behalf of johan...@schlueters.de Revision: http://git.php.net/?p=php-src.git;a=commit;h=064c62e4cf078cf08a40478dfe0e64bd51789e57 Log: Fix #60840 (undefined symbol: mysqlnd_debug_std_no_trace_funcs) Previous Comments: [2013-02-19 23:35:55] johan...@php.net The following patch has been added/updated: Patch Name: bug60840.diff Revision: 1361316955 URL: https://bugs.php.net/patch-display.php?bug=60840&patch=bug60840.diff&revision=1361316955 [2012-10-29 16:03:05] johan...@php.net public at grik dot net, the issue is when building the extensions shared we can't decide what to do with mysqlnd, should that be built-in or shared, too? Or maybe the user has a different mysqlnd? - We leave this to the user. [2012-06-14 10:03:03] public at grik dot net Johannes, thanks for the response, but according to http://php.net/ChangeLog-5.php "ext/mysql, mysqli and pdo_mysql now use mysqlnd by default." in 5.4 So the issues are: 1. Why should we explicitly enable the feature used by default? 2. How can we NOT use mysqlnd in debug mode, if it issues an error for missing mysqlnd_debug_std_no_trace_funcs? [2012-06-14 09:57:57] fausten at pw-internet dot de Hi, the package is going to build with mysqlnd by default: # cd /usr/ports/databases/php5-pdo_mysql && make config MYSQLND - Use MySQL Native Driver (Is selected by default) # make install clean After installation: The following line has been added to your /usr/local/etc/php/extensions.ini configuration file to automatically load the installed extension: extension=pdo_mysql.so So the extension sholud be loaded after restarting php. [2012-06-14 09:41:44] johan...@php.net When building the MySQL extensions you explicitly have to enable mysqlnd. i.e. --enable-mysqlnd=shared. If you build mysqlnd shared you have to remember to load it, too. I will look whether the build system can be made smarter and at least warn. I don't want to make the decision in there whether to build shared or static. If I'd make that decision I'd default to static mysqlnd. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60840 -- Edit this bug report at https://bugs.php.net/bug.php?id=60840&edit=1
Req #64266 [Nab->Wfx]: Pass arrays as reference by default
Edit report at https://bugs.php.net/bug.php?id=64266&edit=1 ID: 64266 Updated by: ras...@php.net Reported by:stormbyte at gmail dot com Summary:Pass arrays as reference by default -Status: Not a bug +Status: Wont fix Type: Feature/Change Request Package:*General Issues Operating System: Linux PHP Version:5.4.11 Block user comment: N Private report: N New Comment: Because PHP uses Copy-On-Write there is actually no performance benefit to passing anything by reference in PHP. In fact creating a reference is slower. Also, while you are correct that C/C++ passes arrays by reference by default, this is mainly because there is simply no way to pass a block of memory by value. If you want to make actual changes to the passed array you would still have to pass an int** since if you need to change the size of the array and re- alloc the block of memory you need a pointer to the pointer, so in essence passing an int* in C is its form of pass-by-value as it simply avoids doing a copy, but doesn't give the receiving function the ability to make real changes to the array and passing an int** is C's version of pass-by-reference. This exactly mirrors PHP's behaviour. Passing a PHP array by value doesn't make a copy of the array because of COW and is thus analogous to passing an int* in C and PHP's pass-by-reference is exactly like C's passing of an int**. Previous Comments: [2013-02-21 14:51:22] johan...@php.net C has no references, but pointers which are a quite different concept. Pass by pointer is neccessary in C to allow maximum performance. In PHP we have copy on write and prefer more intuitive APIs. When reading foo($variable) it is unclear whether $variable will be read only or manipulated, which makes reading code harder. By defaulting to "copies" this is lost. Also mind that objects are not passed by reference but by handle. To learn more please see http://php.net/manual/en/language.references.php http://php.net/manual/en/features.gc.refcounting-basics.php http://php.net/manual/en/language.oop5.references.php http://schlueters.de/blog/archives/125-Do-not-use-PHP-references.html [2013-02-21 14:22:39] stormbyte at gmail dot com Description: One of major benefits from PHP is that it is very close to C/C++ style, so it is its functions and coding style (very similar for, while and those constructs) so if you come from C/C++ world, you have it easy. To keep this consistence I suggest, as well as C/C++ does, passing arrays as reference in function arguments by default, or at least an option to behave like that. For me, it does not make much sense to "follow" C/C++ coding styles and behaviour, while not following that behaviour. Furthermore, objects are already passed by reference as default, so why not arrays? IMHO I think that inconsistence may confuse programmers. Test script: --- function foo($arr) { array_push($arr, "test"); } function bar(&$arr) { array_push($arr, "test"); } $a=array(); foo($a); //$a is empty bar($a); //$a[0]="test" Expected result: To be consistent with the rest behaviour of "imitating" C/C++ and pass arrays as reference automatically as well as objects are. Also, it may be a performance gain by doing that (which is one of the reasons in C world it is that way) -- Edit this bug report at https://bugs.php.net/bug.php?id=64266&edit=1
Bug #64258 [Com]: XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet)
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 Comment by: r...@php.net Reported by:spamik at yum dot pl Summary:XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet) Status: Open Type: Bug Package:XML Reader PHP Version:5.4.11 Block user comment: N Private report: N New Comment: Cannot reproduce. php 5.4.11 and 5.4.12 build against libxml2 and work as expected. Previous Comments: [2013-02-21 00:01:56] spamik at yum dot pl Description: datadata'; $xml->XML($xmldata); ?> php 5.4.11 compiled with libxml2 2.9.0 /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup It works when php is compiled against libxml2 2.6.26 XMLReader is not compatibile with new libxml2 version. -- Edit this bug report at https://bugs.php.net/bug.php?id=64258&edit=1
Req #64266 [Opn->Nab]: Pass arrays as reference by default
Edit report at https://bugs.php.net/bug.php?id=64266&edit=1 ID: 64266 Updated by: johan...@php.net Reported by:stormbyte at gmail dot com Summary:Pass arrays as reference by default -Status: Open +Status: Not a bug Type: Feature/Change Request Package:*General Issues Operating System: Linux PHP Version:5.4.11 Block user comment: N Private report: N New Comment: C has no references, but pointers which are a quite different concept. Pass by pointer is neccessary in C to allow maximum performance. In PHP we have copy on write and prefer more intuitive APIs. When reading foo($variable) it is unclear whether $variable will be read only or manipulated, which makes reading code harder. By defaulting to "copies" this is lost. Also mind that objects are not passed by reference but by handle. To learn more please see http://php.net/manual/en/language.references.php http://php.net/manual/en/features.gc.refcounting-basics.php http://php.net/manual/en/language.oop5.references.php http://schlueters.de/blog/archives/125-Do-not-use-PHP-references.html Previous Comments: [2013-02-21 14:22:39] stormbyte at gmail dot com Description: One of major benefits from PHP is that it is very close to C/C++ style, so it is its functions and coding style (very similar for, while and those constructs) so if you come from C/C++ world, you have it easy. To keep this consistence I suggest, as well as C/C++ does, passing arrays as reference in function arguments by default, or at least an option to behave like that. For me, it does not make much sense to "follow" C/C++ coding styles and behaviour, while not following that behaviour. Furthermore, objects are already passed by reference as default, so why not arrays? IMHO I think that inconsistence may confuse programmers. Test script: --- function foo($arr) { array_push($arr, "test"); } function bar(&$arr) { array_push($arr, "test"); } $a=array(); foo($a); //$a is empty bar($a); //$a[0]="test" Expected result: To be consistent with the rest behaviour of "imitating" C/C++ and pass arrays as reference automatically as well as objects are. Also, it may be a performance gain by doing that (which is one of the reasons in C world it is that way) -- Edit this bug report at https://bugs.php.net/bug.php?id=64266&edit=1
[PHP-BUG] Req #64266 [NEW]: Pass arrays as reference by default
From: stormbyte at gmail dot com Operating system: Linux PHP version: 5.4.11 Package: *General Issues Bug Type: Feature/Change Request Bug description:Pass arrays as reference by default Description: One of major benefits from PHP is that it is very close to C/C++ style, so it is its functions and coding style (very similar for, while and those constructs) so if you come from C/C++ world, you have it easy. To keep this consistence I suggest, as well as C/C++ does, passing arrays as reference in function arguments by default, or at least an option to behave like that. For me, it does not make much sense to "follow" C/C++ coding styles and behaviour, while not following that behaviour. Furthermore, objects are already passed by reference as default, so why not arrays? IMHO I think that inconsistence may confuse programmers. Test script: --- function foo($arr) { array_push($arr, "test"); } function bar(&$arr) { array_push($arr, "test"); } $a=array(); foo($a); //$a is empty bar($a); //$a[0]="test" Expected result: To be consistent with the rest behaviour of "imitating" C/C++ and pass arrays as reference automatically as well as objects are. Also, it may be a performance gain by doing that (which is one of the reasons in C world it is that way) -- Edit bug report at https://bugs.php.net/bug.php?id=64266&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64266&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64266&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64266&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64266&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64266&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64266&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64266&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64266&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64266&r=support Expected behavior: https://bugs.php.net/fix.php?id=64266&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64266&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64266&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64266&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64266&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64266&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64266&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64266&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64266&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64266&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64266&r=mysqlcfg
Bug #54439 [Com]: SSL/OpenSSL broken
Edit report at https://bugs.php.net/bug.php?id=54439&edit=1 ID: 54439 Comment by: ashok975 at hotmail dot com Reported by:paigeat at paigeat dot info Summary:SSL/OpenSSL broken Status: No Feedback Type: Bug Package:OpenSSL related Operating System: linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: fwrite(): SSL: Broken pipe fwrite(): SSL operation failed with code 1. OpenSSL Error messages: error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry Previous Comments: [2013-02-18 00:34:48] php-bugs at lists dot php dot net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2011-04-01 13:15:04] cataphr...@php.net Changed bug meta-data. Also, this doesn't necessarily mean a problem in PHP. More information is needed, namely how to reproduce this problem (linking to a library is not enough). [2011-04-01 10:53:23] paigeat at paigeat dot info Description: --- >From manual page: http://www.php.net/function.fwrite#Description --- Warning: fwrite() [function.fwrite]: SSL operation failed with code 1. OpenSSL Error messages: error:140D00CF:SSL routines:SSL_write:protocol is shutdown Test script: --- in /home/erratic/domains/cl.devel.ws/public_html/include/xpm/PHP5/SMTP5.php on line 222 source code download: http://downloads.sourceforge.net/xpertmailer/XPM4-v.0.5.zip -- Edit this bug report at https://bugs.php.net/bug.php?id=54439&edit=1
[PHP-BUG] Bug #64264 [NEW]: SPLFixedArray toArray problem
From: kwreczycki at gmail dot com Operating system: PHP version: Irrelevant Package: SPL related Bug Type: Bug Bug description:SPLFixedArray toArray problem Description: Be aware if You extends SplFixedArray and use toArray method. Test script: --- class MyFixedArray extends \SplFixedArray { protected $foo; protected $bar; } $myFixedArr = new MyFixedArray(1); $myFixedArray[] = 'foo'; Expected result: array(1) { [0]=> NULL } Actual result: -- array(3) { ["*foo"]=> NULL ["*bar"]=> NULL [0]=> NULL } *foo and *bar keys, can invoke troubles in some situations if You expects array without properties from inherited class. Method toArray should return values only for elements which are added to collection without properties inherited from class. -- Edit bug report at https://bugs.php.net/bug.php?id=64264&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64264&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64264&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64264&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64264&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64264&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64264&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64264&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64264&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64264&r=support Expected behavior: https://bugs.php.net/fix.php?id=64264&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64264&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64264&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64264&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64264&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64264&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64264&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64264&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64264&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64264&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64264&r=mysqlcfg
Bug #63378 [Nab]: xmlreader libxml2 2.9.0 undefined symbol: xmlTextReaderSetup
Edit report at https://bugs.php.net/bug.php?id=63378&edit=1 ID: 63378 Updated by: paj...@php.net Reported by:spamik at yum dot pl Summary:xmlreader libxml2 2.9.0 undefined symbol: xmlTextReaderSetup Status: Not a bug Type: Bug Package:XML Reader PHP Version:5.4.8 Block user comment: N Private report: N New Comment: @spamik at yum dot pl What Felipe said is correct. It builds just fine using 2.9.0 (be unix or windows). Try again using a clean build (read: either download 5.4.x again or do a buildconf, configure, etc.). Previous Comments: [2013-02-20 23:58:13] spamik at yum dot pl Not an answer. Not related to the question. Yes a bug in libxml extension which is not compatibile with new libxml2 libs. [2012-10-29 15:25:36] fel...@php.net 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. Not a PHP problem. Try a clean PHP build on your system again. [2012-10-28 21:29:03] spamik at yum dot pl Description: datadata'; $xml->XML($xmldata); ?> php 5.4.8 compiled with libxml2 2.9.0 /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup It works when php is compiled against libxml2 2.6.26 -- Edit this bug report at https://bugs.php.net/bug.php?id=63378&edit=1
Bug #64235 [Fbk->Csd]: Insteadof not work for class method in 5.4.11
Edit report at https://bugs.php.net/bug.php?id=64235&edit=1 ID: 64235 Updated by: larue...@php.net Reported by:imenem at inox dot ru Summary:Insteadof not work for class method in 5.4.11 -Status: Feedback +Status: Closed Type: Bug Package:Scripting Engine problem Operating System: Debian GNU/Linux PHP Version:5.4.11 Assigned To:dmitry Block user comment: N Private report: N New Comment: Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=9a44a9806c7c7a8c1fc691210335d0691a4597be Log: Fixed bug #64235 (Insteadof not work for class method in 5.4.11) Previous Comments: [2013-02-21 09:12:08] dmi...@php.net Personally, I agree with deny_use_with_classes.patch [2013-02-21 09:09:56] larue...@php.net The following patch has been added/updated: Patch Name: deny_use_with_classes.patch Revision: 1361437796 URL: https://bugs.php.net/patch-display.php?bug=64235&patch=deny_use_with_classes.patch&revision=1361437796 [2013-02-20 19:33:35] dmi...@php.net I agree with Stefan. I think we have to allow only trait names in context of "as" and "insteadof" statements. Stefan showed a simple workarounds for class names. I don't think we should fix the behavior we had in early 5.4 versions by mistake. [2013-02-20 16:22:55] re...@php.net currently using class in context of trait 'as' and 'inteadof' didn't work most of the time (as the code below demonstrated, even after apply the patch larucence attached). Only the use case of this bug report, it HAPPENED to work. To keep the BC of the problem reported, as I suggested in the previous patch we could mark it as deprecated in 5.4. So forbid class in 'as' and 'insteadof' didn't break because most of them didn't even work. in the case of parent class insteadof usage, the REAL need is avoid trait's method overwrite the method inherited but not refer to parent class. there is a really easy workaround: rename the conflict method as a new one `Traits::method as _use_less` or something else, if we really need the method from parent. undefined method StandAlone::foo as bar; // Child::bar() -> undefined method StandAlone::foo as foo; // Child::foo() -> "Trait" GrandParent::foo as bar; // Child::bar() -> undefined method /* insteadof */ Parent::foo insteadof T; // works by accident -> "Parent" GrandParent::foo insteadof T; // -> "Parent" but not "Grand" StandAlone::foo insteadof T; // ->"Parent" } } [2013-02-20 14:40:32] larue...@php.net @Stefan the current patch is allow use insteadof with classes (as the reporter said, it used to works), and forbid use "as" with classes (5.4.11 will result in an unexpected FATAL error "undefined method", which is very confused message), the new solution is trigger compiler ERROR so, for the current patch, I think it is consistent with before, no need to be RFCed again. however, if we decide to forbind using both 'as' and 'insteadof' with classes, that definitely need a RFC The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64235 -- Edit this bug report at https://bugs.php.net/bug.php?id=64235&edit=1
Bug #64235 [Fbk]: Insteadof not work for class method in 5.4.11
Edit report at https://bugs.php.net/bug.php?id=64235&edit=1 ID: 64235 Updated by: dmi...@php.net Reported by:imenem at inox dot ru Summary:Insteadof not work for class method in 5.4.11 Status: Feedback Type: Bug Package:Scripting Engine problem Operating System: Debian GNU/Linux PHP Version:5.4.11 Assigned To:dmitry Block user comment: N Private report: N New Comment: Personally, I agree with deny_use_with_classes.patch Previous Comments: [2013-02-21 09:09:56] larue...@php.net The following patch has been added/updated: Patch Name: deny_use_with_classes.patch Revision: 1361437796 URL: https://bugs.php.net/patch-display.php?bug=64235&patch=deny_use_with_classes.patch&revision=1361437796 [2013-02-20 19:33:35] dmi...@php.net I agree with Stefan. I think we have to allow only trait names in context of "as" and "insteadof" statements. Stefan showed a simple workarounds for class names. I don't think we should fix the behavior we had in early 5.4 versions by mistake. [2013-02-20 16:22:55] re...@php.net currently using class in context of trait 'as' and 'inteadof' didn't work most of the time (as the code below demonstrated, even after apply the patch larucence attached). Only the use case of this bug report, it HAPPENED to work. To keep the BC of the problem reported, as I suggested in the previous patch we could mark it as deprecated in 5.4. So forbid class in 'as' and 'insteadof' didn't break because most of them didn't even work. in the case of parent class insteadof usage, the REAL need is avoid trait's method overwrite the method inherited but not refer to parent class. there is a really easy workaround: rename the conflict method as a new one `Traits::method as _use_less` or something else, if we really need the method from parent. undefined method StandAlone::foo as bar; // Child::bar() -> undefined method StandAlone::foo as foo; // Child::foo() -> "Trait" GrandParent::foo as bar; // Child::bar() -> undefined method /* insteadof */ Parent::foo insteadof T; // works by accident -> "Parent" GrandParent::foo insteadof T; // -> "Parent" but not "Grand" StandAlone::foo insteadof T; // ->"Parent" } } [2013-02-20 14:40:32] larue...@php.net @Stefan the current patch is allow use insteadof with classes (as the reporter said, it used to works), and forbid use "as" with classes (5.4.11 will result in an unexpected FATAL error "undefined method", which is very confused message), the new solution is trigger compiler ERROR so, for the current patch, I think it is consistent with before, no need to be RFCed again. however, if we decide to forbind using both 'as' and 'insteadof' with classes, that definitely need a RFC [2013-02-20 13:20:15] g...@php.net Hi: The `insteadof` and `as` operators where not intended to be used with classes. The syntax is intended to convey that the use operation is refined by specifying how to resolve conflicts __between__ traits. That's the idea at least. My solution for the initial problem presented would be to provide a method such as follows in the TestChildClass: public function method() { parent::method(); } I understand that this is not ideal, and requires you to repeat yourself. However, it is consistent in the sense that traits are traits and not classes, and both get mixed up as little as possible, However, beside the academic notion of purity, I can see that `TestParentClass::method insteadof TestTrait;` is useful. [I wonder whether `parent::method insteadof TestTrait;` should be supported as well.] Laruence's example with `TestParentClass::method as methodParent;` is however problematic. Traits are not supposed to conflict with classes, but with traits. So, allowing the introduction of aliases for method of the super class seems to me as something that is problematic, because it mixes up the concepts. If you need an alias for the method of a parent class, the classic way would be: public function foo() { parent::bar(); } No? Well, that's my point of view. So, from a practical point of view, referring to the parent (and only the direct parent) class in `insteadof` might be a useful/acceptable feature. The use in conjunction with `as` seems to be something I would advocate against. In either way, beside bugs that made this possible in the first place, I would consider both ideas as new features that
Bug #64235 [PATCH]: Insteadof not work for class method in 5.4.11
Edit report at https://bugs.php.net/bug.php?id=64235&edit=1 ID: 64235 Patch added by: larue...@php.net Reported by:imenem at inox dot ru Summary:Insteadof not work for class method in 5.4.11 Status: Feedback Type: Bug Package:Scripting Engine problem Operating System: Debian GNU/Linux PHP Version:5.4.11 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: deny_use_with_classes.patch Revision: 1361437796 URL: https://bugs.php.net/patch-display.php?bug=64235&patch=deny_use_with_classes.patch&revision=1361437796 Previous Comments: [2013-02-20 19:33:35] dmi...@php.net I agree with Stefan. I think we have to allow only trait names in context of "as" and "insteadof" statements. Stefan showed a simple workarounds for class names. I don't think we should fix the behavior we had in early 5.4 versions by mistake. [2013-02-20 16:22:55] re...@php.net currently using class in context of trait 'as' and 'inteadof' didn't work most of the time (as the code below demonstrated, even after apply the patch larucence attached). Only the use case of this bug report, it HAPPENED to work. To keep the BC of the problem reported, as I suggested in the previous patch we could mark it as deprecated in 5.4. So forbid class in 'as' and 'insteadof' didn't break because most of them didn't even work. in the case of parent class insteadof usage, the REAL need is avoid trait's method overwrite the method inherited but not refer to parent class. there is a really easy workaround: rename the conflict method as a new one `Traits::method as _use_less` or something else, if we really need the method from parent. undefined method StandAlone::foo as bar; // Child::bar() -> undefined method StandAlone::foo as foo; // Child::foo() -> "Trait" GrandParent::foo as bar; // Child::bar() -> undefined method /* insteadof */ Parent::foo insteadof T; // works by accident -> "Parent" GrandParent::foo insteadof T; // -> "Parent" but not "Grand" StandAlone::foo insteadof T; // ->"Parent" } } [2013-02-20 14:40:32] larue...@php.net @Stefan the current patch is allow use insteadof with classes (as the reporter said, it used to works), and forbid use "as" with classes (5.4.11 will result in an unexpected FATAL error "undefined method", which is very confused message), the new solution is trigger compiler ERROR so, for the current patch, I think it is consistent with before, no need to be RFCed again. however, if we decide to forbind using both 'as' and 'insteadof' with classes, that definitely need a RFC [2013-02-20 13:20:15] g...@php.net Hi: The `insteadof` and `as` operators where not intended to be used with classes. The syntax is intended to convey that the use operation is refined by specifying how to resolve conflicts __between__ traits. That's the idea at least. My solution for the initial problem presented would be to provide a method such as follows in the TestChildClass: public function method() { parent::method(); } I understand that this is not ideal, and requires you to repeat yourself. However, it is consistent in the sense that traits are traits and not classes, and both get mixed up as little as possible, However, beside the academic notion of purity, I can see that `TestParentClass::method insteadof TestTrait;` is useful. [I wonder whether `parent::method insteadof TestTrait;` should be supported as well.] Laruence's example with `TestParentClass::method as methodParent;` is however problematic. Traits are not supposed to conflict with classes, but with traits. So, allowing the introduction of aliases for method of the super class seems to me as something that is problematic, because it mixes up the concepts. If you need an alias for the method of a parent class, the classic way would be: public function foo() { parent::bar(); } No? Well, that's my point of view. So, from a practical point of view, referring to the parent (and only the direct parent) class in `insteadof` might be a useful/acceptable feature. The use in conjunction with `as` seems to be something I would advocate against. In either way, beside bugs that made this possible in the first place, I would consider both ideas as new features that need to be documented/discussed. I thought that we had a test that only the traits listed in the `use` clause can be used for the `as`/`insteadof` operators, but
Bug #49348 [Asn->Csd]: Uninitialized ++$foo->bar; does not cause a notice (but ++$bar; does!)
Edit report at https://bugs.php.net/bug.php?id=49348&edit=1 ID: 49348 Updated by: s...@php.net Reported by:BelStudent at yandex dot ru Summary:Uninitialized ++$foo->bar; does not cause a notice (but ++$bar; does!) -Status: Assigned +Status: Closed Type: Bug Package:Scripting Engine problem Operating System: * PHP Version:5.*, 6 Assigned To:stas Block user comment: N Private report: N New Comment: Automatic comment on behalf of stas Revision: http://git.php.net/?p=php-src.git;a=commit;h=0c6d903ce7615a7197cb997d67d98058c3ec5d6a Log: fix bug #49348 - issue notice on get_property_ptr_ptr when used for read Previous Comments: [2013-02-20 08:35:21] dmi...@php.net I think the fix is fine, but it may go only into 5.5 and above. [2013-02-19 09:18:04] s...@php.net Potential fix in this pull: https://github.com/php/php-src/pull/281 [2013-02-19 04:59:16] s...@php.net The problem here is that get_property_ptr_ptr does not produce notices. It doesn't because it does not know the fetch type - in some cases it's BP_VAR_W, then it shouldn't produce notice, in some it's BP_VAR_RW and then it should. However get_property_ptr_ptr doesn't have a parameter to pass this info. Looks like such parameter needs to be added... [2009-09-01 08:41:52] sjo...@php.net I was talking about this: http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_execute.c?revision=286362&view=markup#l251 With ++$foo, type is BP_VAR_RW, which makes sense and gives a notice. With ++$this->foo, it is BP_VAR_W. [2009-08-31 22:12:10] j...@php.net # svn log -r100312 zend_object_handlers.c r100312 | stas | 2002-10-20 22:22:04 +0300 (Sun, 20 Oct 2002) | 2 lines looks like this message should go --- Stas, care to explain? Uncommenting that will bring back the notice. And Sjoerd, what did you mean with that comment..? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=49348 -- Edit this bug report at https://bugs.php.net/bug.php?id=49348&edit=1
Bug #62632 [Opn->Nab]: Incorrect image generated
Edit report at https://bugs.php.net/bug.php?id=62632&edit=1 ID: 62632 Updated by: paj...@php.net Reported by:marc at phpmyadmin dot net Summary:Incorrect image generated -Status: Open +Status: Not a bug Type: Bug Package:GD related Operating System: Linux PHP Version:5.4.5 Block user comment: N Private report: N New Comment: . Previous Comments: [2013-02-18 17:26:56] marc at phpmyadmin dot net The solution is to use null as the second parameter of ImageJPEG(). In PHP 5.3.13, using '' worked. [2013-02-18 13:00:44] ka...@php.net have you tried to call the script like: And see if PHP errors out? If headers are sent its often hidden by browsers. Simply go to image.php directly and see if you either get a lot of 'binary' text or an actual PHP error. [2012-09-15 05:27:35] david at nnucomputerwhiz dot com Works for me in php 5.4.4-4 from Debian testing. [2012-07-22 20:52:10] marc at phpmyadmin dot net Here is the image I used: http://www.infomarc.info/MarcDelisle-140x185.jpg [2012-07-22 19:18:32] a...@php.net $contents = file_get_contents('marc.jpg'); A link to marc.jpg would be useful. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=62632 -- Edit this bug report at https://bugs.php.net/bug.php?id=62632&edit=1