[PHP-BUG] Bug #60963 [NEW]: undefined normalizer_normalize
From: Operating system: win 7 PHP version: 5.4.0RC6 Package: Unknown/Other Function Bug Type: Bug Bug description:undefined normalizer_normalize Description: Description: 1. use Apache 2.2.21 VC9 2. download http://windows.php.net/downloads/qa/php-5.4.0RC7-Win32-VC9-x86.zip 3. unpack to c:\php5\ 4. rename php.ini-development -> php.ini 5. change php.ini: extension_dir = "c:\php5\ext" extension=php_intl.dll 6. restart apache 7. run any script Test script: --- Expected result: test Actual result: -- Fatal error: Call to undefined function normalizer_normalize() in C:\htdocs\test.pl\1.php on line 2 -- Edit bug report at https://bugs.php.net/bug.php?id=60963&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60963&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60963&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60963&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60963&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60963&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60963&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60963&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60963&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60963&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60963&r=support Expected behavior: https://bugs.php.net/fix.php?id=60963&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60963&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60963&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60963&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60963&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60963&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60963&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60963&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60963&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60963&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60963&r=mysqlcfg
Bug #38021 [Com]: Uncaught exception 'com_exception'
Edit report at https://bugs.php.net/bug.php?id=38021&edit=1
ID: 38021
Comment by: amreshsinghmca at gmail dot com
Reported by:zyablik at insc dot ru
Summary:Uncaught exception 'com_exception'
Status: No Feedback
Type: Bug
Package:COM related
Operating System: XP SP2 IIS onboard
PHP Version:5.1.4
Assigned To:wharmby
Block user comment: N
Private report: N
New Comment:
please tell me how can generate word file using php and mysql. this word file
also include image.
Previous Comments:
[2009-12-24 05:12:02] imyhchou at gmail dot com
This error message happens when trying to instantiate MS WORD on a system with
improper permissions.
You can refer to http://figured-it-out.com/figured-out.php?sid=24 to solve it.
[2007-06-19 13:35:39] klemen at breg dot si
I using this CVS snapshot but i got the same error !
[2007-02-11 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-02-03 16:17:14] whar...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
By well known example I assume you mean something like the
following: http://www.pastebin.ca/338618.
I have tried this example against the latest level of PHP 5.2 and it works
fine. Can you please retry with the latest 5.2 snapshot and re-open the defect
with details of your actual php script if the problem persists.
[2006-07-06 14:58:36] zyablik at insc dot ru
Description:
Fatal Exeption on new COM("Word.Application")
Reproduce code:
---
Very well known example for testing "word.Application" COM object.
my line 13 is:
$word = new COM("Word.Application");
... the same as expected
$word->Documents->Add();
Expected result:
Creation of new test word file.
Actual result:
--
Fatal error: Uncaught exception 'com_exception' with message 'Source:
Microsoft WordDescription: Could not open macro storage.' in
D:\dir\com.php:13 Stack trace: #0 D:\dir\com.php(13): variant->Add() #1 {main}
thrown in D:\dir\com.php on line 13
What does that means?
--
Edit this bug report at https://bugs.php.net/bug.php?id=38021&edit=1
Bug #60933 [Sus->Csd]: Testing asort with SORT_LOCALE_STRING fails on Mac OS X 10.6
Edit report at https://bugs.php.net/bug.php?id=60933&edit=1 ID: 60933 Updated by: ahar...@php.net Reported by:m...@php.net Summary:Testing asort with SORT_LOCALE_STRING fails on Mac OS X 10.6 -Status: Suspended +Status: Closed Type: Bug Package:Arrays related Operating System: Mac OS X 10.6 PHP Version:5.4SVN-2012-01-30 (SVN) Assigned To:aharvey 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. Fixed on 5.4 as well, per private e-mail with Stas. Previous Comments: [2012-02-03 04:17:08] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=323037 Log: Fix bug #60933 on PHP_5_4 (approved by Stas). [2012-02-03 01:21:34] ahar...@php.net Fixed on trunk and 5.3. Pinging stas and dsp re: 5.4. [2012-02-03 01:21:20] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=323036 Log: Fix bug #60933 (Testing asort with SORT_LOCALE_STRING fails on Mac OS X 10.6) on PHP_5_3 and trunk. [2012-02-02 15:29:39] ras...@php.net Looks good, commit. [2012-02-02 14:18:51] j dot jeising at gmail dot com Patch fixed the problem, test passes. 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=60933 -- Edit this bug report at https://bugs.php.net/bug.php?id=60933&edit=1
Bug #55525 [Com]: --enable-zend-multibyte cause Apache exit on signal 10
Edit report at https://bugs.php.net/bug.php?id=55525&edit=1 ID: 55525 Comment by: anoni at mo dot us Reported by:info at ihead dot ru Summary:--enable-zend-multibyte cause Apache exit on signal 10 Status: Open Type: Bug Package:Apache related Operating System: FreeBSD 7.4 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: To reproduce try php from ports, make config with multibyte, then install magento shop 1.6 and keep refreshing... :) Previous Comments: [2012-02-03 01:23:42] anoni at mo dot us Confirm bug happening on php5.3.9 apache 2.2.21 Freebsd8. PHP compiled with zend_multibyte support. pid (httpd), uid 80: exited on signal 11 another simptom in vhost error.log : PHP Fatal error: require_once() Failed opening required '1' (intermittent, file exists and works 90% of the time). Browser gets white screen of death. Refreshing the page will work ok usually. [2011-09-06 03:12:49] info at ihead dot ru It was tested on Apache 1.3.41 and 2.2.19. I will try on another server later. [2011-09-06 02:50:34] larue...@php.net I can not reproduce this in my environ, and your apache seems to be ancient version, could you test with a newer version of it? thanks [2011-09-03 20:04:16] info at ihead dot ru Here is bugtrace php53test# gdb /usr/local/apache/bin/httpd13 /usr/local/apache/httpd13.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `httpd13'. Program terminated with signal 10, Bus error. Reading symbols from /lib/libcrypt.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.4 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/apache/libexec/libphp5.so...done. Loaded symbols for /usr/local/apache/libexec/libphp5.so Reading symbols from /usr/lib/librt.so.1...done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libz.so.4...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /usr/local/lib/libxml2.so.5...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000200802324 in memcmp () from /lib/libc.so.7 (gdb) bt #0 0x000200802324 in memcmp () from /lib/libc.so.7 #1 0x000200f68a05 in zend_mm_check_ptr (heap=0x201e5d000, ptr=0x201e18220, silent=0, __zend_filename=0x201312554 "Zend/zend_language_scanner.l", __zend_lineno=707, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /root/php/php-5.3.8/Zend/zend_alloc.c:1492 #2 0x000200f6853d in zend_mm_check_ptr (heap=0x201e5d000, ptr=0x201e18220, silent=1, __zend_filename=0x201312554 "Zend/zend_language_scanner.l", __zend_lineno=707, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /root/php/php-5.3.8/Zend/zend_alloc.c:1393 #3 0x000200f69f71 in _zend_mm_free_int (heap=0x201e5d000, p=0x201e18220, __zend_filename=0x201312554 "Zend/zend_language_scanner.l", __zend_lineno=707, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /root/php/php-5.3.8/Zend/zend_alloc.c:1993 #4 0x000200f6b611 in _efree (ptr=0x201e18220, __zend_filename=0x201312554 "Zend/zend_language_scanner.l", __zend_lineno=707, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /root/php/php-5.3.8/Zend/zend_alloc.c:2361 #5 0x000200f4a5e7 in zend_multibyte_read_script ( buf=0x2005c9000 "' . \"\\n\" .\n'Reply-To: ad...@ihead.ru' . \"\\r\\n\"\n"..., n=207) at zend_language_scanner.l:707 #6 0x000200f49178 in open_file_for_scanning (file_handle=0x7fffe540) at zend_language_scanner.l:279 #7 0x000200f4947f in compile_file (file_handle=0x7fffe540, type=8) at zend_language_scanner.l:352 #8 0x000200d96842 in phar_compile_file (file_handle=0x7fffe540, type=8) at /root/php/php-5.3.8/ext/phar/phar.c:3393 #9 0x000200f94935 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php/php-5.3.8/Zend/zend.c:1228 #10 0x000200f12872
Bug #55525 [Com]: --enable-zend-multibyte cause Apache exit on signal 10
Edit report at https://bugs.php.net/bug.php?id=55525&edit=1 ID: 55525 Comment by: anoni at mo dot us Reported by:info at ihead dot ru Summary:--enable-zend-multibyte cause Apache exit on signal 10 Status: Open Type: Bug Package:Apache related Operating System: FreeBSD 7.4 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Confirm bug happening on php5.3.9 apache 2.2.21 Freebsd8. PHP compiled with zend_multibyte support. pid (httpd), uid 80: exited on signal 11 another simptom in vhost error.log : PHP Fatal error: require_once() Failed opening required '1' (intermittent, file exists and works 90% of the time). Browser gets white screen of death. Refreshing the page will work ok usually. Previous Comments: [2011-09-06 03:12:49] info at ihead dot ru It was tested on Apache 1.3.41 and 2.2.19. I will try on another server later. [2011-09-06 02:50:34] larue...@php.net I can not reproduce this in my environ, and your apache seems to be ancient version, could you test with a newer version of it? thanks [2011-09-03 20:04:16] info at ihead dot ru Here is bugtrace php53test# gdb /usr/local/apache/bin/httpd13 /usr/local/apache/httpd13.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `httpd13'. Program terminated with signal 10, Bus error. Reading symbols from /lib/libcrypt.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.4 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/apache/libexec/libphp5.so...done. Loaded symbols for /usr/local/apache/libexec/libphp5.so Reading symbols from /usr/lib/librt.so.1...done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libz.so.4...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /usr/local/lib/libxml2.so.5...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000200802324 in memcmp () from /lib/libc.so.7 (gdb) bt #0 0x000200802324 in memcmp () from /lib/libc.so.7 #1 0x000200f68a05 in zend_mm_check_ptr (heap=0x201e5d000, ptr=0x201e18220, silent=0, __zend_filename=0x201312554 "Zend/zend_language_scanner.l", __zend_lineno=707, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /root/php/php-5.3.8/Zend/zend_alloc.c:1492 #2 0x000200f6853d in zend_mm_check_ptr (heap=0x201e5d000, ptr=0x201e18220, silent=1, __zend_filename=0x201312554 "Zend/zend_language_scanner.l", __zend_lineno=707, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /root/php/php-5.3.8/Zend/zend_alloc.c:1393 #3 0x000200f69f71 in _zend_mm_free_int (heap=0x201e5d000, p=0x201e18220, __zend_filename=0x201312554 "Zend/zend_language_scanner.l", __zend_lineno=707, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /root/php/php-5.3.8/Zend/zend_alloc.c:1993 #4 0x000200f6b611 in _efree (ptr=0x201e18220, __zend_filename=0x201312554 "Zend/zend_language_scanner.l", __zend_lineno=707, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /root/php/php-5.3.8/Zend/zend_alloc.c:2361 #5 0x000200f4a5e7 in zend_multibyte_read_script ( buf=0x2005c9000 "' . \"\\n\" .\n'Reply-To: ad...@ihead.ru' . \"\\r\\n\"\n"..., n=207) at zend_language_scanner.l:707 #6 0x000200f49178 in open_file_for_scanning (file_handle=0x7fffe540) at zend_language_scanner.l:279 #7 0x000200f4947f in compile_file (file_handle=0x7fffe540, type=8) at zend_language_scanner.l:352 #8 0x000200d96842 in phar_compile_file (file_handle=0x7fffe540, type=8) at /root/php/php-5.3.8/ext/phar/phar.c:3393 #9 0x000200f94935 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php/php-5.3.8/Zend/zend.c:1228 #10 0x000200f12872 in php_execute_script (primary_file=0x7fffe540) at /root/php/php-5.3.8/main/main.c:2284 #11 0x000201088bcc in apache_php_module_main (r=0x201d8f060, display_source_mode=0) at /root/php/php-5.3.8/sapi/apache/sapi_apache.c:53
Bug #60933 [Asn->Sus]: Testing asort with SORT_LOCALE_STRING fails on Mac OS X 10.6
Edit report at https://bugs.php.net/bug.php?id=60933&edit=1 ID: 60933 Updated by: ahar...@php.net Reported by:m...@php.net Summary:Testing asort with SORT_LOCALE_STRING fails on Mac OS X 10.6 -Status: Assigned +Status: Suspended Type: Bug Package:Arrays related Operating System: Mac OS X 10.6 PHP Version:5.4SVN-2012-01-30 (SVN) Assigned To:aharvey Block user comment: N Private report: N New Comment: Fixed on trunk and 5.3. Pinging stas and dsp re: 5.4. Previous Comments: [2012-02-03 01:21:20] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=323036 Log: Fix bug #60933 (Testing asort with SORT_LOCALE_STRING fails on Mac OS X 10.6) on PHP_5_3 and trunk. [2012-02-02 15:29:39] ras...@php.net Looks good, commit. [2012-02-02 14:18:51] j dot jeising at gmail dot com Patch fixed the problem, test passes. [2012-02-02 04:50:59] ahar...@php.net The following patch has been added/updated: Patch Name: bug-60933-locale-sort-test Revision: 1328158259 URL: https://bugs.php.net/patch-display.php?bug=60933&patch=bug-60933-locale-sort-test&revision=1328158259 [2012-02-02 04:50:40] ahar...@php.net I think this may just be nothing more than the default fr_FR locale selected on OS X nowadays simply being UTF-8 by default these days, which obviously fails to sort an ISO-8859-1 array correctly. Can people who've had this fail try the attached patch and see if it fixes the problem, please? 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=60933 -- Edit this bug report at https://bugs.php.net/bug.php?id=60933&edit=1
Bug #60960 [Opn->Nab]: Wrong number of days.
Edit report at https://bugs.php.net/bug.php?id=60960&edit=1
ID: 60960
Updated by: ahar...@php.net
Reported by:robertosuursoo at yahoo dot com dot br
Summary:Wrong number of days.
-Status: Open
+Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: Ubuntu 11.04 64bits
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Yep, this happens with the Brazil/East time zone, so it's just crossing a DST
boundary: if you look at $interval->h on the last interval, it's 23 hours from
midnight on the 21st to midnight on the 22nd and therefore not a full day.
Previous Comments:
[2012-02-02 22:04:47] ras...@php.net
Unable to reproduce here as well with PHP 5.3.10. Which timezone are you using?
Most likely DST-related.
[2012-02-02 21:42:58] anon at anon dot anon
Obviously some wretched daylight savings issue. Call:
date_default_timezone_set('UTC');
It's the only way to make any programming language's date handling sane.
[2012-02-02 20:15:53] carloschilazo at gmail dot com
I couldnt reproduce the problem, I get a result of 1 on:
$a = new DateTime('2012-10-21');
$b = new DateTime('2012-10-22');
$interval = $a->diff($b);
Tested Ubuntu 11 64 bits also
[2012-02-02 19:48:53] robertosuursoo at yahoo dot com dot br
Description:
The diff function is calculating the wrong number of days.
PHP 5.3.5-1ubuntu7.4 with Suhosin-Patch (cli) (built: Dec 13 2011 18:30:11)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
Test script:
---
TEST
diff($b);
?>
$interval->days:days?>
diff($b);
?>
$interval->days:days?>
diff($b);
?>
$interval->days:days?>
Expected result:
$interval->days:3
$interval->days:2
$interval->days:1
Actual result:
--
$interval->days:3
$interval->days:2
$interval->days:0
--
Edit this bug report at https://bugs.php.net/bug.php?id=60960&edit=1
Bug #60954 [Opn->Wfx]: error_reporting() = 0?
Edit report at https://bugs.php.net/bug.php?id=60954&edit=1
ID: 60954
Updated by: ahar...@php.net
Reported by:aei at riga dot ahlers dot com
Summary:error_reporting() = 0?
-Status: Open
+Status: Wont fix
Type: Bug
Package:PHP options/info functions
Operating System: Gentoo Linux (x86_64-3.1.7)
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
There is actually a good technical reason for this, which is that internally
the @
operator causes PHP to change the error_reporting value. In effect writing this:
@foo(42);
Really means this in effect on an engine level:
old_error_reporting = error_reporting(0);
foo(42);
error_reporting(old_error_reporting);
In theory it would be possible to expose the value of old_error_reporting to
userspace when within a silence operator, but in practice, it would add
complexity
to the engine for little practical gain.
Closing won't fix.
Previous Comments:
[2012-02-02 23:00:24] aei at riga dot ahlers dot com
Well, I am talking about the situations when external error handler is used.
Suppose we want to catch any errors inside our script using a custom error
handler function, but we also want to respect error_reporting settings provided
by the configuration so as to show/log an error or not. Suppose the current
error_reporting level = E_ALL & ~E_DEPRECATED & ~E_NOTICE (22519), Now, inside
our custom error handler function we would need to be logging all errors except
deprecated and notice-level, so as to respect error_reporting setting. It
seems
to be so simple:
function default_error_handler($errtype, $errstr, $errfile, $errline) {
if ((error_reporting() & $errtype) == 0) {
return FALSE; // only handle errors specified by PHP configuration
}
log_write(sprintf('Error: %s in %s at line %u',
$errstr, $errfile, $errline));
...
}
Unfortunately, since error_reporting() returns 0 for calls that were prepended
by a '@', those errors will never get logged as we wanted. Don't you think if
we instruct PHP interpreter that we want to use our own error handler function,
we would also like to control we might want to respect PHP error_reporting
settings when displaying errors? In my opinion, it makes logical sense.
The solution would be if there was a possibility to know that the failed
statement was prepended with '@', so we could know what to do about it in our
custom error handler, while error_reporting() would always return current level
of error reporting?
Andrejs
[2012-02-02 22:30:00] anon at anon dot anon
>Is there any particular reason why error_reporting() should return 0 if the
statement that caused the error was prepended by the @ error-control operator?
Well for one thing it's the quick 'n' dirty way to make the error handler
function be quiet to implement the @ operator, and PHP usually chooses the
quick 'n' dirty route.
I think it's right though. If you're @ing an expression, it's because you want
to ignore errors in it. Such an error shouldn't be printed or logged except
during debugging, because many PHP functions raise an error as part of their
normal operation. Consider a call to fopen: Code is expected to look at the
return value to see if the file opened successfully and handle it as necessary.
In that case, it may not want the fopen error message to be printed/logged,
since the user code may raise its own more specific error, or it might not be
an error at all (if it was merely testing if the file could be opened in the
given mode, or it can handle the intended file operation in another way).
Because @ applies to complete expressions (which can include calls of entire
large functions and everything they do) it's sometimes too aggressive, in which
case you'd want to disable @ by using a custom error handler function. Apart
from that debugging case, when you can easily hard-wire an error reporting
value into the handler function, you shouldn't really need to differentiate
between the base error reporting value and the @ value. I'm curious why you
want to.
[2012-02-02 13:53:29] aei at riga dot ahlers dot com
Description:
---
>From manual page: http://www.php.net/function.set-error-handler#refsect1-
function.set-error-handler-parameters
---
In the manual, it is written:
error_reporting() settings will have no effect and your error handler will be
called regardless - however you are still able to read the current value of
error_reporting and act appropriately. Of particular note is that this value
will be 0 if the statement that caused the error was prepended by the @ error-
control operator.
Is there any particular reaso
Bug #52339 [Nab->ReO]: SPL autoloader breaks class_exists()
Edit report at https://bugs.php.net/bug.php?id=52339&edit=1
ID: 52339
Updated by: frozenf...@php.net
Reported by:dangerous dot ben at gmail dot com
Summary:SPL autoloader breaks class_exists()
-Status: Not a bug
+Status: Re-Opened
Type: Bug
Package:SPL related
Operating System: any (debian)
PHP Version:5.3.3RC2
Block user comment: N
Private report: N
New Comment:
Re-opening, as there still exists the conflict of class_exists() generating an
error when autoloading fails, which is a chicken and the egg sort of issue. If
one wants to try autoloading if the class doesn't exist, but autoloading fails,
it should be possible to recover from that failure.
My understanding of the underlying code is that it generates an error in this
case. Perhaps it should generate an exception, which can be caught an handled.
Previous Comments:
[2010-10-11 21:37:47] james at nearlysensical dot com
I 100% agree with dangerous dot ben. class_exists should return false if the
class
can't be autoloaded. Allowing it to do so would make it much easier to use an
autoloader in contexts where you're interacting with an existing codebase that
may
not be so spl_autoload friendly. Bump.
[2010-07-15 08:18:01] dangerous dot ben at gmail dot com
I beg to differ. As you say, class_exists() attempts to autoload if there
second param is true, but if autoloading fails it should simply return false as
usual rather than throw an exception. Otherwise it is rather useless.
The fact that this only occurs when there isn't another autoloader in the stack
should make it clear that this is a bug. For example, the following code does
not throw an exception:
spl_autoload_register();
spl_autoload_register(function(){});
class_exists('foo\bar');
[2010-07-15 05:11:04] ka...@php.net
You are calling class_exists() with just a class name, which leaves the second
parameter ($autoload) set to true, which then invokes SPL and throws the
exception, so no bug here
[2010-07-14 21:54:08] dangerous dot ben at gmail dot com
On further investigation, it appears that the error is meant to happen only if
spl_autoload is called directly, and not via spl_autoload_call. Unfortunately
when spl_autoload is the only autoloader in the stack it gets called directly
and spl_autoload_call doesn't get a look in.
[2010-07-14 21:31:46] dangerous dot ben at gmail dot com
Description:
Using PHP 5.3 from svn.
When SPL's default autoloader is the only loader in the stack it triggers an
error or throws an exception when it can't find a class. This means that you
get an exception when calling class_exists() for a class that doesn't exist.
This behaviour seems pointless anyway since PHP will trigger its own fatal
error if the class still doesn't exist after attempting to autoload, so the
attached patch simply removes it.
Test script:
---
spl_autoload_register();
class_exists('foo\bar');
Expected result:
No error
Actual result:
--
ben@arctor:~/src/php-5.3$ sapi/cli/php ~/code/cram/test.php
PHP Fatal error: Uncaught exception 'LogicException' with message 'Class
foo\bar could not be loaded' in /home/ben/code/cram/test.php:4
Stack trace:
#0 [internal function]: spl_autoload('foo\bar')
#1 /home/ben/code/cram/test.php(4): class_exists('foo\bar')
#2 {main}
thrown in /home/ben/code/cram/test.php on line 4
--
Edit this bug report at https://bugs.php.net/bug.php?id=52339&edit=1
Bug #60954 [Opn]: error_reporting() = 0?
Edit report at https://bugs.php.net/bug.php?id=60954&edit=1
ID: 60954
User updated by:aei at riga dot ahlers dot com
Reported by:aei at riga dot ahlers dot com
Summary:error_reporting() = 0?
Status: Open
Type: Bug
Package:PHP options/info functions
Operating System: Gentoo Linux (x86_64-3.1.7)
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
Well, I am talking about the situations when external error handler is used.
Suppose we want to catch any errors inside our script using a custom error
handler function, but we also want to respect error_reporting settings provided
by the configuration so as to show/log an error or not. Suppose the current
error_reporting level = E_ALL & ~E_DEPRECATED & ~E_NOTICE (22519), Now, inside
our custom error handler function we would need to be logging all errors except
deprecated and notice-level, so as to respect error_reporting setting. It
seems
to be so simple:
function default_error_handler($errtype, $errstr, $errfile, $errline) {
if ((error_reporting() & $errtype) == 0) {
return FALSE; // only handle errors specified by PHP configuration
}
log_write(sprintf('Error: %s in %s at line %u',
$errstr, $errfile, $errline));
...
}
Unfortunately, since error_reporting() returns 0 for calls that were prepended
by a '@', those errors will never get logged as we wanted. Don't you think if
we instruct PHP interpreter that we want to use our own error handler function,
we would also like to control we might want to respect PHP error_reporting
settings when displaying errors? In my opinion, it makes logical sense.
The solution would be if there was a possibility to know that the failed
statement was prepended with '@', so we could know what to do about it in our
custom error handler, while error_reporting() would always return current level
of error reporting?
Andrejs
Previous Comments:
[2012-02-02 22:30:00] anon at anon dot anon
>Is there any particular reason why error_reporting() should return 0 if the
statement that caused the error was prepended by the @ error-control operator?
Well for one thing it's the quick 'n' dirty way to make the error handler
function be quiet to implement the @ operator, and PHP usually chooses the
quick 'n' dirty route.
I think it's right though. If you're @ing an expression, it's because you want
to ignore errors in it. Such an error shouldn't be printed or logged except
during debugging, because many PHP functions raise an error as part of their
normal operation. Consider a call to fopen: Code is expected to look at the
return value to see if the file opened successfully and handle it as necessary.
In that case, it may not want the fopen error message to be printed/logged,
since the user code may raise its own more specific error, or it might not be
an error at all (if it was merely testing if the file could be opened in the
given mode, or it can handle the intended file operation in another way).
Because @ applies to complete expressions (which can include calls of entire
large functions and everything they do) it's sometimes too aggressive, in which
case you'd want to disable @ by using a custom error handler function. Apart
from that debugging case, when you can easily hard-wire an error reporting
value into the handler function, you shouldn't really need to differentiate
between the base error reporting value and the @ value. I'm curious why you
want to.
[2012-02-02 13:53:29] aei at riga dot ahlers dot com
Description:
---
>From manual page: http://www.php.net/function.set-error-handler#refsect1-
function.set-error-handler-parameters
---
In the manual, it is written:
error_reporting() settings will have no effect and your error handler will be
called regardless - however you are still able to read the current value of
error_reporting and act appropriately. Of particular note is that this value
will be 0 if the statement that caused the error was prepended by the @ error-
control operator.
Is there any particular reason why error_reporting() should return 0 if the
statement that caused the error was prepended by the @ error-control operator?
I mean, if errors are handled by a custom error handler callback set by
set_error_handler(), there is currently no easy way to get current value of
error_reporting(), right? Because inside error handler callback function it
may
just return 0. If we want to log or not log entries into a custom error log
within this callback function depending on the setting of error_reporting,
we're
unable to do so in situations when '@' was used before the statement that
caused
error? We could of course save value of error_reporting() in the beginning of
Bug #60954 [Com]: error_reporting() = 0?
Edit report at https://bugs.php.net/bug.php?id=60954&edit=1 ID: 60954 Comment by: anon at anon dot anon Reported by:aei at riga dot ahlers dot com Summary:error_reporting() = 0? Status: Open Type: Bug Package:PHP options/info functions Operating System: Gentoo Linux (x86_64-3.1.7) PHP Version:5.3.9 Block user comment: N Private report: N New Comment: >Is there any particular reason why error_reporting() should return 0 if the statement that caused the error was prepended by the @ error-control operator? Well for one thing it's the quick 'n' dirty way to make the error handler function be quiet to implement the @ operator, and PHP usually chooses the quick 'n' dirty route. I think it's right though. If you're @ing an expression, it's because you want to ignore errors in it. Such an error shouldn't be printed or logged except during debugging, because many PHP functions raise an error as part of their normal operation. Consider a call to fopen: Code is expected to look at the return value to see if the file opened successfully and handle it as necessary. In that case, it may not want the fopen error message to be printed/logged, since the user code may raise its own more specific error, or it might not be an error at all (if it was merely testing if the file could be opened in the given mode, or it can handle the intended file operation in another way). Because @ applies to complete expressions (which can include calls of entire large functions and everything they do) it's sometimes too aggressive, in which case you'd want to disable @ by using a custom error handler function. Apart from that debugging case, when you can easily hard-wire an error reporting value into the handler function, you shouldn't really need to differentiate between the base error reporting value and the @ value. I'm curious why you want to. Previous Comments: [2012-02-02 13:53:29] aei at riga dot ahlers dot com Description: --- >From manual page: http://www.php.net/function.set-error-handler#refsect1- function.set-error-handler-parameters --- In the manual, it is written: error_reporting() settings will have no effect and your error handler will be called regardless - however you are still able to read the current value of error_reporting and act appropriately. Of particular note is that this value will be 0 if the statement that caused the error was prepended by the @ error- control operator. Is there any particular reason why error_reporting() should return 0 if the statement that caused the error was prepended by the @ error-control operator? I mean, if errors are handled by a custom error handler callback set by set_error_handler(), there is currently no easy way to get current value of error_reporting(), right? Because inside error handler callback function it may just return 0. If we want to log or not log entries into a custom error log within this callback function depending on the setting of error_reporting, we're unable to do so in situations when '@' was used before the statement that caused error? We could of course save value of error_reporting() in the beginning of our script to a global variable and use it from within the error call back function, but why? Thanks, Andrejs -- Edit this bug report at https://bugs.php.net/bug.php?id=60954&edit=1
Bug #60960 [Opn]: Wrong number of days.
Edit report at https://bugs.php.net/bug.php?id=60960&edit=1
ID: 60960
Updated by: ras...@php.net
Reported by:robertosuursoo at yahoo dot com dot br
Summary:Wrong number of days.
Status: Open
Type: Bug
Package:Date/time related
Operating System: Ubuntu 11.04 64bits
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Unable to reproduce here as well with PHP 5.3.10. Which timezone are you using?
Most likely DST-related.
Previous Comments:
[2012-02-02 21:42:58] anon at anon dot anon
Obviously some wretched daylight savings issue. Call:
date_default_timezone_set('UTC');
It's the only way to make any programming language's date handling sane.
[2012-02-02 20:15:53] carloschilazo at gmail dot com
I couldnt reproduce the problem, I get a result of 1 on:
$a = new DateTime('2012-10-21');
$b = new DateTime('2012-10-22');
$interval = $a->diff($b);
Tested Ubuntu 11 64 bits also
[2012-02-02 19:48:53] robertosuursoo at yahoo dot com dot br
Description:
The diff function is calculating the wrong number of days.
PHP 5.3.5-1ubuntu7.4 with Suhosin-Patch (cli) (built: Dec 13 2011 18:30:11)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
Test script:
---
TEST
diff($b);
?>
$interval->days:days?>
diff($b);
?>
$interval->days:days?>
diff($b);
?>
$interval->days:days?>
Expected result:
$interval->days:3
$interval->days:2
$interval->days:1
Actual result:
--
$interval->days:3
$interval->days:2
$interval->days:0
--
Edit this bug report at https://bugs.php.net/bug.php?id=60960&edit=1
Bug #35057 [Com]: abstract method inheritance and interface implementation problem
Edit report at https://bugs.php.net/bug.php?id=35057&edit=1 ID: 35057 Comment by: lsm...@php.net Reported by:antonsub at pochtamt dot ru Summary:abstract method inheritance and interface implementation problem Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.1.0RC4 Block user comment: N Private report: N New Comment: see #43200 Previous Comments: [2005-11-01 21:53:46] he...@php.net 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 B::foo is not A::foo, so when C inherits B it gets B::foo and when it implements A it gets A:foo, obviously A::foo and B::foo are different. That\'s what the error tells you. [2005-11-01 21:12:39] antonsub at pochtamt dot ru Description: Code given produces fatal error: Can't inherit abstract function A::foo() (previously declared abstract in B) in foo.php on line 20 Reproduce code: --- Expected result: But is expected to run cleanly. -- Edit this bug report at https://bugs.php.net/bug.php?id=35057&edit=1
Bug #41145 [Com]: Interface, Abstract Class & Methods
Edit report at https://bugs.php.net/bug.php?id=41145&edit=1
ID: 41145
Comment by: lsm...@php.net
Reported by:gerald at copix dot org
Summary:Interface, Abstract Class & Methods
Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: Linux
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
see #43200
Previous Comments:
[2007-04-21 20:56:07] he...@php.net
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
This kind of inhereitance trickery is only useful and working in languages that
support MI and there you need to have the leave class reimplement the method or
explicitly use one of the base class\' implementation regardless of whether you
provide new code or not. This is the case because both the abstract class and
the interface are two independant origins of the method. Thus they are
considered different. What you can do instead is having a basic interface that
only contains the shared method. Doing so is absolutely correct because as you
say they are the same protocol entity. And if you were not able to ürovide a
shared base for them, than indeed the methods are different.
[2007-04-20 08:00:05] gerald at copix dot org
Description:
When we want to implement an interface in a child class that extends an
abstract class that contains an abstract method that is in the interface, we
get an error.
This kind of bug has already been submited in #35057 and was marked as bogus
because AClasse::show obviously is not the same as IClasse::show.
But in the code we only say that IClasse::show is the same as
AClasseConcrete::show.
To me, the IClasse should not care how AClasseConcrete manage to implements the
interface. The important thing is that AClasseConcrete::show IS the same as
IClasse::show.
I've checked the documentation and was not able to find this exact case and
I've try this concept in other langages (like Java) with success.
I think at least it should be discussed.
If it has been discussed already, I'm really sorry for the time I made you
spent on this.
Greatings
Reproduce code:
---
interface IClasse {
public function show ();
}
abstract class AClasse {
abstract public function show ();
}
class AClasseConcrete extends AClasse implements IClasse {
public function show (){
echo "Everything is ok";
}
}
$classe = new AClasseConcrete ();
$classe->show ();
Expected result:
"Everything is ok"
Actual result:
--
Fatal error: Can't inherit abstract function IClasse::show() (previously
declared abstract in AClasse) in
/home/geraldc/workspace/Copix_3/www/syntax_playground.php
--
Edit this bug report at https://bugs.php.net/bug.php?id=41145&edit=1
Bug #60960 [Com]: Wrong number of days.
Edit report at https://bugs.php.net/bug.php?id=60960&edit=1
ID: 60960
Comment by: anon at anon dot anon
Reported by:robertosuursoo at yahoo dot com dot br
Summary:Wrong number of days.
Status: Open
Type: Bug
Package:Date/time related
Operating System: Ubuntu 11.04 64bits
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Obviously some wretched daylight savings issue. Call:
date_default_timezone_set('UTC');
It's the only way to make any programming language's date handling sane.
Previous Comments:
[2012-02-02 20:15:53] carloschilazo at gmail dot com
I couldnt reproduce the problem, I get a result of 1 on:
$a = new DateTime('2012-10-21');
$b = new DateTime('2012-10-22');
$interval = $a->diff($b);
Tested Ubuntu 11 64 bits also
[2012-02-02 19:48:53] robertosuursoo at yahoo dot com dot br
Description:
The diff function is calculating the wrong number of days.
PHP 5.3.5-1ubuntu7.4 with Suhosin-Patch (cli) (built: Dec 13 2011 18:30:11)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
Test script:
---
TEST
diff($b);
?>
$interval->days:days?>
diff($b);
?>
$interval->days:days?>
diff($b);
?>
$interval->days:days?>
Expected result:
$interval->days:3
$interval->days:2
$interval->days:1
Actual result:
--
$interval->days:3
$interval->days:2
$interval->days:0
--
Edit this bug report at https://bugs.php.net/bug.php?id=60960&edit=1
[PHP-BUG] Bug #60961 [NEW]: Graceful Restart (USR2) isn't very graceful
From: Operating system: Debian Squeeze PHP version: 5.3.9 Package: FPM related Bug Type: Bug Bug description:Graceful Restart (USR2) isn't very graceful Description: I just compiled a new PHP+APC with the CVE-2012-0830 fix. It looks like all/some of the the active requests died. I had the same problem when upgrading to 5.3.8 and 5.3.9 too. # cat /var/log/nginx/error.log *empty* # cat /var/run/php-fpm.pid 2161 # ps aux | fgrep -i 2161 root 2161 0.1 0.2 123692 4520 ?Ss 06:28 0:00 php-fpm: master process (/opt/php/etc/php-fpm.conf) # kill -USR2 2161 # cat /var/log/nginx/error.log 2012/02/02 21:08:26 [error] 25004#0: *7381002 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7381001 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7372696 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7381238 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7374985 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7369723 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7360478 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7371999 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7375111 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7381000 readv() failed (104: Connection reset by peer) while reading upstream, client: xx.xx.xx.xx, server: XXX This gives 502 Bad Gateway on the client. -- Edit bug report at https://bugs.php.net/bug.php?id=60961&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60961&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60961&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60961&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60961&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60961&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60961&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60961&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60961&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60961&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60961&r=support Expected behavior: https://bugs.php.net/fix.php?id=60961&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60961&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60961&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60961&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60961&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60961&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60961&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60961&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60961&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60961&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60961&r=mysqlcfg
Bug #60960 [Com]: Wrong number of days.
Edit report at https://bugs.php.net/bug.php?id=60960&edit=1
ID: 60960
Comment by: carloschilazo at gmail dot com
Reported by:robertosuursoo at yahoo dot com dot br
Summary:Wrong number of days.
Status: Open
Type: Bug
Package:Date/time related
Operating System: Ubuntu 11.04 64bits
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I couldnt reproduce the problem, I get a result of 1 on:
$a = new DateTime('2012-10-21');
$b = new DateTime('2012-10-22');
$interval = $a->diff($b);
Tested Ubuntu 11 64 bits also
Previous Comments:
[2012-02-02 19:48:53] robertosuursoo at yahoo dot com dot br
Description:
The diff function is calculating the wrong number of days.
PHP 5.3.5-1ubuntu7.4 with Suhosin-Patch (cli) (built: Dec 13 2011 18:30:11)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
Test script:
---
TEST
diff($b);
?>
$interval->days:days?>
diff($b);
?>
$interval->days:days?>
diff($b);
?>
$interval->days:days?>
Expected result:
$interval->days:3
$interval->days:2
$interval->days:1
Actual result:
--
$interval->days:3
$interval->days:2
$interval->days:0
--
Edit this bug report at https://bugs.php.net/bug.php?id=60960&edit=1
Bug #60925 [Opn]: fpm_atomic.h says unknown processor (m68k)
Edit report at https://bugs.php.net/bug.php?id=60925&edit=1
ID: 60925
User updated by:tg at debian dot org
Reported by:tg at debian dot org
Summary:fpm_atomic.h says unknown processor (m68k)
Status: Open
Type: Bug
Package:FPM related
Operating System: Linux
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
OK; in the meantime Iâll try building without FPM, to see whether there are
any other lurking issues on m68k. Thanks for the help with this.
Previous Comments:
[2012-01-31 00:50:00] ahar...@php.net
Thanks again. It's been good to triage this down. :)
I'll let Jérôme figure out what he wants to do here, since he's the FPM
maintainer. I think your list of options pretty much covers it.
[2012-01-31 00:39:53] tg at debian dot org
Heh, your comment made me go and read the old changelogs
of the Debian package on a guess, and I guessed right:
php5 (5.3.5-1) unstable; urgency=low
* Build the FPM SAPI (Closes: #603174)
So this was simply never built before. Now there are two
possibilities, disable FPM on m68k (unless gcc-4.7 or up
is used) or ask the m68k porters for an implementation
of the atomic things. I think. If youâve got a better
idea, do tell.
By the way, thereâs libatomic-ops-dev, which contains a
number of atomic primitives and composed operations on a
number of data types (but the catch is, youâve got to use
the data types of libatomic-ops-dev, not e.g. like mesa
have a function atomic_dec which is passed an int32_t*
so itâs not a plug-in replacement. That might be more
interesting than hacking in m68k support now, and support
for $next_arch laterâ¦
m68k atomic operations apparently have another twist: the
compare-and-swap operation only exists on some processors,
and not in the Coldfire line, so the Linux kernel got a
syscall now to ensure atomicity. GCC 4.7 uses the syscall;
most âinlinedâ application code doesnâtâ¦
[2012-01-31 00:06:52] ahar...@php.net
Ah, I didn't know that, so no, no need on the vanilla tarball front. Thanks!
The fix here would be a patch for fpm_atomic.h implementing the same atomic
functions for m68k as the other fallback platforms in there, such as x86 and
SPARC
v9. I'm not actually sure why 5.3.3-7 built at all, actually -- the only patch
it
had over stock 5.3.3 (which had no support at all for m68k) was implementing
support for __sync_bool_compare_and_swap() if it existed, so it should have
failed
with the same #error. Interesting.
[2012-01-30 16:52:13] tg at debian dot org
configure:12302: checking if gcc supports __sync_bool_compare_and_swap
configure:12319: m68k-linux-gnu-gcc -o conftest -O2 -Wall -fsigned-char
-fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -gstabs
-fvisibility=hidden conftest.c -lrt >&5
/tmp/ccmCFUbp.o: In function `main':
conftest.c:48: undefined reference to `__sync_bool_compare_and_swap_4'
conftest.c:49: undefined reference to `__sync_add_and_fetch_4'
collect2: ld returned 1 exit status
configure:12319: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define __EXTENSIONS__ 1
| #define _ALL_SOURCE 1
| #define _GNU_SOURCE 1
| #define _POSIX_PTHREAD_SEMANTICS 1
| #define _TANDEM_SOURCE 1
| #define HAVE_DEV_URANDOM 1
| #define HAVE_SETENV 1
| #define HAVE_CLEARENV 1
| #define HAVE_ERRNO_H 1
| #define HAVE_FCNTL_H 1
| #define HAVE_STDIO_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_SYS_UIO_H 1
| #define HAVE_SYS_SELECT_H 1
| #define HAVE_SYS_SOCKET_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_ARPA_INET_H 1
| #define HAVE_NETINET_IN_H 1
| #define HAVE_PRCTL 1
| #define HAVE_CLOCK_GETTIME 1
| #define HAVE_PTRACE 1
| #define PROC_MEM_FILE "mem"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| int variable = 1;
| return (__sync_bool_compare_and_swap(&variable, 1, 2)
|&& __sync_add_and_fetch(&variable, 1)) ? 1 : 0;
|
| ;
| return 0;
| }
configure:12329: result: no
[2012-01-30 16:39:04] tg at debian dot org
gcc version 4.6.2 (Debian 4.6.2-12)
I know for sure it does NOT support __sync_* atomic builtins;
on m68k, gc
[PHP-BUG] Bug #60960 [NEW]: Wrong number of days.
From: Operating system: Ubuntu 11.04 64bits PHP version: Irrelevant Package: Date/time related Bug Type: Bug Bug description:Wrong number of days. Description: The diff function is calculating the wrong number of days. PHP 5.3.5-1ubuntu7.4 with Suhosin-Patch (cli) (built: Dec 13 2011 18:30:11) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans Test script: --- TEST diff($b); ?> $interval->days:days?> diff($b); ?> $interval->days:days?> diff($b); ?> $interval->days:days?> Expected result: $interval->days:3 $interval->days:2 $interval->days:1 Actual result: -- $interval->days:3 $interval->days:2 $interval->days:0 -- Edit bug report at https://bugs.php.net/bug.php?id=60960&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60960&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60960&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60960&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60960&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60960&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60960&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60960&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60960&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60960&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60960&r=support Expected behavior: https://bugs.php.net/fix.php?id=60960&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60960&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60960&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60960&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60960&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60960&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60960&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60960&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60960&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60960&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60960&r=mysqlcfg
Bug #36248 [Com]: CURLOPT_HEADERFUNCTION, couldn't set the function in the class (works in 5.1)
Edit report at https://bugs.php.net/bug.php?id=36248&edit=1
ID: 36248
Comment by: brian at ontodevelopment dot com
Reported by:Admin at relax-info dot com
Summary:CURLOPT_HEADERFUNCTION, couldn't set the function in
the class (works in 5.1)
Status: Closed
Type: Bug
Package:cURL related
Operating System: WIN XP SP2
PHP Version:4.4.2
Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
http://ontodevelopment.blogspot.com/2011/04/curloptheaderfunction-tutorial-with.html
Previous Comments:
[2007-01-12 16:38:46] il...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2006-02-13 19:49:26] tony2...@php.net
Assigned to the maintainer.
[2006-02-02 19:59:10] Admin at relax-info dot com
Ok, I then shall install MSVC6 and other debug packs.
Now I give you the reference to my class with an example.
Server: Apache/1.3.31 (Win32) PHP/4.4.2
X-Powered-By: PHP/4.4.2
Transfer-Encoding: chunked
http://relax-info.com/data/file/curl.class.php.rar - example and class
With best regards, X-MAN :)
[2006-02-01 21:18:06] tony2...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Works perfectly fine here.
[2006-02-01 17:55:12] Admin at relax-info dot com
I am truncate all comment from my class and delete other method than not assign
with problem
url = $url;
}
function init()
{
$this->_ch = curl_init();
// ...
}
function execute()
{
// defauukt setup
curl_setopt($this->_ch, CURLOPT_URL, $this->url);
// HEADER
if ($this->header)
{
curl_setopt($this->_ch, CURLOPT_HEADER, true);
curl_setopt($this->_ch, CURLOPT_HEADERFUNCTION,
array($this, '_header_callback');
}
// exec
$result = curl_exec($this->_ch);
// ..
return $result;
}
function _header_callback($ch, $header)
{
return strlen($header);
}
}
// EXAMPLE -
$url = 'http://www.relax-info.com';
$curl = new CURL($url);
if ($curl->init())
{
$curl->returntransfer = true;
$curl->header = true;
$result = $curl->execute();
print_r($result);
}
else echo $curl->get_error();
?>
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=36248
--
Edit this bug report at https://bugs.php.net/bug.php?id=36248&edit=1
[PHP-BUG] Req #60957 [NEW]: if function returns false on error, don't emit a warning
From:
Operating system:
PHP version: Irrelevant
Package: Filesystem function related
Bug Type: Feature/Change Request
Bug description:if function returns false on error, don't emit a warning
Description:
functions that return FALSE on error should not also emit a warning.
Example: filemtime(). it is sufficient to check if the file exists and
retrieve the mtime by doing:
if ($mtime = filemtime()) {
echo date('ymd', $mtime);
} else {
echo 'file does not exist';
}
supressing the warning with "@" is slow and generates an error in the log
(also slow). checking if the file exists before retrieving the mtime is
also wasteful.
Expected result:
filemtime and other functions that emit a warning on error when false is
also returned should not emit a warning.
--
Edit bug report at https://bugs.php.net/bug.php?id=60957&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60957&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60957&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60957&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60957&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60957&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60957&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60957&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60957&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60957&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60957&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60957&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60957&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60957&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60957&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60957&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60957&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60957&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60957&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60957&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60957&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60957&r=mysqlcfg
Bug #60933 [Asn]: Testing asort with SORT_LOCALE_STRING fails on Mac OS X 10.6
Edit report at https://bugs.php.net/bug.php?id=60933&edit=1 ID: 60933 Updated by: ras...@php.net Reported by:m...@php.net Summary:Testing asort with SORT_LOCALE_STRING fails on Mac OS X 10.6 Status: Assigned Type: Bug Package:Arrays related Operating System: Mac OS X 10.6 PHP Version:5.4SVN-2012-01-30 (SVN) Assigned To:aharvey Block user comment: N Private report: N New Comment: Looks good, commit. Previous Comments: [2012-02-02 14:18:51] j dot jeising at gmail dot com Patch fixed the problem, test passes. [2012-02-02 04:50:59] ahar...@php.net The following patch has been added/updated: Patch Name: bug-60933-locale-sort-test Revision: 1328158259 URL: https://bugs.php.net/patch-display.php?bug=60933&patch=bug-60933-locale-sort-test&revision=1328158259 [2012-02-02 04:50:40] ahar...@php.net I think this may just be nothing more than the default fr_FR locale selected on OS X nowadays simply being UTF-8 by default these days, which obviously fails to sort an ISO-8859-1 array correctly. Can people who've had this fail try the attached patch and see if it fixes the problem, please? [2012-02-02 00:55:36] j dot jeising at gmail dot com Only failed test for me too (Mac OS X 10.6.8). Any environment specific details we could provide to reproduce this? (LANG="de_DE.UTF-8", LC_CTYPE="en_US.UTF-8") [2012-02-01 19:32:31] ras...@php.net I just ran it on an Ubuntu 11.10 box and it passed. So then it is environment- specific somehow. 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=60933 -- Edit this bug report at https://bugs.php.net/bug.php?id=60933&edit=1
Bug #55737 [Com]: LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio
Edit report at https://bugs.php.net/bug.php?id=55737&edit=1 ID: 55737 Comment by: stefan dot kaifer at hartmann dot info Reported by:stefan dot kaifer at hartmann dot info Summary:LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio Status: Feedback Type: Bug Package:MySQL related Operating System: opensuse 11.0 PHP Version:5.3.8 Assigned To:mysql Block user comment: N Private report: N New Comment: Hi sorry for the late answer: 5.3.4 worked for me, 5.3.4 to 5.3.7 I don't tested! 5.3.8 and 5.3.9 dont't works for me. I've compiled all versions with the same "configure"-parameters. I hope, that somebody can solve the problem. Best reguards Stefan Previous Comments: [2011-10-25 19:21:14] richardpq at gmail dot com I haven't test this functionality before, this is the first time that I tested it. @Stefan point that it was working before and now not, but I don't know which version he use... At the moment I am testing locally so I can put the files in my mysql data directory and it works, but I don't know, what I will do when I have to upload to the server since is not a private server. [2011-10-25 18:53:41] and...@php.net Which is the last version of 5.3 which worked for you? [2011-10-25 18:36:30] richardpq at gmail dot com and...@php.net, Neither 5.3snv and 5.3.8 snv work, the same problem [2011-10-21 11:20:24] and...@php.net Can you try 5.3-svn? Altough the NEWS entry mentions 5.4 the fix has landed in 5.3 too (committed on Sep 2). 5.3.8 was released on Aug 23rd. [2011-10-20 13:29:11] richardpq at gmail dot com "Some bug fix is planned for PHP 5.4", what is that mean? no solution for php 5.3? I would prefer a solution for this version, rather than wait for the final release of the new version, testing and see if it not affect others thing. 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=55737 -- Edit this bug report at https://bugs.php.net/bug.php?id=55737&edit=1
Bug #60933 [Com]: Testing asort with SORT_LOCALE_STRING fails on Mac OS X 10.6
Edit report at https://bugs.php.net/bug.php?id=60933&edit=1 ID: 60933 Comment by: j dot jeising at gmail dot com Reported by:m...@php.net Summary:Testing asort with SORT_LOCALE_STRING fails on Mac OS X 10.6 Status: Assigned Type: Bug Package:Arrays related Operating System: Mac OS X 10.6 PHP Version:5.4SVN-2012-01-30 (SVN) Assigned To:aharvey Block user comment: N Private report: N New Comment: Patch fixed the problem, test passes. Previous Comments: [2012-02-02 04:50:59] ahar...@php.net The following patch has been added/updated: Patch Name: bug-60933-locale-sort-test Revision: 1328158259 URL: https://bugs.php.net/patch-display.php?bug=60933&patch=bug-60933-locale-sort-test&revision=1328158259 [2012-02-02 04:50:40] ahar...@php.net I think this may just be nothing more than the default fr_FR locale selected on OS X nowadays simply being UTF-8 by default these days, which obviously fails to sort an ISO-8859-1 array correctly. Can people who've had this fail try the attached patch and see if it fixes the problem, please? [2012-02-02 00:55:36] j dot jeising at gmail dot com Only failed test for me too (Mac OS X 10.6.8). Any environment specific details we could provide to reproduce this? (LANG="de_DE.UTF-8", LC_CTYPE="en_US.UTF-8") [2012-02-01 19:32:31] ras...@php.net I just ran it on an Ubuntu 11.10 box and it passed. So then it is environment- specific somehow. [2012-02-01 17:49:59] carloschilazo at gmail dot com I think its not related to MAC OSX, test failed php5.4-201202011630 ubuntu 11.10 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=60933 -- Edit this bug report at https://bugs.php.net/bug.php?id=60933&edit=1
[PHP-BUG] Bug #60955 [NEW]: spl_autoload_register() accept a protected method
From:
Operating system: Linux
PHP version: 5.3.9
Package: SPL related
Bug Type: Bug
Bug description:spl_autoload_register() accept a protected method
Description:
It's possible to register a protected method as an autoloader callback with
the function spl_autoload_register().
Test script:
---
register();
$autoloadFunctions = spl_autoload_functions();
foreach ($autoloadFunctions as $autoloadFunction)
{
spl_autoload_unregister($autoloadFunction);
}
foreach ($autoloadFunctions as $autoloadFunction)
{
spl_autoload_register($autoloadFunction);
}
Expected result:
Cannot register the protected method autoload::requireClass() as a callback
Actual result:
--
Passed array does not specify a callable method (cannot access protected
method autoloader::requireClass())
--
Edit bug report at https://bugs.php.net/bug.php?id=60955&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60955&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60955&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60955&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60955&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60955&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60955&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60955&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60955&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60955&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60955&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60955&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60955&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60955&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60955&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60955&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60955&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60955&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60955&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60955&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60955&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60955&r=mysqlcfg
[PHP-BUG] Bug #60954 [NEW]: error_reporting() = 0?
From: Operating system: Gentoo Linux (x86_64-3.1.7) PHP version: 5.3.9 Package: PHP options/info functions Bug Type: Bug Bug description:error_reporting() = 0? Description: --- >From manual page: http://www.php.net/function.set-error-handler#refsect1- function.set-error-handler-parameters --- In the manual, it is written: error_reporting() settings will have no effect and your error handler will be called regardless - however you are still able to read the current value of error_reporting and act appropriately. Of particular note is that this value will be 0 if the statement that caused the error was prepended by the @ error- control operator. Is there any particular reason why error_reporting() should return 0 if the statement that caused the error was prepended by the @ error-control operator? I mean, if errors are handled by a custom error handler callback set by set_error_handler(), there is currently no easy way to get current value of error_reporting(), right? Because inside error handler callback function it may just return 0. If we want to log or not log entries into a custom error log within this callback function depending on the setting of error_reporting, we're unable to do so in situations when '@' was used before the statement that caused error? We could of course save value of error_reporting() in the beginning of our script to a global variable and use it from within the error call back function, but why? Thanks, Andrejs -- Edit bug report at https://bugs.php.net/bug.php?id=60954&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60954&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60954&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60954&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60954&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60954&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60954&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60954&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60954&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60954&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60954&r=support Expected behavior: https://bugs.php.net/fix.php?id=60954&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60954&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60954&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60954&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60954&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60954&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60954&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60954&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60954&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60954&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60954&r=mysqlcfg
[PHP-BUG] Bug #60953 [NEW]: Bug adding file extension using convertToExecutable()
From:
Operating system: Linux dev 2.6.32-042stab016.1 #1
PHP version: 5.4.0RC6
Package: PHAR related
Bug Type: Bug
Bug description:Bug adding file extension using convertToExecutable()
Description:
When using convertToExecutable() to add compression to an existing phar
archive,
if the original phar name contains full stops . the new phar.tar.gz
extension is
added to early.
eg;
proem-0.1.2.phar
becomes:
proem-0.phar.tar.gz
Test script:
---
#!/usr/bin/env php
buildFromDirectory('lib');
$phar->setStub("registerNamespaces(['Proem' =>
'lib'])->register();
__HALT_COMPILER();
?>");
$phar->convertToExecutable(Phar::TAR, Phar::GZ);
Expected result:
thorpe@dev[~/src/proem][master]+ ls -l build/
total 76
-rw-r--r-- 1 thorpe thorpe 64006 Feb 2 23:53 proem-0.1.2.phar
-rw-r--r-- 1 thorpe thorpe 8523 Feb 2 23:53 proem-0.1.2.phar.tar.gz
Actual result:
--
thorpe@dev[~/src/proem][master]+ ls -l build/
total 76
-rw-r--r-- 1 thorpe thorpe 64006 Feb 2 23:53 proem-0.1.2.phar
-rw-r--r-- 1 thorpe thorpe 8523 Feb 2 23:53 proem-0.phar.tar.gz
--
Edit bug report at https://bugs.php.net/bug.php?id=60953&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60953&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60953&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60953&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60953&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60953&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60953&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60953&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60953&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60953&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60953&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60953&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60953&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60953&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60953&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60953&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60953&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60953&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60953&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60953&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60953&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60953&r=mysqlcfg
Bug #60708 [Asn->Csd]: segmentation fault, use max_input_vars
Edit report at https://bugs.php.net/bug.php?id=60708&edit=1
ID: 60708
Updated by: dmi...@php.net
Reported by:masugata at gmail dot com
Summary:segmentation fault, use max_input_vars
-Status: Assigned
+Status: Closed
Type: Bug
Package:*General Issues
Operating System: x86_64 GNU/Linux
PHP Version:5.3.9
Assigned To:dmitry
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.
Previous Comments:
[2012-02-02 09:12:32] larue...@php.net
The following patch has been added/updated:
Patch Name: memleak_fix_for_bug60708
Revision: 1328173952
URL:
https://bugs.php.net/patch-display.php?bug=60708&patch=memleak_fix_for_bug60708&revision=1328173952
[2012-02-02 09:02:16] paj...@php.net
Assign to Dmitry as he is working on that now.
[2012-02-02 08:58:46] larue...@php.net
fix for leaks referred by Pierre:
--- php_variables.c (revision 323011)
+++ php_variables.c (working copy)
@@ -187,6 +187,10 @@
array_init(gpc_element);
zend_symtable_update(symtable1,
escaped_index, index_len + 1, &gpc_element, sizeof(zval *), (void **)
&gpc_element_p);
} else {
+ if (index != escaped_index) {
+ efree(escaped_index);
+ }
+ zval_dtor(val);
free_alloca(var_orig, use_heap);
return;
}
[2012-02-02 08:00:21] huzaifas at redhat dot com
Is this bug fixed by the following svn commit?
http://svn.php.net/viewvc?view=revision&revision=323007
[2012-02-02 07:55:42] paj...@php.net
Are you sure the fix is complete? There are leaks afaik.
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=60708
--
Edit this bug report at https://bugs.php.net/bug.php?id=60708&edit=1
Bug #60951 [Opn]: PHP-FPM leaks memory, crashes randomly
Edit report at https://bugs.php.net/bug.php?id=60951&edit=1
ID: 60951
User updated by:vytenis dot darulis at gmail dot com
Reported by:vytenis dot darulis at gmail dot com
Summary:PHP-FPM leaks memory, crashes randomly
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Debian testing
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
Sample process memory map - http://darulis.lt/memorymap.txt
Previous Comments:
[2012-02-01 23:25:02] vytenis dot darulis at gmail dot com
Uploaded the script that is indicated in the backtrace at
http://darulis.lt/segf.txt
[2012-02-01 23:17:03] vytenis dot darulis at gmail dot com
Re-read "generating a backtrace" instructions on php.net, will update with more
information as it turns out, a single script is responsible for those segfaults.
[2012-02-01 23:04:29] vytenis dot darulis at gmail dot com
Description:
PHP-FPM crashes on restart (after ~12+ hours of runtime), virtual image size is
always much larger than it should be (have to set request- building with --
enable-debug and report_memleaks=On reports a lot of memory leaks.
(gdb) bt
#0 0x00619b3d in do_bind_function (opline=0x7f7f186ba960,
function_table=0x1115c50, compile_time=0 '\000')
at /usr/src/php-5.3.9/Zend/zend_compile.c:2973
#1 0x00654b7c in ZEND_DECLARE_FUNCTION_SPEC_HANDLER (
execute_data=0x13be1c0) at /usr/src/php-5.3.9/Zend/zend_vm_execute.h:586
#2 0x0065490b in execute (op_array=0x14526c0)
at /usr/src/php-5.3.9/Zend/zend_vm_execute.h:107
#3 0x006329c9 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php-5.3.9/Zend/zend.c:1236
#4 0x005dfa8c in php_execute_script (primary_file=0x7fff185f3ef0)
at /usr/src/php-5.3.9/main/main.c:2308
#5 0x00429028 in main (argc=20419800, argv=0x0)
at /usr/src/php-5.3.9/sapi/fpm/fpm/fpm_main.c:1858
#0 0x00619b3d in do_bind_function (opline=0x7f7f186ba960,
function_table=0x1115c50, compile_time=0 '\000')
at /usr/src/php-5.3.9/Zend/zend_compile.c:2973
function = 0xdc32e0
#1 0x00654b7c in ZEND_DECLARE_FUNCTION_SPEC_HANDLER (
execute_data=0x13be1c0) at /usr/src/php-5.3.9/Zend/zend_vm_execute.h:586
No locals.
#2 0x0065490b in execute (op_array=0x14526c0)
at /usr/src/php-5.3.9/Zend/zend_vm_execute.h:107
ret =
execute_data = 0x13be1c0
nested = 1 '\001'
original_in_execution = 0 '\000'
#3 0x006329c9 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php-5.3.9/Zend/zend.c:1236
files = {{gp_offset = 40, fp_offset = 32639,
overflow_arg_area = 0x7fff185ef8c0,
reg_save_area = 0x7fff185ef850}}
i =
file_handle = 0x7fff185f3ef0
orig_op_array = 0x0
orig_retval_ptr_ptr = 0x0
#4 0x005dfa8c in php_execute_script (primary_file=0x7fff185f3ef0)
---Type to continue, or q to quit---
at /usr/src/php-5.3.9/main/main.c:2308
realfile = " \021_\030\377\177", '\000' ,
"B\367\bZ\177\177\000\000\001\000\000\000\177\177\000\000\001\000\000\000\000\00
0\000\000\310+GP\177\177\000\000\001\000\000\000\000\000\000\000\001\000\000\000
\000\000\000\000Ð7\001\000\000\000\000\200\t_\030\377\177\000\000\206n\250X\177\
177\000\000\240\t_\030\377\177\000\000\000\000\000\000\000\000\000\000\001\000\0
00\000\000\000\000\000\177\352k\000\000\000\000\000\067\370\002\000\000\000\000\
000\300\033_\030\377\177\000\000\000\000\000\000\000\000\000\000\327tl\000\000\0
00\000\000\067\370\002\000\000\000\000\000&6\f\000\000\000\000\000\300\033_\030\
377\177\000\000\365\317k", '\000' ,
"\001\005\000\001\000\000\000\000
\223\067\001\000\000\000\000\300\033_\030\377\177\000\000\217\331k\000\000\000\0
00\000\200+\334\000\000\000\000\000\240"...
__orig_bailout = 0x7fff185f3c10
__bailout = {{__jmpbuf = {14430336, -6770098422908330243, 0, 20419800,
20419368, 0, -6770098428205736195, 6770589603805781757},
__mask_was_saved = 0, __saved_mask = {__val = {0, 0, 0, 0,
20281744, 1, 20505256, 20419368, 0, 7418177, 140184908713798,
14429056, 140733602283248, 14429056, 20423224, 20505256
prepend_file_p =
append_file_p = 0x0
prepend_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0,
opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {
handle = 0x0, isatty = 0, mmap = {len = 0, pos = 0, map = 0x0,
---Type to continue, or q to quit---
buf = 0x0, old_handle = 0x0, old_closer = 0}, reader = 0,
Bug #60708 [PATCH]: segmentation fault, use max_input_vars
Edit report at https://bugs.php.net/bug.php?id=60708&edit=1
ID: 60708
Patch added by: larue...@php.net
Reported by:masugata at gmail dot com
Summary:segmentation fault, use max_input_vars
Status: Assigned
Type: Bug
Package:*General Issues
Operating System: x86_64 GNU/Linux
PHP Version:5.3.9
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: memleak_fix_for_bug60708
Revision: 1328173952
URL:
https://bugs.php.net/patch-display.php?bug=60708&patch=memleak_fix_for_bug60708&revision=1328173952
Previous Comments:
[2012-02-02 09:02:16] paj...@php.net
Assign to Dmitry as he is working on that now.
[2012-02-02 08:58:46] larue...@php.net
fix for leaks referred by Pierre:
--- php_variables.c (revision 323011)
+++ php_variables.c (working copy)
@@ -187,6 +187,10 @@
array_init(gpc_element);
zend_symtable_update(symtable1,
escaped_index, index_len + 1, &gpc_element, sizeof(zval *), (void **)
&gpc_element_p);
} else {
+ if (index != escaped_index) {
+ efree(escaped_index);
+ }
+ zval_dtor(val);
free_alloca(var_orig, use_heap);
return;
}
[2012-02-02 08:00:21] huzaifas at redhat dot com
Is this bug fixed by the following svn commit?
http://svn.php.net/viewvc?view=revision&revision=323007
[2012-02-02 07:55:42] paj...@php.net
Are you sure the fix is complete? There are leaks afaik.
[2012-02-02 07:29:21] s...@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.
Thanks, should be fine in current SVN.
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=60708
--
Edit this bug report at https://bugs.php.net/bug.php?id=60708&edit=1
Bug #60708 [Csd->Asn]: segmentation fault, use max_input_vars
Edit report at https://bugs.php.net/bug.php?id=60708&edit=1
ID: 60708
Updated by: paj...@php.net
Reported by:masugata at gmail dot com
Summary:segmentation fault, use max_input_vars
-Status: Closed
+Status: Assigned
Type: Bug
Package:*General Issues
Operating System: x86_64 GNU/Linux
PHP Version:5.3.9
-Assigned To:stas
+Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
Assign to Dmitry as he is working on that now.
Previous Comments:
[2012-02-02 08:58:46] larue...@php.net
fix for leaks referred by Pierre:
--- php_variables.c (revision 323011)
+++ php_variables.c (working copy)
@@ -187,6 +187,10 @@
array_init(gpc_element);
zend_symtable_update(symtable1,
escaped_index, index_len + 1, &gpc_element, sizeof(zval *), (void **)
&gpc_element_p);
} else {
+ if (index != escaped_index) {
+ efree(escaped_index);
+ }
+ zval_dtor(val);
free_alloca(var_orig, use_heap);
return;
}
[2012-02-02 08:00:21] huzaifas at redhat dot com
Is this bug fixed by the following svn commit?
http://svn.php.net/viewvc?view=revision&revision=323007
[2012-02-02 07:55:42] paj...@php.net
Are you sure the fix is complete? There are leaks afaik.
[2012-02-02 07:29:21] s...@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.
Thanks, should be fine in current SVN.
[2012-02-02 05:58:45] nickg at client9 dot com
Confirmed. Input could be a=1 v[]=2. Last arg past max_input_var just needs to
be array-like. Test file could be a EMPTY FILE. Does not need to be CLI but
any
SAPI source.
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=60708
--
Edit this bug report at https://bugs.php.net/bug.php?id=60708&edit=1
Bug #60708 [Csd]: segmentation fault, use max_input_vars
Edit report at https://bugs.php.net/bug.php?id=60708&edit=1
ID: 60708
Updated by: larue...@php.net
Reported by:masugata at gmail dot com
Summary:segmentation fault, use max_input_vars
Status: Closed
Type: Bug
Package:*General Issues
Operating System: x86_64 GNU/Linux
PHP Version:5.3.9
Assigned To:stas
Block user comment: N
Private report: N
New Comment:
fix for leaks referred by Pierre:
--- php_variables.c (revision 323011)
+++ php_variables.c (working copy)
@@ -187,6 +187,10 @@
array_init(gpc_element);
zend_symtable_update(symtable1,
escaped_index, index_len + 1, &gpc_element, sizeof(zval *), (void **)
&gpc_element_p);
} else {
+ if (index != escaped_index) {
+ efree(escaped_index);
+ }
+ zval_dtor(val);
free_alloca(var_orig, use_heap);
return;
}
Previous Comments:
[2012-02-02 08:00:21] huzaifas at redhat dot com
Is this bug fixed by the following svn commit?
http://svn.php.net/viewvc?view=revision&revision=323007
[2012-02-02 07:55:42] paj...@php.net
Are you sure the fix is complete? There are leaks afaik.
[2012-02-02 07:29:21] s...@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.
Thanks, should be fine in current SVN.
[2012-02-02 05:58:45] nickg at client9 dot com
Confirmed. Input could be a=1 v[]=2. Last arg past max_input_var just needs to
be array-like. Test file could be a EMPTY FILE. Does not need to be CLI but
any
SAPI source.
[2012-01-11 07:04:35] masugata at gmail dot com
Description:
segmentation fault, use max_input_vars
$ gdb /tmp/php-5.3.9/sapi/cgi/php-cgi
(gdb) run -d max_input_vars=1 /tmp/cgitest.php a[]=1 v[]=2
Starting program: /tmp/php-5.3.9/sapi/cgi/php-cgi -d max_input_vars=1
/tmp/cgitest.php a[]=1 v[]=2
warning: no loadable sections found in added symbol-file system-supplied DSO at
0x2aaab000
[Thread debugging using libthread_db enabled]
Unknown(0) : Warning - Unknown: Input variables exceeded 1. To increase the
limit change max_input_vars in php.ini.
Unknown(0) : Warning - Unknown: Input variables exceeded 1. To increase the
limit change max_input_vars in php.ini.
Unknown(0) : Warning - Unknown: Input variables exceeded 1. To increase the
limit change max_input_vars in php.ini.
Program received signal SIGSEGV, Segmentation fault.
0x0077ba65 in php_register_variable_ex (var_name=0xfe6618 "v[]",
val=0x7fffc100, track_vars_array=0xfe5eb8)
at /tmp/php-5.3.9/main/php_variables.c:207
207 symtable1 = Z_ARRVAL_PP(gpc_element_p);
(gdb) bt
#0 0x0077ba65 in php_register_variable_ex (var_name=0xfe6618 "v[]",
val=0x7fffc100, track_vars_array=0xfe5eb8)
at /tmp/php-5.3.9/main/php_variables.c:207
#1 0x005886d9 in php_sapi_filter (arg=1, var=0xfe6618 "v[]",
val=0x7fffc1c0, val_len=1, new_val_len=0x7fffc1b4)
at /tmp/php-5.3.9/ext/filter/filter.c:461
#2 0x0077c6ca in php_default_treat_data (arg=1, str=0x0,
destArray=0x0)
at /tmp/php-5.3.9/main/php_variables.c:408
#3 0x0077d5b0 in php_hash_environment () at /tmp/php-
5.3.9/main/php_variables.c:716
#4 0x00769448 in php_request_startup () at /tmp/php-
5.3.9/main/main.c:1468
#5 0x008d0438 in main (argc=6, argv=0x7fffe928) at /tmp/php-
5.3.9/sapi/cgi/cgi_main.c:2035
Test script:
---
https://bugs.php.net/bug.php?id=60708&edit=1
Bug #60928 [Opn->Fbk]: php crash after http post without content type header set
Edit report at https://bugs.php.net/bug.php?id=60928&edit=1 ID: 60928 Updated by: cataphr...@php.net Reported by:bardobakker at gmail dot com Summary:php crash after http post without content type header set -Status: Open +Status: Feedback Type: Bug Package:Apache2 related Operating System: Linux PHP Version:5.3.9 Block user comment: N Private report: N Previous Comments: [2012-02-02 08:46:57] cataphr...@php.net You can disable mbstring by commenting out the "extension=mbstring.so" line from the configuration file and restarting Apache (and then confirm "mbstring" doesn't show up in phpinfo()). [2012-01-31 22:31:09] bardobakker at gmail dot com php.ini has the default mbstring options = everything commented out mbstring.ini has only the line: extension=mbstring.so In a local .htaccess file I added: php_value mbstring.http_input pass php_value mbstring.http_output pass php_value mbstring.encoding_translation 0 which doesn't change anything in the output of phpinfo() How would you disable mbstring? Can it have something to do with mime type stuff or so? Output phpinfo: http://www.mymoza.com/tup/info.php [2012-01-31 21:54:31] cataphr...@php.net I can't reproduce the error. Could you try disabling mbstring? And if, after disabling mbstring, there's no segfault, please tell us your configuration for mbstring.* ini options (those active for the script that receives the POST request). [2012-01-31 21:04:01] bardobakker at gmail dot com Hi, First of all, a surprising header in tcp dump (for me), I thought content type was not set, but: POST /tup/up.php HTTP/1.1 Content-Length: 1038349 Connection: Keep-Alive Accept-Encoding: gzip Accept-Language: nl-NL,en,* User-Agent: Mozilla/5.0 Host: www.mymoza.com Content-Type: application/x-www-form-urlencoded URL of tcpdump (libpcap format): http://www.mymoza.com/tup/tcpdump.data URL of test image: http://www.mymoza.com/tup/image.jpg With the following headers set no seg. fault will occur: POST /tup/up.php HTTP/1.1 Content-Type: image/jpeg Content-Length: 1038349 Connection: Keep-Alive Accept-Encoding: gzip Accept-Language: nl-NL,en,* User-Agent: Mozilla/5.0 Host: www.mymoza.com [2012-01-31 06:36:10] paj...@php.net Can you post a link to the data you use to upload? Please try to do a tcpdump as well on the client side to see what you send actually and post a link to the dump here as well. We still cannot reproduce it, even with large data. 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=60928 -- Edit this bug report at https://bugs.php.net/bug.php?id=60928&edit=1
Bug #60928 [Opn]: php crash after http post without content type header set
Edit report at https://bugs.php.net/bug.php?id=60928&edit=1 ID: 60928 Updated by: cataphr...@php.net Reported by:bardobakker at gmail dot com Summary:php crash after http post without content type header set Status: Open Type: Bug Package:Apache2 related Operating System: Linux PHP Version:5.3.9 Block user comment: N Private report: N New Comment: You can disable mbstring by commenting out the "extension=mbstring.so" line from the configuration file and restarting Apache (and then confirm "mbstring" doesn't show up in phpinfo()). Previous Comments: [2012-01-31 22:31:09] bardobakker at gmail dot com php.ini has the default mbstring options = everything commented out mbstring.ini has only the line: extension=mbstring.so In a local .htaccess file I added: php_value mbstring.http_input pass php_value mbstring.http_output pass php_value mbstring.encoding_translation 0 which doesn't change anything in the output of phpinfo() How would you disable mbstring? Can it have something to do with mime type stuff or so? Output phpinfo: http://www.mymoza.com/tup/info.php [2012-01-31 21:54:31] cataphr...@php.net I can't reproduce the error. Could you try disabling mbstring? And if, after disabling mbstring, there's no segfault, please tell us your configuration for mbstring.* ini options (those active for the script that receives the POST request). [2012-01-31 21:04:01] bardobakker at gmail dot com Hi, First of all, a surprising header in tcp dump (for me), I thought content type was not set, but: POST /tup/up.php HTTP/1.1 Content-Length: 1038349 Connection: Keep-Alive Accept-Encoding: gzip Accept-Language: nl-NL,en,* User-Agent: Mozilla/5.0 Host: www.mymoza.com Content-Type: application/x-www-form-urlencoded URL of tcpdump (libpcap format): http://www.mymoza.com/tup/tcpdump.data URL of test image: http://www.mymoza.com/tup/image.jpg With the following headers set no seg. fault will occur: POST /tup/up.php HTTP/1.1 Content-Type: image/jpeg Content-Length: 1038349 Connection: Keep-Alive Accept-Encoding: gzip Accept-Language: nl-NL,en,* User-Agent: Mozilla/5.0 Host: www.mymoza.com [2012-01-31 06:36:10] paj...@php.net Can you post a link to the data you use to upload? Please try to do a tcpdump as well on the client side to see what you send actually and post a link to the dump here as well. We still cannot reproduce it, even with large data. [2012-01-30 20:04:01] bardobakker at gmail dot com 1 - Forgot to mention, I need to post a big file. For example a image larger than 5MB. If I post for example a small xml file everything works fine. 2 - I tried to reproduce with the following php script, but everything seems to work here; strange. Maybe the feature is in Qt, which I can rule out since everything used to work, and after upgrade to php 5.3.9 the behaviour started. array( 'method' => 'POST', 'content' => $data )); // Create a streams context $ctx = stream_context_create($params); // Do post $url = "http://www.server.com/post.php";; $fp = @fopen($url, 'rb', false, $ctx); if(!$fp) echo "Problem with $url, $php_errormsg"; // Read response $response = @stream_get_contents($fp); if($response === false) echo "Problem reading data from $url, $php_errormsg"; // Echo response echo $response; ?> 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=60928 -- Edit this bug report at https://bugs.php.net/bug.php?id=60928&edit=1
Bug #60708 [Com]: segmentation fault, use max_input_vars
Edit report at https://bugs.php.net/bug.php?id=60708&edit=1 ID: 60708 Comment by: huzaifas at redhat dot com Reported by:masugata at gmail dot com Summary:segmentation fault, use max_input_vars Status: Closed Type: Bug Package:*General Issues Operating System: x86_64 GNU/Linux PHP Version:5.3.9 Assigned To:stas Block user comment: N Private report: N New Comment: Is this bug fixed by the following svn commit? http://svn.php.net/viewvc?view=revision&revision=323007 Previous Comments: [2012-02-02 07:55:42] paj...@php.net Are you sure the fix is complete? There are leaks afaik. [2012-02-02 07:29:21] s...@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. Thanks, should be fine in current SVN. [2012-02-02 05:58:45] nickg at client9 dot com Confirmed. Input could be a=1 v[]=2. Last arg past max_input_var just needs to be array-like. Test file could be a EMPTY FILE. Does not need to be CLI but any SAPI source. [2012-01-11 07:04:35] masugata at gmail dot com Description: segmentation fault, use max_input_vars $ gdb /tmp/php-5.3.9/sapi/cgi/php-cgi (gdb) run -d max_input_vars=1 /tmp/cgitest.php a[]=1 v[]=2 Starting program: /tmp/php-5.3.9/sapi/cgi/php-cgi -d max_input_vars=1 /tmp/cgitest.php a[]=1 v[]=2 warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaab000 [Thread debugging using libthread_db enabled] Unknown(0) : Warning - Unknown: Input variables exceeded 1. To increase the limit change max_input_vars in php.ini. Unknown(0) : Warning - Unknown: Input variables exceeded 1. To increase the limit change max_input_vars in php.ini. Unknown(0) : Warning - Unknown: Input variables exceeded 1. To increase the limit change max_input_vars in php.ini. Program received signal SIGSEGV, Segmentation fault. 0x0077ba65 in php_register_variable_ex (var_name=0xfe6618 "v[]", val=0x7fffc100, track_vars_array=0xfe5eb8) at /tmp/php-5.3.9/main/php_variables.c:207 207 symtable1 = Z_ARRVAL_PP(gpc_element_p); (gdb) bt #0 0x0077ba65 in php_register_variable_ex (var_name=0xfe6618 "v[]", val=0x7fffc100, track_vars_array=0xfe5eb8) at /tmp/php-5.3.9/main/php_variables.c:207 #1 0x005886d9 in php_sapi_filter (arg=1, var=0xfe6618 "v[]", val=0x7fffc1c0, val_len=1, new_val_len=0x7fffc1b4) at /tmp/php-5.3.9/ext/filter/filter.c:461 #2 0x0077c6ca in php_default_treat_data (arg=1, str=0x0, destArray=0x0) at /tmp/php-5.3.9/main/php_variables.c:408 #3 0x0077d5b0 in php_hash_environment () at /tmp/php- 5.3.9/main/php_variables.c:716 #4 0x00769448 in php_request_startup () at /tmp/php- 5.3.9/main/main.c:1468 #5 0x008d0438 in main (argc=6, argv=0x7fffe928) at /tmp/php- 5.3.9/sapi/cgi/cgi_main.c:2035 Test script: --- https://bugs.php.net/bug.php?id=60708&edit=1
