Bug #61345 [Csd->Asn]: CGI mode - make install don't work
Edit report at https://bugs.php.net/bug.php?id=61345&edit=1 ID: 61345 User updated by:sites at evoluons dot net Reported by:sites at evoluons dot net Summary:CGI mode - make install don't work -Status: Closed +Status: Assigned Type: Bug Package:Compile Failure Operating System: Fedora 16 x86_64 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: I apologize : it's with another computer it was OK. I updated mine too, and it keep same error. I tried today with a new ./configure command : ./configure --with-apxs2=/usr/local/apache/bin/apxs --with-config-file-path=/usr/local/apache/conf --with-gd --with-zlib --with-bz2 --enable-ftp --enable-sockets --with-curl --with-mysql=/usr/local/mysql --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --with-imap --enable-mbstring --enable-exif --without-pear --enable-zip --prefix=/usr/local/php --with-mcrypt --with-jpeg-dir --with-png-dir --with-freetype-dir --enable-gd-native-ttf --with-kerberos --with-imap-ssl Same problem : make install Installing PHP CGI binary:/usr/local/phpcgi/bin/ cp: cannot create regular file `/usr/local/phpcgi/bin/#INST@1706#': No such file or directory And if I create folders myself : mkdir /usr/local/phpcgi mkdir /usr/local/phpcgi/bin It's ok : make install Installing PHP CGI binary:/usr/local/phpcgi/bin/ Installing build environment: /usr/local/phpcgi/lib/php/build/ Installing header files: /usr/local/phpcgi/include/php/ Installing helper programs: /usr/local/phpcgi/bin/ program: phpize program: php-config Installing man pages: /usr/local/phpcgi/php/man/man1/ page: phpize.1 page: php-config.1 Installing PDO headers: /usr/local/phpcgi/include/php/ext/pdo/ Previous Comments: [2012-03-22 08:30:35] sites at evoluons dot net I updated my Fedora 16 x86_64 and now it works directly, without any workaround. So, I close the bug. [2012-03-10 20:40:18] sites at evoluons dot net Description: Hi, With a Fedora 16 x86_64 I compiled PHP in Apache module mode, no problem. But, to use also CGI mode, compilation is OK, but "make install" not. My ./configure : ./configure --with-gd --with-zlib --enable-ftp --enable-sockets --with-curl --enable-mbstring --enable-exif --enable-zip --prefix=/usr/local/phpcgi --disable-cli --with-mysql=/usr/local/mysql --with-jpeg-dir --with-png-dir --with-freetype-dir --enable-gd-native-ttf --with-mcrypt make install Installing PHP CGI binary:/usr/local/phpcgi/bin/ cp: cannot create regular file `/usr/local/phpcgi/bin/#INST@1199#': No such file or directory Expected result: Installing PHP CGI binary:/usr/local/phpcgi/bin/ Installing build environment: /usr/local/phpcgi/lib/php/build/ Installing header files: /usr/local/phpcgi/include/php/ Installing helper programs: /usr/local/phpcgi/bin/ program: phpize program: php-config Installing man pages: /usr/local/phpcgi/php/man/man1/ page: phpize.1 page: php-config.1 Installing PDO headers: /usr/local/phpcgi/include/php/ext/pdo/ Actual result: -- If I manually create /usr/local/phpcgi and /usr/local/phpcgi/bin folders, "make install" work : mkdir /usr/local/phpcgi mkdir /usr/local/phpcgi/bin Thank you for your help ;) -- Edit this bug report at https://bugs.php.net/bug.php?id=61345&edit=1
Bug #61482 [Opn->Csd]: php-cli crashes during 'nmake snap'
Edit report at https://bugs.php.net/bug.php?id=61482&edit=1 ID: 61482 Updated by: s...@php.net Reported by:mattfic...@php.net Summary:php-cli crashes during 'nmake snap' -Status: Open +Status: Closed Type: Bug Package:PHAR related Operating System: Windows PHP Version:5.4.0 -Assigned To: +Assigned To:stas 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. Should be fine now. Previous Comments: [2012-03-23 05:32:04] s...@php.net Automatic comment on behalf of stas Revision: http://git.php.net/?p=php-src.git;a=commit;h=a89c4a34ee55686ab1430a5060e1460335fc5203 Log: Revert "- Fixed bug #61418 (Segmentation fault when DirectoryIterator's or" - causes bug #61482 [2012-03-23 05:31:44] s...@php.net Automatic comment on behalf of stas Revision: http://git.php.net/?p=php-src.git;a=commit;h=a89c4a34ee55686ab1430a5060e1460335fc5203 Log: Revert "- Fixed bug #61418 (Segmentation fault when DirectoryIterator's or" - causes bug #61482 [2012-03-23 05:31:28] s...@php.net Automatic comment on behalf of stas Revision: http://git.php.net/?p=php-src.git;a=commit;h=a89c4a34ee55686ab1430a5060e1460335fc5203 Log: Revert "- Fixed bug #61418 (Segmentation fault when DirectoryIterator's or" - causes bug #61482 [2012-03-23 05:24:54] s...@php.net git bisect says commit 714f1ff4b37c5101b3c61ea108a3d415f41e50df is to blame. Reverting it seems to fix the issue. [2012-03-23 05:24:11] mattfic...@php.net With proper quotes: Release\php.exe -d date.timezone=UTC -n -dphar.readonly=0 win32/build/mkdist.php "Release" "C:\Projects\win32build" "php5.dll" "php-cgi.exe php.exe" "php_intl.dll php_pdo_mysql.dll " " " "no" 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=61482 -- Edit this bug report at https://bugs.php.net/bug.php?id=61482&edit=1
Bug #61418 [Csd->ReO]: Segmentation foult using FiltesystemIterator & RegexIterator
Edit report at https://bugs.php.net/bug.php?id=61418&edit=1 ID: 61418 Updated by: s...@php.net Reported by:melkorm at gmail dot com Summary:Segmentation foult using FiltesystemIterator & RegexIterator -Status: Closed +Status: Re-Opened Type: Bug Package:SPL related Operating System: Linux Mint 12 PHP Version:5.3.10 Assigned To:cataphract Block user comment: N Private report: N New Comment: Had to revert the fix, reopening the bug. Previous Comments: [2012-03-23 05:32:03] s...@php.net Automatic comment on behalf of stas Revision: http://git.php.net/?p=php-src.git;a=commit;h=a89c4a34ee55686ab1430a5060e1460335fc5203 Log: Revert "- Fixed bug #61418 (Segmentation fault when DirectoryIterator's or" - causes bug #61482 [2012-03-23 05:31:43] s...@php.net Automatic comment on behalf of stas Revision: http://git.php.net/?p=php-src.git;a=commit;h=a89c4a34ee55686ab1430a5060e1460335fc5203 Log: Revert "- Fixed bug #61418 (Segmentation fault when DirectoryIterator's or" - causes bug #61482 [2012-03-23 05:31:27] s...@php.net Automatic comment on behalf of stas Revision: http://git.php.net/?p=php-src.git;a=commit;h=a89c4a34ee55686ab1430a5060e1460335fc5203 Log: Revert "- Fixed bug #61418 (Segmentation fault when DirectoryIterator's or" - causes bug #61482 [2012-03-18 15:07:08] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revision&revision=324327 Log: - Fixed bug #61418 (Segmentation fault when DirectoryIterator's or FilesystemIterator's iterators are requested more than once without having had its dtor callback called in between). [2012-03-17 23:27:20] cataphr...@php.net Verified. The zend_object_iterator_funcs.dtor function (implementation: spl_filesystem_tree_it_dtor) seems faulty. In the reproduce script here, the zend_object_iterator is requested twice: first by the RegexIterator constructor, and then by foreach. The zend_object_iterator returned is the same in both cases -- that owned by the FilesystemIterator and its destructor gets called twice. But obviously the destructor is not prepared to be called twice as it unconditionally calls zval_ptr_dtor (for some reason, twice) and zeroes the reference to the owning object. 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=61418 -- Edit this bug report at https://bugs.php.net/bug.php?id=61418&edit=1
Bug #61482 [Opn]: php-cli crashes during 'nmake snap'
Edit report at https://bugs.php.net/bug.php?id=61482&edit=1 ID: 61482 Updated by: s...@php.net Reported by:mattfic...@php.net Summary:php-cli crashes during 'nmake snap' Status: Open Type: Bug Package:PHAR related Operating System: Windows PHP Version:5.4.0 Block user comment: N Private report: N New Comment: git bisect says commit 714f1ff4b37c5101b3c61ea108a3d415f41e50df is to blame. Reverting it seems to fix the issue. Previous Comments: [2012-03-23 05:24:11] mattfic...@php.net With proper quotes: Release\php.exe -d date.timezone=UTC -n -dphar.readonly=0 win32/build/mkdist.php "Release" "C:\Projects\win32build" "php5.dll" "php-cgi.exe php.exe" "php_intl.dll php_pdo_mysql.dll " " " "no" [2012-03-23 05:23:06] s...@php.net This commandline reliably reproduces it: Release\php.exe -d date.timezone=UTC -n -dphar.readonly=0 win32/build/mkdist.php Release C:\Projects\win32build php5.dll php-cgi.exe php.exe php_intl.dll php_pdo_mysql.dllno [2012-03-23 00:47:31] s...@php.net Happens to me with 5.4 branch too. If I remove make_phar_dot_phar(), it does not happen, so definitely has something to do with phar. [2012-03-22 23:03:38] mattfic...@php.net looks like it fails on the first call to file_get_contents() in make_phar_dot_phar(). the first and only arg to file_get_contents() is "c:\php-sdk\git\php-src\ext\phar\phar\clicommand.inc". [2012-03-22 22:56:48] mattfic...@php.net Test Script (stripped down win32/build/mkdist.php): C:\php-sdk\git\obj\Release\php.exe -d date.timezone=UTC -n -dphar.readonly=0 win32/build/mkdist.php "C:\php-sdk\git\obj\Release" "C:\php-sdk\git\php-src\no" "php5.dll" "php-cgi.exe php.exe php-win.exe php5embed.lib" "php_mbstring.dll php_shmop.dll php_sockets.dll php_sqlite3.dll php_exif.dll php_pdo_mysql.dll php_pdo_odbc.dll php_pdo_sqlite.dll " " " "no" // php build directory $build_dir = "C:\php-sdk\git\obj\Release"; $dist_dir = $build_dir . "/php-" . phpversion(); $test_dir = $build_dir . "/php-test-pack-" . phpversion(); $pecl_dir = $build_dir . "/pecl-" . phpversion(); @mkdir($dist_dir); @mkdir("$dist_dir/ext"); @mkdir("$dist_dir/dev"); @mkdir("$dist_dir/extras"); @mkdir($pecl_dir); function make_phar_dot_phar($dist_dir) { if (!extension_loaded('phar')) { return; } $path_to_phar = realpath(__DIR__ . '/../../ext/phar'); echo "Generating pharcommand.phar\n"; $phar = new Phar($dist_dir . '/pharcommand.phar', 0, 'pharcommand'); foreach (new DirectoryIterator($path_to_phar . '/phar') as $file) { if ($file->isDir() || $file == 'phar.php') { continue; } echo 'adding ', $file, "\n"; $phar[(string) $file] = file_get_contents($path_to_phar. '/phar/' . $file); } $phar->setSignatureAlgorithm(Phar::SHA1); $stub = file($path_to_phar . '/phar/phar.php'); unset($stub[0]); // remove hashbang $phar->setStub(implode('', $stub)); echo "Creating phar.phar.bat\n"; file_put_contents($dist_dir . '/phar.phar.bat', "%~dp0php.exe %~dp0pharcommand.phar %*\r\n"); } make_phar_dot_phar($dist_dir); ?> 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=61482 -- Edit this bug report at https://bugs.php.net/bug.php?id=61482&edit=1
Bug #61482 [Opn]: php-cli crashes during 'nmake snap'
Edit report at https://bugs.php.net/bug.php?id=61482&edit=1 ID: 61482 User updated by:mattfic...@php.net Reported by:mattfic...@php.net Summary:php-cli crashes during 'nmake snap' Status: Open Type: Bug Package:PHAR related Operating System: Windows PHP Version:5.4.0 Block user comment: N Private report: N New Comment: With proper quotes: Release\php.exe -d date.timezone=UTC -n -dphar.readonly=0 win32/build/mkdist.php "Release" "C:\Projects\win32build" "php5.dll" "php-cgi.exe php.exe" "php_intl.dll php_pdo_mysql.dll " " " "no" Previous Comments: [2012-03-23 05:23:06] s...@php.net This commandline reliably reproduces it: Release\php.exe -d date.timezone=UTC -n -dphar.readonly=0 win32/build/mkdist.php Release C:\Projects\win32build php5.dll php-cgi.exe php.exe php_intl.dll php_pdo_mysql.dllno [2012-03-23 00:47:31] s...@php.net Happens to me with 5.4 branch too. If I remove make_phar_dot_phar(), it does not happen, so definitely has something to do with phar. [2012-03-22 23:03:38] mattfic...@php.net looks like it fails on the first call to file_get_contents() in make_phar_dot_phar(). the first and only arg to file_get_contents() is "c:\php-sdk\git\php-src\ext\phar\phar\clicommand.inc". [2012-03-22 22:56:48] mattfic...@php.net Test Script (stripped down win32/build/mkdist.php): C:\php-sdk\git\obj\Release\php.exe -d date.timezone=UTC -n -dphar.readonly=0 win32/build/mkdist.php "C:\php-sdk\git\obj\Release" "C:\php-sdk\git\php-src\no" "php5.dll" "php-cgi.exe php.exe php-win.exe php5embed.lib" "php_mbstring.dll php_shmop.dll php_sockets.dll php_sqlite3.dll php_exif.dll php_pdo_mysql.dll php_pdo_odbc.dll php_pdo_sqlite.dll " " " "no" // php build directory $build_dir = "C:\php-sdk\git\obj\Release"; $dist_dir = $build_dir . "/php-" . phpversion(); $test_dir = $build_dir . "/php-test-pack-" . phpversion(); $pecl_dir = $build_dir . "/pecl-" . phpversion(); @mkdir($dist_dir); @mkdir("$dist_dir/ext"); @mkdir("$dist_dir/dev"); @mkdir("$dist_dir/extras"); @mkdir($pecl_dir); function make_phar_dot_phar($dist_dir) { if (!extension_loaded('phar')) { return; } $path_to_phar = realpath(__DIR__ . '/../../ext/phar'); echo "Generating pharcommand.phar\n"; $phar = new Phar($dist_dir . '/pharcommand.phar', 0, 'pharcommand'); foreach (new DirectoryIterator($path_to_phar . '/phar') as $file) { if ($file->isDir() || $file == 'phar.php') { continue; } echo 'adding ', $file, "\n"; $phar[(string) $file] = file_get_contents($path_to_phar. '/phar/' . $file); } $phar->setSignatureAlgorithm(Phar::SHA1); $stub = file($path_to_phar . '/phar/phar.php'); unset($stub[0]); // remove hashbang $phar->setStub(implode('', $stub)); echo "Creating phar.phar.bat\n"; file_put_contents($dist_dir . '/phar.phar.bat', "%~dp0php.exe %~dp0pharcommand.phar %*\r\n"); } make_phar_dot_phar($dist_dir); ?> [2012-03-22 22:33:59] mattfic...@php.net Description: Compiling latest revision from git repo... Using Windows 7sp1x64, VC9 compiler x86 xp release Ran nmake snap... When it gets to 'creating phar.phar.bat' stage php cli crashes. Here is the backtrace: php5.dll!zval_mark_grey(_zval_struct * pz=0x010f0060) Line 425 C php5.dll!gc_mark_roots() Line 501 + 0x6 bytes C php5.dll!gc_collect_cycles() Line 794 C php5.dll!zend_deactivate() Line 962C php5.dll!php_request_shutdown(void * dummy=0x) Line 1784 C php.exe!do_cli(int argc=13, char * * argv=0x00151b10) Line 1169 + 0x8 bytes C php.exe!main(int argc=13, char * * argv=0x00151b10) Line 1358 C php.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C kernel32.dll!7616339a() -- Edit this bug report at https://bugs.php.net/bug.php?id=61482&edit=1
Bug #61482 [Opn]: php-cli crashes during 'nmake snap'
Edit report at https://bugs.php.net/bug.php?id=61482&edit=1 ID: 61482 Updated by: s...@php.net Reported by:mattfic...@php.net Summary:php-cli crashes during 'nmake snap' Status: Open Type: Bug Package:PHAR related Operating System: Windows PHP Version:5.4.0 Block user comment: N Private report: N New Comment: This commandline reliably reproduces it: Release\php.exe -d date.timezone=UTC -n -dphar.readonly=0 win32/build/mkdist.php Release C:\Projects\win32build php5.dll php-cgi.exe php.exe php_intl.dll php_pdo_mysql.dllno Previous Comments: [2012-03-23 00:47:31] s...@php.net Happens to me with 5.4 branch too. If I remove make_phar_dot_phar(), it does not happen, so definitely has something to do with phar. [2012-03-22 23:03:38] mattfic...@php.net looks like it fails on the first call to file_get_contents() in make_phar_dot_phar(). the first and only arg to file_get_contents() is "c:\php-sdk\git\php-src\ext\phar\phar\clicommand.inc". [2012-03-22 22:56:48] mattfic...@php.net Test Script (stripped down win32/build/mkdist.php): C:\php-sdk\git\obj\Release\php.exe -d date.timezone=UTC -n -dphar.readonly=0 win32/build/mkdist.php "C:\php-sdk\git\obj\Release" "C:\php-sdk\git\php-src\no" "php5.dll" "php-cgi.exe php.exe php-win.exe php5embed.lib" "php_mbstring.dll php_shmop.dll php_sockets.dll php_sqlite3.dll php_exif.dll php_pdo_mysql.dll php_pdo_odbc.dll php_pdo_sqlite.dll " " " "no" // php build directory $build_dir = "C:\php-sdk\git\obj\Release"; $dist_dir = $build_dir . "/php-" . phpversion(); $test_dir = $build_dir . "/php-test-pack-" . phpversion(); $pecl_dir = $build_dir . "/pecl-" . phpversion(); @mkdir($dist_dir); @mkdir("$dist_dir/ext"); @mkdir("$dist_dir/dev"); @mkdir("$dist_dir/extras"); @mkdir($pecl_dir); function make_phar_dot_phar($dist_dir) { if (!extension_loaded('phar')) { return; } $path_to_phar = realpath(__DIR__ . '/../../ext/phar'); echo "Generating pharcommand.phar\n"; $phar = new Phar($dist_dir . '/pharcommand.phar', 0, 'pharcommand'); foreach (new DirectoryIterator($path_to_phar . '/phar') as $file) { if ($file->isDir() || $file == 'phar.php') { continue; } echo 'adding ', $file, "\n"; $phar[(string) $file] = file_get_contents($path_to_phar. '/phar/' . $file); } $phar->setSignatureAlgorithm(Phar::SHA1); $stub = file($path_to_phar . '/phar/phar.php'); unset($stub[0]); // remove hashbang $phar->setStub(implode('', $stub)); echo "Creating phar.phar.bat\n"; file_put_contents($dist_dir . '/phar.phar.bat', "%~dp0php.exe %~dp0pharcommand.phar %*\r\n"); } make_phar_dot_phar($dist_dir); ?> [2012-03-22 22:33:59] mattfic...@php.net Description: Compiling latest revision from git repo... Using Windows 7sp1x64, VC9 compiler x86 xp release Ran nmake snap... When it gets to 'creating phar.phar.bat' stage php cli crashes. Here is the backtrace: php5.dll!zval_mark_grey(_zval_struct * pz=0x010f0060) Line 425 C php5.dll!gc_mark_roots() Line 501 + 0x6 bytes C php5.dll!gc_collect_cycles() Line 794 C php5.dll!zend_deactivate() Line 962C php5.dll!php_request_shutdown(void * dummy=0x) Line 1784 C php.exe!do_cli(int argc=13, char * * argv=0x00151b10) Line 1169 + 0x8 bytes C php.exe!main(int argc=13, char * * argv=0x00151b10) Line 1358 C php.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C kernel32.dll!7616339a() -- Edit this bug report at https://bugs.php.net/bug.php?id=61482&edit=1
Bug #61467 [Opn->Fbk]: New "callable" typehint does not work (autoloading)
Edit report at https://bugs.php.net/bug.php?id=61467&edit=1 ID: 61467 Updated by: ras...@php.net Reported by:david at grudl dot com Summary:New "callable" typehint does not work (autoloading) -Status: Open +Status: Feedback Type: Bug Package:Class/Object related PHP Version:5.4.0 Block user comment: N Private report: N New Comment: But it only triggers the autoloader when you pass it something that looks exactly like A::b(). In this case it will go try to load 'A' in order to see if there is a b() method. If you pass it array(1,2,3) it will obviously not trigger the autoloader so I think your assertion that this will cause "major performance issues" is a bit drastic. Previous Comments: [2012-03-21 23:57:25] david at grudl dot com Possible fix is to change in file zend_execute.c on line 645 flag IS_CALLABLE_CHECK_SILENT to IS_CALLABLE_CHECK_SYNTAX_ONLY. [2012-03-21 21:58:51] david at grudl dot com Sorry, in PHP 5.4 there is not "an instance of" in error message. But that's not the point. [2012-03-21 20:49:54] ras...@php.net Are you sure you are running 5.4? Your your test script: % php53 test.php Catchable fatal error: Argument 1 passed to test() must be an instance of callable, array given, called in /home/rasmus/r on line 6 and defined in /home/rasmus/r on line 2 % php54 test.php Catchable fatal error: Argument 1 passed to test() must be callable, array given, called in /home/rasmus/r on line 6 and defined in /home/rasmus/r on line 2 [2012-03-21 20:25:04] david at grudl dot com do -> does [2012-03-21 20:22:00] david at grudl dot com Description: Is really new type hint callable implemented? I see no difference between PHP 5.3 and PHP 5.4, both versions only throw catchable fatal errors. (I think this unexpected behaviour is due to the fact that class "A" do not exists. In this case the error message is confusing. But the callable should not trigger autoload, it should behave like is_callable($arg, TRUE) and just check the syntax. Otherwise typehint callable will cause major performance issues.) Test script: --- function test(callable $a) { } test(array('A', 'b')); // Catchable fatal error: Argument 1 passed to test() must be an instance of callable, array given test('A::b'); // Catchable fatal error: Argument 1 passed to test() must be an instance of callable, string given -- Edit this bug report at https://bugs.php.net/bug.php?id=61467&edit=1
Bug #61482 [Opn]: php-cli crashes during 'nmake snap'
Edit report at https://bugs.php.net/bug.php?id=61482&edit=1 ID: 61482 Updated by: s...@php.net Reported by:mattfic...@php.net Summary:php-cli crashes during 'nmake snap' Status: Open Type: Bug Package:PHAR related Operating System: Windows PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Happens to me with 5.4 branch too. If I remove make_phar_dot_phar(), it does not happen, so definitely has something to do with phar. Previous Comments: [2012-03-22 23:03:38] mattfic...@php.net looks like it fails on the first call to file_get_contents() in make_phar_dot_phar(). the first and only arg to file_get_contents() is "c:\php-sdk\git\php-src\ext\phar\phar\clicommand.inc". [2012-03-22 22:56:48] mattfic...@php.net Test Script (stripped down win32/build/mkdist.php): C:\php-sdk\git\obj\Release\php.exe -d date.timezone=UTC -n -dphar.readonly=0 win32/build/mkdist.php "C:\php-sdk\git\obj\Release" "C:\php-sdk\git\php-src\no" "php5.dll" "php-cgi.exe php.exe php-win.exe php5embed.lib" "php_mbstring.dll php_shmop.dll php_sockets.dll php_sqlite3.dll php_exif.dll php_pdo_mysql.dll php_pdo_odbc.dll php_pdo_sqlite.dll " " " "no" // php build directory $build_dir = "C:\php-sdk\git\obj\Release"; $dist_dir = $build_dir . "/php-" . phpversion(); $test_dir = $build_dir . "/php-test-pack-" . phpversion(); $pecl_dir = $build_dir . "/pecl-" . phpversion(); @mkdir($dist_dir); @mkdir("$dist_dir/ext"); @mkdir("$dist_dir/dev"); @mkdir("$dist_dir/extras"); @mkdir($pecl_dir); function make_phar_dot_phar($dist_dir) { if (!extension_loaded('phar')) { return; } $path_to_phar = realpath(__DIR__ . '/../../ext/phar'); echo "Generating pharcommand.phar\n"; $phar = new Phar($dist_dir . '/pharcommand.phar', 0, 'pharcommand'); foreach (new DirectoryIterator($path_to_phar . '/phar') as $file) { if ($file->isDir() || $file == 'phar.php') { continue; } echo 'adding ', $file, "\n"; $phar[(string) $file] = file_get_contents($path_to_phar. '/phar/' . $file); } $phar->setSignatureAlgorithm(Phar::SHA1); $stub = file($path_to_phar . '/phar/phar.php'); unset($stub[0]); // remove hashbang $phar->setStub(implode('', $stub)); echo "Creating phar.phar.bat\n"; file_put_contents($dist_dir . '/phar.phar.bat', "%~dp0php.exe %~dp0pharcommand.phar %*\r\n"); } make_phar_dot_phar($dist_dir); ?> [2012-03-22 22:33:59] mattfic...@php.net Description: Compiling latest revision from git repo... Using Windows 7sp1x64, VC9 compiler x86 xp release Ran nmake snap... When it gets to 'creating phar.phar.bat' stage php cli crashes. Here is the backtrace: php5.dll!zval_mark_grey(_zval_struct * pz=0x010f0060) Line 425 C php5.dll!gc_mark_roots() Line 501 + 0x6 bytes C php5.dll!gc_collect_cycles() Line 794 C php5.dll!zend_deactivate() Line 962C php5.dll!php_request_shutdown(void * dummy=0x) Line 1784 C php.exe!do_cli(int argc=13, char * * argv=0x00151b10) Line 1169 + 0x8 bytes C php.exe!main(int argc=13, char * * argv=0x00151b10) Line 1358 C php.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C kernel32.dll!7616339a() -- Edit this bug report at https://bugs.php.net/bug.php?id=61482&edit=1
Req #49914 [Com]: DateInterval doesn't implement comparison functions
Edit report at https://bugs.php.net/bug.php?id=49914&edit=1 ID: 49914 Comment by: kavi at postpro dot net Reported by:ahar...@php.net Summary:DateInterval doesn't implement comparison functions Status: Open Type: Feature/Change Request Package:Date/time related Operating System: * PHP Version:5.3SVN-2009-10-18 (SVN) Block user comment: N Private report: N New Comment: So... patch submitted 2.5 years ago. Sup guys? Previous Comments: [2011-11-25 11:01:25] albertcasademont at gmail dot com Did this patch make it into the trunk? [2009-10-18 17:20:41] ahar...@php.net Description: (This is really a feature request, rather than a bug per se.) Unlike DateTime objects, DateInterval objects cannot easily be compared within PHP. While it would be possible to concoct a workaround in userspace using a few calls to DateInterval::format() and some arithmetic, it would probably be preferable to implement it within ext/date itself. I've prepared a patch (yes, it even has a simple test) against PHP_5_3 at http://www.adamharvey.name/patches/DateInterval-comparators.patch which implements comparator support. I can probably prepare a HEAD patch if necessary; I just don't have a HEAD checkout to hand to do so at present. There's one fairly significant issue with this patch worth noting: I've implemented a new function (timelib_rel_time_to_seconds) which converts a timelib_rel_time structure to the number of seconds it represents. The issue with this is that, as per bug #49778, we don't always know exactly how many days a timelib_rel_time actually represents because of the varying number of days in a month and year. As per the comments in the function, for now I've fudged it and effectively chosen the default length of a month and year out of thin air if the days field isn't set within the structure. If the resolution to bug #49778 results in the days field always being filled in, then timelib_rel_time_to_seconds can be simplified accordingly. Alternatively, we could only support this in cases where we definitely know the days within the timelib_rel_time structure and error out otherwise. As a side note, I have a second patch that I can upload that implements support for a DateInterval::getSeconds() method which effectively provides a PHP wrapper around the proposed internal timelib_rel_time_to_seconds function. If it's decided to accept this approach, I can create another bug to track getting that in. Reproduce code: --- Expected result: bool(true) Actual result: -- bool(false) -- Edit this bug report at https://bugs.php.net/bug.php?id=49914&edit=1
Bug #61485 [Com]: rename('..', '..') doesn't report a warning
Edit report at https://bugs.php.net/bug.php?id=61485&edit=1 ID: 61485 Comment by: juzna dot cz at gmail dot com Reported by:juzna dot cz at gmail dot com Summary:rename('..', '..') doesn't report a warning Status: Open Type: Bug Package:Directory function related Operating System: Ubuntu PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Tested on 5.4.0, 5.4.1-RC1, 5.3.10, 5.3.9 Previous Comments: [2012-03-23 00:30:40] juzna dot cz at gmail dot com Description: This command executed in shell fails: mv .. .. but the same reports no error in PHP: rename('..', '..') (I think it reports error on windows) Test script: --- rename('..', '..') Expected result: Warning: rename(..,..): . Actual result: -- nothing -- Edit this bug report at https://bugs.php.net/bug.php?id=61485&edit=1
[PHP-BUG] Bug #61485 [NEW]: rename('..', '..') doesn't report a warning
From: Operating system: Ubuntu PHP version: 5.4.0 Package: Directory function related Bug Type: Bug Bug description:rename('..', '..') doesn't report a warning Description: This command executed in shell fails: mv .. .. but the same reports no error in PHP: rename('..', '..') (I think it reports error on windows) Test script: --- rename('..', '..') Expected result: Warning: rename(..,..): . Actual result: -- nothing -- Edit bug report at https://bugs.php.net/bug.php?id=61485&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61485&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61485&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61485&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61485&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61485&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61485&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61485&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61485&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61485&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61485&r=support Expected behavior: https://bugs.php.net/fix.php?id=61485&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61485&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61485&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61485&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61485&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61485&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61485&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61485&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61485&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61485&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61485&r=mysqlcfg
Bug #61474 [Opn->Fbk]: Compile failure with OCI8 - instantclient 11.2
Edit report at https://bugs.php.net/bug.php?id=61474&edit=1 ID: 61474 Updated by: s...@php.net Reported by:hakim at agl dot fr Summary:Compile failure with OCI8 - instantclient 11.2 -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: RedHat Entreprise Linux 5 x86_64 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: What was the exact 'configure' command used? Previous Comments: [2012-03-22 16:34:12] hakim at agl dot fr Description: Trying to compile PHP 5.4.0 with Oracle Instant Client 11.2 and I receive the following error: ~# ./configure ... --with-oci8=instantclient,/usr/lib/oracle/11.2/client64/lib \ ... ~# make /bin/sh /data/pkgs/ws/php-5.4.0/libtool --silent --preserve-dup-deps --mode=compile /data/pkgs/ws/php-5.4.0/meta_ccld -DLDAP_DEPRECATED=1 -Iext/ldap/ -I/data/pkgs/ws/php-5.4.0/ext/ldap/ -DPHP_ATOM_INC -I/data/pkgs/ws/php-5.4.0/include -I/data/pkgs/ws/php-5.4.0/main -I/data/pkgs/ws/php-5.4.0 -I/data/pkgs/ws/php-5.4.0/ext/date/lib -I/data/pkgs/ws/php-5.4.0/ext/ereg/regex -I/usr/include/libxml2 -I/usr/kerberos/include -I/usr/include/freetype2 -I/data/pkgs/ws/php-5.4.0/ext/mbstring/oniguruma -I/data/pkgs/ws/php-5.4.0/ext/mbstring/libmbfl -I/data/pkgs/ws/php-5.4.0/ext/mbstring/libmbfl/mbfl -I/usr//include/mysql -I/usr/include/mysql -I/usr/include/oracle/11.2/client64 -I/data/pkgs/ws/php-5.4.0/ext/sqlite3/libsqlite -I/data/pkgs/ws/php-5.4.0/TSRM -I/data/pkgs/ws/php-5.4.0/Zend -D_REENTRANT -I/usr/include -g -O2 -fvisibility=hidden -pthread -DZTS -c /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c -o ext/ldap/ldap.lo Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:30, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/oracle/11.2/client64/ldap.h:68:1: attention : « LBER_CLASS_UNIVERSAL » redéfini Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:27, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/lber.h:52:1: attention : ceci est la localisation d'une précédente définition Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:30, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/oracle/11.2/client64/ldap.h:69:1: attention : « LBER_CLASS_APPLICATION » redéfini Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:27, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/lber.h:53:1: attention : ceci est la localisation d'une précédente définition Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:30, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/oracle/11.2/client64/ldap.h:70:1: attention : « LBER_CLASS_CONTEXT » redéfini Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:27, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/lber.h:54:1: attention : ceci est la localisation d'une précédente définition Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:30, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/oracle/11.2/client64/ldap.h:71:1: attention : « LBER_CLASS_PRIVATE » redéfini Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:27, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/lber.h:55:1: attention : ceci est la localisation d'une précédente définition Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:30, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/oracle/11.2/client64/ldap.h:72:1: attention : « LBER_CLASS_MASK » redéfini Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:27, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/lber.h:56:1: attention : ceci est la localisation d'une précédente définition Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:30, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/oracle/11.2/client64/ldap.h:75:1: attention : « LBER_PRIMITIVE » redéfini Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:27, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/lber.h:59:1: attention : ceci est la localisation d'une précédente définition Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:30, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/oracle/11.2/client64/ldap.h:76:1: attention
[PHP-BUG] Bug #61484 [NEW]: iconv //IGNORE option doesn't work anymore in PHP5.4
From: Operating system: Ubuntu PHP version: 5.4.0 Package: ICONV related Bug Type: Bug Bug description:iconv //IGNORE option doesn't work anymore in PHP5.4 Description: When adding "//IGNORE" to target encoding in iconv function, wrong characters should be skipped. This worked in PHP 5.3, but doesn't work anymore in 5.4. I just compiled 5.3.10, where it works fine. Doesn't work on 5.4.0 nor on 5.4.1- RC1. Test script: --- var_dump(iconv('UTF-8', 'UTF-16//IGNORE', "\xc5\xbea\x01b\xed\xa0\x80c\xef\xbb\xbfd\xf4\x90\x80\x80e")); Expected result: string(18) "��~abc��de" Actual result: -- bool(false) -- Edit bug report at https://bugs.php.net/bug.php?id=61484&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61484&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61484&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61484&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61484&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61484&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61484&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61484&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61484&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61484&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61484&r=support Expected behavior: https://bugs.php.net/fix.php?id=61484&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61484&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61484&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61484&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61484&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61484&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61484&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61484&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61484&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61484&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61484&r=mysqlcfg
Bug #60332 [Opn->Nab]: timezone_abbreviations_list() returns incorrect time offset
Edit report at https://bugs.php.net/bug.php?id=60332&edit=1 ID: 60332 Updated by: der...@php.net Reported by:nazar-pc at yandex dot ru Summary:timezone_abbreviations_list() returns incorrect time offset -Status: Open +Status: Not a bug Type: Bug Package:Date/time related Operating System: Ubuntu Linux 11.10 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php It also tells you between which timestamps those UTC offsets were valid. If you run zdump -v Europe/Kiev on the command line, you get the same output: Europe/Kiev Wed Dec 31 21:57:55 1879 UTC = Wed Dec 31 23:59:59 1879 LMT isdst=0 gmtoff=7324 Europe/Kiev Wed Dec 31 21:57:56 1879 UTC = Thu Jan 1 00:00:00 1880 KMT isdst=0 gmtoff=7324 Europe/Kiev Thu May 1 21:57:55 1924 UTC = Thu May 1 23:59:59 1924 KMT isdst=0 gmtoff=7324 Europe/Kiev Thu May 1 21:57:56 1924 UTC = Thu May 1 23:57:56 1924 EET isdst=0 gmtoff=7200 Europe/Kiev Fri Jun 20 21:59:59 1930 UTC = Fri Jun 20 23:59:59 1930 EET isdst=0 gmtoff=7200 Europe/Kiev Fri Jun 20 22:00:00 1930 UTC = Sat Jun 21 01:00:00 1930 MSK isdst=0 gmtoff=10800 Europe/Kiev Fri Sep 19 20:59:59 1941 UTC = Fri Sep 19 23:59:59 1941 MSK isdst=0 gmtoff=10800 Europe/Kiev Fri Sep 19 21:00:00 1941 UTC = Fri Sep 19 23:00:00 1941 CEST isdst=1 gmtoff=7200 Europe/Kiev Mon Nov 2 00:59:59 1942 UTC = Mon Nov 2 02:59:59 1942 CEST isdst=1 gmtoff=7200 Europe/Kiev Mon Nov 2 01:00:00 1942 UTC = Mon Nov 2 02:00:00 1942 CET isdst=0 gmtoff=3600 Europe/Kiev Mon Mar 29 00:59:59 1943 UTC = Mon Mar 29 01:59:59 1943 CET isdst=0 gmtoff=3600 Europe/Kiev Mon Mar 29 01:00:00 1943 UTC = Mon Mar 29 03:00:00 1943 CEST isdst=1 gmtoff=7200 Europe/Kiev Mon Oct 4 00:59:59 1943 UTC = Mon Oct 4 02:59:59 1943 CEST isdst=1 gmtoff=7200 Europe/Kiev Mon Oct 4 01:00:00 1943 UTC = Mon Oct 4 02:00:00 1943 CET isdst=0 gmtoff=3600 Europe/Kiev Fri Nov 5 22:59:59 1943 UTC = Fri Nov 5 23:59:59 1943 CET isdst=0 gmtoff=3600 Europe/Kiev Fri Nov 5 23:00:00 1943 UTC = Sat Nov 6 02:00:00 1943 MSK isdst=0 gmtoff=10800 Europe/Kiev Tue Mar 31 20:59:59 1981 UTC = Tue Mar 31 23:59:59 1981 MSK isdst=0 gmtoff=10800 Europe/Kiev Tue Mar 31 21:00:00 1981 UTC = Wed Apr 1 01:00:00 1981 MSD isdst=1 gmtoff=14400 Europe/Kiev Wed Sep 30 19:59:59 1981 UTC = Wed Sep 30 23:59:59 1981 MSD isdst=1 gmtoff=14400 Europe/Kiev Wed Sep 30 20:00:00 1981 UTC = Wed Sep 30 23:00:00 1981 MSK isdst=0 gmtoff=10800 Europe/Kiev Wed Mar 31 20:59:59 1982 UTC = Wed Mar 31 23:59:59 1982 MSK isdst=0 gmtoff=10800 Europe/Kiev Wed Mar 31 21:00:00 1982 UTC = Thu Apr 1 01:00:00 1982 MSD isdst=1 gmtoff=14400 ... Europe/Kiev Sun Mar 27 00:59:59 2011 UTC = Sun Mar 27 02:59:59 2011 EET isdst=0 gmtoff=7200 Europe/Kiev Sun Mar 27 01:00:00 2011 UTC = Sun Mar 27 04:00:00 2011 EEST isdst=1 gmtoff=10800 Europe/Kiev Sun Oct 30 00:59:59 2011 UTC = Sun Oct 30 03:59:59 2011 EEST isdst=1 gmtoff=10800 Europe/Kiev Sun Oct 30 01:00:00 2011 UTC = Sun Oct 30 03:00:00 2011 EET isdst=0 gmtoff=7200 Europe/Kiev Sun Mar 25 00:59:59 2012 UTC = Sun Mar 25 02:59:59 2012 EET isdst=0 gmtoff=7200 Europe/Kiev Sun Mar 25 01:00:00 2012 UTC = Sun Mar 25 04:00:00 2012 EEST isdst=1 gmtoff=10800 Europe/Kiev Sun Oct 28 00:59:59 2012 UTC = Sun Oct 28 03:59:59 2012 EEST isdst=1 gmtoff=10800 Europe/Kiev Sun Oct 28 01:00:00 2012 UTC = Sun Oct 28 03:00:00 2012 EET isdst=0 gmtoff=7200 Europe/Kiev Sun Mar 31 00:59:59 2013 UTC = Sun Mar 31 02:59:59 2013 EET isdst=0 gmtoff=7200 It just shows that in the past, it was different. Previous Comments: [2012-03-22 21:40:06] nazar-pc at yandex dot ru But why it returns mean solar time? After changing of timezone to Europe/Kiev, time on site offsets on +2 hours, and it is obvious, that I expect to obtain the same value in returned array, but observe such unexpected behaviour (who needs this?). So, if this function returns mean solar time, how to get true time offsets for each timezone correctly? [2012-03-22 21:27:01] jdmcadam at hotmail dot com The documentation on this isn't very clear, but the array that is returned has multiple timezones for most locations, organized by timezone abbreviation (ex CET, GMT, PST). In this case, Europe/Kiev shows up under 7 different timezones with offsets ranging from UTC+1 (no DST) to UTC+4. One of these is mean solar time which, for Kiev, is UTC +7324 seconds (based on distance from 0 deg of longitude). At 24hrs = 360°, 7324sec = 30.51667°E, which runs straight through
Bug #61482 [Com]: php-cli crashes during 'nmake snap'
Edit report at https://bugs.php.net/bug.php?id=61482&edit=1 ID: 61482 Comment by: mattfic...@php.net Reported by:mattfic...@php.net Summary:php-cli crashes during 'nmake snap' Status: Open Type: Bug Package:PHAR related Operating System: Windows PHP Version:5.4.0 Block user comment: N Private report: N New Comment: looks like it fails on the first call to file_get_contents() in make_phar_dot_phar(). the first and only arg to file_get_contents() is "c:\php-sdk\git\php-src\ext\phar\phar\clicommand.inc". Previous Comments: [2012-03-22 22:56:48] mattfic...@php.net Test Script (stripped down win32/build/mkdist.php): C:\php-sdk\git\obj\Release\php.exe -d date.timezone=UTC -n -dphar.readonly=0 win32/build/mkdist.php "C:\php-sdk\git\obj\Release" "C:\php-sdk\git\php-src\no" "php5.dll" "php-cgi.exe php.exe php-win.exe php5embed.lib" "php_mbstring.dll php_shmop.dll php_sockets.dll php_sqlite3.dll php_exif.dll php_pdo_mysql.dll php_pdo_odbc.dll php_pdo_sqlite.dll " " " "no" // php build directory $build_dir = "C:\php-sdk\git\obj\Release"; $dist_dir = $build_dir . "/php-" . phpversion(); $test_dir = $build_dir . "/php-test-pack-" . phpversion(); $pecl_dir = $build_dir . "/pecl-" . phpversion(); @mkdir($dist_dir); @mkdir("$dist_dir/ext"); @mkdir("$dist_dir/dev"); @mkdir("$dist_dir/extras"); @mkdir($pecl_dir); function make_phar_dot_phar($dist_dir) { if (!extension_loaded('phar')) { return; } $path_to_phar = realpath(__DIR__ . '/../../ext/phar'); echo "Generating pharcommand.phar\n"; $phar = new Phar($dist_dir . '/pharcommand.phar', 0, 'pharcommand'); foreach (new DirectoryIterator($path_to_phar . '/phar') as $file) { if ($file->isDir() || $file == 'phar.php') { continue; } echo 'adding ', $file, "\n"; $phar[(string) $file] = file_get_contents($path_to_phar. '/phar/' . $file); } $phar->setSignatureAlgorithm(Phar::SHA1); $stub = file($path_to_phar . '/phar/phar.php'); unset($stub[0]); // remove hashbang $phar->setStub(implode('', $stub)); echo "Creating phar.phar.bat\n"; file_put_contents($dist_dir . '/phar.phar.bat', "%~dp0php.exe %~dp0pharcommand.phar %*\r\n"); } make_phar_dot_phar($dist_dir); ?> [2012-03-22 22:33:59] mattfic...@php.net Description: Compiling latest revision from git repo... Using Windows 7sp1x64, VC9 compiler x86 xp release Ran nmake snap... When it gets to 'creating phar.phar.bat' stage php cli crashes. Here is the backtrace: php5.dll!zval_mark_grey(_zval_struct * pz=0x010f0060) Line 425 C php5.dll!gc_mark_roots() Line 501 + 0x6 bytes C php5.dll!gc_collect_cycles() Line 794 C php5.dll!zend_deactivate() Line 962C php5.dll!php_request_shutdown(void * dummy=0x) Line 1784 C php.exe!do_cli(int argc=13, char * * argv=0x00151b10) Line 1169 + 0x8 bytes C php.exe!main(int argc=13, char * * argv=0x00151b10) Line 1358 C php.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C kernel32.dll!7616339a() -- Edit this bug report at https://bugs.php.net/bug.php?id=61482&edit=1
Bug #61482 [Com]: php-cli crashes during 'nmake snap'
Edit report at https://bugs.php.net/bug.php?id=61482&edit=1 ID: 61482 Comment by: mattfic...@php.net Reported by:mattfic...@php.net Summary:php-cli crashes during 'nmake snap' Status: Open Type: Bug Package:PHAR related Operating System: Windows PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Test Script (stripped down win32/build/mkdist.php): C:\php-sdk\git\obj\Release\php.exe -d date.timezone=UTC -n -dphar.readonly=0 win32/build/mkdist.php "C:\php-sdk\git\obj\Release" "C:\php-sdk\git\php-src\no" "php5.dll" "php-cgi.exe php.exe php-win.exe php5embed.lib" "php_mbstring.dll php_shmop.dll php_sockets.dll php_sqlite3.dll php_exif.dll php_pdo_mysql.dll php_pdo_odbc.dll php_pdo_sqlite.dll " " " "no" // php build directory $build_dir = "C:\php-sdk\git\obj\Release"; $dist_dir = $build_dir . "/php-" . phpversion(); $test_dir = $build_dir . "/php-test-pack-" . phpversion(); $pecl_dir = $build_dir . "/pecl-" . phpversion(); @mkdir($dist_dir); @mkdir("$dist_dir/ext"); @mkdir("$dist_dir/dev"); @mkdir("$dist_dir/extras"); @mkdir($pecl_dir); function make_phar_dot_phar($dist_dir) { if (!extension_loaded('phar')) { return; } $path_to_phar = realpath(__DIR__ . '/../../ext/phar'); echo "Generating pharcommand.phar\n"; $phar = new Phar($dist_dir . '/pharcommand.phar', 0, 'pharcommand'); foreach (new DirectoryIterator($path_to_phar . '/phar') as $file) { if ($file->isDir() || $file == 'phar.php') { continue; } echo 'adding ', $file, "\n"; $phar[(string) $file] = file_get_contents($path_to_phar. '/phar/' . $file); } $phar->setSignatureAlgorithm(Phar::SHA1); $stub = file($path_to_phar . '/phar/phar.php'); unset($stub[0]); // remove hashbang $phar->setStub(implode('', $stub)); echo "Creating phar.phar.bat\n"; file_put_contents($dist_dir . '/phar.phar.bat', "%~dp0php.exe %~dp0pharcommand.phar %*\r\n"); } make_phar_dot_phar($dist_dir); ?> Previous Comments: [2012-03-22 22:33:59] mattfic...@php.net Description: Compiling latest revision from git repo... Using Windows 7sp1x64, VC9 compiler x86 xp release Ran nmake snap... When it gets to 'creating phar.phar.bat' stage php cli crashes. Here is the backtrace: php5.dll!zval_mark_grey(_zval_struct * pz=0x010f0060) Line 425 C php5.dll!gc_mark_roots() Line 501 + 0x6 bytes C php5.dll!gc_collect_cycles() Line 794 C php5.dll!zend_deactivate() Line 962C php5.dll!php_request_shutdown(void * dummy=0x) Line 1784 C php.exe!do_cli(int argc=13, char * * argv=0x00151b10) Line 1169 + 0x8 bytes C php.exe!main(int argc=13, char * * argv=0x00151b10) Line 1358 C php.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C kernel32.dll!7616339a() -- Edit this bug report at https://bugs.php.net/bug.php?id=61482&edit=1
[PHP-BUG] Bug #61482 [NEW]: php-cli crashes during 'nmake snap'
From: mattficken Operating system: Windows PHP version: 5.4.0 Package: PHAR related Bug Type: Bug Bug description:php-cli crashes during 'nmake snap' Description: Compiling latest revision from git repo... Using Windows 7sp1x64, VC9 compiler x86 xp release Ran nmake snap... When it gets to 'creating phar.phar.bat' stage php cli crashes. Here is the backtrace: php5.dll!zval_mark_grey(_zval_struct * pz=0x010f0060) Line 425 C php5.dll!gc_mark_roots() Line 501 + 0x6 bytes C php5.dll!gc_collect_cycles() Line 794 C php5.dll!zend_deactivate() Line 962C php5.dll!php_request_shutdown(void * dummy=0x) Line 1784 C php.exe!do_cli(int argc=13, char * * argv=0x00151b10) Line 1169 + 0x8 bytes C php.exe!main(int argc=13, char * * argv=0x00151b10) Line 1358 C php.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C kernel32.dll!7616339a() -- Edit bug report at https://bugs.php.net/bug.php?id=61482&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61482&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61482&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61482&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61482&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61482&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61482&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61482&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61482&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61482&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61482&r=support Expected behavior: https://bugs.php.net/fix.php?id=61482&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61482&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61482&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61482&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61482&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61482&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61482&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61482&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61482&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61482&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61482&r=mysqlcfg
Bug #60332 [Opn]: timezone_abbreviations_list() returns incorrect time offset
Edit report at https://bugs.php.net/bug.php?id=60332&edit=1 ID: 60332 User updated by:nazar-pc at yandex dot ru Reported by:nazar-pc at yandex dot ru Summary:timezone_abbreviations_list() returns incorrect time offset Status: Open Type: Bug Package:Date/time related Operating System: Ubuntu Linux 11.10 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: But why it returns mean solar time? After changing of timezone to Europe/Kiev, time on site offsets on +2 hours, and it is obvious, that I expect to obtain the same value in returned array, but observe such unexpected behaviour (who needs this?). So, if this function returns mean solar time, how to get true time offsets for each timezone correctly? Previous Comments: [2012-03-22 21:27:01] jdmcadam at hotmail dot com The documentation on this isn't very clear, but the array that is returned has multiple timezones for most locations, organized by timezone abbreviation (ex CET, GMT, PST). In this case, Europe/Kiev shows up under 7 different timezones with offsets ranging from UTC+1 (no DST) to UTC+4. One of these is mean solar time which, for Kiev, is UTC +7324 seconds (based on distance from 0 deg of longitude). At 24hrs = 360°, 7324sec = 30.51667°E, which runs straight through Kiev. [2011-11-19 01:59:51] nazar-pc at yandex dot ru PHP version corrected [2011-11-19 01:57:45] nazar-pc at yandex dot ru Description: --- >From manual page: http://www.php.net/datetimezone.listabbreviations --- Function timezone_abbreviations_list() returns incorrect values of time offset. For example, I live in Ukraine, Kiev (timezone Europe/Kiev) with time offset +2 hours, but function returns value, that equals to +2:02:04 (in seconds 7324), similar problems are for other timezones. Other cities in my country has the same offset +2 hours, but function returns other values from interval +2 till +3 hours, why? But functions, which works with time after changing of timezone return correct values, so, the problem is only in this function. -- Edit this bug report at https://bugs.php.net/bug.php?id=60332&edit=1
Bug #60332 [Com]: timezone_abbreviations_list() returns incorrect time offset
Edit report at https://bugs.php.net/bug.php?id=60332&edit=1 ID: 60332 Comment by: jdmcadam at hotmail dot com Reported by:nazar-pc at yandex dot ru Summary:timezone_abbreviations_list() returns incorrect time offset Status: Open Type: Bug Package:Date/time related Operating System: Ubuntu Linux 11.10 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: The documentation on this isn't very clear, but the array that is returned has multiple timezones for most locations, organized by timezone abbreviation (ex CET, GMT, PST). In this case, Europe/Kiev shows up under 7 different timezones with offsets ranging from UTC+1 (no DST) to UTC+4. One of these is mean solar time which, for Kiev, is UTC +7324 seconds (based on distance from 0 deg of longitude). At 24hrs = 360°, 7324sec = 30.51667°E, which runs straight through Kiev. Previous Comments: [2011-11-19 01:59:51] nazar-pc at yandex dot ru PHP version corrected [2011-11-19 01:57:45] nazar-pc at yandex dot ru Description: --- >From manual page: http://www.php.net/datetimezone.listabbreviations --- Function timezone_abbreviations_list() returns incorrect values of time offset. For example, I live in Ukraine, Kiev (timezone Europe/Kiev) with time offset +2 hours, but function returns value, that equals to +2:02:04 (in seconds 7324), similar problems are for other timezones. Other cities in my country has the same offset +2 hours, but function returns other values from interval +2 till +3 hours, why? But functions, which works with time after changing of timezone return correct values, so, the problem is only in this function. -- Edit this bug report at https://bugs.php.net/bug.php?id=60332&edit=1
Bug #61481 [PATCH]: Test Bug - ext/com_dotnet/tests/bug49192
Edit report at https://bugs.php.net/bug.php?id=61481&edit=1 ID: 61481 Patch added by: mattfic...@php.net Reported by:mattfic...@php.net Summary:Test Bug - ext/com_dotnet/tests/bug49192 Status: Open Type: Bug Package:Testing related Operating System: Windows PHP Version:5.3.10 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug49192 Revision: 1332450831 URL: https://bugs.php.net/patch-display.php?bug=61481&patch=bug49192&revision=1332450831 Previous Comments: [2012-03-22 21:13:29] mattfic...@php.net Description: Expected result: test pass Actual result: -- test fail 001+ Fatal error: Uncaught exception 'com_exception' with message 'Failed to create COM object `ADODB.Connection': The specified module could not be found. 001- int(0) 002+ ' in C:\php-sdk\php-5.3-src-r324324\ext\com_dotnet\tests\bug49192.php:15 003+ Stack trace: 004+ #0 C:\php-sdk\php-5.3-src-r324324\ext\com_dotnet\tests\bug49192.php(15): com->com('ADODB.Connectio...') 005+ #1 {main} 006+ thrown in C:\php-sdk\php-5.3-src-r324324\ext\com_dotnet\tests\bug49192.php on line 15 This test fails to load ADO (using COM). The patch marks it as XFAIL and provides this info. A change in windows longhorn x64(affecting vista, 7, 8, 2008, 2008r2) broke ADO. There is a fix available, but user has to install it. Given that ADO was deprecated a long time ago in favor of newer APIs, I don't think its worth the trouble of making the user install the fix to get an accurate test run. its better to just not run the test or expect it to fail. see: http://support.microsoft.com/kb/2517589 see: http://www.infoq.com/news/2011/10/ADO-Win7 -- Edit this bug report at https://bugs.php.net/bug.php?id=61481&edit=1
[PHP-BUG] Bug #61481 [NEW]: Test Bug - ext/com_dotnet/tests/bug49192
From: mattficken Operating system: Windows PHP version: 5.3.10 Package: Testing related Bug Type: Bug Bug description:Test Bug - ext/com_dotnet/tests/bug49192 Description: Expected result: test pass Actual result: -- test fail 001+ Fatal error: Uncaught exception 'com_exception' with message 'Failed to create COM object `ADODB.Connection': The specified module could not be found. 001- int(0) 002+ ' in C:\php-sdk\php-5.3-src-r324324\ext\com_dotnet\tests\bug49192.php:15 003+ Stack trace: 004+ #0 C:\php-sdk\php-5.3-src-r324324\ext\com_dotnet\tests\bug49192.php(15): com->com('ADODB.Connectio...') 005+ #1 {main} 006+ thrown in C:\php-sdk\php-5.3-src-r324324\ext\com_dotnet\tests\bug49192.php on line 15 This test fails to load ADO (using COM). The patch marks it as XFAIL and provides this info. A change in windows longhorn x64(affecting vista, 7, 8, 2008, 2008r2) broke ADO. There is a fix available, but user has to install it. Given that ADO was deprecated a long time ago in favor of newer APIs, I don't think its worth the trouble of making the user install the fix to get an accurate test run. its better to just not run the test or expect it to fail. see: http://support.microsoft.com/kb/2517589 see: http://www.infoq.com/news/2011/10/ADO-Win7 -- Edit bug report at https://bugs.php.net/bug.php?id=61481&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61481&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61481&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61481&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61481&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61481&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61481&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61481&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61481&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61481&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61481&r=support Expected behavior: https://bugs.php.net/fix.php?id=61481&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61481&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61481&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61481&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61481&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61481&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61481&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61481&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61481&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61481&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61481&r=mysqlcfg
Bug #61480 [PATCH]: test bug - ext/gd/tests/bug48555.phpt
Edit report at https://bugs.php.net/bug.php?id=61480&edit=1 ID: 61480 Patch added by: mattfic...@php.net Reported by:mattfic...@php.net Summary:test bug - ext/gd/tests/bug48555.phpt Status: Open Type: Bug Package:Testing related PHP Version:5.3.10 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug48555 Revision: 1332450447 URL: https://bugs.php.net/patch-display.php?bug=61480&patch=bug48555&revision=1332450447 Previous Comments: [2012-03-22 21:07:19] mattfic...@php.net Description: Expected result: tests pass Actual result: -- tests fail 001+ Top without line-break: -15 002+ Top with line-break: -15 001- Top without line-break: -14 002- Top with line-break: -14 Failure occurs with FreeType 2.4.3 which is what PHP uses. Test patch will skip test if FreeType version is less than 2.4.3. -- Edit this bug report at https://bugs.php.net/bug.php?id=61480&edit=1
[PHP-BUG] Bug #61480 [NEW]: test bug - ext/gd/tests/bug48555.phpt
From: mattficken Operating system: PHP version: 5.3.10 Package: Testing related Bug Type: Bug Bug description:test bug - ext/gd/tests/bug48555.phpt Description: Expected result: tests pass Actual result: -- tests fail 001+ Top without line-break: -15 002+ Top with line-break: -15 001- Top without line-break: -14 002- Top with line-break: -14 Failure occurs with FreeType 2.4.3 which is what PHP uses. Test patch will skip test if FreeType version is less than 2.4.3. -- Edit bug report at https://bugs.php.net/bug.php?id=61480&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61480&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61480&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61480&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61480&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61480&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61480&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61480&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61480&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61480&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61480&r=support Expected behavior: https://bugs.php.net/fix.php?id=61480&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61480&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61480&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61480&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61480&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61480&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61480&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61480&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61480&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61480&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61480&r=mysqlcfg
Bug #61468 [Com]: ext/phar/tests/phar_oo_005.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61468&edit=1 ID: 61468 Comment by: mattfic...@php.net Reported by:a...@php.net Summary:ext/phar/tests/phar_oo_005.phpt fails Status: Open Type: Bug Package:PHAR related Operating System: all PHP Version:Irrelevant Block user comment: N Private report: N New Comment: With the patch, the test passes for me on Windows 7 sp1x64 with PHP_5_3-r324324 Previous Comments: [2012-03-21 20:27:25] a...@php.net In the patch phar_oo_005.phpt.diff the output is adopted according to the new iterator functionality. [2012-03-21 20:26:38] a...@php.net The following patch has been added/updated: Patch Name: phar_oo_005.phpt.diff Revision: 1332361598 URL: https://bugs.php.net/patch-display.php?bug=61468&patch=phar_oo_005.phpt.diff&revision=1332361598 [2012-03-21 20:24:08] a...@php.net Description: RecursiveIterator functionality changed, the test diff is 005+ string(21) "phar_oo_test.phar.php" 005- string(5) "a.php" 010+ string(1) "b" 010- string(5) "c.php" 015+ string(1) "b" 015- string(5) "d.php" 020+ string(21) "phar_oo_test.phar.php" 020- string(5) "b.php" 025+ string(21) "phar_oo_test.phar.php" 025- string(5) "e.php" Expected result: test pass Actual result: -- test fail -- Edit this bug report at https://bugs.php.net/bug.php?id=61468&edit=1
[PHP-BUG] Bug #61476 [NEW]: debug_backtrace() crashes if it has to return too large data
From: Operating system: All PHP version: 5.4.0 Package: *General Issues Bug Type: Bug Bug description:debug_backtrace() crashes if it has to return too large data Description: version 5.3.3.7 So the problem is that I use debug_backtrace() for logging, when an error occurs, so that I have record of what happened and where. The problem is that if you are using for example Zend framework, and a couple of huge objects are encountered, then PHP basically crashes (nothing is logged in the error log, no error output is produced, only a blank output). This is probably because of the lack of memory. Yes, I know that I should use the ..._PROVIDE_OBJECT flag to skip them, but that's the point. I don't want to. Because I need it 99% of the time, but sometimes I get these huge backtraces which makes PHP fail. So there should either be a way to check how big the output debug_backtrace() produces, (so that I will know when not to execute it), or it should return FALSE if there is not enough memory to store the result or something similar no? You added the limit parameter in PHP 5.4 I can see that, but that still doesn't guarantee you that you will have enough memory to get results of this function. It can still cause a crash. -- Edit bug report at https://bugs.php.net/bug.php?id=61476&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61476&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61476&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61476&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61476&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61476&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61476&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61476&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61476&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61476&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61476&r=support Expected behavior: https://bugs.php.net/fix.php?id=61476&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61476&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61476&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61476&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61476&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61476&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61476&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61476&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61476&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61476&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61476&r=mysqlcfg
[PHP-BUG] Bug #61474 [NEW]: Compile failure with OCI8 - instantclient 11.2
From: Operating system: RedHat Entreprise Linux 5 x86_64 PHP version: 5.4.0 Package: Compile Failure Bug Type: Bug Bug description:Compile failure with OCI8 - instantclient 11.2 Description: Trying to compile PHP 5.4.0 with Oracle Instant Client 11.2 and I receive the following error: ~# ./configure ... --with-oci8=instantclient,/usr/lib/oracle/11.2/client64/lib \ ... ~# make /bin/sh /data/pkgs/ws/php-5.4.0/libtool --silent --preserve-dup-deps --mode=compile /data/pkgs/ws/php-5.4.0/meta_ccld -DLDAP_DEPRECATED=1 -Iext/ldap/ -I/data/pkgs/ws/php-5.4.0/ext/ldap/ -DPHP_ATOM_INC -I/data/pkgs/ws/php-5.4.0/include -I/data/pkgs/ws/php-5.4.0/main -I/data/pkgs/ws/php-5.4.0 -I/data/pkgs/ws/php-5.4.0/ext/date/lib -I/data/pkgs/ws/php-5.4.0/ext/ereg/regex -I/usr/include/libxml2 -I/usr/kerberos/include -I/usr/include/freetype2 -I/data/pkgs/ws/php-5.4.0/ext/mbstring/oniguruma -I/data/pkgs/ws/php-5.4.0/ext/mbstring/libmbfl -I/data/pkgs/ws/php-5.4.0/ext/mbstring/libmbfl/mbfl -I/usr//include/mysql -I/usr/include/mysql -I/usr/include/oracle/11.2/client64 -I/data/pkgs/ws/php-5.4.0/ext/sqlite3/libsqlite -I/data/pkgs/ws/php-5.4.0/TSRM -I/data/pkgs/ws/php-5.4.0/Zend -D_REENTRANT -I/usr/include -g -O2 -fvisibility=hidden -pthread -DZTS -c /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c -o ext/ldap/ldap.lo Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:30, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/oracle/11.2/client64/ldap.h:68:1: attention : « LBER_CLASS_UNIVERSAL » redéfini Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:27, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/lber.h:52:1: attention : ceci est la localisation d'une précédente définition Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:30, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/oracle/11.2/client64/ldap.h:69:1: attention : « LBER_CLASS_APPLICATION » redéfini Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:27, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/lber.h:53:1: attention : ceci est la localisation d'une précédente définition Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:30, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/oracle/11.2/client64/ldap.h:70:1: attention : « LBER_CLASS_CONTEXT » redéfini Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:27, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/lber.h:54:1: attention : ceci est la localisation d'une précédente définition Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:30, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/oracle/11.2/client64/ldap.h:71:1: attention : « LBER_CLASS_PRIVATE » redéfini Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:27, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/lber.h:55:1: attention : ceci est la localisation d'une précédente définition Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:30, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/oracle/11.2/client64/ldap.h:72:1: attention : « LBER_CLASS_MASK » redéfini Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:27, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/lber.h:56:1: attention : ceci est la localisation d'une précédente définition Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:30, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/oracle/11.2/client64/ldap.h:75:1: attention : « LBER_PRIMITIVE » redéfini Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:27, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/lber.h:59:1: attention : ceci est la localisation d'une précédente définition Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:30, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/oracle/11.2/client64/ldap.h:76:1: attention : « LBER_CONSTRUCTED » redéfini Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:27, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/lber.h:60:1: attention : ceci est la localisation d'une précédente définition Dans le fichier inclus à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/php_ldap.h:30, à partir de /data/pkgs/ws/php-5.4.0/ext/ldap/ldap.c:45: /usr/include/oracle/11.2/client64/ldap.h:77:1: attention : « LBER_EN
Bug #61423 [Csd->Asn]: gzip compression fails
Edit report at https://bugs.php.net/bug.php?id=61423&edit=1 ID: 61423 User updated by:borrible13th at gmx dot net Reported by:borrible13th at gmx dot net Summary:gzip compression fails -Status: Closed +Status: Assigned Type: Bug Package:SOAP related Operating System: ALL PHP Version:5.4.0 Assigned To:iliaa Block user comment: N Private report: N New Comment: This bug is PHP 5.4 only, and not PHP 5.3! So, applying the bugfix on branch PHP-5.3 is totally wrong! Zlib introduces new constants ZLIB_ENCODING_RAW, ZLIB_ENCODING_GZIP, ZLIB_ENCODING_DEFLATE in PHP 5.4 and redefines the older constants of PHP 5.3 and older (FORCE_GZIP as ZLIB_ENCODING_GZIP and FORCE_DEFLATE as ZLIB_ENCODING_DEFLATE). Sorry for changing status again. --- Overview of constants in ext/zlib/php_zlib.h: PHP 5.3: CODING_GZIP 1 (registered as "FORCE_GZIP") CODING_DEFLATE 2 (registered as "FORCE_DEFLATE") PHP 5.4: PHP_ZLIB_ENCODING_RAW -0xf (registered as "ZLIB_ENCODING_RAW") PHP_ZLIB_ENCODING_GZIP 0x1f (31) (registered as "ZLIB_ENCODING_GZIP" and "FORCE_GZIP") PHP_ZLIB_ENCODING_DEFLATE 0x0f (15) (registered as "ZLIB_ENCODING_DEFLATE" and "FORCE_DEFLATE") [PHP_ZLIB_ENCODING_ANY 0x2f (47)] Previous Comments: [2012-03-22 13:54:48] il...@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. There was an issue with the fix push, all good now. [2012-03-22 13:48:23] il...@php.net Automatic comment on behalf of iliaa Revision: http://git.php.net/?p=php-src.git;a=commit;h=f9f631fb765dc08e3d62073b6eb35ce1b11db0e4 Log: Fixed bug #61423 (gzip compression fails). [2012-03-22 13:47:22] il...@php.net Automatic comment on behalf of iliaa Revision: http://git.php.net/?p=php-src.git;a=commit;h=f9f631fb765dc08e3d62073b6eb35ce1b11db0e4 Log: Fixed bug #61423 (gzip compression fails). [2012-03-22 13:17:01] ili...@php.net Automatic comment on behalf of iliaal Revision: http://git.php.net/?p=php-src.git;a=commit;h=b4aea52682a6e7a8f0e2a7638ba37145cb6bf16d Log: Fixed bug #61423 (gzip compression fails). [2012-03-22 13:16:44] ili...@php.net Automatic comment on behalf of iliaal Revision: http://git.php.net/?p=php-src.git;a=commit;h=b4aea52682a6e7a8f0e2a7638ba37145cb6bf16d Log: Fixed bug #61423 (gzip compression fails). 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=61423 -- Edit this bug report at https://bugs.php.net/bug.php?id=61423&edit=1
Bug #61469 [Nab->Opn]: simplexml_load_file() url encodes file names if they use a stream wrapper
Edit report at https://bugs.php.net/bug.php?id=61469&edit=1 ID: 61469 Updated by: ber...@php.net Reported by:saschagros at gmail dot com Summary:simplexml_load_file() url encodes file names if they use a stream wrapper -Status: Not a bug +Status: Open Type: Bug Package:SimpleXML related Operating System: Linux/Windows PHP Version:5.3.10 Block user comment: N Private report: N Previous Comments: [2012-03-22 14:00:44] saschagros at gmail dot com temporary is not a remote URI that points to a HTTP resource. This is a local file. If the space needs to be encoded internally, fine. But it has to be possible to access a file with a space in it using a stream wrapper? After all, file_get_contents() works just fine. [2012-03-22 07:35:40] cataphr...@php.net Looks right. URIs cannot contain spaces. See RFC 3986. [2012-03-21 22:43:03] saschagros at gmail dot com Description: Drupal uses custom stream wrappers for accessing files. Given the file name "$imported_file = 'temporary://translated file.xlf'", the following does not work: $xml = simplexml_load_file($imported_file); It results in the following warning: simplexml_load_file(): I/O warning : failed to load external entity "temporary://translated%20file.xlf" However, this works just fine: $xml_string = file_get_contents($imported_file); $xml = simplexml_load_string($xml_string); -- Edit this bug report at https://bugs.php.net/bug.php?id=61469&edit=1
Bug #61470 [Com]: session_regenerate_id() do not create session file
Edit report at https://bugs.php.net/bug.php?id=61470&edit=1 ID: 61470 Comment by: david at grudl dot com Reported by:david at grudl dot com Summary:session_regenerate_id() do not create session file Status: Open Type: Bug Package:Session related Operating System: Windows 7 x64 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Because this bug is very insidious and difficult to discover, I offer workaround https://github.com/nette/nette/commit/a4e4e80562cfb45d11d80e05d254fc207c456308#L0R241 $_SESSION is backed up before session_start() and restored to preserve the references. Previous Comments: [2012-03-22 04:48:03] david at grudl dot com Description: session_start() creates and locks session file, but session_regenerate_id() doesn't do it. After session_regenerate_id() session is started with new ID, but the file is not created immediately (is created when session is closed) and therefore is not locked. I think this causes bugs like #49462. Test script: --- $path = ini_get('session.save_path') . '/sess_'; session_start(); // starts session & creates and locks file echo is_file($path . session_id()); // -> TRUE session_regenerate_id(); // starts new session, but file is not create! echo is_file($path . session_id()); // -> FALSE -- Edit this bug report at https://bugs.php.net/bug.php?id=61470&edit=1
Bug #61469 [Com]: simplexml_load_file() url encodes file names if they use a stream wrapper
Edit report at https://bugs.php.net/bug.php?id=61469&edit=1 ID: 61469 Comment by: saschagros at gmail dot com Reported by:saschagros at gmail dot com Summary:simplexml_load_file() url encodes file names if they use a stream wrapper Status: Not a bug Type: Bug Package:SimpleXML related Operating System: Linux/Windows PHP Version:5.3.10 Block user comment: N Private report: N New Comment: temporary is not a remote URI that points to a HTTP resource. This is a local file. If the space needs to be encoded internally, fine. But it has to be possible to access a file with a space in it using a stream wrapper? After all, file_get_contents() works just fine. Previous Comments: [2012-03-22 07:35:40] cataphr...@php.net Looks right. URIs cannot contain spaces. See RFC 3986. [2012-03-21 22:43:03] saschagros at gmail dot com Description: Drupal uses custom stream wrappers for accessing files. Given the file name "$imported_file = 'temporary://translated file.xlf'", the following does not work: $xml = simplexml_load_file($imported_file); It results in the following warning: simplexml_load_file(): I/O warning : failed to load external entity "temporary://translated%20file.xlf" However, this works just fine: $xml_string = file_get_contents($imported_file); $xml = simplexml_load_string($xml_string); -- Edit this bug report at https://bugs.php.net/bug.php?id=61469&edit=1
Bug #61423 [Asn->Csd]: gzip compression fails
Edit report at https://bugs.php.net/bug.php?id=61423&edit=1 ID: 61423 Updated by: il...@php.net Reported by:borrible13th at gmx dot net Summary:gzip compression fails -Status: Assigned +Status: Closed Type: Bug Package:SOAP related Operating System: ALL PHP Version:5.4.0 Assigned To:iliaa 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. There was an issue with the fix push, all good now. Previous Comments: [2012-03-22 13:48:23] il...@php.net Automatic comment on behalf of iliaa Revision: http://git.php.net/?p=php-src.git;a=commit;h=f9f631fb765dc08e3d62073b6eb35ce1b11db0e4 Log: Fixed bug #61423 (gzip compression fails). [2012-03-22 13:47:22] il...@php.net Automatic comment on behalf of iliaa Revision: http://git.php.net/?p=php-src.git;a=commit;h=f9f631fb765dc08e3d62073b6eb35ce1b11db0e4 Log: Fixed bug #61423 (gzip compression fails). [2012-03-22 13:17:01] ili...@php.net Automatic comment on behalf of iliaal Revision: http://git.php.net/?p=php-src.git;a=commit;h=b4aea52682a6e7a8f0e2a7638ba37145cb6bf16d Log: Fixed bug #61423 (gzip compression fails). [2012-03-22 13:16:44] ili...@php.net Automatic comment on behalf of iliaal Revision: http://git.php.net/?p=php-src.git;a=commit;h=b4aea52682a6e7a8f0e2a7638ba37145cb6bf16d Log: Fixed bug #61423 (gzip compression fails). [2012-03-22 13:16:26] ili...@php.net Automatic comment on behalf of iliaal Revision: http://git.php.net/?p=php-src.git;a=commit;h=b4aea52682a6e7a8f0e2a7638ba37145cb6bf16d Log: Fixed bug #61423 (gzip compression fails). 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=61423 -- Edit this bug report at https://bugs.php.net/bug.php?id=61423&edit=1
Bug #61437 [Opn->Nab]: Illegal stub for phar
Edit report at https://bugs.php.net/bug.php?id=61437&edit=1 ID: 61437 Updated by: il...@php.net Reported by:nison dot mael at gmail dot com Summary:Illegal stub for phar -Status: Open +Status: Not a bug Type: Bug Package:PHAR related Operating System: Archlinux PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2012-03-19 15:50:14] nison dot mael at gmail dot com Description: It's not possible to add spaces in the __halt_compiler argument list. Test script: --- setStub( "https://bugs.php.net/bug.php?id=61437&edit=1
Bug #61472 [Opn]: cannot use date function in mips64
Edit report at https://bugs.php.net/bug.php?id=61472&edit=1 ID: 61472 User updated by:jonathanbj at qq dot com Reported by:jonathanbj at qq dot com Summary:cannot use date function in mips64 Status: Open Type: Bug Package:Reproducible crash Operating System: linux 2.6 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: (gdb) bt #0 0x00e4ba38 in memcpy () at ../ports/sysdeps/unix/sysv/linux/mips/nptl/lowlevellock.h:195 #1 0x00012007ef18 in timelib_parse_tzfile (timezone=, tzdb=) at /home/ck/trunk/dongda/apps/php-5.4.0/ext/date/lib/parse_tz.c:124 #2 0x0001200540f0 in php_date_parse_tzfile (formal_tzname=0x55565496b0 "", tzdb=0x120795ffe) at /home/ck/trunk/dongda/apps/php-5.4.0/ext/date/php_date.c:831 #3 0x000120056c9c in get_timezone_info () at /home/ck/trunk/dongda/apps/php-5.4.0/ext/date/php_date.c:877 #4 0x000120059964 in php_format_date (format=0x555614b0c0 "l", format_len=1, ts=4839792638, localtime=1) at /home/ck/trunk/dongda/apps/php-5.4.0/ext/date/php_date.c:1126 #5 0x00012005a40c in php_date (ht=1, return_value=0x5ab368, return_value_ptr=, this_ptr=, return_value_used=, localtime=1) at /home/ck/trunk/dongda/apps/php-5.4.0/ext/date/php_date.c: #6 0x0001203a0bc0 in zend_do_fcall_common_helper_SPEC (execute_data=0x579060) at /home/ck/trunk/dongda/apps/php-5.4.0/Zend/zend_vm_execute.h:642 #7 0x0001203a8d0c in execute (op_array=) at /home/ck/trunk/dongda/apps/php-5.4.0/Zend/zend_vm_execute.h:410 #8 0x000120369180 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/ck/trunk/dongda/apps/php-5.4.0/Zend/zend.c:1272 #9 0x0001202f92f4 in php_execute_script (primary_file=0xaec568) at /home/ck/trunk/dongda/apps/php-5.4.0/main/main.c:2473 #10 0x00012043d328 in do_cli (argc=0, argv=0xaecbe8) at /home/ck/trunk/dongda/apps/php-5.4.0/sapi/cli/php_cli.c:983 #11 0x00012043daa0 in main (argc=0, argv=0xaecbe8) at /home/ck/trunk/dongda/apps/php-5.4.0/sapi/cli/php_cli.c:1356 (gdb) Previous Comments: [2012-03-22 12:31:48] jonathanbj at qq dot com Description: 1) get the source of php 5.4.0 or 5.3.6: ./configure --host=mips64-unkown-linux make 2) do the test ./php 3.php Result with date()Segmentation fault (core dumped) Test script: --- -- Edit this bug report at https://bugs.php.net/bug.php?id=61472&edit=1
[PHP-BUG] Bug #61472 [NEW]: cannot use date function in mips64
From: Operating system: linux 2.6 PHP version: 5.4.0 Package: Reproducible crash Bug Type: Bug Bug description:cannot use date function in mips64 Description: 1) get the source of php 5.4.0 or 5.3.6: ./configure --host=mips64-unkown-linux make 2) do the test ./php 3.php Result with date()Segmentation fault (core dumped) Test script: --- -- Edit bug report at https://bugs.php.net/bug.php?id=61472&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61472&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61472&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61472&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61472&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61472&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61472&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61472&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61472&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61472&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61472&r=support Expected behavior: https://bugs.php.net/fix.php?id=61472&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61472&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61472&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61472&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61472&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61472&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61472&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61472&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61472&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61472&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61472&r=mysqlcfg
Bug #53294 [Fbk->Csd]: DateTime->setTimezone() very slow far future dates
Edit report at https://bugs.php.net/bug.php?id=53294&edit=1 ID: 53294 User updated by:maarten at react dot com Reported by:maarten at react dot com Summary:DateTime->setTimezone() very slow far future dates -Status: Feedback +Status: Closed Type: Bug Package:Date/time related Operating System: 64 bit Centos PHP Version:5.2.14 Assigned To:derick Block user comment: N Private report: N New Comment: I confirmed it was already fixed in 5.3.6, and a 3rd person (php dot net at doppy dot nl) confirmed it for 5.3.10, so issue is resolved. :) Previous Comments: [2012-03-21 16:48:21] php dot net at doppy dot nl Seems to be fixed for me as well. PHP 5.3.10-1ubuntu2 with Suhosin-Patch (cli) (built: Mar 5 2012 18:27:21) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies on 64bit. [2011-07-25 14:36:07] maarten at react dot com Tested in 5.3.6, and appears to be fixed. $date = new DateTime('@'.(int)(PHP_INT_MAX / 2)); now takes less than 1ms. :) [2011-01-22 08:52:50] s...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-11-11 13:55:30] maarten at react dot com Description: DateTime->setTimezone() is very slow on dates in the far future (or history), and the time needed isnt monotonic for greater dates. ie. setTimezone() on a DateTime(PHP_INT_MAX) /* 64 bit max */ takes 0.05 seconds, but takes 250 whole seconds for PHP_INT_MAX/2 . Using the $timezone parameter of the DateTime constructor is always fast though. Test script: --- $start = microtime(1); $date = new DateTime('@'.(PHP_INT_MAX)); // $date = new DateTime('@'.(int)(PHP_INT_MAX / 2)); $date->setTimezone(new DateTimeZone('Europe/Amsterdam')); echo microtime(1) - $start; Expected result: A faster change of the timezone; performance equal to using the constructor parameter -- Edit this bug report at https://bugs.php.net/bug.php?id=53294&edit=1
Bug #61345 [Opn->Csd]: CGI mode - make install don't work
Edit report at https://bugs.php.net/bug.php?id=61345&edit=1 ID: 61345 User updated by:sites at evoluons dot net Reported by:sites at evoluons dot net Summary:CGI mode - make install don't work -Status: Open +Status: Closed Type: Bug Package:Compile Failure Operating System: Fedora 16 x86_64 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: I updated my Fedora 16 x86_64 and now it works directly, without any workaround. So, I close the bug. Previous Comments: [2012-03-10 20:40:18] sites at evoluons dot net Description: Hi, With a Fedora 16 x86_64 I compiled PHP in Apache module mode, no problem. But, to use also CGI mode, compilation is OK, but "make install" not. My ./configure : ./configure --with-gd --with-zlib --enable-ftp --enable-sockets --with-curl --enable-mbstring --enable-exif --enable-zip --prefix=/usr/local/phpcgi --disable-cli --with-mysql=/usr/local/mysql --with-jpeg-dir --with-png-dir --with-freetype-dir --enable-gd-native-ttf --with-mcrypt make install Installing PHP CGI binary:/usr/local/phpcgi/bin/ cp: cannot create regular file `/usr/local/phpcgi/bin/#INST@1199#': No such file or directory Expected result: Installing PHP CGI binary:/usr/local/phpcgi/bin/ Installing build environment: /usr/local/phpcgi/lib/php/build/ Installing header files: /usr/local/phpcgi/include/php/ Installing helper programs: /usr/local/phpcgi/bin/ program: phpize program: php-config Installing man pages: /usr/local/phpcgi/php/man/man1/ page: phpize.1 page: php-config.1 Installing PDO headers: /usr/local/phpcgi/include/php/ext/pdo/ Actual result: -- If I manually create /usr/local/phpcgi and /usr/local/phpcgi/bin folders, "make install" work : mkdir /usr/local/phpcgi mkdir /usr/local/phpcgi/bin Thank you for your help ;) -- Edit this bug report at https://bugs.php.net/bug.php?id=61345&edit=1
[PHP-BUG] Bug #61471 [NEW]: Incomplete POST does not timeout but is passed to PHP
From: Operating system: linux PHP version: Irrelevant Package: Apache2 related Bug Type: Bug Bug description:Incomplete POST does not timeout but is passed to PHP Description: When a user has a really slow connection (we experienced the problem with POSTs longer than single TCP/IP frame) it may happen, that in expected amount of time the number of POST body bytes transmited is less than announced in Content-Length header. It seems, that even with the mod_reqtimeout installed and configured, apache2 happilly passes the request to PHP interpreter, with $_POST set to an empty array. It does so if the reqeusted page is a PHP script, which is inconsistent with the way a static HTML file is handled (400 Bad Request). Test script: --- I assume you have a script with var_dump($_POST) on the server. Please note how 1755 is much greater than "foo=bar" length netcat localhost 80 POST / HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 1755 foo=bar Expected result: 408 Request Timeout or 504 Gateway Timeout or 400 Bad Request or in the worst case 200 OK array(1){ "foo" => "bar" } Actual result: -- 200 OK array(0){ } -- Edit bug report at https://bugs.php.net/bug.php?id=61471&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61471&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61471&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61471&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61471&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61471&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61471&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61471&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61471&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61471&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61471&r=support Expected behavior: https://bugs.php.net/fix.php?id=61471&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61471&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61471&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61471&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61471&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61471&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61471&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61471&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61471&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61471&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61471&r=mysqlcfg
Bug #61368 [Opn->Csd]: Upstream tarball includes cruft (*.orig and autom4te.cache)
Edit report at https://bugs.php.net/bug.php?id=61368&edit=1 ID: 61368 Updated by: s...@php.net Reported by:ond...@php.net Summary:Upstream tarball includes cruft (*.orig and autom4te.cache) -Status: Open +Status: Closed Type: Bug Package:*General Issues Operating System: Any PHP Version:5.4.0 -Assigned To: +Assigned To:stas 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. New git version doesn't have this problem anymore. Previous Comments: [2012-03-13 07:12:21] ond...@php.net Description: On Mon, Mar 12, 2012 at 23:32, Stas Malyshev wrote: > On Mon, Mar 12, 2012 at 23:11, Christopher Jones > wrote: > > The autom4te.cache and *.orig files originally mentioned are included in > > php.net's php-5.4.0.tar.bz2 > > I.e. this is a valid issue. > > Definitely seems to be a bug in the makedist script, since these files are > not in the SVN but appear when packaging. > > > OndÅej, please log a bug. Test script: --- ondrej@kiMac:/tmp$ md5 ~/Downloads/php-5.4.0.tar.gz MD5 (/Users/ondrej/Downloads/php-5.4.0.tar.gz) = 46b72e274c6ea7e775245ffdb81c9ce5 ondrej@kiMac:/tmp$ tar -tzvf ~/Downloads/php-5.4.0.tar.gz | grep .orig -rw-r--r-- 0 smalyshev staff 30417 29 úno 08:37 php-5.4.0/ext/standard/url_scanner_ex.c.orig -rw-r--r-- 0 smalyshev staff 27289 29 úno 08:37 php-5.4.0/ext/standard/var_unserializer.c.orig -rw-r--r-- 0 smalyshev staff 19670 29 úno 08:37 php-5.4.0/ext/pdo/pdo_sql_parser.c.orig -rw-r--r-- 0 smalyshev staff 518939 29 úno 08:37 php-5.4.0/ext/date/lib/parse_date.c.orig ondrej@kiMac:/tmp$ tar -tzvf ~/Downloads/php-5.4.0.tar.gz | grep autom4te drwxr-xr-x 0 smalyshev staff 0 29 úno 08:37 php-5.4.0/autom4te.cache/ -rw-r--r-- 0 smalyshev staff 3012815 29 úno 08:37 php-5.4.0/autom4te.cache/output.0 -rw-r--r-- 0 smalyshev staff 2855 29 úno 08:37 php-5.4.0/autom4te.cache/requests -rw-r--r-- 0 smalyshev staff 387029 29 úno 08:37 php-5.4.0/autom4te.cache/traces.0 Expected result: Neither .orig nor autom4te.cache/ directory in distribution tarball. -- Edit this bug report at https://bugs.php.net/bug.php?id=61368&edit=1
Bug #61469 [Opn->Nab]: simplexml_load_file() url encodes file names if they use a stream wrapper
Edit report at https://bugs.php.net/bug.php?id=61469&edit=1 ID: 61469 Updated by: cataphr...@php.net Reported by:saschagros at gmail dot com Summary:simplexml_load_file() url encodes file names if they use a stream wrapper -Status: Open +Status: Not a bug Type: Bug Package:SimpleXML related Operating System: Linux/Windows PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Looks right. URIs cannot contain spaces. See RFC 3986. Previous Comments: [2012-03-21 22:43:03] saschagros at gmail dot com Description: Drupal uses custom stream wrappers for accessing files. Given the file name "$imported_file = 'temporary://translated file.xlf'", the following does not work: $xml = simplexml_load_file($imported_file); It results in the following warning: simplexml_load_file(): I/O warning : failed to load external entity "temporary://translated%20file.xlf" However, this works just fine: $xml_string = file_get_contents($imported_file); $xml = simplexml_load_string($xml_string); -- Edit this bug report at https://bugs.php.net/bug.php?id=61469&edit=1