Bug #48507 [Nab]: fgetcsv() ignoring special characters
Edit report at https://bugs.php.net/bug.php?id=48507&edit=1
ID: 48507
Updated by: ras...@php.net
Reported by:krynble at yahoo dot com dot br
Summary:fgetcsv() ignoring special characters
Status: Not a bug
Type: Bug
Package:Filesystem function related
Operating System: Unix
PHP Version:5.*
Block user comment: N
Private report: N
New Comment:
eswald@middil, I am not able to reproduce your results with either en_US.UTF-8
nor C with a UTF8 input file:
~> echo $LANG
en_US.UTF-8
~> file utf8.txt
utf8.txt: UTF-8 Unicode text
~> cat utf8.txt
a,"a",é,"é",óú,"óú",ó&ú,"ó&ú"
~> php -r "print_r(fgetcsv(fopen('./utf8.txt','r')));"
Array
(
[0] => a
[1] => a
[2] => é
[3] => é
[4] => óú
[5] => óú
[6] => ó&ú
[7] => ó&ú
)
I don't see any corruption. I can understand problems with charsets that are
not
low-ascii compatible with a low-ascii delimiter, but I don't see why this UTF8
case would break.
Previous Comments:
[2012-02-13 01:46:59] figura at hotbox dot ru
setlocale() might solve the issue but I do not see any reason to set up
dependence of this fgetcsv on locale settings. The format is straight and
clear.
Especially this "feature" confuses when the string is read in UTF-8 format.
[2012-01-26 19:55:01] eswald at middil dot com
Tested with LANG=C, input file encoding of UTF-8.
Also tested with LANG=C, input file encoding of cp1252, with identical results,
except that the output characters (what was left of them) were also cp1252.
[2012-01-26 19:50:26] eswald at middil dot com
Confirmed with php5 (5.3.6-13ubuntu3.2 on Oneiric Ocelot); can be worked around
by quoting the value with quotation marks. For example, the line
a,"a",é,"é",óú,"óú",ó&ú,"ó&ú"
yields
array (
0 => 'a',
1 => 'a',
2 => '',
3 => 'é',
4 => '',
5 => 'óú',
6 => '&ú',
7 => 'ó&ú',
)
Note the corruption in elements 2, 4, and 6, but not in their quoted
counterparts 3, 5, and 7.
[2012-01-18 11:53:48] tero dot tasanen at gmail dot com
I can also confirm that this is an actual bug. File encoding UTF-8, locale
settings are set correctly and characters like äöå are dropped from the
beginning
of the csv column.
Tested with php versions 5.2.6, 5.2.10, 5.3.6
[2011-10-28 08:33:25] peter dot e dot lind at gmail dot com
This is definitely still a bug - my locale is set to da_DK.utf8, the file I'm
trying to read is in UTF8 (confirmed with a hex-editor but in fact does not
matter - the behaviour is the same, UTF8 or ISO-8859-1) yet special characters
are still thrown away when they are first in a field
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=48507
--
Edit this bug report at https://bugs.php.net/bug.php?id=48507&edit=1
Bug #61047 [Opn->Nab]: easyapache not compiling
Edit report at https://bugs.php.net/bug.php?id=61047&edit=1 ID: 61047 Updated by: ahar...@php.net Reported by:pandit dot dhruv at gmail dot com Summary:easyapache not compiling -Status: Open +Status: Not a bug Type: Bug Package:Apache related Operating System: cent OS 6.2 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Sorry, but we can't accept bugs for third party projects, including EasyApache. Previous Comments: [2012-02-10 17:29:20] pandit dot dhruv at gmail dot com Description: Installing PHP SAPI module: apache2handler /usr/local/apache/build/instdso.sh SH_LIBTOOL='/usr/local/apache/build/libtool' libphp5.la /usr/local/apache/modules /usr/local/apache/build/libtool --mode=install cp libphp5.la /usr/local/apache/modules/ cp .libs/libphp5.lai /usr/local/apache/modules/libphp5.la cp .libs/libphp5.a /usr/local/apache/modules/libphp5.a chmod 644 /usr/local/apache/modules/libphp5.a ranlib /usr/local/apache/modules/libphp5.a libtool: install: warning: remember to run `libtool --finish /home/cpeasyapache/src/php-5.3.10/libs' Warning! dlname not found in /usr/local/apache/modules/libphp5.la. Assuming installing a .so rather than a libtool archive. chmod 755 /usr/local/apache/modules/libphp5.so chmod: cannot access `/usr/local/apache/modules/libphp5.so': No such file or directory apxs:Error: Command failed with rc=65536 . make: *** [install-sapi] Error 1 !! 'make install' failed with exit code '512' !! !! Restoring original working apache !! Expected result: i am trying to run easyapache , but getting this error. and /usr/local/apache/modules/libphp5.so is already there. -- Edit this bug report at https://bugs.php.net/bug.php?id=61047&edit=1
Bug #48507 [Com]: fgetcsv() ignoring special characters
Edit report at https://bugs.php.net/bug.php?id=48507&edit=1 ID: 48507 Comment by: figura at hotbox dot ru Reported by:krynble at yahoo dot com dot br Summary:fgetcsv() ignoring special characters Status: Not a bug Type: Bug Package:Filesystem function related Operating System: Unix PHP Version:5.* Block user comment: N Private report: N New Comment: setlocale() might solve the issue but I do not see any reason to set up dependence of this fgetcsv on locale settings. The format is straight and clear. Especially this "feature" confuses when the string is read in UTF-8 format. Previous Comments: [2012-01-26 19:55:01] eswald at middil dot com Tested with LANG=C, input file encoding of UTF-8. Also tested with LANG=C, input file encoding of cp1252, with identical results, except that the output characters (what was left of them) were also cp1252. [2012-01-26 19:50:26] eswald at middil dot com Confirmed with php5 (5.3.6-13ubuntu3.2 on Oneiric Ocelot); can be worked around by quoting the value with quotation marks. For example, the line a,"a",é,"é",óú,"óú",ó&ú,"ó&ú" yields array ( 0 => 'a', 1 => 'a', 2 => '', 3 => 'é', 4 => '', 5 => 'óú', 6 => '&ú', 7 => 'ó&ú', ) Note the corruption in elements 2, 4, and 6, but not in their quoted counterparts 3, 5, and 7. [2012-01-18 11:53:48] tero dot tasanen at gmail dot com I can also confirm that this is an actual bug. File encoding UTF-8, locale settings are set correctly and characters like äöå are dropped from the beginning of the csv column. Tested with php versions 5.2.6, 5.2.10, 5.3.6 [2011-10-28 08:33:25] peter dot e dot lind at gmail dot com This is definitely still a bug - my locale is set to da_DK.utf8, the file I'm trying to read is in UTF8 (confirmed with a hex-editor but in fact does not matter - the behaviour is the same, UTF8 or ISO-8859-1) yet special characters are still thrown away when they are first in a field [2011-10-18 13:59:30] me at monicag dot it Quoting my fellows above: how comes this is not a bug? 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=48507 -- Edit this bug report at https://bugs.php.net/bug.php?id=48507&edit=1
[PHP-BUG] Bug #61067 [NEW]: free() from signal handler leads to deadlock
From: Operating system: Debian Squeeze PHP version: 5.3.10 Package: FPM related Bug Type: Bug Bug description:free() from signal handler leads to deadlock Description: Using PHP-FPM-5.3.10+APC-3.1.9. I just discovered 30 PHP processes that's been running for 22 hours. Further inspection revealed all of them (except one) are waiting to flock() a session file. The process holding the flock() is doing: futex(0x7f21238f9e40, FUTEX_WAIT_PRIVATE, 2, NULL (gdb) info threads Id Target Id Frame * 1Thread 0x7f2126114720 (LWP 4271) __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97 (gdb) bt #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97 #1 0x7f2123614558 in _L_lock_9590 () from /lib/libc.so.6 #2 0x7f2123612941 in *__GI___libc_free (mem=0x7f21238f9e40) at malloc.c:3737 #3 0x7f21263f5820 in php_error_cb (type=1, error_filename=0x7f2121088fd8 "", error_lineno=154, format=, args=) at /build/php-5.3.10/main/main.c:931 #4 0x7f2126446d7c in zend_error (type=1, format=0x7f2126902028 "Maximum execution time of %d second%s exceeded") at /build/php-5.3.10/Zend/zend.c:1127 #5 #6 0x7f2123612a1d in *__GI___libc_malloc (bytes=50) at malloc.c:3658 #7 0x7f2123617a22 in *__GI___strdup (s=0x7f2121088fd8 "") at strdup.c:43 #8 0x7f21263f587a in php_error_cb (type=8, error_filename=0x7f2121088fd8 "", error_lineno=154, format=, args=) at /build/php-5.3.10/main/main.c:943 #9 0x7f2126446d7c in zend_error (type=8, format=0x7f2126907356 "Undefined index: %s") at /build/php-5.3.10/Zend/zend.c:1127 #10 0x7f21264b2f89 in zend_fetch_dimension_address_inner (type=, dim=, ht=) at /build/php-5.3.10/Zend/zend_execute.c:820 #11 zend_fetch_dimension_address_read (result=0x7f2127f17930, container_ptr=, dim=0x7f2126bf25c8, dim_is_tmp_var=, type=0) at /build/php-5.3.10/Zend/zend_execute.c:1043 #12 0x7f21264b4059 in ZEND_FETCH_DIM_R_SPEC_CV_VAR_HANDLER (execute_data=0x7f2127f17678) at /build/php-5.3.10/Zend/zend_vm_execute.h:26962 #13 0x7f212646ee30 in execute (op_array=0x7f2127efe020) at /build/php-5.3.10/Zend/zend_vm_execute.h:107 #14 0x7f212644654f in zend_execute_scripts (type=8, retval=, file_count=3) at /build/php-5.3.10/Zend/zend.c:1308 #15 0x7f21263f2bc7 in php_execute_script (primary_file=) at /build/php-5.3.10/main/main.c:2323 #16 0x7f21264db7c8 in main (argc=669766600, argv=) at /build/php-5.3.10/sapi/fpm/fpm/fpm_main.c:1875 It looks like PHP caught a signal inside malloc(), causing glibc to take some lock, and that free() wants the same lock, leading to deadlock. I'm not sure if malloc/free is safe to use in signal handlers. http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.apps/2005-07/0323.html seems to suggest it's not. -- Edit bug report at https://bugs.php.net/bug.php?id=61067&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61067&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61067&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61067&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61067&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61067&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61067&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61067&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61067&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61067&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61067&r=support Expected behavior: https://bugs.php.net/fix.php?id=61067&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61067&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61067&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61067&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61067&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61067&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61067&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61067&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61067&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61067&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61067&r=mysqlcfg
[PHP-BUG] Req #61066 [NEW]: clones an object if using unserialize,spl_autoload_register
From:
Operating system: FreeBSD
PHP version: 5.3.10
Package: SPL related
Bug Type: Feature/Change Request
Bug description:clones an object if using unserialize,spl_autoload_register
Description:
clones an object if using unserialize,spl_autoload_register. This confuses
the understanding of.
Test script:
---
spl_autoload_register(function($Class){
/* Include file */
});
/* File Core.php */
class Core{
public $field;
public function __construct(){
$this->field = time();
}
}
/* File Lite.php */
class Lite{
protected $Core;
public function __construct($Core){
$this->Core = $Core;
}
}
$Core = new Core();
if(!$Lite = $Cache->Load('Lite')){
$Lite = new Lite(); // Ok ...
}
echo $Core->field; // Ok ...
echo $Lite->Core->field; // Out null. $Core != $Core. $Core new object.
Expected result:
if($Core->field == $Lite->Core->field){
echo 'Ok!';
}else{
echo 'poorly';
}
Actual result:
--
$Core->field != $Lite->Core->field
--
Edit bug report at https://bugs.php.net/bug.php?id=61066&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61066&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61066&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61066&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61066&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61066&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61066&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61066&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61066&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61066&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61066&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61066&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61066&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61066&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61066&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61066&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61066&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61066&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61066&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61066&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61066&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61066&r=mysqlcfg
Bug #61057 [Fbk->Opn]: PHP 5.3.10 fails to cross compile when FPM is enabled (ptrace)
Edit report at https://bugs.php.net/bug.php?id=61057&edit=1 ID: 61057 User updated by:d dot albano at gmail dot com Reported by:d dot albano at gmail dot com Summary:PHP 5.3.10 fails to cross compile when FPM is enabled (ptrace) -Status: Feedback +Status: Open Type: Bug Package:Compile Failure Operating System: Linux PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I'm cross compiling because i'm building a set of images for boards like alix, routerboards and, when it will be out, raspberry pi too. I know that it may sound strange, but i don't want to put an entire distribution on the alix my 30mb systems works perfectly and has everything i need. Thank you, i'll do a test. Previous Comments: [2012-02-12 21:27:44] ras...@php.net Why are you cross-compiling to the same architecture? You may be able to solve this simply by using a newer version of autoconf to generate the configure script. As a quick test, try building the latest PHP 5.4 with a recent version of autoconf installed. (use ./buildconf --force to force re-generation of the configure script) For PHP 5.3 the latest you can use is autoconf-2.59 For PHP 5.4 the oldest you can use is autoconf-2.59 [2012-02-12 21:06:43] hotseason007 at gmail dot com I also reach it ,but php.net don't regard it as a bug ! here is my report: https://bugs.php.net/bug.php?id=61063 I have fix and Here is the guid: https://github.com/Qzi/webstore/wiki the page attaches the patch enjoy it !! [2012-02-11 17:15:22] d dot albano at gmail dot com Description: I'm trying to cross compile php 5.3.10 (build x86, host x86, target x86) but when i enable FPM i get the following error checking whether ptrace works... configure: error: can not run test program while cross compiling I know that FPM is experimental, btw the bug is related to configure script and not to FPM itself. Wihtout fpm, enabling only cgi and cli works fine Here more output, starting from SAPI modules Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking whether to enable Apache charset compatibility option... no checking for Apache 2.0 filter-module support via DSO through APXS... no checking for Apache 2.0 handler-module support via DSO through APXS... no checking for Apache 1.x (hooks) module support via DSO through APXS... no checking for Apache 1.x (hooks) module support... no checking whether to enable Apache charset compatibility option... no checking for Caudium support... no checking for CLI build... yes checking for Continuity support... no checking for embedded SAPI library support... no checking for FPM build... yes checking for setenv... yes checking for clearenv... yes checking for setproctitle... no checking for library containing socket... none required checking for library containing inet_addr... none required checking for errno.h... yes checking for fcntl.h... yes checking for stdio.h... yes checking for stdlib.h... yes checking for unistd.h... yes checking for sys/uio.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/time.h... yes checking for arpa/inet.h... yes checking for netinet/in.h... yes checking for prctl... yes checking for clock_gettime... yes checking for ptrace... yes checking whether ptrace works... configure: error: can not run test program while cross compiling make[1]: *** [/home/daniele/sviluppo/clew.js/br-rootfs/build/php- 5.3.10/.stamp_configured] Errore 1 make: *** [all] Errore 2 Expected result: it should go ahead Actual result: -- checking whether ptrace works... configure: error: can not run test program while cross compiling -- Edit this bug report at https://bugs.php.net/bug.php?id=61057&edit=1
Bug #61057 [Opn->Fbk]: PHP 5.3.10 fails to cross compile when FPM is enabled (ptrace)
Edit report at https://bugs.php.net/bug.php?id=61057&edit=1 ID: 61057 Updated by: ras...@php.net Reported by:d dot albano at gmail dot com Summary:PHP 5.3.10 fails to cross compile when FPM is enabled (ptrace) -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: Linux PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Why are you cross-compiling to the same architecture? You may be able to solve this simply by using a newer version of autoconf to generate the configure script. As a quick test, try building the latest PHP 5.4 with a recent version of autoconf installed. (use ./buildconf --force to force re-generation of the configure script) For PHP 5.3 the latest you can use is autoconf-2.59 For PHP 5.4 the oldest you can use is autoconf-2.59 Previous Comments: [2012-02-12 21:06:43] hotseason007 at gmail dot com I also reach it ,but php.net don't regard it as a bug ! here is my report: https://bugs.php.net/bug.php?id=61063 I have fix and Here is the guid: https://github.com/Qzi/webstore/wiki the page attaches the patch enjoy it !! [2012-02-11 17:15:22] d dot albano at gmail dot com Description: I'm trying to cross compile php 5.3.10 (build x86, host x86, target x86) but when i enable FPM i get the following error checking whether ptrace works... configure: error: can not run test program while cross compiling I know that FPM is experimental, btw the bug is related to configure script and not to FPM itself. Wihtout fpm, enabling only cgi and cli works fine Here more output, starting from SAPI modules Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking whether to enable Apache charset compatibility option... no checking for Apache 2.0 filter-module support via DSO through APXS... no checking for Apache 2.0 handler-module support via DSO through APXS... no checking for Apache 1.x (hooks) module support via DSO through APXS... no checking for Apache 1.x (hooks) module support... no checking whether to enable Apache charset compatibility option... no checking for Caudium support... no checking for CLI build... yes checking for Continuity support... no checking for embedded SAPI library support... no checking for FPM build... yes checking for setenv... yes checking for clearenv... yes checking for setproctitle... no checking for library containing socket... none required checking for library containing inet_addr... none required checking for errno.h... yes checking for fcntl.h... yes checking for stdio.h... yes checking for stdlib.h... yes checking for unistd.h... yes checking for sys/uio.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/time.h... yes checking for arpa/inet.h... yes checking for netinet/in.h... yes checking for prctl... yes checking for clock_gettime... yes checking for ptrace... yes checking whether ptrace works... configure: error: can not run test program while cross compiling make[1]: *** [/home/daniele/sviluppo/clew.js/br-rootfs/build/php- 5.3.10/.stamp_configured] Errore 1 make: *** [all] Errore 2 Expected result: it should go ahead Actual result: -- checking whether ptrace works... configure: error: can not run test program while cross compiling -- Edit this bug report at https://bugs.php.net/bug.php?id=61057&edit=1
Bug #61063 [Com]: enable-fpm bugs
Edit report at https://bugs.php.net/bug.php?id=61063&edit=1 ID: 61063 Comment by: hotseason007 at gmail dot com Reported by:hotseason007 at gmail dot com Summary:enable-fpm bugs Status: Not a bug Type: Bug Package:*Configuration Issues Operating System: centos 5.7 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I know that fpm ships with 5.3.10,but there is compile error,I'm not along ! https://bugs.php.net/bug.php?id=61057 Previous Comments: [2012-02-12 20:42:18] ras...@php.net FPM ships with the PHP source distribution. Use ./configure --enable-fpm && make to build it. [2012-02-12 20:36:50] hotseason007 at gmail dot com Description: http://php-fpm.org/downloads/ there is no fpm for 5.3.10 the feature is EXPERIMENTAL,bug it will make install fail! cd php-5.3.x svn co http://svn.php.net/repository/php/php-src/trunk/sapi/fpm sapi/fpm there is a error Test script: --- after installed,there is no sbin/php-fpm! Expected result: Enable fpm ok ! Actual result: -- Enable fpm ok and everything goes right after the patch ! here is more about the patch https://github.com/Qzi/webstore/wiki -- Edit this bug report at https://bugs.php.net/bug.php?id=61063&edit=1
Bug #61057 [Com]: PHP 5.3.10 fails to cross compile when FPM is enabled (ptrace)
Edit report at https://bugs.php.net/bug.php?id=61057&edit=1 ID: 61057 Comment by: hotseason007 at gmail dot com Reported by:d dot albano at gmail dot com Summary:PHP 5.3.10 fails to cross compile when FPM is enabled (ptrace) Status: Open Type: Bug Package:Compile Failure Operating System: Linux PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I also reach it ,but php.net don't regard it as a bug ! here is my report: https://bugs.php.net/bug.php?id=61063 I have fix and Here is the guid: https://github.com/Qzi/webstore/wiki the page attaches the patch enjoy it !! Previous Comments: [2012-02-11 17:15:22] d dot albano at gmail dot com Description: I'm trying to cross compile php 5.3.10 (build x86, host x86, target x86) but when i enable FPM i get the following error checking whether ptrace works... configure: error: can not run test program while cross compiling I know that FPM is experimental, btw the bug is related to configure script and not to FPM itself. Wihtout fpm, enabling only cgi and cli works fine Here more output, starting from SAPI modules Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking whether to enable Apache charset compatibility option... no checking for Apache 2.0 filter-module support via DSO through APXS... no checking for Apache 2.0 handler-module support via DSO through APXS... no checking for Apache 1.x (hooks) module support via DSO through APXS... no checking for Apache 1.x (hooks) module support... no checking whether to enable Apache charset compatibility option... no checking for Caudium support... no checking for CLI build... yes checking for Continuity support... no checking for embedded SAPI library support... no checking for FPM build... yes checking for setenv... yes checking for clearenv... yes checking for setproctitle... no checking for library containing socket... none required checking for library containing inet_addr... none required checking for errno.h... yes checking for fcntl.h... yes checking for stdio.h... yes checking for stdlib.h... yes checking for unistd.h... yes checking for sys/uio.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/time.h... yes checking for arpa/inet.h... yes checking for netinet/in.h... yes checking for prctl... yes checking for clock_gettime... yes checking for ptrace... yes checking whether ptrace works... configure: error: can not run test program while cross compiling make[1]: *** [/home/daniele/sviluppo/clew.js/br-rootfs/build/php- 5.3.10/.stamp_configured] Errore 1 make: *** [all] Errore 2 Expected result: it should go ahead Actual result: -- checking whether ptrace works... configure: error: can not run test program while cross compiling -- Edit this bug report at https://bugs.php.net/bug.php?id=61057&edit=1
Bug #61063 [Opn->Nab]: enable-fpm bugs
Edit report at https://bugs.php.net/bug.php?id=61063&edit=1 ID: 61063 Updated by: ras...@php.net Reported by:hotseason007 at gmail dot com Summary:enable-fpm bugs -Status: Open +Status: Not a bug Type: Bug Package:*Configuration Issues Operating System: centos 5.7 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: FPM ships with the PHP source distribution. Use ./configure --enable-fpm && make to build it. Previous Comments: [2012-02-12 20:36:50] hotseason007 at gmail dot com Description: http://php-fpm.org/downloads/ there is no fpm for 5.3.10 the feature is EXPERIMENTAL,bug it will make install fail! cd php-5.3.x svn co http://svn.php.net/repository/php/php-src/trunk/sapi/fpm sapi/fpm there is a error Test script: --- after installed,there is no sbin/php-fpm! Expected result: Enable fpm ok ! Actual result: -- Enable fpm ok and everything goes right after the patch ! here is more about the patch https://github.com/Qzi/webstore/wiki -- Edit this bug report at https://bugs.php.net/bug.php?id=61063&edit=1
[PHP-BUG] Bug #61063 [NEW]: enable-fpm bugs
From: Operating system: centos 5.7 PHP version: 5.3.10 Package: *Configuration Issues Bug Type: Bug Bug description:enable-fpm bugs Description: http://php-fpm.org/downloads/ there is no fpm for 5.3.10 the feature is EXPERIMENTAL,bug it will make install fail! cd php-5.3.x svn co http://svn.php.net/repository/php/php-src/trunk/sapi/fpm sapi/fpm there is a error Test script: --- after installed,there is no sbin/php-fpm! Expected result: Enable fpm ok ! Actual result: -- Enable fpm ok and everything goes right after the patch ! here is more about the patch https://github.com/Qzi/webstore/wiki -- Edit bug report at https://bugs.php.net/bug.php?id=61063&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61063&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61063&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61063&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61063&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61063&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61063&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61063&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61063&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61063&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61063&r=support Expected behavior: https://bugs.php.net/fix.php?id=61063&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61063&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61063&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61063&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61063&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61063&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61063&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61063&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61063&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61063&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61063&r=mysqlcfg
Bug #55348 [Com]: SoapServer (typemap related) "Error calling from_xml callback"
Edit report at https://bugs.php.net/bug.php?id=55348&edit=1 ID: 55348 Comment by: chris at cmbuckley dot co dot uk Reported by:sprotte at visionconnect dot de Summary:SoapServer (typemap related) "Error calling from_xml callback" Status: Open Type: Bug Package:SOAP related Operating System: openSUSE 11.4 PHP Version:5.3.7RC4 Block user comment: N Private report: N New Comment: Regardless of the Xdebug comment, the error is still present without Xdebug; if the from_xml callback generates an error more than once during server handling, the error message "Error calling from_xml callback" is shown instead of the actual fault. Previous Comments: [2011-08-23 12:26:15] der...@php.net There is an incompatibility with Xdebug and the SOAP extension, due to the way that the SOAP extension also overloads php_error_cb. In order to properly fix this, the error_cb overloading needs to be changed. I don't however know, exactly how. See also: http://bugs.xdebug.org/view.php?id=609 http://bugs.xdebug.org/view.php?id=705 [2011-08-23 11:19:45] chris at cmbuckley dot co dot uk Additional: Fatal only happens in conjunction with Xdebug (see https://bugs.php.net/bug.php?id=50547). [2011-08-22 19:48:28] chris at cmbuckley dot co dot uk Description: Reduced to smaller test script. Test script: http://starsquare.co.uk/code/php/bugs/55348.phps Expected result: ... SOAP-ENV:Server Conversion Fault ... Actual result: -- Fatal error: SOAP-ERROR: Encoding: Error calling from_xml callback [2011-08-02 15:14:41] sprotte at visionconnect dot de Description: Throwing a SoapFault exception inside the from_xml callback function (when using the "typemap" feature with SoapServer) does not work as expected in some cases. I have created a small client/server application with one working example (type "date") and one not working example (type "myType"). In case of the "date" type the SoapFault exception is transformed into a matching SOAP-Response. The original message is available on the client side. In case of the "myType" type the thrown SoapFault exception is completely ignored and the SOAP-Response contains another error message. Test script: --- http://www.visionconnect.de/php_bugreports/soapserver_to_xml.tar.gz Expected result: Faultcode: 0001 Faultstring: Invalid date: 2011-15-15 Faultcode: 0002 Faultstring: Invalid type: foobar Actual result: -- Faultcode: 0001 Faultstring: Invalid date: 2011-15-15 Faultcode: SOAP-ENV:Server Faultstring: SOAP-ERROR: Encoding: Error calling from_xml callback -- Edit this bug report at https://bugs.php.net/bug.php?id=55348&edit=1
Bug #43261 [Com]: Use ^ as escape char for windows escapeshellcmd
Edit report at https://bugs.php.net/bug.php?id=43261&edit=1 ID: 43261 Comment by: microsoftsux at gmx dot de Reported by:RQuadling at GMail dot com Summary:Use ^ as escape char for windows escapeshellcmd Status: Closed Type: Bug Package:Program Execution Operating System: Windows XP SP2 PHP Version:5.3CVS-2007-11-12 (snap) Assigned To:scottmac Block user comment: N Private report: N New Comment: I can confirm this issue is not fixed as "d dot kreuer at ibrams dot com" stated. The problem is, that windows does not require escaping characters if the path or argument is quoted. Since paths that contain whitespaces NEED TO BE quoted, they on the other hand MAY NOT be escaped. So the solution would be to NOT escape the path/argument, if it contains whitespaces on windows within escapeshellcmd. Additionally quoting the argument however, would be a breaking change - though correct implementation wise - because most applications up to now do this themself and double quoting is also not permitted. Test cases: C:\>C:\Dev\test(1)\test.bat Der Befehl "C:\Dev\test" ist entweder falsch geschrieben oder konnte nicht gefunden werden. C:\>C:\Dev\test^(1^)\test.bat 'OK' C:\>"C:\Dev\test^(1^)\test.bat" Das System kann den angegebenen Pfad nicht finden. C:\>"C:\Dev\test(1)\test.bat" 'OK' C:\>C:\Dev\test (2)\test.bat Der Befehl "C:\Dev\test" ist entweder falsch geschrieben oder konnte nicht gefunden werden. C:\>C:\Dev\test ^(2^)\test.bat Der Befehl "C:\Dev\test" ist entweder falsch geschrieben oder konnte nicht gefunden werden. C:\>"C:\Dev\test ^(2^)\test.bat" Das System kann den angegebenen Pfad nicht finden. C:\>"C:\Dev\test (2)\test.bat" 'OK' Previous Comments: [2011-12-14 15:35:53] d dot kreuer at ibrams dot com This issue is not fixed. It happened that I tried to use PHPUnit which escapes the command to invoke PHP. In my installation the php.exe can be found under the following path: C:\Program Files (x86)\PHP\v5.3\php.exe This is the default path for a PHP installation in combination with Windows and IIS (+ Platform Installer). This path is currently escaped in the following way: C:^\Program Files ^(x86^)^\PHP^\v5.3^\php.exe Called from the commandline (which I assume is the same as called via exec()) the following happens: C:\>C:^\Program Files ^(x86^)^\PHP^\v5.3^\php.exe The command "C:\Program" is invalid or could not be found. Even escaping the spaces does not work: C:\>C:^\Program^ Files^ ^(x86^)^\PHP^\v5.3^\php.exe Could not open input file: Files Additionally surrounding the command with quotation marks which normally does not fail (because the spaces are threated as part of the command) does not work: C:\>"C:^\Program Files ^(x86^)^\PHP^\v5.3^\php.exe" The system cannot find the path specified. If I run the command not escaped via escapeshellcmd() and only surrounded with quotes, it works. C:\>"C:\Program Files (x86)\PHP\v5.3\php.exe" -v PHP 5.3.8 (cli) (built: Aug 23 2011 12:14:39) Used PHP Version is 5.3.8 (NTS) and OS is Windows 7. [2008-07-22 16:22:07] scott...@php.net This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Test added for this now. [2008-06-10 12:10:08] paj...@php.net Assigned to Scott, needs more tests cases and explanation (as it may break a lot of scripts). [2008-06-10 10:20:14] ka...@php.net Actually Scott fixed this without marking it as fixed =) [2008-06-10 10:12:54] ka...@php.net Well if nobody else wanna apply it, then Ill take it =) 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=43261 -- Edit this bug report at https://bugs.php.net/bug.php?id=43261&edit=1
Bug #60471 [Com]: Random "Invalid request (unexpected EOF)" using a router script
Edit report at https://bugs.php.net/bug.php?id=60471&edit=1 ID: 60471 Comment by: rbrunius at gmail dot com Reported by:lolautruche at gmail dot com Summary:Random "Invalid request (unexpected EOF)" using a router script Status: Assigned Type: Bug Package:Built-in web server Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.4.0RC2 Assigned To:laruence Block user comment: N Private report: N New Comment: I'm am having the same thing happen and I Googled error code it and found this thread. I tried various ways to terminate the file but none solved it. php 5.4 RC7 development server on Windows 7 Chrome browser has brings the issue but Firefox does not. Previous Comments: [2011-12-09 13:59:12] patrickalla...@php.net @laruence: Gentoo Linux Most of the time, several of those messages appears in one block like in: [Thu Dec 8 13:39:29 2011] 127.0.0.1:50358 Invalid request (Unexpected EOF) [Thu Dec 8 13:39:29 2011] 127.0.0.1:50359 Invalid request (Unexpected EOF) [Thu Dec 8 13:39:29 2011] 127.0.0.1:50360 Invalid request (Unexpected EOF) [Thu Dec 8 13:39:29 2011] 127.0.0.1:50361 Invalid request (Unexpected EOF) [Thu Dec 8 13:39:29 2011] 127.0.0.1:50362 Invalid request (Unexpected EOF) I expect it comes from the fact that the page generated by the built-in server contains references to pictures, js and css files that has been downloaded by chrome through the built-in server. Does chrome do some special treatment? Can't reproduce with a dummy page with just an Hello World. [2011-12-09 05:44:26] larue...@php.net I can't reproduce this on Linux. @patrickallaert, what is your OS? [2011-12-08 16:24:27] patrickalla...@php.net I can confirm those messages. It looks like it happens only with Chrome/Chromium. Debugging at the TCP level shows that it comes from empty messages: TCP messages corresponding to port 41767 that generated the error message: [Thu Dec 8 16:48:33 2011] 127.0.0.1:41767 Invalid request (Unexpected EOF) appears below, as captured by Wireshark. No. TimeSourceDestination Protocol Length Info 1214 196.678104 127.0.0.1 127.0.0.1 TCP 74 41767 > http-alt [SYN] Seq=0 Win=32792 Len=0 MSS=16396 SACK_PERM=1 TSval=209439162 TSecr=0 WS=128 Frame 1214: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) Arrival Time: Dec 8, 2011 16:48:22.673873000 CET Epoch Time: 1323359302.673873000 seconds [Time delta from previous captured frame: 9.255505000 seconds] [Time delta from previous displayed frame: 0.0 seconds] [Time since reference or first frame: 196.678104000 seconds] Frame Number: 1214 Frame Length: 74 bytes (592 bits) Capture Length: 74 bytes (592 bits) [Frame is marked: True] [Frame is ignored: False] [Protocols in frame: eth:ip:tcp] [Coloring Rule Name: TCP SYN/FIN] [Coloring Rule String: tcp.flags & 0x02 || tcp.flags.fin == 1] Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Destination: 00:00:00_00:00:00 (00:00:00:00:00:00) Address: 00:00:00_00:00:00 (00:00:00:00:00:00) ...0 = IG bit: Individual address (unicast) ..0. = LG bit: Globally unique address (factory default) Source: 00:00:00_00:00:00 (00:00:00:00:00:00) Address: 00:00:00_00:00:00 (00:00:00:00:00:00) ...0 = IG bit: Individual address (unicast) ..0. = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol Version 4, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 00.. = Differentiated Services Codepoint: Default (0x00) ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 60 Identification: 0x6b16 (27414) Flags: 0x02 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: TCP (6) Header checksum: 0xd1a3 [correct] [Good: True] [Bad: False] Source: 127.0.0.1 (127.0.0.1) Destination: 127.0.0.1 (127.0.0.1) Transmission Control Protocol, Src Port: 41767 (41767), Dst Port: http-alt (8080), Seq: 0, Len: 0 Source port: 41767 (41767) Destination port: http-alt (8080)
Bug #55416 [Com]: array_map() throws PHP warning if the callback throws an exception
Edit report at https://bugs.php.net/bug.php?id=55416&edit=1
ID: 55416
Comment by: harvey dot robin at gmail dot com
Reported by:roan dot kattouw at gmail dot com
Summary:array_map() throws PHP warning if the callback
throws an exception
Status: Open
Type: Bug
Package:Arrays related
Operating System: Ubuntu Natty
PHP Version:5.4.0alpha3
Block user comment: N
Private report: N
New Comment:
I've just come across this too and I'm really surprised at this inconsistent
behavior, for me the question isn't "what kind of situation needs throw a
exception in map function" but "why would the map function behave differently
to any other situation". If you change array_map to array_walk in the original
example then the exception propagates upward, as expected.
At the very least, I'd expect to see a note on the PHP manual page warning
users that exceptions work differently for the callback parameter to array_walk.
Previous Comments:
[2011-08-16 16:20:17] mah at everybody dot org
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94433 has Roan's actual
use case.
[2011-08-15 09:35:40] roan dot kattouw at gmail dot com
Basically what I'm doing is
implode("\n", array_map('readStyleFile', $files)
where $files is an array of file names, and readStyleFile() can throw an
exception if something is wrong (in this case it's if the file doesn't exist,
but other cases are imaginable). This exception then propagates up a few levels
and is caught and handled. Throwing an exception from inside the map callback
works just fine: it stops the callback, stops array_map(), propagates up to the
caller of array_map(), then works its way up the call stack like any other
exception. The only issue is that warning that won't go away.
[2011-08-15 08:54:02] larue...@php.net
I was wondering what kind of situation needs throw a exception in map function?
and why doing that? thanks
[2011-08-13 20:40:11] roan dot kattouw at gmail dot com
Something I forgot to mention in the original report:
Using @array_map(...) suppresses the warning. However, it also suppresses any
other notices or warnings that might happen in the callback. That's why I put
the $foo = $bar['baz']; bit in barf(): if you use @array_map, the "Undefined
variable" notice, which is legitimate, goes away as well.
More generally, @ is kind of a blunt instrument that often suppresses more than
you expect it to, masking mistakes.
[2011-08-13 20:32:50] roan dot kattouw at gmail dot com
The attached patch fixes this by not throwing the warning if EG(exception) is
not NULL. IMO the warning should be removed completely (because it's
superfluous, and I don't see offhand how it can be triggered other than by an
exception, but I don't know PHP core at all), but it's easy to tweak my patch
into doing that instead; this patch is just the minimal solution.
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=55416
--
Edit this bug report at https://bugs.php.net/bug.php?id=55416&edit=1
Bug #60886 [Com]: Random segmentation faults in autoload (PHP 5.3.9)
Edit report at https://bugs.php.net/bug.php?id=60886&edit=1
ID: 60886
Comment by: sefer at hotmail dot com
Reported by:sefer at hotmail dot com
Summary:Random segmentation faults in autoload (PHP 5.3.9)
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Ubuntu Linux
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
Hi
I will try to provide the autoload module (if I receive permission to).
I seem to be getting other stack traces that lead me to suspect the multibyte
module.
The [mbstring] section in our php.ini file doesn't contain any definitions, so
defaults apply.
I hope this provides another clue.
#0 _zend_mm_free_int (heap=0x30bd6f0, p=0x37b8fe0) at /home/sababa/t/php-
5.3.9/Zend/zend_alloc.c:2028
2028if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
#0 _zend_mm_free_int (heap=0x30bd6f0, p=0x37b8fe0) at /home/sababa/t/php-
5.3.9/Zend/zend_alloc.c:2028
#1 0x7f030e3a92d7 in zend_multibyte_read_script (buf=0x7f0318495000
, n=1445, tsrm_ls=0x2dc6800)
at Zend/zend_language_scanner.l:709
#2 0x7f030e3a9410 in open_file_for_scanning (file_handle=0x7f02f87f7c40,
tsrm_ls=0x2dc6800) at Zend/zend_language_scanner.l:279
#3 0x7f030e3a97f8 in compile_file (file_handle=0x7f02f87f7c40, type=8,
tsrm_ls=0x2dc6800) at Zend/zend_language_scanner.l:352
#4 0x7f030e219366 in phar_compile_file (file_handle=0x7f02f87f7c40,
type=8,
tsrm_ls=0x2dc6800)
at /home/sababa/t/php-5.3.9/ext/phar/phar.c:3393
#5 0x7f030e3dd266 in zend_execute_scripts (type=8, tsrm_ls=0x2dc6800,
retval=0x0, file_count=3)
at /home/sababa/t/php-5.3.9/Zend/zend.c:1228
#6 0x7f030e380273 in php_execute_script (primary_file=0x7f02f87f7c40,
tsrm_ls=0x2dc6800) at /home/sababa/t/php-5.3.9/main/main.c:2308
#7 0x7f030e476fb2 in php_handler (r=0x467ee10) at /home/sababa/t/php-
5.3.9/sapi/apache2handler/sapi_apache2.c:669
#8 0x00438c48 in ap_run_handler (r=0x467ee10) at config.c:158
#9 0x0043908c in ap_invoke_handler (r=0x467ee10) at config.c:376
#10 0x0044565c in ap_internal_redirect (new_uri=,
r=) at http_request.c:554
#11 0x7f030edf40fd in handler_redirect (r=0x4677970) at mod_rewrite.c:4838
#12 0x00438c48 in ap_run_handler (r=0x4677970) at config.c:158
#13 0x0043908c in ap_invoke_handler (r=0x4677970) at config.c:376
#14 0x00445fb0 in ap_process_request (r=0x4677970) at http_request.c:282
#15 0x00443120 in ap_process_http_connection (c=0x4671278) at
http_core.c:190
#16 0x0043f568 in ap_run_process_connection (c=0x4671278) at
connection.c:43
#17 0x0044bb11 in process_socket (thd=0x18a33f0, dummy=) at worker.c:544
#18 worker_thread (thd=0x18a33f0, dummy=) at worker.c:894
#19 0x7f031731fd8c in start_thread (arg=0x7f02f87f8700) at
pthread_create.c:304
#20 0x7f0316e6704d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#21 0x in ?? ()
Previous Comments:
[2012-01-27 09:40:43] ahar...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
I can't reproduce this out of the box. We're going to need to know at least
what's
in your autoload function to progress here, and preferably a self-contained
example.
[2012-01-25 16:06:31] sefer at hotmail dot com
Description:
Hi,
I have been experiencing sporadic segmentation faults in our PHP 5.3.8/9
(running as a module under Apache 2.2.21 in Ubuntu Linux ). We upgraded to PHP
5.3.9 but the random segmentation problems remain.
>From the core dump I see that this is happening in our autoload function.
Here's how we register the autoload call:
spl_autoload_register(array("AutoLoadCache", "autoload"));
class AutoLoadCache
{
static public function autoload($class_name)
{
...
}
}
This is how we built our PHP instance:
./configure --prefix=/opt/php-5.3.9 --with-apxs2=/opt/httpd/bin/apxs --enable-
zip --enable-zend-multibyte --enable-sysvshm --enable-sysvsem --enable-sysvmsg -
-with-openssl --with-zlib --enable-calendar --with-zlib --enable-ftp --enable-
intl --enable-intl --with-pgsql=/opt/postgresql --with-readline
--enable-sockets
--enable-sqlite-utf8 --enable-soap --with-mcrypt=/opt/libmcrypt --enable-
mbstring --with-curl --with-gd --enable-gd-native-ttf --with-free
Bug #61054 [Com]: preg_match () matching end of line in text file of windows style make a mistake
Edit report at https://bugs.php.net/bug.php?id=61054&edit=1 ID: 61054 Comment by: ni...@php.net Reported by:gzpan123 at gmail dot com Summary:preg_match () matching end of line in text file of windows style make a mistake Status: Open Type: Bug Package:*Regular Expressions Operating System: Windows,linux all PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I don't really understand the issue you have from your example, but in general LF is the compile-default linebreak for PCRE. If you want to use a different linebreak character you can either compile PCRE with the appropriate option or specify a control option like (*CRLF) before your regular expression. Previous Comments: [2012-02-11 09:47:27] gzpan123 at gmail dot com windows,linux all meet this bug [2012-02-11 09:42:45] gzpan123 at gmail dot com Description: function:preg_ match() when processing text file of windows style like blow example,it get wrong the $matches[2] behind follow a character , Create a text file(test.txt) in windowsï¼Content: hello guo hi jason test Test script: --- Expected result: Array ( [0] => hello guo [1] => hello [2] => guo ) hello guo helloguo Array ( [0] => hi jason [1] => hi [2] => jason ) hi jason hijason Array ( ) test Actual result: -- hello guo Array ( [0] => hello guo [1] => hello [2] => guo ) hi jason Array ( [0] => hi jason [1] => hi [2] => jason ) testArray ( ) test -- Edit this bug report at https://bugs.php.net/bug.php?id=61054&edit=1
Bug #51425 [Com]: segfaults at method_exists()
Edit report at https://bugs.php.net/bug.php?id=51425&edit=1
ID: 51425
Comment by: eduards at cervon dot net
Reported by:jimmyxx at gmail dot com
Summary:segfaults at method_exists()
Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: Ubuntu 9.10
PHP Version:5.2.13
Block user comment: N
Private report: N
New Comment:
This also happens with PHP 5.3.3-7+squeeze7 with Suhosin-Patch (latest stable
for Debian production systems)
Code that causes crash:
class db_result extends mysqli_result
{
public function fetch_all()
{
if (method_exists('parent', 'fetch_all'))
{
$result = parent::fetch_all(MYSQLI_ASSOC);
$this->free();
return (array)$result;
}
else
{
// [...] code that emulates mysqli_result::fetch_all
functionality
}
}
}
Previous Comments:
[2011-11-16 13:56:50] fel...@php.net
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
[2010-07-20 16:38:44] adam dot zivner at gmail dot com
PHP 5.3.12 => PHP 5.2.13
[2010-07-20 16:37:38] adam dot zivner at gmail dot com
Experiencing the same problem on PHP 5.3.12. PHP 5.3.1 runs fine.
[2010-03-30 12:12:30] jimmyxx at gmail dot com
Urgh I just installed the debs I compiled but realised this it's still 5.2.10
as
I use package manager to get me the build-deps.
here is the backtrace from the compiled version:
#0 0x012d8a5d in zif_method_exists (ht=2, return_value=0x20d06588,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /home/jimmy/php5-
5.2.10.dfsg.1/Zend/zend_builtin_functions.c:935
935 convert_to_string_ex(method_name);
(gdb) bt full
#0 0x012d8a5d in zif_method_exists (ht=2, return_value=0x20d06588,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /home/jimmy/php5-
5.2.10.dfsg.1/Zend/zend_builtin_functions.c:935
klass = 0x20bb047c
method_name = 0x20bb0480
lcname = 0x0
ce = 0x20d0f03c
pce = 0x20b0c364
#1 0x012f0f52 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfc4830c) at
/home/jimmy/php5-5.2.10.dfsg.1/Zend/zend_vm_execute.h:200
return_reference = 0 '\000'
opline = 0x20d22008
original_return_value = 0x20d0a4c8
current_scope = 0x0
current_this = 0x0
return_value_used = 1
should_change_scope = 0 '\000'
ctor_opline = 0xbfc48314
#2 0x012f4ca9 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbfc4830c) at
/home/jimmy/php5-5.2.10.dfsg.1/Zend/zend_vm_execute.h:1739
opline = 0x20d22008
fname = 0x20d22024
#3 0x012f0a8b in execute (op_array=0x20d07aa8) at /home/jimmy/php5-
5.2.10.dfsg.1/Zend/zend_vm_execute.h:92
execute_data = {opline = 0x20d22008, function_state =
{function_symbol_table = 0x20bdf8e0, function = 0x20ac7080, reserved = {0x21,
0x648855b6, 0xbfc48344, 0x20c18f24}}, fbc = 0x0,
op_array = 0x20d07aa8, object = 0x0, Ts = 0xbfc46bf0, CVs =
0xbfc46bc0, original_in_execution = 1 '\001', symbol_table = 0x20bdf550,
prev_execute_data = 0xbfc4872c,
old_error_reporting = 0x0}
op_array = 0x20d07aa8
#4 0x012f110d in zend_do_fcall_common_helper_SPEC (execute_data=0xbfc4872c) at
/home/jimmy/php5-5.2.10.dfsg.1/Zend/zend_vm_execute.h:234
opline = 0x20c1e9f8
original_return_value = 0xbfc488b0
current_scope = 0x20c18f24
current_this = 0x20cea3e0
return_value_used = 1
should_change_scope = 1 '\001'
ctor_opline = 0xbfc485d0
#5 0x012f1687 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfc4872c)
at /home/jimmy/php5-5.2.10.dfsg.1/Zend/zend_vm_execute.h:322
No locals.
#6 0x012f0a8b in execute (op_array=0x20c1cc9c) at /home/jimmy/php5-
5.2.10.dfsg.1/Zend/zend_vm_execute.h:92
execute_data = {opline = 0x20c1e9f8, function_state =
{function_symbol_table = 0x20bdf550, function = 0x20d07aa8, reserved =
{0xbfc487c8, 0x12ea192, 0x0, 0x20c18f24}}, fbc = 0x20d07aa8,
op_array = 0x20c1cc9c, object = 0x20d00620, Ts = 0xbfc48450, CVs =
0xbfc48
Bug #61029 [Fbk->Csd]: '@' operator before a function call causes php to hang till max-exec-time
Edit report at https://bugs.php.net/bug.php?id=61029&edit=1 ID: 61029 User updated by:yonni dot m at zend dot com Reported by:yonni dot m at zend dot com Summary:'@' operator before a function call causes php to hang till max-exec-time -Status: Feedback +Status: Closed Type: Bug Package:*General Issues Operating System: MacOS 10.6 PHP Version:5.4.0RC7 Block user comment: N Private report: N New Comment: I misreported this issue, the actual problem involved common resources used by Zend's extensions and php itself. The real underlying problem was reported to the internals mailing list for continued handling. Previous Comments: [2012-02-09 16:19:53] larue...@php.net I can not reproduce this, could you help us to find more infos? like: run the test script. when it hanged, put the php process background (ctrl+z, then $bg). find the process's pid. gdb --pid=php's pid then gdb>bt paste the backtrace to here. thanks [2012-02-09 15:36:02] yonni dot m at zend dot com Description: Steps to reproduce: Php 5.4RC7 on MACOS 10.6 Execute script in test script doesn't matter if index.html is actually there Note php error logs Test script: --- https://bugs.php.net/bug.php?id=61029&edit=1
Bug #61052 [Opn]: missing error check in trait 'insteadof' clause
Edit report at https://bugs.php.net/bug.php?id=61052&edit=1 ID: 61052 Updated by: g...@php.net Reported by:ottoni at fb dot com Summary:missing error check in trait 'insteadof' clause Status: Open Type: Bug Package:*Compile Issues Operating System: Linux PHP Version:5.4.0RC7 -Assigned To: +Assigned To:gron Block user comment: N Private report: N New Comment: Thanks for the report!. Would classify this issue as non-critical. So, I will look into it once 5.4.0 is out. Previous Comments: [2012-02-10 23:49:43] ottoni at fb dot com Description: See example script. Test script: --- https://bugs.php.net/bug.php?id=61052&edit=1
Bug #45191 [Com]: error_log ignores date.timezone php.ini val when setting logging timestamps
Edit report at https://bugs.php.net/bug.php?id=45191&edit=1
ID: 45191
Comment by: wadkar at gmail dot com
Reported by:info at organicdata dot co dot za
Summary:error_log ignores date.timezone php.ini val when
setting logging timestamps
Status: Closed
Type: Bug
Package:Date/time related
Operating System: Centos el5
PHP Version:5.2CVS-2008-06-05 (snap)
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
@christopher
Interesting observation. My report is with 5.3.8 version, which outputs the log
with UTC timestamp (the timezone is part of it). I am getting a feeling that
this might not be a direct issue with php-src but somewhere in between system
calls made by php-src for logging and the OS itself which passes on TZ data for
this call.
Previous Comments:
[2012-02-11 18:15:29] christopher at specialtyproduce dot com
It seems this bug may have reappeared between 5.3.8 and 5.3.9?
I have two MS 2008 R2 VMs, built from the same starting images. Both running
IIS 7.5, system timezone is set for "Pacific Standard Time" and the TZ
environment variable is not set.
Machine A : PHP 5.3.8 (cli) (built: Aug 23 2011 12:14:39)
(Originally configured with PHP 5.2.17 and subsequently upgraded to 5.3.8)
Machine B : PHP 5.3.9 (cli) (built: Jan 10 2012 16:33:06)
Their php.ini files are virtually identical, with:
log_errors = On
date.timezone=America/Los_Angeles
error_log="C:\PHP\logs\php53_errors.log"
I ran a version of the "mycode.php" from the original bug report on both
machines.
mycode.php
--
FIRSTBADCONSTANT;
date_default_timezone_set("UTC");
SOMEBADCONSTANT;
date_default_timezone_set("America/Los_Angeles");
ANOTHERBADCONSTANT;
Machine A php53_errors.log
--
[11-Feb-2012 09:39:18] PHP Notice: Use of undefined constant FIRSTBADCONSTANT
- assumed 'FIRSTBADCONSTANT' in C:\Temp\mycode.php on line 2
[11-Feb-2012 17:39:18] PHP Notice: Use of undefined constant SOMEBADCONSTANT -
assumed 'SOMEBADCONSTANT' in C:\Temp\mycode.php on line 4
[11-Feb-2012 09:39:18] PHP Notice: Use of undefined constant
ANOTHERBADCONSTANT - assumed 'ANOTHERBADCONSTANT' in C:\Temp\mycode.php on line
6
Machine B php53_errors.log
--
[11-Feb-2012 18:06:52 UTC] PHP Notice: Use of undefined constant
FIRSTBADCONSTANT - assumed 'FIRSTBADCONSTANT' in C:\Temp\mycode.php on line 2
[11-Feb-2012 18:06:52 UTC] PHP Notice: Use of undefined constant
SOMEBADCONSTANT - assumed 'SOMEBADCONSTANT' in C:\Temp\mycode.php on line 4
[11-Feb-2012 18:06:52 UTC] PHP Notice: Use of undefined constant
ANOTHERBADCONSTANT - assumed 'ANOTHERBADCONSTANT' in C:\Temp\mycode.php on line
6
The 5.3.9 error reporting seems locked in UTC.
[2012-02-09 23:21:35] daniel dot caillibaud at sesamath dot net
In an openvz VM, with php-fpm 5.3.10 (debian squeeze OS), with a sytem date
configured on UTC+1 (on physical host, but `date` in VM also show UTC+1), in
php.ini I've a
date.timezone = "Europe/Paris"
but php error_log date is displayed as UTC
[09-Feb-2012 23:15:08 UTC] PHP Notice: ...
while all others logs are in the system timezone, e.g nginx
[10/Feb/2012:00:16:46 +0100] ...
and syslog as well is UTC+1 (but doesn't show it on each log line).
Hope it helps...
[2012-01-30 09:20:08] wadkar at gmail dot com
This bug may still be a problem for someone, here are the details :
# php -v
PHP 5.3.8 (cli) (built: Dec 1 2011 12:23:50)
The problem is with the OS this time= CentOS 5+OpenVZ with IUS repo. The host
machine (with the OpenVZ kernel) has no problems
# uname -a
Linux vz-node2 2.6.18-274.el5.028stab093.2xen #1 SMP Tue Aug 23 16:50:42 MSD
2011 x86_64 x86_64 x86_64 GNU/Linux
# echo '' > /tmp/error.log && php -dlog_errors=On -derror_log=/tmp/error.log -r
'error_reporting(-1); SOMEBADCONSTANT;' && cat /tmp/error.log && date
[30-Jan-2012 14:38:56] PHP Notice: Use of undefined constant SOMEBADCONSTANT -
assumed 'SOMEBADCONSTANT' in Command line code on line 1
Mon Jan 30 14:38:56 IST 2012
The same code snippet, however, when run on a VM gives
# uname -a
Linux container1 2.6.18-274.el5.028stab093.2xen #1 SMP Tue Aug 23 16:50:42 MSD
2011 x86_64 x86_64 x86_64 GNU/Linux
# echo '' > /tmp/error.log && php -dlog_errors=On -derror_log=/tmp/error.log -r
'error_reporting(-1); SOMEBADCONSTANT;' && cat /tmp/error.log && date
[30-Jan-2012 09:10:05 UTC] PHP Notice: Use of undefined constant
SOMEBADCONSTANT - assumed 'SOMEBADCONSTANT' in Command line code on line 1
Mon Jan 30 14:40:05 IST 2012
The internal TZ settings are respected though:
# php -i | grep timezone
Default timezone => Asia/Calcutta
date.timezone => Asia/Calcutta => Asia/
Bug #60704 [PATCH]: unlink() bug with some files path
Edit report at https://bugs.php.net/bug.php?id=60704&edit=1
ID: 60704
Patch added by: s...@php.net
Reported by:dean at dacunha dot net
Summary:unlink() bug with some files path
Status: Assigned
Type: Bug
Package:Filesystem function related
Operating System: Linux 3.0.0-14-generic #23-Ubunt
PHP Version:5.3.10
Assigned To:shm
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: themostevilpatchever2.patch
Revision: 1329040416
URL:
https://bugs.php.net/patch-display.php?bug=60704&patch=themostevilpatchever2.patch&revision=1329040416
Previous Comments:
[2012-02-11 08:32:47] s...@php.net
Attached patch should fix this issue. Will commit if after a review.
[2012-02-11 08:32:04] s...@php.net
The following patch has been added/updated:
Patch Name: themostevilpatchever.patch
Revision: 1328949124
URL:
https://bugs.php.net/patch-display.php?bug=60704&patch=themostevilpatchever.patch&revision=1328949124
[2012-02-06 14:55:40] dean at dacunha dot net
Hi,
I've just tested with php 5.3.10, the bug is still here.
Do you still need me to test with version 5.3.9 ?
Here is the proof:
root@djavanubu:/root#
root@djavanubu:/root# cat b.php
#!/usr/local/bin/php
root@djavanubu:/root#
root@djavanubu:/root# /usr/local/bin/php -v
PHP 5.3.10 (cli) (built: Jan 31 2012 22:48:16)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
root@djavanubu:/root#
root@djavanubu:/root#
root@djavanubu:/root# ./b.php
Warning: unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3): No such file or directory in /root/b.php on line 7
root@djavanubu:/root#
root@djavanubu:/root# rm "/mnt/M:/NEWBASE/BRASIL/Carlinhos
Brown/Alfagamabetizado - Angel's Robot List.1.2.mp3"
root@djavanubu:/root#
root@djavanubu:/root# strace ./b.php
[...]
lstat("/mnt/M://BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3", {st_mode=S_IFREG|0755, st_size=1247232, ...}) = 0
lstat("/mnt/M://BRASIL/Carlinhos Brown", {st_mode=S_IFDIR|0755, st_size=40960,
...}) = 0
lstat("/mnt/M://BRASIL", {st_mode=S_IFDIR|0755, st_size=81920, ...}) = 0
link("/mnt/M://BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3", "/mnt/M:/NEWBASE/BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's
Robot List.1.2.mp3") = 0
unlink("BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot List.mp3") = -1
ENOENT (No such file or directory)
write(1, "\nWarning: unlink(BRASIL/Carlinho"..., 135
Warning: unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3): No such file or directory in /root/b.php on line 7
) = 135
[...]
[2012-01-27 05:42:04] carloschilazo at gmail dot com
Does this happen also in 5.3.9 ?
Please confirm so I can look into it
Thanks
[2012-01-10 19:58:07] dean at dacunha dot net
Description:
unlink() function truncates the file path name argument in some cases.
This bug appears also with the rename() function in the same cases.
The given source code use link() to duplicate a file, then unlink() to remove
the
source file. link() function works and unlink() bugs.
Test script:
---
#!/usr/local/bin/php
Expected result:
unlink() should remove the "/mnt/M://BRASIL/Carlinhos Brown/Alfagamabetizado -
Angel's Robot List.mp3" file
Actual result:
--
root@djavanubu:/# ./b.php
Warning: unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3): No such file or directory in /b.php on line 8
###
below trace shows the truncated file path given to unlink() syscall:
[...]
lstat("/mnt/M://BRASIL", {st_mode=S_IFDIR|0755, st_size=69632, ...}) = 0
link("/mnt/M://BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3", "/mnt/M:/NEWBASE/BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's
Robot List.1.2.mp3") = 0
unlink("BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot List.mp3") = -1
ENOENT (No such file or directory)
write(1, "\nWarning: unlink(BRASIL/Carlinho"..., 130
Warning: unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3): No such file or directory in /b.php on line 8
) = 130
[...]
--
Edit this bug report at https://bugs.php.net/bug.php?id=60704&edit=1
Bug #60837 [ReO->Csd]: Segmentation fail, if use trait
Edit report at https://bugs.php.net/bug.php?id=60837&edit=1 ID: 60837 Updated by: larue...@php.net Reported by:piphon at gmail dot com Summary:Segmentation fail, if use trait -Status: Re-Opened +Status: Closed Type: Bug Package:Reproducible crash Operating System: Ubuntu 11.10 64bit PHP Version:5.4SVN-2012-01-22 (SVN) -Assigned To: +Assigned To:laruence Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. 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. okey, closed Previous Comments: [2012-02-12 07:14:48] piphon at gmail dot com Sorry. SVN branch so far not compiled, but last snapshots, e.g PHP 5.4.0RC7 Feb 10 2012, worked normal without this bug. You can probably close this issue. [2012-01-26 01:16:15] larue...@php.net oh, I mis-read your words, re-opened. [2012-01-26 01:15:32] larue...@php.net This bug has been fixed in SVN. 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. [2012-01-24 06:46:57] piphon at gmail dot com I check svn head, when https://bugs.php.net/bug.php?id=60840 fixed [2012-01-24 06:27:54] piphon at gmail dot com Snapshot PHP 5.4.0RC7-dev (cli) (built: Jan 24 2012 11:49:24) worked. Sorry, can't try SVN branch (https://svn.php.net/repository/php/php-src/branches/PHP_5_4@322646). Could not compile sources for test issue. Modules (pdo, pdo_mysql) not compiled as static libraries (multiple definition of `get_module') or pdo_mysql not linked as shared library (mysqlnd_debug_std_no_trace_funcs not found). And debugging and normal. I'll try again. 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=60837 -- Edit this bug report at https://bugs.php.net/bug.php?id=60837&edit=1
