Bug #61467 [Fbk-Opn]: New callable typehint does not work (autoloading)
Edit report at https://bugs.php.net/bug.php?id=61467edit=1
ID: 61467
Updated by: vr...@php.net
Reported by:david at grudl dot com
Summary:New callable typehint does not work (autoloading)
-Status: Feedback
+Status: Open
Type: Bug
Package:Class/Object related
PHP Version:5.4.0
Block user comment: N
Private report: N
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=61467edit=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=61469edit=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=61469edit=1
Bug #61368 [Opn-Csd]: Upstream tarball includes cruft (*.orig and autom4te.cache)
Edit report at https://bugs.php.net/bug.php?id=61368edit=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 smalys...@sugarcrm.com wrote: On Mon, Mar 12, 2012 at 23:11, Christopher Jones christopher.jo...@oracle.com 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=61368edit=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=61471edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61471r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61471r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61471r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61471r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61471r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61471r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61471r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61471r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61471r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61471r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61471r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61471r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61471r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61471r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61471r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61471r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61471r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61471r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61471r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61471r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61471r=mysqlcfg
Bug #61345 [Opn-Csd]: CGI mode - make install don't work
Edit report at https://bugs.php.net/bug.php?id=61345edit=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=61345edit=1
Bug #53294 [Fbk-Csd]: DateTime-setTimezone() very slow far future dates
Edit report at https://bugs.php.net/bug.php?id=53294edit=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=53294edit=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: --- ?php echo(Result with date()); echo(date(l)); ? -- Edit bug report at https://bugs.php.net/bug.php?id=61472edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61472r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61472r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61472r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61472r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61472r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61472r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61472r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61472r=needscript Try newer version: https://bugs.php.net/fix.php?id=61472r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61472r=support Expected behavior: https://bugs.php.net/fix.php?id=61472r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61472r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61472r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61472r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61472r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61472r=dst IIS Stability: https://bugs.php.net/fix.php?id=61472r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61472r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61472r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61472r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61472r=mysqlcfg
Bug #61472 [Opn]: cannot use date function in mips64
Edit report at https://bugs.php.net/bug.php?id=61472edit=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=value optimized out, tzdb=value optimized out) 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=value optimized out, this_ptr=value optimized out, return_value_used=value optimized out, 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=value optimized out) 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: --- ?php echo(Result with date()); echo(date(l)); ? -- Edit this bug report at https://bugs.php.net/bug.php?id=61472edit=1
Bug #61437 [Opn-Nab]: Illegal stub for phar
Edit report at https://bugs.php.net/bug.php?id=61437edit=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: --- ?php $phar-setStub( ?php __HALT_COMPILER( ); ); Expected result: Works Actual result: -- Fatal error: Uncaught exception 'PharException' with message 'illegal stub for phar /tmp/foo.phar' in /tmp/compile.php:21 -- Edit this bug report at https://bugs.php.net/bug.php?id=61437edit=1
Bug #61423 [Asn-Csd]: gzip compression fails
Edit report at https://bugs.php.net/bug.php?id=61423edit=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=61423edit=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=61469edit=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=61469edit=1
Bug #61470 [Com]: session_regenerate_id() do not create session file
Edit report at https://bugs.php.net/bug.php?id=61470edit=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=61470edit=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=61469edit=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=61469edit=1
Bug #61423 [Csd-Asn]: gzip compression fails
Edit report at https://bugs.php.net/bug.php?id=61423edit=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=61423edit=1
[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 : «
[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=61476edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61476r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61476r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61476r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61476r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61476r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61476r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61476r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61476r=needscript Try newer version: https://bugs.php.net/fix.php?id=61476r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61476r=support Expected behavior: https://bugs.php.net/fix.php?id=61476r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61476r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61476r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61476r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61476r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61476r=dst IIS Stability: https://bugs.php.net/fix.php?id=61476r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61476r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61476r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61476r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61476r=mysqlcfg
Bug #61468 [Com]: ext/phar/tests/phar_oo_005.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61468edit=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=61468patch=phar_oo_005.phpt.diffrevision=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=61468edit=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=61480edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61480r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61480r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61480r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61480r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61480r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61480r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61480r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61480r=needscript Try newer version: https://bugs.php.net/fix.php?id=61480r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61480r=support Expected behavior: https://bugs.php.net/fix.php?id=61480r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61480r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61480r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61480r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61480r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61480r=dst IIS Stability: https://bugs.php.net/fix.php?id=61480r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61480r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61480r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61480r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61480r=mysqlcfg
Bug #61480 [PATCH]: test bug - ext/gd/tests/bug48555.phpt
Edit report at https://bugs.php.net/bug.php?id=61480edit=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=61480patch=bug48555revision=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=61480edit=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=61481edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61481r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61481r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61481r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61481r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61481r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61481r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61481r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61481r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61481r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61481r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61481r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61481r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61481r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61481r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61481r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61481r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61481r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61481r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61481r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61481r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61481r=mysqlcfg
Bug #61481 [PATCH]: Test Bug - ext/com_dotnet/tests/bug49192
Edit report at https://bugs.php.net/bug.php?id=61481edit=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=61481patch=bug49192revision=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=61481edit=1
Bug #60332 [Com]: timezone_abbreviations_list() returns incorrect time offset
Edit report at https://bugs.php.net/bug.php?id=60332edit=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=60332edit=1
Bug #60332 [Opn]: timezone_abbreviations_list() returns incorrect time offset
Edit report at https://bugs.php.net/bug.php?id=60332edit=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=60332edit=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=61482edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61482r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61482r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61482r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61482r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61482r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61482r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61482r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61482r=needscript Try newer version: https://bugs.php.net/fix.php?id=61482r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61482r=support Expected behavior: https://bugs.php.net/fix.php?id=61482r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61482r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61482r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61482r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61482r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61482r=dst IIS Stability: https://bugs.php.net/fix.php?id=61482r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61482r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61482r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61482r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61482r=mysqlcfg
Bug #61482 [Com]: php-cli crashes during 'nmake snap'
Edit report at https://bugs.php.net/bug.php?id=61482edit=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):
?php
// FYI: nmake snap runs mkdist.php with these args
//
// c:\php-sdk\git\php-srcC:\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.dllno
// 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=61482edit=1
Bug #61482 [Com]: php-cli crashes during 'nmake snap'
Edit report at https://bugs.php.net/bug.php?id=61482edit=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):
?php
// FYI: nmake snap runs mkdist.php with these args
//
// c:\php-sdk\git\php-srcC:\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.dllno
// 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=61482edit=1
Bug #60332 [Opn-Nab]: timezone_abbreviations_list() returns incorrect time offset
Edit report at https://bugs.php.net/bug.php?id=60332edit=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
[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=61484edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61484r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61484r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61484r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61484r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61484r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61484r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61484r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61484r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61484r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61484r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61484r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61484r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61484r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61484r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61484r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61484r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61484r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61484r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61484r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61484r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61484r=mysqlcfg
Bug #61474 [Opn-Fbk]: Compile failure with OCI8 - instantclient 11.2
Edit report at https://bugs.php.net/bug.php?id=61474edit=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 #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=61485edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61485r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61485r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61485r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61485r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61485r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61485r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61485r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61485r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61485r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61485r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61485r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61485r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61485r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61485r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61485r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61485r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61485r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61485r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61485r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61485r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61485r=mysqlcfg
Bug #61485 [Com]: rename('..', '..') doesn't report a warning
Edit report at https://bugs.php.net/bug.php?id=61485edit=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=61485edit=1
Req #49914 [Com]: DateInterval doesn't implement comparison functions
Edit report at https://bugs.php.net/bug.php?id=49914edit=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:
---
?php
$ten = new DateInterval('PT10S');
$twenty = new DateInterval('PT20S');
var_dump($ten $twenty);
?
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=49914edit=1
Bug #61482 [Opn]: php-cli crashes during 'nmake snap'
Edit report at https://bugs.php.net/bug.php?id=61482edit=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):
?php
// FYI: nmake snap runs mkdist.php with these args
//
// c:\php-sdk\git\php-srcC:\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.dllno
// 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=61482edit=1
Bug #61467 [Opn-Fbk]: New callable typehint does not work (autoloading)
Edit report at https://bugs.php.net/bug.php?id=61467edit=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=61467edit=1
Bug #61482 [Opn]: php-cli crashes during 'nmake snap'
Edit report at https://bugs.php.net/bug.php?id=61482edit=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):
?php
// FYI: nmake snap runs mkdist.php with these args
//
// c:\php-sdk\git\php-srcC:\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.dllno
// 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=61482edit=1
Bug #61482 [Opn]: php-cli crashes during 'nmake snap'
Edit report at https://bugs.php.net/bug.php?id=61482edit=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.dllno
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):
?php
// FYI: nmake snap runs mkdist.php with these args
//
// c:\php-sdk\git\php-srcC:\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.dllno
// 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=61482edit=1
Bug #61482 [Opn]: php-cli crashes during 'nmake snap'
Edit report at https://bugs.php.net/bug.php?id=61482edit=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.dllno
[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):
?php
// FYI: nmake snap runs mkdist.php with these args
//
// c:\php-sdk\git\php-srcC:\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.dllno
// 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=61482edit=1
Bug #61418 [Csd-ReO]: Segmentation foult using FiltesystemIterator RegexIterator
Edit report at https://bugs.php.net/bug.php?id=61418edit=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 quot;- Fixed bug #61418 (Segmentation fault when DirectoryIterator's orquot; - 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 quot;- Fixed bug #61418 (Segmentation fault when DirectoryIterator's orquot; - 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 quot;- Fixed bug #61418 (Segmentation fault when DirectoryIterator's orquot; - 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=revisionamp;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=61418edit=1
