Bug #61068 [Fbk->Nab]: Regexp crashes http server
Edit report at https://bugs.php.net/bug.php?id=61068&edit=1 ID: 61068 Updated by: paj...@php.net Reported by:bald at epf dot pl Summary:Regexp crashes http server -Status: Feedback +Status: Not a bug Type: Bug Package:PCRE related Operating System: Windows 7 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: It is not something PHP is responsible for. The stacksize of Apache is too small, it works in PHP's cli because PHP builds have a larger default stacksize. You can increase it using this config option: http://httpd.apache.org/docs/2.2/mod/mpm_common.html#ThreadStackSize or change the default stacksize of the Apache binaries: http://msdn.microsoft.com/en-us/library/xd3shwhf.aspx Previous Comments: [2012-02-15 00:57:08] ahar...@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 for me, too. I don't think we can really progress this without a backtrace. [2012-02-13 11:37:25] bald at epf dot pl Apache version: 2.2.22 I downloaded thread safe version of PHP. Works fine when I use command line: php test.php [2012-02-13 10:43:55] bald at epf dot pl Sorry, it's Windows 7. Apache logs does not really say anything. This regular expression just kills my httpd.exe proccess. Works fine without character < at the begining of the $string variable. [2012-02-13 09:01:19] ras...@php.net I was unable to reproduce any sort of Apache crash with this code on Linux. Are you really on XP? What does it say in your Apache logs? [2012-02-13 08:53:02] bald at epf dot pl Description: Regular expression crashes http server. It's all because character < at the beginning of te string. Test script: --- )|[^/>])*)(/?>)~', $string, $matches); ?> Expected result: Blank page. Actual result: -- Apache fails. -- Edit this bug report at https://bugs.php.net/bug.php?id=61068&edit=1
Bug->Req #61126 [Nab]: associative array syntax
Edit report at https://bugs.php.net/bug.php?id=61126&edit=1
ID: 61126
Updated by: ras...@php.net
Reported by:cornelius dot howl at gmail dot com
Summary:associative array syntax
Status: Not a bug
-Type: Bug
+Type: Feature/Change Request
Package:*General Issues
Operating System: Any
PHP Version:5.4.0RC7
Block user comment: N
Private report: N
New Comment:
People are just as apt to make mistakes in key names as they are in hash names.
$_SERVER['REQUEST_URL'] when you meant to check $_SERVER['REQUEST_URI'], for
example. So I don't agree there is no value in a notice on trying to access an
array element that hasn't been defined.
I don't disagree with the notion of having a clean operator that you can use
explicitly on undefined array elements. We have a number of functions that are
specifically aimed at these. This is a valid feature request.
Previous Comments:
[2012-02-22 06:44:54] cornelius dot howl at gmail dot com
Making new function to handle undefined key makes code slow. function call is
really slow in PHP, and wrapping with a function makes code ugly.
I mean, an undefined hash should throw an error or notice (the behavior is
right).
but when using an undefined key from a defined hash, PHP should not throw an
error.
[2012-02-18 11:45:03] ni...@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
You access an undefined index so you obviously get a notice, nothing will
change about that.
If you want, you can define a function like
function getWithDefault(&$var, $default = null) {
return isset($var) ? $var : $default;
}
$abc = getWithDefault($def['abc'], 'ghi');
[2012-02-17 17:54:01] cornelius dot howl at gmail dot com
Description:
When using undefined $args['method'] this should not throw an error, instead,
it
should return undef or null.
In Perl or Ruby, Python, we usually write:
$value = $hash{key} || 'default value';
But in PHP, we have to write such code, that's such inefficient:
$value = isset($hash['key']) ? $hash['key'] : 'default';
Yes, we can use '@', but the '@' makes PHP runs more slower.
It will be better if we can have the following syntax:
$value = $hash['key'] || 'default value';
so that if you have multiple hashes:
$value = $hash['key'] || $hash2['key'] || $hash3['key'] || 'last value';
then we don't have to write:
$value = isset($hash['key']) ? $hash['key'] : isset($hash2['key']) ?
$hash2['key'] : $hash2['key'] # whatever
Thanks
--
Edit this bug report at https://bugs.php.net/bug.php?id=61126&edit=1
Bug #61126 [Nab]: associative array syntax
Edit report at https://bugs.php.net/bug.php?id=61126&edit=1
ID: 61126
User updated by:cornelius dot howl at gmail dot com
Reported by:cornelius dot howl at gmail dot com
Summary:associative array syntax
Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: Any
PHP Version:5.4.0RC7
Block user comment: N
Private report: N
New Comment:
Making new function to handle undefined key makes code slow. function call is
really slow in PHP, and wrapping with a function makes code ugly.
I mean, an undefined hash should throw an error or notice (the behavior is
right).
but when using an undefined key from a defined hash, PHP should not throw an
error.
Previous Comments:
[2012-02-18 11:45:03] ni...@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
You access an undefined index so you obviously get a notice, nothing will
change about that.
If you want, you can define a function like
function getWithDefault(&$var, $default = null) {
return isset($var) ? $var : $default;
}
$abc = getWithDefault($def['abc'], 'ghi');
[2012-02-17 17:54:01] cornelius dot howl at gmail dot com
Description:
When using undefined $args['method'] this should not throw an error, instead,
it
should return undef or null.
In Perl or Ruby, Python, we usually write:
$value = $hash{key} || 'default value';
But in PHP, we have to write such code, that's such inefficient:
$value = isset($hash['key']) ? $hash['key'] : 'default';
Yes, we can use '@', but the '@' makes PHP runs more slower.
It will be better if we can have the following syntax:
$value = $hash['key'] || 'default value';
so that if you have multiple hashes:
$value = $hash['key'] || $hash2['key'] || $hash3['key'] || 'last value';
then we don't have to write:
$value = isset($hash['key']) ? $hash['key'] : isset($hash2['key']) ?
$hash2['key'] : $hash2['key'] # whatever
Thanks
--
Edit this bug report at https://bugs.php.net/bug.php?id=61126&edit=1
Bug #50688 [Com]: Using exceptions inside usort() callback function causes a warning
Edit report at https://bugs.php.net/bug.php?id=50688&edit=1 ID: 50688 Comment by: eric_haney at yahoo dot com Reported by:jcampbell at remindermedia dot com Summary:Using exceptions inside usort() callback function causes a warning Status: Assigned Type: Bug Package:Arrays related Operating System: Fedora Core 12 PHP Version:5.*, 6 Assigned To:stas Block user comment: N Private report: N New Comment: It took me a while to figure out that some code called from usort was throwing, catching, and (gracefully) handling an Exception. Then I found this post. Quite frustrating. I turned off warnings with ini_set before calling usort, then turned them on again after. This is an effective workaround for now, but I'd love to clean that nastiness out of my code. It is also my opinion that usort should be allowed to change the elements in the array. EG: an instance variable of an object may be lazy-loaded as a result of a method call from within a usort callback. Should a warning really be issued in that case? Previous Comments: [2011-10-10 21:44:56] poehler at interworx dot com This bug is still present as of PHP 5.3.8, we ran into it today and spent most of a day trying to figure out what was causing the error message "Array was modified by the user comparison function", when CLEARLY, NOTHING was changing the array at all! The exception was not thrown/caught directly in the usort function but rather in a constructor of a class that was called about 3 or 4 functions deep from the usort, making it very difficult to track down. After finally figuring out the exception was somehow related, we searched google and found this bug report. I'm sure we can agree that the minor act of catching an exception should not result in usort throwing a warning message. This bug is a huge timewaster :( [2010-10-07 23:34:54] philipwhiuk at hotmail dot com I notice this is still affecting PHP 5.3.3 (Windows/Apache install). Is this likely to be fixed soon - is it a question of developer time and priority or is it too difficult to fix? It's quite irritating - I realise that the obvious solution is to avoid throwing the exception (ha-ha) but it's a useful function and exceptions are... inevitable. [2010-05-31 17:24:05] ajrattink at correct dot net I printed a debug line from my usort callback. It called debug_backtrace() to print the line and sourcefile in the debuglog. And therefor triggered the error. Even more, it did not sort. Maybe the phpmanual should state that usort() callbacks are not allowed to write loglines. I also think that usort() callbacks that DO change the array are perfectly legal, as long as they don't change the sort. Maybe your sorter code needs stackoverflow protection or whatever, but calling certain code 'invalid', because it causes your code to SEGV is a stupid way to solve a bug. [2010-04-01 02:12:52] s...@php.net The reason seems to be that when making exception backtrace, debug_backtrace_get_args() uses SEPARATE_ZVAL_TO_MAKE_IS_REF() on arguments, which makes it look as if the argument was indeed modified (which usort is designed to protect against, since cmp callback is not supposed to modify the arguments) [2010-03-05 17:41:30] bernie at dcbl dot ca affects gentoo builds after > 5.2.10 (5.2.11, 5.2.11-r1, and 5.2.12) 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=50688 -- Edit this bug report at https://bugs.php.net/bug.php?id=50688&edit=1
Bug #61154 [Asn->Fbk]: configure fails with Oracle Instantclient 11.2
Edit report at https://bugs.php.net/bug.php?id=61154&edit=1 ID: 61154 Updated by: s...@php.net Reported by:wayne dot krauth at insuranceautomationgroup dot co Summary:configure fails with Oracle Instantclient 11.2 -Status: Assigned +Status: Feedback Type: Bug Package:OCI8 related Operating System: aix 6.1 PHP Version:5.3.10 Assigned To:sixd Block user comment: N Private report: N Previous Comments: [2012-02-21 22:15:53] s...@php.net What created libclntsh.so.11.2? The instantclient-basic-aix.ppc64-11.2.0.3.0.zip and instantclient-basic-aix.ppc32-11.2.0.3.0.zip files only contain libclntsh.so What's your configure line? [2012-02-21 15:04:35] wayne dot krauth at insuranceautomationgroup dot co Description: Trying to build php 6.3.10 on AIX 6.1, and including the oci8 InstantClient 11.2 from Oracle fails at the configure stage. Configure reports: checking Oracle Instant Client library version compatibility... configure: error: Oracle Instant Client libraries libnnz.so and libclntsh.so not found I modified the configure script to solve this problem, changing a 1 to a 2 as seen in the before and after lines: # OCI8_LCS=`ls $OCI8_LCS_BASE.*.1 2> /dev/null | tail -1` # Oracle 10g, 11g etc OCI8_LCS=`ls $OCI8_LCS_BASE.*.2 2> /dev/null | tail -1` # Oracle 10g, 11g etc -- Edit this bug report at https://bugs.php.net/bug.php?id=61154&edit=1
Bug #61154 [Asn]: configure fails with Oracle Instantclient 11.2
Edit report at https://bugs.php.net/bug.php?id=61154&edit=1 ID: 61154 Updated by: s...@php.net Reported by:wayne dot krauth at insuranceautomationgroup dot co Summary:configure fails with Oracle Instantclient 11.2 Status: Assigned Type: Bug Package:OCI8 related Operating System: aix 6.1 PHP Version:5.3.10 Assigned To:sixd Block user comment: N Private report: N New Comment: What created libclntsh.so.11.2? The instantclient-basic-aix.ppc64-11.2.0.3.0.zip and instantclient-basic-aix.ppc32-11.2.0.3.0.zip files only contain libclntsh.so What's your configure line? Previous Comments: [2012-02-21 15:04:35] wayne dot krauth at insuranceautomationgroup dot co Description: Trying to build php 6.3.10 on AIX 6.1, and including the oci8 InstantClient 11.2 from Oracle fails at the configure stage. Configure reports: checking Oracle Instant Client library version compatibility... configure: error: Oracle Instant Client libraries libnnz.so and libclntsh.so not found I modified the configure script to solve this problem, changing a 1 to a 2 as seen in the before and after lines: # OCI8_LCS=`ls $OCI8_LCS_BASE.*.1 2> /dev/null | tail -1` # Oracle 10g, 11g etc OCI8_LCS=`ls $OCI8_LCS_BASE.*.2 2> /dev/null | tail -1` # Oracle 10g, 11g etc -- Edit this bug report at https://bugs.php.net/bug.php?id=61154&edit=1
Bug #50776 [Com]: openssl_pkcs7_verify
Edit report at https://bugs.php.net/bug.php?id=50776&edit=1
ID: 50776
Comment by: gufophp at gmail dot com
Reported by:gufophp at gmail dot com
Summary:openssl_pkcs7_verify
Status: No Feedback
Type: Bug
Package:OpenSSL related
Operating System: win32 apache
PHP Version:5.3.1
Block user comment: N
Private report: N
New Comment:
please CHECK all certificate in filesysem (pubblic key):
auto signed certificate "root ca"(H0)
-->create and sign certifichate used H0, this certificate is H1
>create a new certificate used H1 to sign, this certificate is H2
to check certificate(H2) authority ALL certificate is necessary (H0, H1, and H2)
if not have ALL publik key of all cert, cerificate check fail "certificate
verify error"
You have all certificate ?
please update documentation (no bug)
Previous Comments:
[2010-04-25 20:25:17] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-01-24 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".
[2010-01-16 19:53:10] j...@php.net
Try Google for the error:
"Likewise, if the senderâs certificate isnât recognized by your OpenSSL
infrastructure, youâll get a similar error"
Looks like your script is buggy.
[2010-01-16 06:06:14] gufophp at gmail dot com
Description:
PKCS7_verify:certificate verify error
Reproduce code:
---
\n";
echo ""; // view 1
$arr = array("To" => "j...@example.com", // keyed syntax
"From: HQ ", // indexed syntax
"Subject" => "Eyes only");
echo openssl_pkcs7_sign($file, $signed, $crt, array($key,
"gufogufogufogufogufogufo"),$arr);
while ($msg = openssl_error_string())
echo $msg . "\n";
echo "";
$body = file_get_contents($signed);
file_put_contents("signed.txt",$body);
$pa = "C:\\Programmi\\Apache Software Foundation\\Apache2.2\\htdocs\sign\\";
// error here
echo openssl_pkcs7_verify(
$pa."signed.txt",
PKCS7_BINARY,
$pa.'test3.crt',
array($pa.'test.crt'),
$pa.'test.crt',
$pa.'content.eml'
);
// error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error
while ($msg = openssl_error_string())
echo $msg . "\n";
?>
Expected result:
1
Actual result:
--
error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error
--
Edit this bug report at https://bugs.php.net/bug.php?id=50776&edit=1
Bug #50776 [Fbk->NoF]: openssl_pkcs7_verify
Edit report at https://bugs.php.net/bug.php?id=50776&edit=1
ID: 50776
Updated by: ras...@php.net
Reported by:gufophp at gmail dot com
Summary:openssl_pkcs7_verify
-Status: Feedback
+Status: No Feedback
Type: Bug
Package:OpenSSL related
Operating System: win32 apache
PHP Version:5.3.1
Block user comment: N
Private report: N
Previous Comments:
[2010-04-25 20:25:17] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-01-24 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".
[2010-01-16 19:53:10] j...@php.net
Try Google for the error:
"Likewise, if the senderâs certificate isnât recognized by your OpenSSL
infrastructure, youâll get a similar error"
Looks like your script is buggy.
[2010-01-16 06:06:14] gufophp at gmail dot com
Description:
PKCS7_verify:certificate verify error
Reproduce code:
---
\n";
echo ""; // view 1
$arr = array("To" => "j...@example.com", // keyed syntax
"From: HQ ", // indexed syntax
"Subject" => "Eyes only");
echo openssl_pkcs7_sign($file, $signed, $crt, array($key,
"gufogufogufogufogufogufo"),$arr);
while ($msg = openssl_error_string())
echo $msg . "\n";
echo "";
$body = file_get_contents($signed);
file_put_contents("signed.txt",$body);
$pa = "C:\\Programmi\\Apache Software Foundation\\Apache2.2\\htdocs\sign\\";
// error here
echo openssl_pkcs7_verify(
$pa."signed.txt",
PKCS7_BINARY,
$pa.'test3.crt',
array($pa.'test.crt'),
$pa.'test.crt',
$pa.'content.eml'
);
// error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error
while ($msg = openssl_error_string())
echo $msg . "\n";
?>
Expected result:
1
Actual result:
--
error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error
--
Edit this bug report at https://bugs.php.net/bug.php?id=50776&edit=1
Bug #61142 [Opn->Fbk]: error : child pid 16289 exit signal Illegal instruction (4) - if using SQLT_CHR
Edit report at https://bugs.php.net/bug.php?id=61142&edit=1 ID: 61142 Updated by: s...@php.net Reported by:hinaresh2000 at gmail dot com Summary:error : child pid 16289 exit signal Illegal instruction (4) - if using SQLT_CHR -Status: Open +Status: Feedback Type: Bug Package:OCI8 related Operating System: RHEL5.3 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I need: 1. A complete PHP test script showing the values (if any) in $filter_permissions_array. 2. The SQL to create any DB objects used. 3. The versions of the Oracle client libraries and of the database. Thanks. Previous Comments: [2012-02-20 11:39:32] hinaresh2000 at gmail dot com Also i have tested it on another box having php 5.3.9 - (built: Jan 12 2012 15:14:33) then i saw below error in log: "child pid 7758 exit signal Segmentation fault (11)" [2012-02-20 11:26:19] hinaresh2000 at gmail dot com Description: --- >From manual page: >http://www.php.net/function.oci-bind-array-by-name#refsect1-function.oci-bind-array-by-name-returnvalues --- Hi, I am testing my application on Amazon Cloud Box where PHP 5.3.9 is installed on RHEL5.3 Below is my php source code line : oci_bind_array_by_name($stmt, "filter_permissions", $filter_permissions_array, 1,-1,SQLT_STR); here $filter_permissions may or may not contain any value. The above code line shows error in /var/log/httpd/error_log file that "child pid 16289 exit signal Illegal instruction (4)" and browser stops and shows blank page. The same line is working fine with PHP 5.1.6 and showing results perfectly. Also if it fails somewhere on any version then i have replaced SQLT_STR with SQLT_CHR and it works fine. In that case i am not in a position to fix this issue in 5.3.9. Is this a PHP issue or the OCI one? help me resolving this issue. Thanks in Advance Naresh K. Test script: --- Below is my php source code line : oci_bind_array_by_name($stmt, "filter_permissions", $filter_permissions_array, 1,-1,SQLT_STR); here $filter_permissions may or may not contain any value. The above code line shows error in /var/log/httpd/error_log file that "child pid 16289 exit signal Illegal instruction (4)" and browser stops and shows blank page. Expected result: It should run without any error in log and doesn't stop the functionlity of page at browser. Actual result: -- Error in log - "child pid 16289 exit signal Illegal instruction (4)" and browser stops and shows blank page. -- Edit this bug report at https://bugs.php.net/bug.php?id=61142&edit=1
Bug #54051 [Opn->Ana]: output_buffering boolean values not interpreted correctly
Edit report at https://bugs.php.net/bug.php?id=54051&edit=1 ID: 54051 Updated by: ras...@php.net Reported by:chealer at gmail dot com Summary:output_buffering boolean values not interpreted correctly -Status: Open +Status: Analyzed Type: Bug Package:PHP options/info functions Operating System: Debian GNU/Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Yes, this isn't completely consistent. An empty string is the same as Off. It doesn't display the same as the boolean flags in phpinfo() because it isn't a boolean since it can take numeric values. 0, "" and Off all mean the same thing here. So it is purely aesthetic, but we should still go through and clean this up at some point. Previous Comments: [2011-02-18 22:28:08] chealer at gmail dot com Description: As reported in http://bugs.php.net/bug.php?id=29575 phpinfo() displays the value of output_buffering as "no value" instead of Off when it is set to Off. output_buffering is supposed to support boolean values: ; Output buffering is a mechanism for controlling how much output data ; (excluding headers and cookies) PHP should keep internally before pushing that ; data to the client. If your application's output exceeds this setting, PHP ; will send that data in chunks of roughly the size you specify. ; Turning on this setting and managing its maximum buffer size can yield some ; interesting side-effects depending on your application and web server. ; You may be able to send headers and cookies after you've already sent output ; through print or echo. You also may see performance benefits if your server is ; emitting less packets due to buffered output versus PHP streaming the output ; as it gets it. On production servers, 4096 bytes is a good setting for performance ; reasons. ; Note: Output buffering can also be controlled via Output Buffering Control ; functions. ; Possible Values: ; On = Enabled and buffer is unlimited. (Use with caution) ; Off = Disabled ; Integer = Enables the buffer and sets its maximum size in bytes. ; Note: This directive is hardcoded to Off for the CLI SAPI ; Default Value: Off ; Development Value: 4096 ; Production Value: 4096 ; http://php.net/output-buffering But if it is set to Off, its value becomes an empty string. If it is set to On, its value becomes 1. I set the version to Irrelevant so the system would let me submit the report, but the version I verified this on is PHP 5.3.3. -- Edit this bug report at https://bugs.php.net/bug.php?id=54051&edit=1
Bug #61115 [Opn->Ana]: Stream related segfault on fatal error in php_stream_context_del_link
Edit report at https://bugs.php.net/bug.php?id=61115&edit=1 ID: 61115 Updated by: cataphr...@php.net Reported by:ni...@php.net Summary:Stream related segfault on fatal error in php_stream_context_del_link -Status: Open +Status: Analyzed Type: Bug Package:Reproducible crash PHP Version:5.4.0RC7 Block user comment: N Private report: N New Comment: I don't think this can be solved without significant changes. The stream stores a pointer directly to the context structure (and increments the context resource refcount), but on an unorderly shutdown the resources are simply destroyed in inverse order of created. _php_stream_free then makes invalid reads, not just on the place that causes this segfault, but also near the end when it tries to decrease the context refcount. I think the solution here would be to have the stream store the context resource id instead of the context structure (basically adding one level of indirection). We may be able to this without breaking binary compatibility, and the details of the stream structure are supposedly private (see comment on php_streams.h), but I have no doubt this would be a very problematic change nonetheless. Previous Comments: [2012-02-16 21:59:09] ni...@php.net Description: links)); (gdb) bt #0 0x084c95cb in php_stream_context_del_link (context=0xb73cbddc, stream=0xb73cba00) at /home/nikic/dev/php-src/main/streams/streams.c:2256 #1 0x084c4953 in _php_stream_free (stream=0xb73cba00, close_options=3, tsrm_ls=0x8b26050) at /home/nikic/dev/php-src/main/streams/streams.c:449 #2 0x084c48a4 in _php_stream_free (stream=0xb73cbb90, close_options=11, tsrm_ls=0x8b26050) at /home/nikic/dev/php-src/main/streams/streams.c:406 #3 0x084c7059 in stream_resource_regular_dtor (rsrc=0xb73cbca0, tsrm_ls=0x8b26050) at /home/nikic/dev/php-src/main/streams/streams.c:1578 #4 0x085587f3 in list_entry_destructor (ptr=0xb73cbca0) at /home/nikic/dev/php-src/Zend/zend_list.c:183 #5 0x08555fc6 in zend_hash_apply_deleter (ht=0x8b280ac, p=0xb73cbc4c) at /home/nikic/dev/php-src/Zend/zend_hash.c:650 #6 0x08556154 in zend_hash_graceful_reverse_destroy (ht=0x8b280ac) at /home/nikic/dev/php-src/Zend/zend_hash.c:687 #7 0x085589d5 in zend_destroy_rsrc_list (ht=0x8b280ac, tsrm_ls=0x8b26050) at /home/nikic/dev/php-src/Zend/zend_list.c:239 #8 0x0854474a in zend_deactivate (tsrm_ls=0x8b26050) at /home/nikic/dev/php-src/Zend/zend.c:940 #9 0x084a6b4d in php_request_shutdown (dummy=0x0) at /home/nikic/dev/php-src/main/main.c:1781 #10 0x086907c5 in do_cli (argc=2, argv=0xb3d4, tsrm_ls=0x8b26050) at /home/nikic/dev/php-src/sapi/cli/php_cli.c:1169 #11 0x08691058 in main (argc=2, argv=0xb3d4) at /home/nikic/dev/php-src/sapi/cli/php_cli.c:1356 I was not yet able to understand the source of the segfault; would be nice if someone who knows the stream stuff better could give a hand :) -- Edit this bug report at https://bugs.php.net/bug.php?id=61115&edit=1
Bug #61155 [Nab]: session_strat gives error
Edit report at https://bugs.php.net/bug.php?id=61155&edit=1
ID: 61155
User updated by:elcmusic at inter dot net dot il
Reported by:elcmusic at inter dot net dot il
Summary:session_strat gives error
Status: Not a bug
Type: Bug
Package:Session related
Operating System: Server Version: Apache/2.2.11
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
When I added $_SESSION['form'] = "anything"; before:
$_SESSION['product'] = $_SESSION['form'];
the warning did not show!
so I guess this because I tried to read an undefined variable.
Is it or is it not a bug?
Thanks!
Previous Comments:
[2012-02-21 15:27:39] ahar...@php.net
As the warning says, disable session.bug_compat_42 (after making sure your code
doesn't rely on it) and the warning will go away.
[2012-02-21 15:25:13] elcmusic at inter dot net dot il
Description:
---
>From manual page: http://www.php.net/function.session-start
---
I'm using session_start(); and some times when a $_SESSION param is EMPTY I get
this error:
Warning: Unknown: Your script possibly relies on a session side-effect which
existed until PHP 4.2.3. Please be advised that the session extension does not
consider global variables as a source of data, unless register_globals is
enabled. You can disable this functionality and this warning by setting
session.bug_compat_42 or session.bug_compat_warn to off, respectively. in
Unknown on line 0
Test script:
---
session_start();
//error_reporting(0);
//session_unset ();
$_SESSION['product'] = $_SESSION['form'];//received from prev. page this is the
bug when ['form'] is empty or not defined
include('do-csv.php');// save $_GET in a csv file
include('do-Scsv.php');// save $_SESSION in a csv file
Expected result:
no warning should be output.
Actual result:
--
Warning: Unknown: Your script possibly relies on a session side-effect which
existed until PHP 4.2.3. Please be advised that the session extension does not
consider global variables as a source of data, unless register_globals is
enabled. You can disable this functionality and this warning by setting
session.bug_compat_42 or session.bug_compat_warn to off, respectively. in
Unknown on line 0
--
Edit this bug report at https://bugs.php.net/bug.php?id=61155&edit=1
Bug #61153 [Nab]: phpinfo reporting incorrect Configure Command
Edit report at https://bugs.php.net/bug.php?id=61153&edit=1 ID: 61153 Updated by: ras...@php.net Reported by:935c at itsynergy dot co dot uk Summary:phpinfo reporting incorrect Configure Command Status: Not a bug Type: Bug Package:PHP options/info functions Operating System: Scientific Linux 6.1 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Yes, odd autoconf quirk that -sysconfdir sets it still. File a bug with the autoconf folks. There isn't anything we can do about that. But despite that, "./configure --help" clearly shows that the correct way to set it is by using -- sysconfdir Previous Comments: [2012-02-21 18:35:00] 935c at itsynergy dot co dot uk In main/build-defs.h #define PHP_SYSCONFDIR "/etc/mydir" and yet #define CONFIGURE_COMMAND " './configure' " PHP_SYSCONFDIR would not show /etc/mydir unless CONFIGURE_COMMAND was called with sysconfdir. My default shell is bash : $ ps -p $$ PID TTY TIME CMD 16040 pts/000:00:00 bash $ bash --version GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu) [2012-02-21 17:54:12] ras...@php.net Forgot to close [2012-02-21 17:52:40] ras...@php.net Ah, I see your mistake. It is --sysconfigdir not -sysconfigdir I think you will find it will magically work when you fix that. [2012-02-21 17:46:07] ras...@php.net Ok, since you are not stupid, track down why it isn't working on your system. ext/standard/info.c shows that it prints the contents of the CONFIGURE_COMMAND #define. This is defined in main/build-defs.h which gets generated from main/build-defs.h.in at configure time. It also gets put into the top-level Makefile. So check these files. If you don't see it in main/build-defs.h it would mean that the configure VAR_SUBST stuff isn't working which should have caused your entire build to fail badly, or the configure shell script isn't doing the right thing on your system for some reason. [2012-02-21 17:36:17] 935c at itsynergy dot co dot uk Whilst you're in the mood for not believing me, why not check out the hard facts in my QA Report ? http://qa.php.net/reports/details.php? version=5.3.10&signature=30a4793560ae3e5862c1d5f16d5fa5fc&idreport=1519#phpinfo 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=61153 -- Edit this bug report at https://bugs.php.net/bug.php?id=61153&edit=1
Bug #61153 [Com]: phpinfo reporting incorrect Configure Command
Edit report at https://bugs.php.net/bug.php?id=61153&edit=1 ID: 61153 Comment by: 935c at itsynergy dot co dot uk Reported by:935c at itsynergy dot co dot uk Summary:phpinfo reporting incorrect Configure Command Status: Not a bug Type: Bug Package:PHP options/info functions Operating System: Scientific Linux 6.1 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: In main/build-defs.h #define PHP_SYSCONFDIR "/etc/mydir" and yet #define CONFIGURE_COMMAND " './configure' " PHP_SYSCONFDIR would not show /etc/mydir unless CONFIGURE_COMMAND was called with sysconfdir. My default shell is bash : $ ps -p $$ PID TTY TIME CMD 16040 pts/000:00:00 bash $ bash --version GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu) Previous Comments: [2012-02-21 17:54:12] ras...@php.net Forgot to close [2012-02-21 17:52:40] ras...@php.net Ah, I see your mistake. It is --sysconfigdir not -sysconfigdir I think you will find it will magically work when you fix that. [2012-02-21 17:46:07] ras...@php.net Ok, since you are not stupid, track down why it isn't working on your system. ext/standard/info.c shows that it prints the contents of the CONFIGURE_COMMAND #define. This is defined in main/build-defs.h which gets generated from main/build-defs.h.in at configure time. It also gets put into the top-level Makefile. So check these files. If you don't see it in main/build-defs.h it would mean that the configure VAR_SUBST stuff isn't working which should have caused your entire build to fail badly, or the configure shell script isn't doing the right thing on your system for some reason. [2012-02-21 17:36:17] 935c at itsynergy dot co dot uk Whilst you're in the mood for not believing me, why not check out the hard facts in my QA Report ? http://qa.php.net/reports/details.php? version=5.3.10&signature=30a4793560ae3e5862c1d5f16d5fa5fc&idreport=1519#phpinfo [2012-02-21 17:30:20] 935c at itsynergy dot co dot uk Do you seriously think I'm that stupid ? (1) I am only running one version of PHP on that server (2) Before, phpinfo stated 5.3.9, now it states 5.3.10 ... thus I am running the right version (3) The build date is Feb 21 2012 14:02:25, which you see correlates to the time I opened this ticket. 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=61153 -- Edit this bug report at https://bugs.php.net/bug.php?id=61153&edit=1
Bug #61153 [Opn->Nab]: phpinfo reporting incorrect Configure Command
Edit report at https://bugs.php.net/bug.php?id=61153&edit=1 ID: 61153 Updated by: ras...@php.net Reported by:935c at itsynergy dot co dot uk Summary:phpinfo reporting incorrect Configure Command -Status: Open +Status: Not a bug Type: Bug Package:PHP options/info functions Operating System: Scientific Linux 6.1 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Forgot to close Previous Comments: [2012-02-21 17:52:40] ras...@php.net Ah, I see your mistake. It is --sysconfigdir not -sysconfigdir I think you will find it will magically work when you fix that. [2012-02-21 17:46:07] ras...@php.net Ok, since you are not stupid, track down why it isn't working on your system. ext/standard/info.c shows that it prints the contents of the CONFIGURE_COMMAND #define. This is defined in main/build-defs.h which gets generated from main/build-defs.h.in at configure time. It also gets put into the top-level Makefile. So check these files. If you don't see it in main/build-defs.h it would mean that the configure VAR_SUBST stuff isn't working which should have caused your entire build to fail badly, or the configure shell script isn't doing the right thing on your system for some reason. [2012-02-21 17:36:17] 935c at itsynergy dot co dot uk Whilst you're in the mood for not believing me, why not check out the hard facts in my QA Report ? http://qa.php.net/reports/details.php? version=5.3.10&signature=30a4793560ae3e5862c1d5f16d5fa5fc&idreport=1519#phpinfo [2012-02-21 17:30:20] 935c at itsynergy dot co dot uk Do you seriously think I'm that stupid ? (1) I am only running one version of PHP on that server (2) Before, phpinfo stated 5.3.9, now it states 5.3.10 ... thus I am running the right version (3) The build date is Feb 21 2012 14:02:25, which you see correlates to the time I opened this ticket. [2012-02-21 17:27:01] ras...@php.net I am pretty sure you are not running the php that you built with that configure line then. I don't see how it could end up having a different configure line in phpinfo() the way the code is written. Please triple-check by looking at the "Build Date" near the top of the phpinfo() output. 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=61153 -- Edit this bug report at https://bugs.php.net/bug.php?id=61153&edit=1
Bug #61153 [Opn]: phpinfo reporting incorrect Configure Command
Edit report at https://bugs.php.net/bug.php?id=61153&edit=1 ID: 61153 Updated by: ras...@php.net Reported by:935c at itsynergy dot co dot uk Summary:phpinfo reporting incorrect Configure Command Status: Open Type: Bug Package:PHP options/info functions Operating System: Scientific Linux 6.1 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Ah, I see your mistake. It is --sysconfigdir not -sysconfigdir I think you will find it will magically work when you fix that. Previous Comments: [2012-02-21 17:46:07] ras...@php.net Ok, since you are not stupid, track down why it isn't working on your system. ext/standard/info.c shows that it prints the contents of the CONFIGURE_COMMAND #define. This is defined in main/build-defs.h which gets generated from main/build-defs.h.in at configure time. It also gets put into the top-level Makefile. So check these files. If you don't see it in main/build-defs.h it would mean that the configure VAR_SUBST stuff isn't working which should have caused your entire build to fail badly, or the configure shell script isn't doing the right thing on your system for some reason. [2012-02-21 17:36:17] 935c at itsynergy dot co dot uk Whilst you're in the mood for not believing me, why not check out the hard facts in my QA Report ? http://qa.php.net/reports/details.php? version=5.3.10&signature=30a4793560ae3e5862c1d5f16d5fa5fc&idreport=1519#phpinfo [2012-02-21 17:30:20] 935c at itsynergy dot co dot uk Do you seriously think I'm that stupid ? (1) I am only running one version of PHP on that server (2) Before, phpinfo stated 5.3.9, now it states 5.3.10 ... thus I am running the right version (3) The build date is Feb 21 2012 14:02:25, which you see correlates to the time I opened this ticket. [2012-02-21 17:27:01] ras...@php.net I am pretty sure you are not running the php that you built with that configure line then. I don't see how it could end up having a different configure line in phpinfo() the way the code is written. Please triple-check by looking at the "Build Date" near the top of the phpinfo() output. [2012-02-21 14:19:40] 935c at itsynergy dot co dot uk Description: I called configure as follows : "./configure -sysconfdir=/etc/mydir --with-xmlrpc" However phpinfo() reports the configure command as : "'./configure'" (i.e. no args are shown) Test script: --- Expected result: Phpinfo should show "./configure -sysconfdir=/etc/mydir --with-xmlrpc" Actual result: -- './configure' -- Edit this bug report at https://bugs.php.net/bug.php?id=61153&edit=1
Bug #61153 [Opn]: phpinfo reporting incorrect Configure Command
Edit report at https://bugs.php.net/bug.php?id=61153&edit=1 ID: 61153 Updated by: ras...@php.net Reported by:935c at itsynergy dot co dot uk Summary:phpinfo reporting incorrect Configure Command Status: Open Type: Bug Package:PHP options/info functions Operating System: Scientific Linux 6.1 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Ok, since you are not stupid, track down why it isn't working on your system. ext/standard/info.c shows that it prints the contents of the CONFIGURE_COMMAND #define. This is defined in main/build-defs.h which gets generated from main/build-defs.h.in at configure time. It also gets put into the top-level Makefile. So check these files. If you don't see it in main/build-defs.h it would mean that the configure VAR_SUBST stuff isn't working which should have caused your entire build to fail badly, or the configure shell script isn't doing the right thing on your system for some reason. Previous Comments: [2012-02-21 17:36:17] 935c at itsynergy dot co dot uk Whilst you're in the mood for not believing me, why not check out the hard facts in my QA Report ? http://qa.php.net/reports/details.php? version=5.3.10&signature=30a4793560ae3e5862c1d5f16d5fa5fc&idreport=1519#phpinfo [2012-02-21 17:30:20] 935c at itsynergy dot co dot uk Do you seriously think I'm that stupid ? (1) I am only running one version of PHP on that server (2) Before, phpinfo stated 5.3.9, now it states 5.3.10 ... thus I am running the right version (3) The build date is Feb 21 2012 14:02:25, which you see correlates to the time I opened this ticket. [2012-02-21 17:27:01] ras...@php.net I am pretty sure you are not running the php that you built with that configure line then. I don't see how it could end up having a different configure line in phpinfo() the way the code is written. Please triple-check by looking at the "Build Date" near the top of the phpinfo() output. [2012-02-21 14:19:40] 935c at itsynergy dot co dot uk Description: I called configure as follows : "./configure -sysconfdir=/etc/mydir --with-xmlrpc" However phpinfo() reports the configure command as : "'./configure'" (i.e. no args are shown) Test script: --- Expected result: Phpinfo should show "./configure -sysconfdir=/etc/mydir --with-xmlrpc" Actual result: -- './configure' -- Edit this bug report at https://bugs.php.net/bug.php?id=61153&edit=1
Bug #61153 [Com]: phpinfo reporting incorrect Configure Command
Edit report at https://bugs.php.net/bug.php?id=61153&edit=1 ID: 61153 Comment by: 935c at itsynergy dot co dot uk Reported by:935c at itsynergy dot co dot uk Summary:phpinfo reporting incorrect Configure Command Status: Open Type: Bug Package:PHP options/info functions Operating System: Scientific Linux 6.1 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Whilst you're in the mood for not believing me, why not check out the hard facts in my QA Report ? http://qa.php.net/reports/details.php? version=5.3.10&signature=30a4793560ae3e5862c1d5f16d5fa5fc&idreport=1519#phpinfo Previous Comments: [2012-02-21 17:30:20] 935c at itsynergy dot co dot uk Do you seriously think I'm that stupid ? (1) I am only running one version of PHP on that server (2) Before, phpinfo stated 5.3.9, now it states 5.3.10 ... thus I am running the right version (3) The build date is Feb 21 2012 14:02:25, which you see correlates to the time I opened this ticket. [2012-02-21 17:27:01] ras...@php.net I am pretty sure you are not running the php that you built with that configure line then. I don't see how it could end up having a different configure line in phpinfo() the way the code is written. Please triple-check by looking at the "Build Date" near the top of the phpinfo() output. [2012-02-21 14:19:40] 935c at itsynergy dot co dot uk Description: I called configure as follows : "./configure -sysconfdir=/etc/mydir --with-xmlrpc" However phpinfo() reports the configure command as : "'./configure'" (i.e. no args are shown) Test script: --- Expected result: Phpinfo should show "./configure -sysconfdir=/etc/mydir --with-xmlrpc" Actual result: -- './configure' -- Edit this bug report at https://bugs.php.net/bug.php?id=61153&edit=1
Bug #61153 [Fbk->Opn]: phpinfo reporting incorrect Configure Command
Edit report at https://bugs.php.net/bug.php?id=61153&edit=1 ID: 61153 User updated by:935c at itsynergy dot co dot uk Reported by:935c at itsynergy dot co dot uk Summary:phpinfo reporting incorrect Configure Command -Status: Feedback +Status: Open Type: Bug Package:PHP options/info functions Operating System: Scientific Linux 6.1 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Do you seriously think I'm that stupid ? (1) I am only running one version of PHP on that server (2) Before, phpinfo stated 5.3.9, now it states 5.3.10 ... thus I am running the right version (3) The build date is Feb 21 2012 14:02:25, which you see correlates to the time I opened this ticket. Previous Comments: [2012-02-21 17:27:01] ras...@php.net I am pretty sure you are not running the php that you built with that configure line then. I don't see how it could end up having a different configure line in phpinfo() the way the code is written. Please triple-check by looking at the "Build Date" near the top of the phpinfo() output. [2012-02-21 14:19:40] 935c at itsynergy dot co dot uk Description: I called configure as follows : "./configure -sysconfdir=/etc/mydir --with-xmlrpc" However phpinfo() reports the configure command as : "'./configure'" (i.e. no args are shown) Test script: --- Expected result: Phpinfo should show "./configure -sysconfdir=/etc/mydir --with-xmlrpc" Actual result: -- './configure' -- Edit this bug report at https://bugs.php.net/bug.php?id=61153&edit=1
Bug #61153 [Opn->Fbk]: phpinfo reporting incorrect Configure Command
Edit report at https://bugs.php.net/bug.php?id=61153&edit=1 ID: 61153 Updated by: ras...@php.net Reported by:935c at itsynergy dot co dot uk Summary:phpinfo reporting incorrect Configure Command -Status: Open +Status: Feedback Type: Bug Package:PHP options/info functions Operating System: Scientific Linux 6.1 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I am pretty sure you are not running the php that you built with that configure line then. I don't see how it could end up having a different configure line in phpinfo() the way the code is written. Please triple-check by looking at the "Build Date" near the top of the phpinfo() output. Previous Comments: [2012-02-21 14:19:40] 935c at itsynergy dot co dot uk Description: I called configure as follows : "./configure -sysconfdir=/etc/mydir --with-xmlrpc" However phpinfo() reports the configure command as : "'./configure'" (i.e. no args are shown) Test script: --- Expected result: Phpinfo should show "./configure -sysconfdir=/etc/mydir --with-xmlrpc" Actual result: -- './configure' -- Edit this bug report at https://bugs.php.net/bug.php?id=61153&edit=1
[PHP-BUG] Bug #61156 [NEW]: Segfault when using get_defined_constants(true)
From: Operating system: openSUSE 11.4 PHP version: Irrelevant Package: Reproducible crash Bug Type: Bug Bug description:Segfault when using get_defined_constants(true) Description: ATTN: This is a bug in php verison 5.3.5 !! I do realize that this is about an earlier version, but I have no available environments on which i could simply upgrade. So consider this bug report as a notification. It can be closed if not considered a valid report. We resolved our issue by circumventing use of the categorization of get_defined_constants. The function get_defined_constants(true) causes a client segfault ([Tue Feb 21 16:18:24 2012] [notice] child pid 12564 exit signal Segmentation fault (11)) There are some references to this issue occurring ie. #51788. In that particular case however, the issue seemed to have been caused by suhosin. My installation is running native php2 engine v2.3.0. When using get_defined_constants() (without the categorization parameter) there is no problem. Further information: OS: openSUSE 11.4 Kernel: 2.6.37.6-0.11-default Apache version: 2.2.17 ( API Version 20051115) PHP Version: 5.3.5 Loaded modules: core prefork http_core mod_so mod_unique_id mod_actions mod_alias mod_auth_basic mod_authn_file mod_authz_host mod_authz_groupfile mod_authz_default mod_authz_user mod_authn_dbm mod_autoindex mod_cgi mod_dir mod_env mod_expires mod_include mod_log_config mod_mime mod_negotiation mod_setenvif mod_ssl mod_status mod_suexec mod_userdir mod_vhost_alias mod_rewrite mod_php5 mod_info mod_dav mod_deflate mod_proxy mod_proxy_http Test script: --- Expected result: No output, no error logging. Actual result: -- Output: Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data. Apache error log: [Tue Feb 21 16:18:24 2012] [notice] child pid 12564 exit signal Segmentation fault (11) -- Edit bug report at https://bugs.php.net/bug.php?id=61156&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61156&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61156&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61156&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61156&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61156&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61156&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61156&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61156&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61156&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61156&r=support Expected behavior: https://bugs.php.net/fix.php?id=61156&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61156&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61156&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61156&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61156&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61156&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61156&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61156&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61156&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61156&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61156&r=mysqlcfg
Bug #61155 [Opn->Nab]: session_strat gives error
Edit report at https://bugs.php.net/bug.php?id=61155&edit=1
ID: 61155
Updated by: ahar...@php.net
Reported by:elcmusic at inter dot net dot il
Summary:session_strat gives error
-Status: Open
+Status: Not a bug
Type: Bug
Package:Session related
Operating System: Server Version: Apache/2.2.11
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
As the warning says, disable session.bug_compat_42 (after making sure your code
doesn't rely on it) and the warning will go away.
Previous Comments:
[2012-02-21 15:25:13] elcmusic at inter dot net dot il
Description:
---
>From manual page: http://www.php.net/function.session-start
---
I'm using session_start(); and some times when a $_SESSION param is EMPTY I get
this error:
Warning: Unknown: Your script possibly relies on a session side-effect which
existed until PHP 4.2.3. Please be advised that the session extension does not
consider global variables as a source of data, unless register_globals is
enabled. You can disable this functionality and this warning by setting
session.bug_compat_42 or session.bug_compat_warn to off, respectively. in
Unknown on line 0
Test script:
---
session_start();
//error_reporting(0);
//session_unset ();
$_SESSION['product'] = $_SESSION['form'];//received from prev. page this is the
bug when ['form'] is empty or not defined
include('do-csv.php');// save $_GET in a csv file
include('do-Scsv.php');// save $_SESSION in a csv file
Expected result:
no warning should be output.
Actual result:
--
Warning: Unknown: Your script possibly relies on a session side-effect which
existed until PHP 4.2.3. Please be advised that the session extension does not
consider global variables as a source of data, unless register_globals is
enabled. You can disable this functionality and this warning by setting
session.bug_compat_42 or session.bug_compat_warn to off, respectively. in
Unknown on line 0
--
Edit this bug report at https://bugs.php.net/bug.php?id=61155&edit=1
[PHP-BUG] Bug #61155 [NEW]: session_strat gives error
From:
Operating system: Server Version: Apache/2.2.11
PHP version: 5.3.10
Package: Session related
Bug Type: Bug
Bug description:session_strat gives error
Description:
---
>From manual page: http://www.php.net/function.session-start
---
I'm using session_start(); and some times when a $_SESSION param is EMPTY I
get this error:
Warning: Unknown: Your script possibly relies on a session side-effect
which existed until PHP 4.2.3. Please be advised that the session extension
does not consider global variables as a source of data, unless
register_globals is enabled. You can disable this functionality and this
warning by setting session.bug_compat_42 or session.bug_compat_warn to off,
respectively. in Unknown on line 0
Test script:
---
session_start();
//error_reporting(0);
//session_unset ();
$_SESSION['product'] = $_SESSION['form'];//received from prev. page this is
the bug when ['form'] is empty or not defined
include('do-csv.php');// save $_GET in a csv file
include('do-Scsv.php');// save $_SESSION in a csv file
Expected result:
no warning should be output.
Actual result:
--
Warning: Unknown: Your script possibly relies on a session side-effect
which existed until PHP 4.2.3. Please be advised that the session extension
does not consider global variables as a source of data, unless
register_globals is enabled. You can disable this functionality and this
warning by setting session.bug_compat_42 or session.bug_compat_warn to off,
respectively. in Unknown on line 0
--
Edit bug report at https://bugs.php.net/bug.php?id=61155&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61155&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61155&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61155&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61155&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61155&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61155&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61155&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61155&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61155&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61155&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61155&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61155&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61155&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61155&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61155&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61155&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61155&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61155&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61155&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61155&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61155&r=mysqlcfg
Req #61147 [Com]: No conflict resolution for properties in traits
Edit report at https://bugs.php.net/bug.php?id=61147&edit=1 ID: 61147 Comment by: greywire at gmail dot com Reported by:greywire at gmail dot com Summary:No conflict resolution for properties in traits Status: Suspended Type: Feature/Change Request Package:Class/Object related Operating System: MacOS X 10.7 PHP Version:5.4.0RC8 Block user comment: N Private report: N New Comment: I'm trying to understand here. When you say alias, do you mean generically like "reference" or "pointer" to a method? Or is there some aliasing construct I'm not aware of in the language? Traits are supposed to be flattened in the class, so its more like a language assisted cut and paste, correct? Which means two conflicting method names have to be renamed uniquely (or not named at all?) and then a reference/alias/pointer to the desired one is put in place with the original name. I don't know how the traits are actually implemented internally... Attempting to do this by hand I see that you could, using runkit, remove the two conflicting methods and put in one "aliased" method pointing to one that was removed. But doing this with a property as you said results in a new property that does not affect the other two. I thought maybe you could set that new property with a "&$obj->renamedprop" but that doesnt work. Running through my options (thinking about if runkit could be used to fix it. I've used runkit before to sorta implement my own traits functionality) I see its a tricky problem to solve indeed. The only thing I came up with is that if at runtime PHP just removed the conflicting properties altogether so the code compiles and runs, and then the two properties (and the needed alias) could just be caught with __get/__set and handled by the user. You'd get no warning or error about the conflict, but, you would immediately know about it when you accessed one of the properties. This may seem like a hack but at least it would give people an option... Is that a palatable compromise that wouldn't be hard to implement? :) Previous Comments: [2012-02-21 09:26:36] g...@php.net Unfortunately, the solution is not easy at all. One reason is the dynamic nature of PHP. You can easily access properties based on their string name: $foo = 'bar'; $this->$foo = 'foobar'; For exactly the same reason, we do NOT provide 'renaming'. The conflict resolution for methods allows to introduce an alias. Nothing more. An alias is a new name pointing to an unchanged method-body. (If you think about what that means, note that it breaks recursion in typical cases.) Thus, your proposal does not work with the current semantics. It would only result in a new property in the class that is never actually used. So far, we refrained from adding any of the constructs proposed in literature, since they would add considerable complexity. >From time to time there have been proposals for related features that could >make it into a future version of PHP, but for the moment being, I do not see how we can make this work without changing the nature of PHP. Suggestions are welcome of course. Thanks Stefan [2012-02-20 18:59:00] greywire at gmail dot com Description: There is no way to resolve a conflict in two used traits with the same property. The resolution method used to resolve conflicting method names should be able to be used similarly on properties. I realize this may be the intended behavior to discourage use of properties in traits as properties were not originally intended in traits, but since properties are allowed, there should be a way to resolve the conflict, and the solution is simple and fits with existing syntax. Test script: --- Expected result: No errors or warnings. Actual result: -- Parse error: syntax error, unexpected '$test' (T_VARIABLE), expecting identifier (T_STRING) in index.php on line 14 -- Edit this bug report at https://bugs.php.net/bug.php?id=61147&edit=1
[PHP-BUG] Bug #61154 [NEW]: configure fails with Oracle Instantclient 11.2
From: Operating system: aix 6.1 PHP version: 5.3.10 Package: *Configuration Issues Bug Type: Bug Bug description:configure fails with Oracle Instantclient 11.2 Description: Trying to build php 6.3.10 on AIX 6.1, and including the oci8 InstantClient 11.2 from Oracle fails at the configure stage. Configure reports: checking Oracle Instant Client library version compatibility... configure: error: Oracle Instant Client libraries libnnz.so and libclntsh.so not found I modified the configure script to solve this problem, changing a 1 to a 2 as seen in the before and after lines: # OCI8_LCS=`ls $OCI8_LCS_BASE.*.1 2> /dev/null | tail -1` # Oracle 10g, 11g etc OCI8_LCS=`ls $OCI8_LCS_BASE.*.2 2> /dev/null | tail -1` # Oracle 10g, 11g etc -- Edit bug report at https://bugs.php.net/bug.php?id=61154&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61154&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61154&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61154&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61154&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61154&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61154&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61154&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61154&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61154&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61154&r=support Expected behavior: https://bugs.php.net/fix.php?id=61154&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61154&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61154&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61154&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61154&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61154&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61154&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61154&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61154&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61154&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61154&r=mysqlcfg
[PHP-BUG] Bug #61153 [NEW]: phpinfo reporting incorrect Configure Command
From: Operating system: Scientific Linux 6.1 PHP version: 5.3.10 Package: PHP options/info functions Bug Type: Bug Bug description:phpinfo reporting incorrect Configure Command Description: I called configure as follows : "./configure -sysconfdir=/etc/mydir --with-xmlrpc" However phpinfo() reports the configure command as : "'./configure'" (i.e. no args are shown) Test script: --- Expected result: Phpinfo should show "./configure -sysconfdir=/etc/mydir --with-xmlrpc" Actual result: -- './configure' -- Edit bug report at https://bugs.php.net/bug.php?id=61153&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61153&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61153&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61153&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61153&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61153&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61153&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61153&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61153&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61153&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61153&r=support Expected behavior: https://bugs.php.net/fix.php?id=61153&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61153&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61153&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61153&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61153&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61153&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61153&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61153&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61153&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61153&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61153&r=mysqlcfg
Req #28331 [Com]: Fatal Errors
Edit report at https://bugs.php.net/bug.php?id=28331&edit=1
ID: 28331
Comment by: lang at b1-systems dot de
Reported by:microcamers at hotmail dot com
Summary:Fatal Errors
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Windows XP
PHP Version:5CVS-2004-05-09 (dev)
Block user comment: N
Private report: N
New Comment:
+1 from my side. Mixing and matching expressions with fatals and
return-0-checks is evil and clutters the code.
Rationale:
At least methods on non-objects can happen when you come from javascript or
similar scripting communities which encourage chaining/nesting calls to more or
less human-readable commands like
$granny_name = $baby->getMother()->getMother()->getName();
In PHP you would rather do
$mother = $baby->getMother();
if ($mother) {
$granny = $mother->getMother();
if ($granny) {
$granny_name = $granny->getName();
}
}
A comment would be welcome if such a patch would generally be apreciated or you
want to keep this fatal as a design decision. If the change is welcome, i'll
see if I can provide a patch.
Previous Comments:
[2005-12-07 19:54:21] paul dot ossenbruggen at websidestory dot com
It would be especially useful to be able to catch a missing
function or method errors in an eval() statement with
arbitrary code. This can be used in a unit test situation
where you want the script to continue to complete other tests.
[2004-05-09 04:13:48] microcamers at hotmail dot com
Description:
Can you make it possible to make most fatal errors catchable, such as the ones
for undefined functions, classes, redefined things and so on. Generally make it
so any error that can be caught can be caught.
--
Edit this bug report at https://bugs.php.net/bug.php?id=28331&edit=1
Bug #53572 [Opn->Wfx]: Bug appeared in php 5.2.15, FastCGI
Edit report at https://bugs.php.net/bug.php?id=53572&edit=1 ID: 53572 Updated by: ahar...@php.net Reported by:admin at xaker1 dot ru Summary:Bug appeared in php 5.2.15, FastCGI -Status: Open +Status: Wont fix Type: Bug -Package:Unknown/Other Function +Package:CGI/CLI related Operating System: FreeBSD 8.1 PHP Version:5.2.16 Block user comment: N Private report: N New Comment: PHP 5.2 is no longer supported; please reopen if this still occurs with PHP 5.3.10 or 5.4.0RC8. Previous Comments: [2011-01-18 21:46:31] anthon dot pang at gmail dot com Just an observation, but ini the php.ini for the affected account, the open_basedir setting has spaces in the paths. [2011-01-14 17:42:37] admin at xaker1 dot ru Error disappears if you disable open_basedir [2010-12-20 19:36:53] markusb at gmx dot at Same probleme We use php (cgi) and open_basedir > all php scrips > No input file specified. [2010-12-19 09:05:26] admin at xaker1 dot ru The problem exists on php 5.2.15 and php 5.2.16. I'm using php 5.2.14, as work is needed for all sites. php.ini on the affected account: register_globals = Off display_errors = Off log_errors = On max_execution_time = 30 memory_limit = 128M upload_max_filesize = 16M post_max_size = 16M session.save_path = "/ home/saki2/data/tmp" upload_tmp_dir = "/ home/saki2/data/tmp" open_basedir = "/ home/saki2: / tmp: / var / tmp" ; [suhosin] ; suhosin.log.syslog = E_ALL & ~ S_SQL ; suhosin.log.sapi = E_ALL & ~ S_SQL ; suhosin.executor.include.max_traversal = 4 ; suhosin.executor.func.blacklist = popen, dl, passthru, system, exec, proc_open, shell_exec, proc_close, symlink ; WARNING ; Or eAccelerator or Zend!!! ; Not twice!!! ; [eAccelerator] ; zend_extension = "/ usr/local/lib/php/20060613/eaccelerator.so" ; eaccelerator.cache_dir = "/ home/saki2/data/tmp" ; eaccelerator.debug = "0" ; eaccelerator.shm_size = "16" ; [Zend] ; zend_optimizer.optimization_level = 15 ; zend_extension_manager.optimizer = "/ usr/local/lib/php/20060613/Optimizer" ; zend_extension_manager.optimizer_ts = "/ usr/local/lib/php/20060613/Optimizer_TS" ; zend_extension = "/ usr/local/lib/php/20060613/ZendExtensionManager.so" ; zend_extension_ts = "/ usr/local/lib/php/20060613/ZendExtensionManager_TS.so" php.ini in the working account: register_globals= Off display_errors= On log_errors= On max_execution_time= 900 memory_limit= 512M upload_max_filesize= 16M post_max_size = 16M session.save_path = "/home/bravohost/data/tmp" upload_tmp_dir="/home/bravohost/data/tmp" open_basedir = "/home/bravohost:/tmp:/var/tmp" ;[suhosin] ;suhosin.log.syslog = E_ALL & ~S_SQL ;suhosin.log.sapi = E_ALL & ~S_SQL ;suhosin.executor.include.max_traversal = 4 ;suhosin.executor.func.blacklist = popen,dl,passthru,system,exec,proc_open,shell_exec,proc_close,symlink ; WARNING ; or eAccelerator or Zend!!! ; not twice!!! [eAccelerator] zend_extension="/usr/local/lib/php/20060613/eaccelerator.so" eaccelerator.cache_dir="/home/bravohost/data/tmp" eaccelerator.debug="0" eaccelerator.shm_size="16" ;[Zend] ;zend_optimizer.optimization_level=15 ;zend_extension_manager.optimizer="/usr/local/lib/php/20060613/Optimizer" ;zend_extension_manager.optimizer_ts="/usr/local/lib/php/20060613/Optimizer_TS" ;zend_extension="/usr/local/lib/php/20060613/ZendExtensionManager.so" ;zend_extension_ts="/usr/local/lib/php/20060613/ZendExtensionManager_TS.so ;extension = filter.so php modules are used: [PHP Modules] bcmath bz2 calendar ctype curl date dom filter gd gettext hash iconv imap ionCube Loader json libxml mbstring mcrypt mhash mysql mysqli openssl pcre PDO pdo_mysql pdo_sqlite posix Reflection session SimpleXML sockets SPL SQLite standard suhosin tokenizer xml xmlreader xmlwriter Zend Optimizer zip zlib [Zend Modules] Zend Extension Manager Zend Optimizer the ionCube PHP Loader [2010-12-18 22:14:48] cataphr...@php.net We'd need more information than what you gave. First, are you using 5.2.15 or 5.2.16. If you're using 5.2.15, upgrade. Then, what exactly is causing this (not a vague it may be root folder or name/group or open_basedir) and, preferably, steps to reproduce, would go a long way. Thanks. 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=53572 -- Edit this bug report at https://bugs.php.net/bug.php?id=53572&edit=1
Bug #60560 [Opn->Csd]: SplFixedArray un-/serialize, getSize(), count() return 0, keys are strings
Edit report at https://bugs.php.net/bug.php?id=60560&edit=1
ID: 60560
Updated by: ahar...@php.net
Reported by:digital1kk at interia dot pl
Summary:SplFixedArray un-/serialize, getSize(), count()
return 0, keys are strings
-Status: Open
+Status: Closed
Type: Bug
Package:SPL related
PHP Version:Irrelevant
-Assigned To:
+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 trunk.
Previous Comments:
[2012-02-21 10:34:39] ahar...@php.net
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&revision=323408
Log: Add a __wakeup() method to SplFixedArray, thereby fixing serialising an
SplFixedArray object and bug #60560 (SplFixedArray un-/serialize, getSize(),
count() return 0, keys are strings).
[2011-12-19 13:49:25] digital1kk at interia dot pl
Quick fix is to store in serialized form internal array:
-
$sa = serialize($a->toArray());
$ua = unserialize($sa);
$b = SplFixedArray::fromArray($ua);
var_dump($b);
echo 'Sizeof $b = ' . $b->getSize(), PHP_EOL;
echo 'Count $b = ' . $b->count(), PHP_EOL;
-
Gives the expected results
Also I forgot in php >= 5.4.0RC3 (should I report this as separate bug?)
The actual result of var_dump($b) is:
$b = object(SplFixedArray)#2 (2) {
["0"]=>
int(1)
["1"]=>
int(2)
}
The keys are strings and not integers and this causes
-
$b = unserialize(serialize($a));
SplFixedArray::fromArray($b->toarray());
-
To throw an exception 'InvalidArgumentException' with message 'array must
contain only positive integer keys'
[2011-12-19 10:31:53] digital1kk at interia dot pl
Description:
If SplFixedArray object is created via unserialize() of serialized instance
then the getSize() and count() methods return 0 instead of expected actual size.
Tested on Debian Squeeze 6 64bit:
x86-5.4.0RC3-dev
Tested on windows 7 64bit:
x86-5.4.0RC3-nts
x86-5.4.0trunk(12.12)-nts
x86-5.4.0snap(13.12)-nts
x86-5.3.8-nts
x86-5.3.6-ts
x86-5.3.6-nts
x64-5.3.6-nts
x86-5.3.4-nts
x86-5.3.1-ts
Test script:
---
getSize(), PHP_EOL;
echo 'Count $a = ' . $a->count(), PHP_EOL;
echo PHP_EOL;
$b = unserialize(serialize($a));
echo '$b = ', var_dump($b);
echo 'Sizeof $b = ' . $b->getSize(), PHP_EOL;
echo 'Count $b = ' . $b->count(), PHP_EOL;
Expected result:
$a = object(SplFixedArray)#1 (2) {
[0]=>
int(1)
[1]=>
int(2)
}
Sizeof $a = 2
Count $a = 2
$b = object(SplFixedArray)#2 (2) {
[0]=>
int(1)
[1]=>
int(2)
}
Sizeof $b = 2
Count $b = 2
Actual result:
--
$a = object(SplFixedArray)#1 (2) {
[0]=>
int(1)
[1]=>
int(2)
}
Sizeof $a = 2
Count $a = 2
$b = object(SplFixedArray)#2 (2) {
[0]=>
int(1)
[1]=>
int(2)
}
Sizeof $b = 0
Count $b = 0
--
Edit this bug report at https://bugs.php.net/bug.php?id=60560&edit=1
Req #52776 [Com]: MessageFormatter::__construct should throw an exception for invalid patterns
Edit report at https://bugs.php.net/bug.php?id=52776&edit=1 ID: 52776 Comment by: jinmoku at hotmail dot com Reported by:clicky at erebot dot net Summary:MessageFormatter::__construct should throw an exception for invalid patterns Status: Assigned Type: Feature/Change Request Package:I18N and L10N related Operating System: Ubuntu 9.10 PHP Version:Irrelevant Assigned To:stas Block user comment: N Private report: N New Comment: use the ini directive : intl.error_level Previous Comments: [2010-09-04 23:23:04] clicky at erebot dot net Description: MessageFormatter's constructor returns NULL when an invalid pattern is given. Instead, it should throw an exception. This bug has already been reported twice before (see #52042 & #49161). Each time the report was marked as bogus because the real problem got overlooked. (the problem lies not in the given pattern being considered invalid by ICU, the problem is in the constructor returning NULL) Test script: --- Expected result: f1 is NULL f2 is NULL Fatal error: Uncaught exception 'Exception' with message 'Invalid pattern' in %s:%d. Actual result: -- f1 is NULL f2 is NULL f3 is NULL -- Edit this bug report at https://bugs.php.net/bug.php?id=52776&edit=1
Bug #55047 [Com]: \ResourceBundle misses keys
Edit report at https://bugs.php.net/bug.php?id=55047&edit=1
ID: 55047
Comment by: jinmoku at hotmail dot com
Reported by:franssen dot roland at gmail dot com
Summary:\ResourceBundle misses keys
Status: Open
Type: Bug
Package:I18N and L10N related
Operating System: Ubuntu 11.04
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
With ICU 4+, the Languages key is in another file, you should open it with
"/usr/data/icu441/lang" unfortunately it doesn't work
Previous Comments:
[2011-06-13 20:14:09] franssen dot roland at gmail dot com
Until ICU4C library 4.2 all keys seem to be available
[2011-06-13 19:32:53] franssen dot roland at gmail dot com
Description:
I currently use the \ResourceBundle class from the intl extension. After an
upgrade to 5.3.6 some essental keys were missing.
Before i used a ICU4C data library for 3.8.1, after the upgrade i noticed ICU
version upgraded too (4.4.1). Using \ResourceBundle with the new data library
results in unknown keys, downgrading the data library resolves it.
Created the data library at;
http://apps.icu-project.org/datacustom/ICUData38.html
http://apps.icu-project.org/datacustom/ICUData44.html
See also;
http://site.icu-project.org/design/resbund/issues
Test script:
---
get('Languages'));
var_dump($res->getErrorMessage());
$res = new \ResourceBundle('en_US', '/usr/data/icu441', true);
var_dump($res->get('Languages'));
var_dump($res->getErrorMessage());
Expected result:
object(ResourceBundle)
"U_ZERO_ERROR"
object(ResourceBundle)
"U_ZERO_ERROR"
Actual result:
--
object(ResourceBundle)
"U_ZERO_ERROR"
NULL
"Cannot load resource element 'Languages': U_MISSING_RESOURCE_ERROR"
--
Edit this bug report at https://bugs.php.net/bug.php?id=55047&edit=1
Bug #55873 [Com]: resourcebundle shoud throw error if it desn't recognize the file
Edit report at https://bugs.php.net/bug.php?id=55873&edit=1 ID: 55873 Comment by: jinmoku at hotmail dot com Reported by:miha dot vrhovnik at domenca dot com Summary:resourcebundle shoud throw error if it desn't recognize the file Status: Open Type: Bug Package:I18N and L10N related Operating System: Linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: use the ini directive : intl.error_level Previous Comments: [2011-10-08 15:45:23] miha dot vrhovnik at domenca dot com Description: ICU 4.4 upgraded it's resource file format. If you are using older version of ICU e.g 4.2 and try to load a newer version of resource file function returns null but there is no way of developer knowing what the hell happened. Getting some sort of error message would be most welcome otherwise you just get a WTF moment. Test script: --- https://bugs.php.net/bug.php?id=55873&edit=1
Bug #53791 [Csd]: NumberFormat::parse fail with French thousands separator
Edit report at https://bugs.php.net/bug.php?id=53791&edit=1
ID: 53791
Updated by: ras...@php.net
Reported by:jinmoku at hotmail dot com
Summary:NumberFormat::parse fail with French thousands
separator
Status: Closed
Type: Bug
Package:I18N and L10N related
PHP Version:5.3.5
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
Jinmoku, well, they fixed this non-bug in ICU 4.8 it seems. It really should
work
with spaces.
Previous Comments:
[2012-02-21 10:01:23] der...@php.net
Ok, in any case, in 4.8.1 a normal space seems to work as well.
[2012-02-21 10:00:21] der...@php.net
4.8.1 gives:
derick@whisky:/tmp$ ./unum fr_FR "1 234.56"
1234.00
derick@whisky:/tmp$ ./unum fr_FR "1 234,56"
1234.56
derick@whisky:/tmp$ ./unum fr_FR "1234,56"
1234.56
[2012-02-21 10:00:13] jinmoku at hotmail dot com
This is not a bug, the real test should be
---
$nombre = 1234.56;
$fmt = new NumberFormatter('fr_FR', NumberFormatter::DECIMAL);
var_dump($fmt->format($nombre));
$nombre = "1\xc2\xa0234,56";
$fmt = new NumberFormatter('fr_FR', NumberFormatter::DECIMAL);
var_dump($fmt->parse($nombre));
$nombre = '1234,56';
$fmt = new NumberFormatter('fr_FR', NumberFormatter::DECIMAL);
var_dump($fmt->parse($nombre));
---
---
string(9) "1 234,56"
float(1234.56)
float(1234.56)
---
[2012-02-21 09:44:13] ras...@php.net
I spent a bit of time looking at this tonight. As far as I can tell there is
nothing wrong on the PHP side here. A quick ICU test program that reproduces
this bug is here:
== [unum.c]
#include
#include "unicode/utypes.h"
#include "unicode/unum.h"
#include "unicode/uloc.h"
#include "unicode/umisc.h"
#include "unicode/parseerr.h"
void main(int argc, char *argv[]) {
UChar tmp[64];
UNumberFormat *cur_def;
int32_t parsepos = 0;
UErrorCode status=U_ZERO_ERROR;
UNumberFormatStyle style= UNUM_DEFAULT;
double d;
cur_def = unum_open(style, NULL, 0, argv[1], NULL, &status);
if(U_FAILURE(status)) printf("Error1: %s\n", u_errorName(status));
u_uastrcpy(tmp, argv[2]);
d = unum_parseDouble(cur_def, tmp, u_strlen(tmp), &parsepos, &status);
if(U_FAILURE(status)) printf("Error2: %s\n", u_errorName(status));
printf("%f\n",d);
}
Compile with:
gcc -o unum unum.c -ldl -lm -L/usr/lib -licui18n -licuuc -licudata -ldl -lm
or check what your flags should be on your platform with:
/usr/bin/icu-config --ldflags
then run it like this:
$ ./unum fr_FR "1234,56"
1234.56
$ ./unum fr_FR "1 234,56"
1.00
I get this with ICU 4.4.2 on Ubuntu.
Could someone please try this on ICU 4.6 or 4.8?
[2011-12-10 04:57:26] playa71 at gmail dot com
Running PHP 5.3.8 on Win7 - this problem still happens.
Amazing in 2011 a programming language exists that doesn't support entire
countries! sigh.
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=53791
--
Edit this bug report at https://bugs.php.net/bug.php?id=53791&edit=1
Bug #53791 [Fbk->Csd]: NumberFormat::parse fail with French thousands separator
Edit report at https://bugs.php.net/bug.php?id=53791&edit=1
ID: 53791
Updated by: der...@php.net
Reported by:jinmoku at hotmail dot com
Summary:NumberFormat::parse fail with French thousands
separator
-Status: Feedback
+Status: Closed
Type: Bug
Package:I18N and L10N related
PHP Version:5.3.5
-Assigned To:
+Assigned To:derick
Block user comment: N
Private report: N
New Comment:
Ok, in any case, in 4.8.1 a normal space seems to work as well.
Previous Comments:
[2012-02-21 10:00:21] der...@php.net
4.8.1 gives:
derick@whisky:/tmp$ ./unum fr_FR "1 234.56"
1234.00
derick@whisky:/tmp$ ./unum fr_FR "1 234,56"
1234.56
derick@whisky:/tmp$ ./unum fr_FR "1234,56"
1234.56
[2012-02-21 10:00:13] jinmoku at hotmail dot com
This is not a bug, the real test should be
---
$nombre = 1234.56;
$fmt = new NumberFormatter('fr_FR', NumberFormatter::DECIMAL);
var_dump($fmt->format($nombre));
$nombre = "1\xc2\xa0234,56";
$fmt = new NumberFormatter('fr_FR', NumberFormatter::DECIMAL);
var_dump($fmt->parse($nombre));
$nombre = '1234,56';
$fmt = new NumberFormatter('fr_FR', NumberFormatter::DECIMAL);
var_dump($fmt->parse($nombre));
---
---
string(9) "1 234,56"
float(1234.56)
float(1234.56)
---
[2012-02-21 09:44:13] ras...@php.net
I spent a bit of time looking at this tonight. As far as I can tell there is
nothing wrong on the PHP side here. A quick ICU test program that reproduces
this bug is here:
== [unum.c]
#include
#include "unicode/utypes.h"
#include "unicode/unum.h"
#include "unicode/uloc.h"
#include "unicode/umisc.h"
#include "unicode/parseerr.h"
void main(int argc, char *argv[]) {
UChar tmp[64];
UNumberFormat *cur_def;
int32_t parsepos = 0;
UErrorCode status=U_ZERO_ERROR;
UNumberFormatStyle style= UNUM_DEFAULT;
double d;
cur_def = unum_open(style, NULL, 0, argv[1], NULL, &status);
if(U_FAILURE(status)) printf("Error1: %s\n", u_errorName(status));
u_uastrcpy(tmp, argv[2]);
d = unum_parseDouble(cur_def, tmp, u_strlen(tmp), &parsepos, &status);
if(U_FAILURE(status)) printf("Error2: %s\n", u_errorName(status));
printf("%f\n",d);
}
Compile with:
gcc -o unum unum.c -ldl -lm -L/usr/lib -licui18n -licuuc -licudata -ldl -lm
or check what your flags should be on your platform with:
/usr/bin/icu-config --ldflags
then run it like this:
$ ./unum fr_FR "1234,56"
1234.56
$ ./unum fr_FR "1 234,56"
1.00
I get this with ICU 4.4.2 on Ubuntu.
Could someone please try this on ICU 4.6 or 4.8?
[2011-12-10 04:57:26] playa71 at gmail dot com
Running PHP 5.3.8 on Win7 - this problem still happens.
Amazing in 2011 a programming language exists that doesn't support entire
countries! sigh.
[2011-09-05 17:03:26] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
or 5.3.8
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=53791
--
Edit this bug report at https://bugs.php.net/bug.php?id=53791&edit=1
Bug #53791 [Csd->Fbk]: NumberFormat::parse fail with French thousands separator
Edit report at https://bugs.php.net/bug.php?id=53791&edit=1
ID: 53791
Updated by: der...@php.net
Reported by:jinmoku at hotmail dot com
Summary:NumberFormat::parse fail with French thousands
separator
-Status: Closed
+Status: Feedback
Type: Bug
Package:I18N and L10N related
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
4.8.1 gives:
derick@whisky:/tmp$ ./unum fr_FR "1 234.56"
1234.00
derick@whisky:/tmp$ ./unum fr_FR "1 234,56"
1234.56
derick@whisky:/tmp$ ./unum fr_FR "1234,56"
1234.56
Previous Comments:
[2012-02-21 10:00:13] jinmoku at hotmail dot com
This is not a bug, the real test should be
---
$nombre = 1234.56;
$fmt = new NumberFormatter('fr_FR', NumberFormatter::DECIMAL);
var_dump($fmt->format($nombre));
$nombre = "1\xc2\xa0234,56";
$fmt = new NumberFormatter('fr_FR', NumberFormatter::DECIMAL);
var_dump($fmt->parse($nombre));
$nombre = '1234,56';
$fmt = new NumberFormatter('fr_FR', NumberFormatter::DECIMAL);
var_dump($fmt->parse($nombre));
---
---
string(9) "1 234,56"
float(1234.56)
float(1234.56)
---
[2012-02-21 09:44:13] ras...@php.net
I spent a bit of time looking at this tonight. As far as I can tell there is
nothing wrong on the PHP side here. A quick ICU test program that reproduces
this bug is here:
== [unum.c]
#include
#include "unicode/utypes.h"
#include "unicode/unum.h"
#include "unicode/uloc.h"
#include "unicode/umisc.h"
#include "unicode/parseerr.h"
void main(int argc, char *argv[]) {
UChar tmp[64];
UNumberFormat *cur_def;
int32_t parsepos = 0;
UErrorCode status=U_ZERO_ERROR;
UNumberFormatStyle style= UNUM_DEFAULT;
double d;
cur_def = unum_open(style, NULL, 0, argv[1], NULL, &status);
if(U_FAILURE(status)) printf("Error1: %s\n", u_errorName(status));
u_uastrcpy(tmp, argv[2]);
d = unum_parseDouble(cur_def, tmp, u_strlen(tmp), &parsepos, &status);
if(U_FAILURE(status)) printf("Error2: %s\n", u_errorName(status));
printf("%f\n",d);
}
Compile with:
gcc -o unum unum.c -ldl -lm -L/usr/lib -licui18n -licuuc -licudata -ldl -lm
or check what your flags should be on your platform with:
/usr/bin/icu-config --ldflags
then run it like this:
$ ./unum fr_FR "1234,56"
1234.56
$ ./unum fr_FR "1 234,56"
1.00
I get this with ICU 4.4.2 on Ubuntu.
Could someone please try this on ICU 4.6 or 4.8?
[2011-12-10 04:57:26] playa71 at gmail dot com
Running PHP 5.3.8 on Win7 - this problem still happens.
Amazing in 2011 a programming language exists that doesn't support entire
countries! sigh.
[2011-09-05 17:03:26] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
or 5.3.8
[2011-09-05 16:56:50] jinmoku at hotmail dot com
in fact the french group sep is not a "space" but a "no-breaking space"
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=53791
--
Edit this bug report at https://bugs.php.net/bug.php?id=53791&edit=1
Bug #53791 [Fbk->Csd]: NumberFormat::parse fail with French thousands separator
Edit report at https://bugs.php.net/bug.php?id=53791&edit=1
ID: 53791
User updated by:jinmoku at hotmail dot com
Reported by:jinmoku at hotmail dot com
Summary:NumberFormat::parse fail with French thousands
separator
-Status: Feedback
+Status: Closed
Type: Bug
Package:I18N and L10N related
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
This is not a bug, the real test should be
---
$nombre = 1234.56;
$fmt = new NumberFormatter('fr_FR', NumberFormatter::DECIMAL);
var_dump($fmt->format($nombre));
$nombre = "1\xc2\xa0234,56";
$fmt = new NumberFormatter('fr_FR', NumberFormatter::DECIMAL);
var_dump($fmt->parse($nombre));
$nombre = '1234,56';
$fmt = new NumberFormatter('fr_FR', NumberFormatter::DECIMAL);
var_dump($fmt->parse($nombre));
---
---
string(9) "1 234,56"
float(1234.56)
float(1234.56)
---
Previous Comments:
[2012-02-21 09:44:13] ras...@php.net
I spent a bit of time looking at this tonight. As far as I can tell there is
nothing wrong on the PHP side here. A quick ICU test program that reproduces
this bug is here:
== [unum.c]
#include
#include "unicode/utypes.h"
#include "unicode/unum.h"
#include "unicode/uloc.h"
#include "unicode/umisc.h"
#include "unicode/parseerr.h"
void main(int argc, char *argv[]) {
UChar tmp[64];
UNumberFormat *cur_def;
int32_t parsepos = 0;
UErrorCode status=U_ZERO_ERROR;
UNumberFormatStyle style= UNUM_DEFAULT;
double d;
cur_def = unum_open(style, NULL, 0, argv[1], NULL, &status);
if(U_FAILURE(status)) printf("Error1: %s\n", u_errorName(status));
u_uastrcpy(tmp, argv[2]);
d = unum_parseDouble(cur_def, tmp, u_strlen(tmp), &parsepos, &status);
if(U_FAILURE(status)) printf("Error2: %s\n", u_errorName(status));
printf("%f\n",d);
}
Compile with:
gcc -o unum unum.c -ldl -lm -L/usr/lib -licui18n -licuuc -licudata -ldl -lm
or check what your flags should be on your platform with:
/usr/bin/icu-config --ldflags
then run it like this:
$ ./unum fr_FR "1234,56"
1234.56
$ ./unum fr_FR "1 234,56"
1.00
I get this with ICU 4.4.2 on Ubuntu.
Could someone please try this on ICU 4.6 or 4.8?
[2011-12-10 04:57:26] playa71 at gmail dot com
Running PHP 5.3.8 on Win7 - this problem still happens.
Amazing in 2011 a programming language exists that doesn't support entire
countries! sigh.
[2011-09-05 17:03:26] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
or 5.3.8
[2011-09-05 16:56:50] jinmoku at hotmail dot com
in fact the french group sep is not a "space" but a "no-breaking space"
[2011-07-13 08:38:46] jinmoku at hotmail dot com
Feedback sent
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=53791
--
Edit this bug report at https://bugs.php.net/bug.php?id=53791&edit=1
Bug #53791 [Fbk]: NumberFormat::parse fail with French thousands separator
Edit report at https://bugs.php.net/bug.php?id=53791&edit=1
ID: 53791
Updated by: ras...@php.net
Reported by:jinmoku at hotmail dot com
Summary:NumberFormat::parse fail with French thousands
separator
Status: Feedback
Type: Bug
Package:I18N and L10N related
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
I spent a bit of time looking at this tonight. As far as I can tell there is
nothing wrong on the PHP side here. A quick ICU test program that reproduces
this bug is here:
== [unum.c]
#include
#include "unicode/utypes.h"
#include "unicode/unum.h"
#include "unicode/uloc.h"
#include "unicode/umisc.h"
#include "unicode/parseerr.h"
void main(int argc, char *argv[]) {
UChar tmp[64];
UNumberFormat *cur_def;
int32_t parsepos = 0;
UErrorCode status=U_ZERO_ERROR;
UNumberFormatStyle style= UNUM_DEFAULT;
double d;
cur_def = unum_open(style, NULL, 0, argv[1], NULL, &status);
if(U_FAILURE(status)) printf("Error1: %s\n", u_errorName(status));
u_uastrcpy(tmp, argv[2]);
d = unum_parseDouble(cur_def, tmp, u_strlen(tmp), &parsepos, &status);
if(U_FAILURE(status)) printf("Error2: %s\n", u_errorName(status));
printf("%f\n",d);
}
Compile with:
gcc -o unum unum.c -ldl -lm -L/usr/lib -licui18n -licuuc -licudata -ldl -lm
or check what your flags should be on your platform with:
/usr/bin/icu-config --ldflags
then run it like this:
$ ./unum fr_FR "1234,56"
1234.56
$ ./unum fr_FR "1 234,56"
1.00
I get this with ICU 4.4.2 on Ubuntu.
Could someone please try this on ICU 4.6 or 4.8?
Previous Comments:
[2011-12-10 04:57:26] playa71 at gmail dot com
Running PHP 5.3.8 on Win7 - this problem still happens.
Amazing in 2011 a programming language exists that doesn't support entire
countries! sigh.
[2011-09-05 17:03:26] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
or 5.3.8
[2011-09-05 16:56:50] jinmoku at hotmail dot com
in fact the french group sep is not a "space" but a "no-breaking space"
[2011-07-13 08:38:46] jinmoku at hotmail dot com
Feedback sent
[2011-01-21 17:08:20] jinmoku at hotmail dot com
On VC9 :
string(6) "1 234"
float(1)
float(1234.56)
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=53791
--
Edit this bug report at https://bugs.php.net/bug.php?id=53791&edit=1
Req #61147 [Opn->Sus]: No conflict resolution for properties in traits
Edit report at https://bugs.php.net/bug.php?id=61147&edit=1 ID: 61147 Updated by: g...@php.net Reported by:greywire at gmail dot com Summary:No conflict resolution for properties in traits -Status: Open +Status: Suspended Type: Feature/Change Request Package:Class/Object related Operating System: MacOS X 10.7 PHP Version:5.4.0RC8 Block user comment: N Private report: N New Comment: Unfortunately, the solution is not easy at all. One reason is the dynamic nature of PHP. You can easily access properties based on their string name: $foo = 'bar'; $this->$foo = 'foobar'; For exactly the same reason, we do NOT provide 'renaming'. The conflict resolution for methods allows to introduce an alias. Nothing more. An alias is a new name pointing to an unchanged method-body. (If you think about what that means, note that it breaks recursion in typical cases.) Thus, your proposal does not work with the current semantics. It would only result in a new property in the class that is never actually used. So far, we refrained from adding any of the constructs proposed in literature, since they would add considerable complexity. >From time to time there have been proposals for related features that could >make it into a future version of PHP, but for the moment being, I do not see how we can make this work without changing the nature of PHP. Suggestions are welcome of course. Thanks Stefan Previous Comments: [2012-02-20 18:59:00] greywire at gmail dot com Description: There is no way to resolve a conflict in two used traits with the same property. The resolution method used to resolve conflicting method names should be able to be used similarly on properties. I realize this may be the intended behavior to discourage use of properties in traits as properties were not originally intended in traits, but since properties are allowed, there should be a way to resolve the conflict, and the solution is simple and fits with existing syntax. Test script: --- Expected result: No errors or warnings. Actual result: -- Parse error: syntax error, unexpected '$test' (T_VARIABLE), expecting identifier (T_STRING) in index.php on line 14 -- Edit this bug report at https://bugs.php.net/bug.php?id=61147&edit=1
Bug #61152 [Nab]: parse_ini_string problem with html input
Edit report at https://bugs.php.net/bug.php?id=61152&edit=1
ID: 61152
Updated by: ras...@php.net
Reported by:momchil dot bozhinov at hp dot com
Summary:parse_ini_string problem with html input
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Windows
PHP Version:5.4.0RC8
Block user comment: N
Private report: N
New Comment:
Usually a syntax error in an ini file is a pretty serious situation that there
is no recovery from. So a big warning tends to be warranted. But, if you really
do have a situation where it is ok for there to be syntax errors in your ini,
then just swallow the error and check the return.
eg.
if(!@parse_ini_string($result)) {
echo "Fail!";
} else {
echo "Ok";
}
Previous Comments:
[2012-02-21 08:00:31] momchil dot bozhinov at hp dot com
Thank you for explaining that. Sorry for rushing in and submitting a bug for it.
How would one validate INI input? It seems a bad idea to try and handle such
warning as exception
[2012-02-21 07:48:12] ras...@php.net
No, the ini parser is a parser much like PHP uses a parser to parse the
language.
Parsers generate syntax errors when the text they are trying to parse doesn't
match the defined syntax. This is expected behaviour.
[2012-02-21 07:39:34] momchil dot bozhinov at hp dot com
Description:
I get a warning while trying to parse ini input.
problem is that the input comes from a file stored on the web and sometimes it
comes back as HTML (proxy issue).
The warning is reported as "syntax error", which I understand as something that
got out of the variable and was executed.
Test script:
---
Network Error
Network Error (dns_unresolved_hostname)
";
parse_ini_string($result);
// = 5.4 RC8
// Warning: syntax error, unexpected '=' in Unknown on line 9
// in C:\Users\***\Desktop\SFK\AutoPHP\bug.php on line 25
// = 5.3.10
// Warning: syntax error, unexpected '=' in Unknown on line 9
//in C:\Users\bozhinov\Desktop\SFK\AutoPHP\php53\bug.php on line 25
?>
--
Edit this bug report at https://bugs.php.net/bug.php?id=61152&edit=1
Bug #51618 [Fbk->NoF]: GC enabled causing huge memory allocations
Edit report at https://bugs.php.net/bug.php?id=51618&edit=1
ID: 51618
Updated by: ahar...@php.net
Reported by:mark at dynom dot nl
Summary:GC enabled causing huge memory allocations
-Status: Feedback
+Status: No Feedback
Type: Bug
Package:Scripting Engine problem
Operating System: linux
PHP Version:5.3.2
Block user comment: N
Private report: N
Previous Comments:
[2010-04-21 00:35:01] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-04-20 20:53:01] mark at dynom dot nl
Description:
I'm unable to reproduce it in a small snippet, the problem occurred in a huge
code base at "random" places trough out the application. However after setting
"zend.enable_gc = Off" the problem disappeared.
The problem varied, but were all related to memory_issues of massive
allocations. Some up to 3GB:
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 3061525857 bytes) in [...]
Sometimes the errors were more informative:
PHP Fatal error: Allowed memory size of 209715200 bytes exhausted at
/usr/src/php-5.3.2/Zend/zend_operators.c:1243 (tried to allocate 1515870818
bytes) in [..]
And all errors were string related. They all happened on lines where some sort
of concatenation was going on, like:
$string = $value. $string ;
or with functions like str_replace():
$string = str_replace("[".$field."]", $value, $string);
* APC was not installed on the machine.
* We tried both mysqlnd and libmysql, since initially that was the biggest
difference between the development and production servers.
* PHP was source build on a debian server, the following parameter were used:
./configure --prefix=/usr/local --with-apxs2=/usr/local/apache2/bin/apxs
--enable-soap --with-freetype-dir=/usr --enable-gd-native-ttf --with-gd
--with-zlib --with-bz2 --enable-zip --with-mcrypt --enable-ftp --with-openssl
--with-curl --enable-mbstring --with-mysql=mysqlnd --with-mysqli=mysqlnd
--with-pdo-mysql=mysqlnd --with-ldap --with-pdo-mysql --with-sqlite --with-tidy
--enable-calendar
Actual result:
--
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/local/apache2/lib/libaprutil-1.so.0...done.
Loaded symbols for /usr/local/apache2/lib/libaprutil-1.so.0
Reading symbols from /usr/local/apache2/lib/libexpat.so.0...done.
Loaded symbols for /usr/local/apache2/lib/libexpat.so.0
Reading symbols from /usr/local/apache2/lib/libapr-1.so.0...done.
Loaded symbols for /usr/local/apache2/lib/libapr-1.so.0
Reading symbols from /lib/librt.so.1...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_compat.so.2...done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnss_nis.so.2...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/local/apache2/modules/mod_authn_file.so...done.
Loaded symbols for /usr/local/apache2/modules/mod_authn_file.so
Reading symbols from /usr/local/apache2/modules/mod_authn_dbm.so...done.
Loaded symbols for /usr/local/apache2/modules/mod_authn_dbm.so
Reading symbols from /usr/local/apache2/modules/mod_authn_anon.so...done.
Loaded symbols for /usr/local/apache2/modules/mod_authn_anon.so
Reading symbols from /usr/local/apache2/modules/mod_authn_dbd.so...done.
Loaded symbols for /usr/local/apache2/modules/mod_authn_dbd.so
Reading symbols from /usr/local/apache2/modules/mod_authn_default.so...done.
Loaded symbols for /usr/local/apache2/modules/mod_authn_default.so
Reading symbols from /usr/local/apache2/modules/mod_authz_host.so...done.
Loaded symbols for /usr/local/apache2/modules/mod_a
Bug #61152 [Com]: parse_ini_string problem with html input
Edit report at https://bugs.php.net/bug.php?id=61152&edit=1 ID: 61152 Comment by: momchil dot bozhinov at hp dot com Reported by:momchil dot bozhinov at hp dot com Summary:parse_ini_string problem with html input Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: Windows PHP Version:5.4.0RC8 Block user comment: N Private report: N New Comment: Thank you for explaining that. Sorry for rushing in and submitting a bug for it. How would one validate INI input? It seems a bad idea to try and handle such warning as exception Previous Comments: [2012-02-21 07:48:12] ras...@php.net No, the ini parser is a parser much like PHP uses a parser to parse the language. Parsers generate syntax errors when the text they are trying to parse doesn't match the defined syntax. This is expected behaviour. [2012-02-21 07:39:34] momchil dot bozhinov at hp dot com Description: I get a warning while trying to parse ini input. problem is that the input comes from a file stored on the web and sometimes it comes back as HTML (proxy issue). The warning is reported as "syntax error", which I understand as something that got out of the variable and was executed. Test script: --- Network Error Network Error (dns_unresolved_hostname) "; parse_ini_string($result); // = 5.4 RC8 // Warning: syntax error, unexpected '=' in Unknown on line 9 // in C:\Users\***\Desktop\SFK\AutoPHP\bug.php on line 25 // = 5.3.10 // Warning: syntax error, unexpected '=' in Unknown on line 9 //in C:\Users\bozhinov\Desktop\SFK\AutoPHP\php53\bug.php on line 25 ?> -- Edit this bug report at https://bugs.php.net/bug.php?id=61152&edit=1
