Bug #64007 [Opn]: There is an ability to create instance of Generator by hand
Edit report at https://bugs.php.net/bug.php?id=64007edit=1
ID: 64007
Updated by: larue...@php.net
Reported by:lisachenko dot it at gmail dot com
Summary:There is an ability to create instance of Generator
by hand
Status: Open
Type: Bug
Package:Reflection related
Operating System: Windows 7 x64
PHP Version:5.5.0alpha2
-Assigned To:
+Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
agree, I will make a patch
Previous Comments:
[2013-01-16 12:50:56] ni...@php.net
Looks like a bug in Reflection. It should get the constructor through the
`get_constructor` handler, not from the class property.
[2013-01-16 12:37:13] lisachenko dot it at gmail dot com
Description:
Generator is an internal class, so there shouldn't be an ability to create it
by hand. However, the Generator class doesn't have a private constructor and
instance of it can be created via ReflectionClass.
Solution: add a private constructor for this class to prevent instantiation
(like for Closure class).
Test script:
---
$reflection = new ReflectionClass('Generator');
$generator = $reflection-newInstance();
var_dump($generator);
Expected result:
Expected ReflectionException that restricts an object instantiation.
Fatal error: Uncaught exception 'ReflectionException' with message 'Access to
non-public constructor of class Generator'
Actual result:
--
Generator object created:
object(Generator)#2 (0) { }
--
Edit this bug report at https://bugs.php.net/bug.php?id=64007edit=1
Bug #64001 [Com]: Slow method invocation for PHP5.5.0 with Development Server
Edit report at https://bugs.php.net/bug.php?id=64001edit=1
ID: 64001
Comment by: lisachenko dot it at gmail dot com
Reported by:lisachenko dot it at gmail dot com
Summary:Slow method invocation for PHP5.5.0 with Development
Server
Status: Feedback
Type: Bug
Package:Performance problem
Operating System: Windows 7 x64
PHP Version:5.5.0alpha3
Block user comment: N
Private report: N
New Comment:
Yeah, detected the issue.
Configurations were the same for all installations (default configuration), so
this issue doesn't relate to the output buffering. Just to be sure, I have
compared output for php -i for all installations, there were only differences
in REQUEST_TIME, build version and ... presence of loaded php.ini file for
PHP5.4.10.
If php.ini file is present (settings are still default) and loaded, then speed
of method invocation is higher... Amazing ) Without php.ini (but with the same
default settings) speed is lower for internal development server.
This can be reproduced with PHP5.4.10 too. So this performance bug is more
general.
Previous Comments:
[2013-01-17 05:45:40] larue...@php.net
I can not reproduce this, do they (5.4 and 5.5) share the same php.ini
configure?
I think maybe due to output buffer.
[2013-01-16 07:41:27] lisachenko dot it at gmail dot com
Update PHP version for issue manually (There isn't alpha3 in select).
[2013-01-16 07:38:38] lisachenko dot it at gmail dot com
Description:
I notice, that speed of method invocation for PHP5.5.0alpha3 is significantly
slower than for PHP5.4 when running the script with internal Development
Server. However, for CLI-mode PHP5.5.0 is faster than PHP5.4.10, as expected.
To reproduce the issue, please start the development server and execute test
script in the browser.
Test script:
---
class TestPerformance {
public function speed()
{
$time = microtime(true);
$this-nop();
echo 'Took ', sprintf(%0.3fms to call method, (microtime(true) -
$time) * 1e3);
}
protected function nop() {}
}
$instance = new TestPerformance;
$instance-speed();
Expected result:
Expecting that method invocation will take microseconds to finish:
php-5.4.10-Win32-VC9-x86:
Took 0.005ms to call method
php-5.5.0alpha3-Win32-VC9-x86:
Took 0.00Xms to call method
Actual result:
--
Method invocation for 5.5.0alpha3 took millisecond to finish:
php-5.4.10-Win32-VC9-x86:
Took 0.005ms to call method
php-5.5.0alpha3-Win32-VC9-x86:
Took 1.008ms to call method
php-5.5.0alpha3-nts-Win32-VC9-x86:
Took 1.000ms to call method
--
Edit this bug report at https://bugs.php.net/bug.php?id=64001edit=1
Bug #64007 [Asn]: There is an ability to create instance of Generator by hand
Edit report at https://bugs.php.net/bug.php?id=64007edit=1
ID: 64007
Updated by: larue...@php.net
Reported by:lisachenko dot it at gmail dot com
Summary:There is an ability to create instance of Generator
by hand
Status: Assigned
Type: Bug
Package:Reflection related
Operating System: Windows 7 x64
PHP Version:5.5.0alpha2
-Assigned To:laruence
+Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
@nikic, after a digging, I think it's better to make a private constructor for
generators. here is the reason:
refelction_class-newInstance used to throw exception while the constructor is
non-public..
if change to get_constructor, boom~ FATAL ERROR.
Previous Comments:
[2013-01-17 10:07:24] larue...@php.net
agree, I will make a patch
[2013-01-16 12:50:56] ni...@php.net
Looks like a bug in Reflection. It should get the constructor through the
`get_constructor` handler, not from the class property.
[2013-01-16 12:37:13] lisachenko dot it at gmail dot com
Description:
Generator is an internal class, so there shouldn't be an ability to create it
by hand. However, the Generator class doesn't have a private constructor and
instance of it can be created via ReflectionClass.
Solution: add a private constructor for this class to prevent instantiation
(like for Closure class).
Test script:
---
$reflection = new ReflectionClass('Generator');
$generator = $reflection-newInstance();
var_dump($generator);
Expected result:
Expected ReflectionException that restricts an object instantiation.
Fatal error: Uncaught exception 'ReflectionException' with message 'Access to
non-public constructor of class Generator'
Actual result:
--
Generator object created:
object(Generator)#2 (0) { }
--
Edit this bug report at https://bugs.php.net/bug.php?id=64007edit=1
[PHP-BUG] Bug #64009 [NEW]: fsockopen function not work on chrooted ubuntu linux os on android device.
From: anilsoneji at gmail dot com
Operating system: chrooted ubuntu on android
PHP version: 5.3.20
Package: PHP options/info functions
Bug Type: Bug
Bug description:fsockopen function not work on chrooted ubuntu linux os on
android device.
Description:
fsockopen function not work on chrooted ubuntu linux os on android device.
Test script:
---
?php
$socket = fsockopen(127.0.0.1,5038, $errno, $errstr, 1);
fputs($socket, Action: Login\r\n);
fputs($socket, UserName: admin\r\n);
fputs($socket, Secret: devindia\r\n\r\n);
fputs($socket, Action: Command\r\n);
fputs($socket, Command: reload\r\n\r\n);
fputs($socket, Action: Logoff\r\n\r\n);
while (!feof($socket))
{
fgets($socket,200);
echo $value[$count].'br';
}
fclose($socket);
?
Actual result:
--
2013-01-17 15:52:20: (mod_fastcgi.c.2701) FastCGI-stderr: PHP Warning:
fsockopen(): unable to connect to 127.0.0.1:5038 (Unknown error) in
/var/www/test.php on line 2
--
Edit bug report at https://bugs.php.net/bug.php?id=64009edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64009r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64009r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64009r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64009r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64009r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64009r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64009r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64009r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64009r=support
Expected behavior: https://bugs.php.net/fix.php?id=64009r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64009r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64009r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64009r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64009r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64009r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64009r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64009r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64009r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64009r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64009r=mysqlcfg
[PHP-BUG] Bug #64010 [NEW]: htmlentities fundamentally broken in 5.4
From: spam2 at rhsoft dot net Operating system: Linux PHP version: 5.4.10 Package: Scripting Engine problem Bug Type: Bug Bug description:htmlentities fundamentally broken in 5.4 Description: Like htmlspecialchars(), htmlentities() takes an optional third argument encoding which defines encoding used in conversion. If omitted, the default value for this argument is ISO-8859-1 in versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards and you broke randomly applications with this without specifiy 'ISO-8859-1' we get randomly EMPTY STRINGS back [harry@rh:/downloads/htmlentities]$ ./test.php strlen($input): 4464 strlen(htmlentities($input, ENT_QUOTES)): 0 strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')): 6522 Test script: --- #!/usr/bin/php ?php $input = base64_decode(file_get_contents(__DIR__ . '/70acc70b9c93b6a677825241e8165562_base64.txt')); echo '' . \n; echo 'strlen($input):' . \n; echo strlen($input) . \n; echo '' . \n; echo 'strlen(htmlentities($input, ENT_QUOTES)):' . \n; echo strlen(htmlentities($input, ENT_QUOTES)) . \n; echo '' . \n; echo 'strlen(htmlentities($input, ENT_QUOTES, \'ISO-8859-1\')):' . \n; echo strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')) . \n; ? Expected result: NON-EMPTY reuturn value -- Edit bug report at https://bugs.php.net/bug.php?id=64010edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64010r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64010r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64010r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64010r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64010r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64010r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64010r=needscript Try newer version: https://bugs.php.net/fix.php?id=64010r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64010r=support Expected behavior: https://bugs.php.net/fix.php?id=64010r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64010r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64010r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64010r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64010r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64010r=dst IIS Stability: https://bugs.php.net/fix.php?id=64010r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64010r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64010r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64010r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64010r=mysqlcfg
Bug #64010 [Com]: htmlentities fundamentally broken in 5.4
Edit report at https://bugs.php.net/bug.php?id=64010edit=1 ID: 64010 Comment by: spam2 at rhsoft dot net Reported by:spam2 at rhsoft dot net Summary:htmlentities fundamentally broken in 5.4 Status: Open Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.4.10 Block user comment: N Private report: N New Comment: WTF - why can i not submit a simple zip containing the spmale input base64_encoded in a seperate file because here you have only the option to attach patches Previous Comments: [2013-01-17 12:36:29] spam2 at rhsoft dot net Description: Like htmlspecialchars(), htmlentities() takes an optional third argument encoding which defines encoding used in conversion. If omitted, the default value for this argument is ISO-8859-1 in versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards and you broke randomly applications with this without specifiy 'ISO-8859-1' we get randomly EMPTY STRINGS back [harry@rh:/downloads/htmlentities]$ ./test.php strlen($input): 4464 strlen(htmlentities($input, ENT_QUOTES)): 0 strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')): 6522 Test script: --- #!/usr/bin/php ?php $input = base64_decode(file_get_contents(__DIR__ . '/70acc70b9c93b6a677825241e8165562_base64.txt')); echo '' . \n; echo 'strlen($input):' . \n; echo strlen($input) . \n; echo '' . \n; echo 'strlen(htmlentities($input, ENT_QUOTES)):' . \n; echo strlen(htmlentities($input, ENT_QUOTES)) . \n; echo '' . \n; echo 'strlen(htmlentities($input, ENT_QUOTES, \'ISO-8859-1\')):' . \n; echo strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')) . \n; ? Expected result: NON-EMPTY reuturn value -- Edit this bug report at https://bugs.php.net/bug.php?id=64010edit=1
Bug #64010 [Com]: htmlentities fundamentally broken in 5.4
Edit report at https://bugs.php.net/bug.php?id=64010edit=1
ID: 64010
Comment by: spam2 at rhsoft dot net
Reported by:spam2 at rhsoft dot net
Summary:htmlentities fundamentally broken in 5.4
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
and NO it is not a smart idea to change the complete default behavior
it is bullshit, if your page is ISO-8859-1 and you do htmlentities('üöä') it
is fundamentally broken to return empty strings in a random number of funtions
Previous Comments:
[2013-01-17 12:40:25] spam2 at rhsoft dot net
WTF - why can i not submit a simple zip containing the spmale input
base64_encoded in a seperate file because here you have only the
option to attach patches
[2013-01-17 12:36:29] spam2 at rhsoft dot net
Description:
Like htmlspecialchars(), htmlentities() takes an optional third
argument encoding which defines encoding used in conversion. If
omitted, the default value for this argument is ISO-8859-1 in
versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards
and you broke randomly applications with this
without specifiy 'ISO-8859-1' we get randomly EMPTY STRINGS back
[harry@rh:/downloads/htmlentities]$ ./test.php
strlen($input):
4464
strlen(htmlentities($input, ENT_QUOTES)):
0
strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')):
6522
Test script:
---
#!/usr/bin/php
?php
$input = base64_decode(file_get_contents(__DIR__ .
'/70acc70b9c93b6a677825241e8165562_base64.txt'));
echo '' .
\n;
echo 'strlen($input):' . \n;
echo strlen($input) . \n;
echo '' .
\n;
echo 'strlen(htmlentities($input, ENT_QUOTES)):' . \n;
echo strlen(htmlentities($input, ENT_QUOTES)) . \n;
echo '' .
\n;
echo 'strlen(htmlentities($input, ENT_QUOTES, \'ISO-8859-1\')):' . \n;
echo strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')) . \n;
?
Expected result:
NON-EMPTY reuturn value
--
Edit this bug report at https://bugs.php.net/bug.php?id=64010edit=1
Bug #64010 [Opn-Nab]: htmlentities fundamentally broken in 5.4
Edit report at https://bugs.php.net/bug.php?id=64010edit=1
ID: 64010
Updated by: ras...@php.net
Reported by:spam2 at rhsoft dot net
Summary:htmlentities fundamentally broken in 5.4
-Status: Open
+Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
If your page is ISO-8859-1 and you are using that as your internal encoding as
well, then you need to specify that. Otherwise it leads to security issues. And
since most people don't use ISO-8859-1 anymore, the safer default is to make
sure
we don't output invalid UTF-8 byte sequences when the developer has not
specified
the encoding.
Previous Comments:
[2013-01-17 13:08:28] spam2 at rhsoft dot net
and NO it is not a smart idea to change the complete default behavior
it is bullshit, if your page is ISO-8859-1 and you do htmlentities('üöä') it
is fundamentally broken to return empty strings in a random number of funtions
[2013-01-17 12:40:25] spam2 at rhsoft dot net
WTF - why can i not submit a simple zip containing the spmale input
base64_encoded in a seperate file because here you have only the
option to attach patches
[2013-01-17 12:36:29] spam2 at rhsoft dot net
Description:
Like htmlspecialchars(), htmlentities() takes an optional third
argument encoding which defines encoding used in conversion. If
omitted, the default value for this argument is ISO-8859-1 in
versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards
and you broke randomly applications with this
without specifiy 'ISO-8859-1' we get randomly EMPTY STRINGS back
[harry@rh:/downloads/htmlentities]$ ./test.php
strlen($input):
4464
strlen(htmlentities($input, ENT_QUOTES)):
0
strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')):
6522
Test script:
---
#!/usr/bin/php
?php
$input = base64_decode(file_get_contents(__DIR__ .
'/70acc70b9c93b6a677825241e8165562_base64.txt'));
echo '' .
\n;
echo 'strlen($input):' . \n;
echo strlen($input) . \n;
echo '' .
\n;
echo 'strlen(htmlentities($input, ENT_QUOTES)):' . \n;
echo strlen(htmlentities($input, ENT_QUOTES)) . \n;
echo '' .
\n;
echo 'strlen(htmlentities($input, ENT_QUOTES, \'ISO-8859-1\')):' . \n;
echo strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')) . \n;
?
Expected result:
NON-EMPTY reuturn value
--
Edit this bug report at https://bugs.php.net/bug.php?id=64010edit=1
Bug #64010 [Com]: htmlentities fundamentally broken in 5.4
Edit report at https://bugs.php.net/bug.php?id=64010edit=1
ID: 64010
Comment by: spam2 at rhsoft dot net
Reported by:spam2 at rhsoft dot net
Summary:htmlentities fundamentally broken in 5.4
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
as long as PHP at whole is NOT really capable UTF8 it is bullshit to assume
that any input is UTF8 as default
Previous Comments:
[2013-01-17 13:23:21] ras...@php.net
If your page is ISO-8859-1 and you are using that as your internal encoding as
well, then you need to specify that. Otherwise it leads to security issues. And
since most people don't use ISO-8859-1 anymore, the safer default is to make
sure
we don't output invalid UTF-8 byte sequences when the developer has not
specified
the encoding.
[2013-01-17 13:08:28] spam2 at rhsoft dot net
and NO it is not a smart idea to change the complete default behavior
it is bullshit, if your page is ISO-8859-1 and you do htmlentities('üöä') it
is fundamentally broken to return empty strings in a random number of funtions
[2013-01-17 12:40:25] spam2 at rhsoft dot net
WTF - why can i not submit a simple zip containing the spmale input
base64_encoded in a seperate file because here you have only the
option to attach patches
[2013-01-17 12:36:29] spam2 at rhsoft dot net
Description:
Like htmlspecialchars(), htmlentities() takes an optional third
argument encoding which defines encoding used in conversion. If
omitted, the default value for this argument is ISO-8859-1 in
versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards
and you broke randomly applications with this
without specifiy 'ISO-8859-1' we get randomly EMPTY STRINGS back
[harry@rh:/downloads/htmlentities]$ ./test.php
strlen($input):
4464
strlen(htmlentities($input, ENT_QUOTES)):
0
strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')):
6522
Test script:
---
#!/usr/bin/php
?php
$input = base64_decode(file_get_contents(__DIR__ .
'/70acc70b9c93b6a677825241e8165562_base64.txt'));
echo '' .
\n;
echo 'strlen($input):' . \n;
echo strlen($input) . \n;
echo '' .
\n;
echo 'strlen(htmlentities($input, ENT_QUOTES)):' . \n;
echo strlen(htmlentities($input, ENT_QUOTES)) . \n;
echo '' .
\n;
echo 'strlen(htmlentities($input, ENT_QUOTES, \'ISO-8859-1\')):' . \n;
echo strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')) . \n;
?
Expected result:
NON-EMPTY reuturn value
--
Edit this bug report at https://bugs.php.net/bug.php?id=64010edit=1
Bug #64010 [Com]: htmlentities fundamentally broken in 5.4
Edit report at https://bugs.php.net/bug.php?id=64010edit=1
ID: 64010
Comment by: spam2 at rhsoft dot net
Reported by:spam2 at rhsoft dot net
Summary:htmlentities fundamentally broken in 5.4
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
and if you guys would be smart there would be an php.ini setting to specify the
bahvior globally and/or per Directory instead hardcode incompatible changes
breaking nearly ANY code written without wrappers
Previous Comments:
[2013-01-17 13:33:21] spam2 at rhsoft dot net
as long as PHP at whole is NOT really capable UTF8 it is bullshit to assume
that any input is UTF8 as default
[2013-01-17 13:23:21] ras...@php.net
If your page is ISO-8859-1 and you are using that as your internal encoding as
well, then you need to specify that. Otherwise it leads to security issues. And
since most people don't use ISO-8859-1 anymore, the safer default is to make
sure
we don't output invalid UTF-8 byte sequences when the developer has not
specified
the encoding.
[2013-01-17 13:08:28] spam2 at rhsoft dot net
and NO it is not a smart idea to change the complete default behavior
it is bullshit, if your page is ISO-8859-1 and you do htmlentities('üöä') it
is fundamentally broken to return empty strings in a random number of funtions
[2013-01-17 12:40:25] spam2 at rhsoft dot net
WTF - why can i not submit a simple zip containing the spmale input
base64_encoded in a seperate file because here you have only the
option to attach patches
[2013-01-17 12:36:29] spam2 at rhsoft dot net
Description:
Like htmlspecialchars(), htmlentities() takes an optional third
argument encoding which defines encoding used in conversion. If
omitted, the default value for this argument is ISO-8859-1 in
versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards
and you broke randomly applications with this
without specifiy 'ISO-8859-1' we get randomly EMPTY STRINGS back
[harry@rh:/downloads/htmlentities]$ ./test.php
strlen($input):
4464
strlen(htmlentities($input, ENT_QUOTES)):
0
strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')):
6522
Test script:
---
#!/usr/bin/php
?php
$input = base64_decode(file_get_contents(__DIR__ .
'/70acc70b9c93b6a677825241e8165562_base64.txt'));
echo '' .
\n;
echo 'strlen($input):' . \n;
echo strlen($input) . \n;
echo '' .
\n;
echo 'strlen(htmlentities($input, ENT_QUOTES)):' . \n;
echo strlen(htmlentities($input, ENT_QUOTES)) . \n;
echo '' .
\n;
echo 'strlen(htmlentities($input, ENT_QUOTES, \'ISO-8859-1\')):' . \n;
echo strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')) . \n;
?
Expected result:
NON-EMPTY reuturn value
--
Edit this bug report at https://bugs.php.net/bug.php?id=64010edit=1
Bug #52339 [Com]: SPL autoloader breaks class_exists()
Edit report at https://bugs.php.net/bug.php?id=52339edit=1
ID: 52339
Comment by: php at maisqi dot com
Reported by:dangerous dot ben at gmail dot com
Summary:SPL autoloader breaks class_exists()
Status: Re-Opened
Type: Bug
Package:SPL related
Operating System: any (debian)
PHP Version:5.3.3RC2
Block user comment: N
Private report: N
New Comment:
This is clearly a bug. We're testing if a class exists not asserting it.
There's seam to be a patch for this. Any chance it will be accepted?
Previous Comments:
[2012-11-24 20:29:04] ciantic at oksidi dot com
Is this bug still happening in PHP5.4 and greater? I'm using 5.3.8.
If one uses class_exists it should never throw error, only true or false. It
makes
no sense otherwise. This is one of those where setting of some other
application
can totally broke functionality elsewhere. Should everyone using class_exists
catch try LogicException too? I'd argue not.
Though the workaround (empty function for spl) is kind of nice, as dangerous
dot
ben mentioned.
[2012-08-08 16:18:39] kilbyc at bellsouth dot net
Even worse. The no arg register is inconsistent.
?php
print_r(class_exists('asdfasdf'));//no error, just false.
spl_autoload_register();
print_r(class_exists('asdfasdf'));//LogicException
?
?php
print_r(class_exists('asdfasdf'));//no error, just false.
spl_autoload_register('spl_autoload');
spl_autoload_unregister('spl_autoload');
spl_autoload_register();
print_r(class_exists('asdfasdf'));//no error, just false.
?
If the autoload stack is empty by the time the no arg registered is called, how
can it function differently than if the autoload stack has been emptied by the
time the no arg register is called?
This is nonsensical behavior, and manual for spl_autoload say nothing about it
throwing. Let alone LogicException. I would have expected this to be a
RuntimeException. As it depends on the specific environment it is run in as to
whether or not spl_autoload will find something.
[2012-08-08 16:02:40] kilbyc at bellsouth dot net
PHP 5.3.8 (cli) (built: Aug 23 2011 11:50:20)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
?php
print_r(class_exists('asdfasdf'));//no error, just false
spl_autoload_register();
print_r(class_exists('asdfasdf'));//LogicException.
?
?php
class_exists('asdfasdf');//no error, just false.
spl_autoload_register('spl_autoload');
class_exists('asdfasdf');//no error, just false.
?
spl_autoload is inconsistent with itself.
[2012-03-16 22:02:29] pwolfenden at qualys dot com
Although I have not yet migrated to 5.3, I care about this bug because I'm
using
an autoload function (in 5.2) which contains some directory traversal logic and
uses class_exists() to decide whether or not to keep looking. I need to do this
because I'm in the scenario described by james (and so cannot assume that all
the
package files in my codebase follow my preferred naming convention), and I
would
much prefer class_exists() to continue to return false rather than having it
throw
a new Exception.
[2012-02-03 00:01:46] frozenf...@php.net
Re-opening, as there still exists the conflict of class_exists() generating an
error when autoloading fails, which is a chicken and the egg sort of issue. If
one wants to try autoloading if the class doesn't exist, but autoloading fails,
it should be possible to recover from that failure.
My understanding of the underlying code is that it generates an error in this
case. Perhaps it should generate an exception, which can be caught an handled.
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=52339
--
Edit this bug report at https://bugs.php.net/bug.php?id=52339edit=1
[PHP-BUG] Bug #64011 [NEW]: PHP 5.4 BREAKS get_html_translation_table()
From: spam2 at rhsoft dot net Operating system: PHP version: 5.4.10 Package: Scripting Engine problem Bug Type: Bug Bug description:PHP 5.4 BREAKS get_html_translation_table() Description: the 5.4 return value can not be seriously hopefully at least Returns the translation table used by htmlspecialchars() and htmlentities() is NOT true however, this breaks dialogs for special chars using this table and insert the enitity in the HTML code realize that not every page out there is UTF8 and never will be _ PHP 5.4: php -r print_r(get_html_translation_table(HTML_ENTITIES, ENT_QUOTES, 'ISO8859-1')); Array ( [] = quot; [] = amp; ['] = #039; [] = lt; [] = gt; ) _ PHP 5.3: php -r print_r(get_html_translation_table(HTML_ENTITIES, ENT_QUOTES, 'ISO8859-1')); Array ( [ ] = nbsp; [¡] = iexcl; [¢] = cent; [£] = pound; [¤] = curren; [Â¥] = yen; [¦] = brvbar; [§] = sect; [¨] = uml; [©] = copy; [ª] = ordf; [«] = laquo; [¬] = not; [Â] = shy; [®] = reg; [¯] = macr; [°] = deg; [±] = plusmn; [²] = sup2; [³] = sup3; [´] = acute; [µ] = micro; [¶] = para; [·] = middot; [¸] = cedil; [¹] = sup1; [º] = ordm; [»] = raquo; [¼] = frac14; [½] = frac12; [¾] = frac34; [¿] = iquest; [Ã] = Agrave; [Ã] = Aacute; [Ã] = Acirc; [Ã] = Atilde; [Ã] = Auml; [à ] = Aring; [Ã] = AElig; [Ã] = Ccedil; [Ã] = Egrave; [Ã] = Eacute; [Ã] = Ecirc; [Ã] = Euml; [Ã] = Igrave; [Ã] = Iacute; [Ã] = Icirc; [Ã] = Iuml; [Ã] = ETH; [Ã] = Ntilde; [Ã] = Ograve; [Ã] = Oacute; [Ã] = Ocirc; [Ã] = Otilde; [Ã] = Ouml; [Ã] = times; [Ã] = Oslash; [Ã] = Ugrave; [Ã] = Uacute; [Ã] = Ucirc; [Ã] = Uuml; [Ã] = Yacute; [Ã] = THORN; [Ã] = szlig; [à ] = agrave; [á] = aacute; [â] = acirc; [ã] = atilde; [ä] = auml; [Ã¥] = aring; [æ] = aelig; [ç] = ccedil; [è] = egrave; [é] = eacute; [ê] = ecirc; [ë] = euml; [ì] = igrave; [Ã] = iacute; [î] = icirc; [ï] = iuml; [ð] = eth; [ñ] = ntilde; [ò] = ograve; [ó] = oacute; [ô] = ocirc; [õ] = otilde; [ö] = ouml; [÷] = divide; [ø] = oslash; [ù] = ugrave; [ú] = uacute; [û] = ucirc; [ü] = uuml; [ý] = yacute; [þ] = thorn; [ÿ] = yuml; [] = amp; [] = quot; ['] = #039; [] = lt; [] = gt; ) Test script: --- php -r print_r(get_html_translation_table(HTML_ENTITIES, ENT_QUOTES, 'ISO8859-1')); Expected result: the full entity table like it worked for many years Actual result: -- a crippled array -- Edit bug report at https://bugs.php.net/bug.php?id=64011edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64011r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64011r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64011r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64011r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64011r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64011r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64011r=needscript Try newer version: https://bugs.php.net/fix.php?id=64011r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64011r=support Expected behavior: https://bugs.php.net/fix.php?id=64011r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64011r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64011r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64011r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64011r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64011r=dst IIS Stability: https://bugs.php.net/fix.php?id=64011r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64011r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64011r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64011r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64011r=mysqlcfg
[PHP-BUG] Bug #64012 [NEW]: Make rsvg compilable for PHP = 5.4
From: pm at datasphere dot ch Operating system: linux (all) PHP version: 5.4.11 Package: Compile Failure Bug Type: Bug Bug description:Make rsvg compilable for PHP = 5.4 Description: There is a compilation error for rsvg on PHP 5.4: .../php-pecl-rsvg-0.1.0/RSVG-0.1.0/rsvg.c: In function 'rsvg_object_new': .../php-pecl-rsvg-0.1.0/RSVG-0.1.0/rsvg.c:458:44 error: 'zend_class_entry' has no member named 'default_properties' Here is a patch directly inspired from https://bugs.php.net/bug.php?id=59731 -- Edit bug report at https://bugs.php.net/bug.php?id=64012edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64012r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64012r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64012r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64012r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64012r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64012r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64012r=needscript Try newer version: https://bugs.php.net/fix.php?id=64012r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64012r=support Expected behavior: https://bugs.php.net/fix.php?id=64012r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64012r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64012r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64012r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64012r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64012r=dst IIS Stability: https://bugs.php.net/fix.php?id=64012r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64012r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64012r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64012r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64012r=mysqlcfg
Bug #64012 [Opn]: Make rsvg compilable for PHP = 5.4
Edit report at https://bugs.php.net/bug.php?id=64012edit=1 ID: 64012 User updated by:pm at datasphere dot ch Reported by:pm at datasphere dot ch Summary:Make rsvg compilable for PHP = 5.4 Status: Open Type: Bug Package:Compile Failure Operating System: linux (all) PHP Version:5.4.11 Block user comment: N Private report: N New Comment: Please note also that PECL/rsvg is not an option as a package for this bug's classification. Previous Comments: [2013-01-17 17:43:40] pm at datasphere dot ch Description: There is a compilation error for rsvg on PHP 5.4: .../php-pecl-rsvg-0.1.0/RSVG-0.1.0/rsvg.c: In function 'rsvg_object_new': .../php-pecl-rsvg-0.1.0/RSVG-0.1.0/rsvg.c:458:44 error: 'zend_class_entry' has no member named 'default_properties' Here is a patch directly inspired from https://bugs.php.net/bug.php?id=59731 -- Edit this bug report at https://bugs.php.net/bug.php?id=64012edit=1
Bug #64007 [Com]: There is an ability to create instance of Generator by hand
Edit report at https://bugs.php.net/bug.php?id=64007edit=1
ID: 64007
Comment by: ni...@php.net
Reported by:lisachenko dot it at gmail dot com
Summary:There is an ability to create instance of Generator
by hand
Status: Assigned
Type: Bug
Package:Reflection related
Operating System: Windows 7 x64
PHP Version:5.5.0alpha2
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
@laruence: Imho `new Foo($bar)` and `(new
ReflectionClass('Foo'))-newInstance($bar)` should behave the same. So if the
constructor throws a fatal error then the constructor invoked through
reflection should also throw a fatal error.
If reflection doesn't go through get_constructor then it won't work correctly
if that handler is overloaded. It just works so well right now because nearly
noone overrides get_constructor.
Previous Comments:
[2013-01-17 10:40:17] larue...@php.net
@nikic, after a digging, I think it's better to make a private constructor for
generators. here is the reason:
refelction_class-newInstance used to throw exception while the constructor is
non-public..
if change to get_constructor, boom~ FATAL ERROR.
[2013-01-17 10:07:24] larue...@php.net
agree, I will make a patch
[2013-01-16 12:50:56] ni...@php.net
Looks like a bug in Reflection. It should get the constructor through the
`get_constructor` handler, not from the class property.
[2013-01-16 12:37:13] lisachenko dot it at gmail dot com
Description:
Generator is an internal class, so there shouldn't be an ability to create it
by hand. However, the Generator class doesn't have a private constructor and
instance of it can be created via ReflectionClass.
Solution: add a private constructor for this class to prevent instantiation
(like for Closure class).
Test script:
---
$reflection = new ReflectionClass('Generator');
$generator = $reflection-newInstance();
var_dump($generator);
Expected result:
Expected ReflectionException that restricts an object instantiation.
Fatal error: Uncaught exception 'ReflectionException' with message 'Access to
non-public constructor of class Generator'
Actual result:
--
Generator object created:
object(Generator)#2 (0) { }
--
Edit this bug report at https://bugs.php.net/bug.php?id=64007edit=1
Bug #64010 [Com]: htmlentities fundamentally broken in 5.4
Edit report at https://bugs.php.net/bug.php?id=64010edit=1
ID: 64010
Comment by: spam2 at rhsoft dot net
Reported by:spam2 at rhsoft dot net
Summary:htmlentities fundamentally broken in 5.4
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
and last but not least WTF did whoever implemented the bullshit returning an
emptry string WITHOUT THROW A WARNING AT LEAST - who do you guys imagine that
admins/developers which are running in E_ALL | E_STRICT since years smell if
there something is still broken and need to get fixed?
Previous Comments:
[2013-01-17 13:35:36] spam2 at rhsoft dot net
and if you guys would be smart there would be an php.ini setting to specify the
bahvior globally and/or per Directory instead hardcode incompatible changes
breaking nearly ANY code written without wrappers
[2013-01-17 13:33:21] spam2 at rhsoft dot net
as long as PHP at whole is NOT really capable UTF8 it is bullshit to assume
that any input is UTF8 as default
[2013-01-17 13:23:21] ras...@php.net
If your page is ISO-8859-1 and you are using that as your internal encoding as
well, then you need to specify that. Otherwise it leads to security issues. And
since most people don't use ISO-8859-1 anymore, the safer default is to make
sure
we don't output invalid UTF-8 byte sequences when the developer has not
specified
the encoding.
[2013-01-17 13:08:28] spam2 at rhsoft dot net
and NO it is not a smart idea to change the complete default behavior
it is bullshit, if your page is ISO-8859-1 and you do htmlentities('üöä') it
is fundamentally broken to return empty strings in a random number of funtions
[2013-01-17 12:40:25] spam2 at rhsoft dot net
WTF - why can i not submit a simple zip containing the spmale input
base64_encoded in a seperate file because here you have only the
option to attach patches
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=64010
--
Edit this bug report at https://bugs.php.net/bug.php?id=64010edit=1
Bug #64012 [Opn-Asn]: Make rsvg compilable for PHP = 5.4
Edit report at https://bugs.php.net/bug.php?id=64012edit=1 ID: 64012 Updated by: johan...@php.net Reported by:pm at datasphere dot ch Summary:Make rsvg compilable for PHP = 5.4 -Status: Open +Status: Assigned Type: Bug Package:Compile Failure Operating System: linux (all) PHP Version:5.4.11 -Assigned To: +Assigned To:mgdm Block user comment: N Private report: N Previous Comments: [2013-01-17 17:57:12] pm at datasphere dot ch Please note also that PECL/rsvg is not an option as a package for this bug's classification. [2013-01-17 17:43:40] pm at datasphere dot ch Description: There is a compilation error for rsvg on PHP 5.4: .../php-pecl-rsvg-0.1.0/RSVG-0.1.0/rsvg.c: In function 'rsvg_object_new': .../php-pecl-rsvg-0.1.0/RSVG-0.1.0/rsvg.c:458:44 error: 'zend_class_entry' has no member named 'default_properties' Here is a patch directly inspired from https://bugs.php.net/bug.php?id=59731 -- Edit this bug report at https://bugs.php.net/bug.php?id=64012edit=1
Bug #53035 [Com]: finfo_file() returns incorrect mimetype
Edit report at https://bugs.php.net/bug.php?id=53035edit=1 ID: 53035 Comment by: a dot lecca at gmail dot com Reported by:stuart at horuskol dot net Summary:finfo_file() returns incorrect mimetype Status: Feedback Type: Bug Package:Filesystem function related Operating System: Linux/Ubuntu 10.04 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: On PHP 5.3.18 Keven will also trigger a text/x-asm mime type Also, confirming the Charlotte issue Previous Comments: [2012-11-29 14:34:54] stepan dot stepanov at gmail dot com The problem still exists (PHP 5.3.19) If i have csv file with names (e.g.) it is recognised as text/plan (that is expected) But when i have someone called 'charles' or 'charlotte' inside - my file is recognised as text/x-c (obviously dues to word 'char') [2012-09-30 17:13:01] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2012-09-29 11:00:33] DonJaime at donjaime dot de This problem occurs with no comment at the start of the file, too. Rather than giving up because other programs using the same magic database are resulting in the same file being detected as C source it might be worth putting in the extra few lines of code required to return the right mime type on the basis of the file extension, if it exists. Worldwide, this would save a lot of energy and frustration. [2011-12-12 12:08:56] n dot delargy at ctidigital dot com It may also be worth noting that the file was converted from an excel sheet to a text tab delimited and charset was us-ascii [2011-12-12 12:06:42] n dot delargy at ctidigital dot com I've also had this issue, using ZF Zend_Validate_File_MimeType a text/plain file (according to file -i /path/to/file.txt) is incorrectly identified as text/x-c in ubuntu 11.10 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=53035 -- Edit this bug report at https://bugs.php.net/bug.php?id=53035edit=1
[PHP-BUG] Bug #64014 [NEW]: 10 second delay in returning file_get_contents('php://input')
From: dagan at digitalconversations dot tv
Operating system: ubuntu 12+
PHP version: 5.3.21
Package: Apache2 related
Bug Type: Bug
Bug description:10 second delay in returning file_get_contents('php://input')
Description:
If an invalid Content-Length header is sent with a request, attempting to
read the
request body via file_get_contents('php://input') results in a delay of 10
seconds
while, I assume, a timeout is waited on.
--
Edit bug report at https://bugs.php.net/bug.php?id=64014edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64014r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64014r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64014r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64014r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64014r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64014r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64014r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64014r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64014r=support
Expected behavior: https://bugs.php.net/fix.php?id=64014r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64014r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64014r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64014r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64014r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64014r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64014r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64014r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64014r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64014r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64014r=mysqlcfg
Bug #64005 [Opn-Nab]: array_merge memorry issues.
Edit report at https://bugs.php.net/bug.php?id=64005edit=1
ID: 64005
Updated by: google...@php.net
Reported by:youri dot essa at gmail dot com
Summary:array_merge memorry issues.
-Status: Open
+Status: Not a bug
Type: Bug
Package:Arrays related
Operating System: Linux
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
This is not a bug, but a simple mistake of using references in foreach. Pelase
see http://php.net/references and http://php.net/foreach for more details.
Particularly the red warning box at the bottom of the page at php.net/foreach
where it states Reference of a $value and the last array element remain even
after the foreach loop. It is recommended to destroy it by unset().
Previous Comments:
[2013-01-16 10:10:56] youri dot essa at gmail dot com
Description:
---
From manual page:
http://www.php.net/function.array-merge#refsect1-function.array-
merge-description
---
Test script:
---
foreach($cols as $key = $value) {
if(array_key_exists($key, $fields)) {
$value = array_merge($fields[$key], $value);
}
}
foreach($fields as $key = $value) {
if(!array_key_exists($key, $cols)) {
$cols[$key] = $value;
}
}
Expected result:
Expected result is that col becomes is an array with all the values that where
already defined added with the values from fields.
Actual result:
--
The sub-array in cols wich was merged with the same sub-array in fields becomes
overwritten everytime the next foreach statement accesses the value $value,
witch
result. the fix for this is to have a diffrent name for the array merging, this
leads me to belive that array_merge keeps re-evaluating the values.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64005edit=1
Bug #64009 [Opn-Fbk]: fsockopen function not work on chrooted ubuntu linux os on android device.
Edit report at https://bugs.php.net/bug.php?id=64009edit=1
ID: 64009
Updated by: ahar...@php.net
Reported by:anilsoneji at gmail dot com
Summary:fsockopen function not work on chrooted ubuntu linux
os on android device.
-Status: Open
+Status: Feedback
Type: Bug
-Package:PHP options/info functions
+Package:Sockets related
Operating System: chrooted ubuntu on android
PHP Version:5.3.20
Block user comment: N
Private report: N
New Comment:
I have a similar setup on my own tablet, so I can have a go at replicating this
over the weekend, but to ask the obvious question first: are you sure there's a
socket server listening on the loopback interface on port 5038? What happens if
you telnet 127.0.0.1 5038 from the shell?
Previous Comments:
[2013-01-17 11:56:25] anilsoneji at gmail dot com
Description:
fsockopen function not work on chrooted ubuntu linux os on android device.
Test script:
---
?php
$socket = fsockopen(127.0.0.1,5038, $errno, $errstr, 1);
fputs($socket, Action: Login\r\n);
fputs($socket, UserName: admin\r\n);
fputs($socket, Secret: devindia\r\n\r\n);
fputs($socket, Action: Command\r\n);
fputs($socket, Command: reload\r\n\r\n);
fputs($socket, Action: Logoff\r\n\r\n);
while (!feof($socket))
{
fgets($socket,200);
echo $value[$count].'br';
}
fclose($socket);
?
Actual result:
--
2013-01-17 15:52:20: (mod_fastcgi.c.2701) FastCGI-stderr: PHP Warning:
fsockopen(): unable to connect to 127.0.0.1:5038 (Unknown error) in
/var/www/test.php on line 2
--
Edit this bug report at https://bugs.php.net/bug.php?id=64009edit=1
Bug #61411 [Com]: PDO Segfaults with PERSISTENT == TRUE EMULATE_PREPARES == FALSE
Edit report at https://bugs.php.net/bug.php?id=61411edit=1
ID: 61411
Comment by: don at smugmug dot com
Reported by:julien at palard dot fr
Summary:PDO Segfaults with PERSISTENT == TRUE
EMULATE_PREPARES == FALSE
Status: Re-Opened
Type: Bug
Package:PDO related
Operating System: Linux 2.6.32-5-amd64
PHP Version:5.4.0
Assigned To:uw
Block user comment: N
Private report: N
New Comment:
I can reproduce this in 5.4.10 and 5.4.4, FWIW.
Previous Comments:
[2013-01-08 17:48:23] ras...@php.net
I can still reproduce this in PHP 5.4.12-dev built today.
[2013-01-08 12:18:49] johan...@php.net
Related To: Bug #53716
[2012-05-04 08:56:52] u...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
http://news.php.net/php.cvs/68917
[2012-05-02 09:14:42] u...@php.net
Andrey,
do you think we should mnd_p*alloc(.., .., stmt-persistent) here?
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/mysqlnd/mysqlnd_ps.c?annotate=321634
1624if (!stmt-result_bind) {
1625andrey 289028 stmt-result_bind = mnd_ecalloc(stmt-field_count,
sizeof(MYSQLND_RESULT_BIND));
1626andrey 258383 } else {
1627andrey 289028 stmt-result_bind = mnd_erealloc(stmt-result_bind,
stmt-field_count * sizeof(MYSQLND_RESULT_BIND));
1628andrey 258383 }
[2012-03-16 09:16:27] julien at palard dot fr
Description:
PDO Segfaults or hangs when a statement is executed with both ATTR_PERSISTENT
=
TRUE and ATTR_EMULATE_PREPARES = FALSE
The exact bug is actually :
*** glibc detected *** /usr/local/php-5.4.0/bin/php: free(): invalid pointer:
0x7ff976ee84c8 ***
But from my tests yesterday I have seen a segfault and a double free, that I
can't reproduce today, only the invalid pointer.
Playing with PERSISTENT and EMULATE_PREPARE with the given test script give :
| ATTR_PERSISENT | ATTR_EMULATE_PREPARES | WORKS |
| FALSE | FALSE |YES |
| FALSE | TRUE |YES |
| TRUE | FALSE | free() invalid pointer |
| TRUE | TRUE |YES |
Configure command :
./configure' '--enable-fpm' '--prefix=/usr/local/php-5.4.0'
'--enable-mbstring'
'--enable-gd-native-ttf' '--enable-zip' '--with-mcrypt' '--with-openssl' '--
with-gd' '--with-jpeg-dir=/usr/lib' '--with-freetype-dir' '--with-curl' '--with-
pcre-regex' '--with-gettext' '--without-sqlite' '--without-sqlite3' '--with-pdo-
mysql=mysqlnd' '--disable-rpath' '--disable-debug' '--disable-fileinfo' '--
without-pdo-sqlite' '--disable-phar' '--disable-posix' '--disable-tokenizer' '--
disable-xmlreader' '--disable-xmlwriter' '--without-pear'
Same bug reproduced in php 5.3.8 and php 5.3.10
Test script:
---
?php
$options = array(PDO::ATTR_PERSISTENT = TRUE,
PDO::ATTR_EMULATE_PREPARES = FALSE);
$pdo = new PDO('mysql:host=sql;dbname=??;charset=utf8',
'??', '??', $options);
$statement = $pdo-prepare(SELECT count(*) from a_table);
$statement-execute();
foreach ($statement as $line)
var_dump($line);
Expected result:
I expect PHP not to segfault
Actual result:
--
*** glibc detected *** /usr/local/php-5.4.0/bin/php: free(): invalid pointer:
0x7ff976ee84c8 ***
--
Edit this bug report at https://bugs.php.net/bug.php?id=61411edit=1
Bug #61411 [Com]: PDO Segfaults with PERSISTENT == TRUE EMULATE_PREPARES == FALSE
Edit report at https://bugs.php.net/bug.php?id=61411edit=1
ID: 61411
Comment by: don at smugmug dot com
Reported by:julien at palard dot fr
Summary:PDO Segfaults with PERSISTENT == TRUE
EMULATE_PREPARES == FALSE
Status: Re-Opened
Type: Bug
Package:PDO related
Operating System: Linux 2.6.32-5-amd64
PHP Version:5.4.0
Assigned To:uw
Block user comment: N
Private report: N
New Comment:
FWIW, 5.3.3 segfaults like this, but 5.3.2 doesn't. I spot-checked a handful
of
other versions up to .21 and they all segfaulted as well.
Previous Comments:
[2013-01-18 01:07:03] don at smugmug dot com
I can reproduce this in 5.4.10 and 5.4.4, FWIW.
[2013-01-08 17:48:23] ras...@php.net
I can still reproduce this in PHP 5.4.12-dev built today.
[2013-01-08 12:18:49] johan...@php.net
Related To: Bug #53716
[2012-05-04 08:56:52] u...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
http://news.php.net/php.cvs/68917
[2012-05-02 09:14:42] u...@php.net
Andrey,
do you think we should mnd_p*alloc(.., .., stmt-persistent) here?
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/mysqlnd/mysqlnd_ps.c?annotate=321634
1624if (!stmt-result_bind) {
1625andrey 289028 stmt-result_bind = mnd_ecalloc(stmt-field_count,
sizeof(MYSQLND_RESULT_BIND));
1626andrey 258383 } else {
1627andrey 289028 stmt-result_bind = mnd_erealloc(stmt-result_bind,
stmt-field_count * sizeof(MYSQLND_RESULT_BIND));
1628andrey 258383 }
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=61411
--
Edit this bug report at https://bugs.php.net/bug.php?id=61411edit=1
Bug #64009 [Com]: fsockopen function not work on chrooted ubuntu linux os on android device.
Edit report at https://bugs.php.net/bug.php?id=64009edit=1
ID: 64009
Comment by: anilsoneji at gmail dot com
Reported by:anilsoneji at gmail dot com
Summary:fsockopen function not work on chrooted ubuntu linux
os on android device.
Status: Feedback
Type: Bug
Package:Sockets related
Operating System: chrooted ubuntu on android
PHP Version:5.3.20
Block user comment: N
Private report: N
New Comment:
Problem has been solved.
include users mysql and apache (www-data) in group 3003 (aid_inet)
Previous Comments:
[2013-01-18 00:48:15] ahar...@php.net
I have a similar setup on my own tablet, so I can have a go at replicating this
over the weekend, but to ask the obvious question first: are you sure there's a
socket server listening on the loopback interface on port 5038? What happens if
you telnet 127.0.0.1 5038 from the shell?
[2013-01-17 11:56:25] anilsoneji at gmail dot com
Description:
fsockopen function not work on chrooted ubuntu linux os on android device.
Test script:
---
?php
$socket = fsockopen(127.0.0.1,5038, $errno, $errstr, 1);
fputs($socket, Action: Login\r\n);
fputs($socket, UserName: admin\r\n);
fputs($socket, Secret: devindia\r\n\r\n);
fputs($socket, Action: Command\r\n);
fputs($socket, Command: reload\r\n\r\n);
fputs($socket, Action: Logoff\r\n\r\n);
while (!feof($socket))
{
fgets($socket,200);
echo $value[$count].'br';
}
fclose($socket);
?
Actual result:
--
2013-01-17 15:52:20: (mod_fastcgi.c.2701) FastCGI-stderr: PHP Warning:
fsockopen(): unable to connect to 127.0.0.1:5038 (Unknown error) in
/var/www/test.php on line 2
--
Edit this bug report at https://bugs.php.net/bug.php?id=64009edit=1
Bug #63988 [Asn-Csd]: Two Date tests fail
Edit report at https://bugs.php.net/bug.php?id=63988edit=1
ID: 63988
Updated by: larue...@php.net
Reported by:larue...@php.net
Summary:Two Date tests fail
-Status: Assigned
+Status: Closed
Type: Bug
Package:Date/time related
PHP Version:5.5.0alpha2
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=4eae08729673492a1f545d366c5df5cd76af9bcf
Log: Fixed bug #63988 (Two Date tests fail) only for PHP-5.5
Previous Comments:
[2013-01-15 03:23:00] larue...@php.net
Description:
Test DateTime::modify() function : usage variation - Passing unexpected values
to
first argument $modify. [ext/date/tests/DateTime_modify_variation1.phpt]
Test date_modify() function : usage variation - Passing unexpected values to
second argument $format. [ext/date/tests/date_modify_variation2.phpt]
Test script:
---
$ cat ext/date/tests/DateTime_modify_variation1.diff
006+ object(DateTime)#3 (3) {
007+ [date]=
008+ string(19) 2009-01-31 14:28:41
009+ [timezone_type]=
010+ int(3)
011+ [timezone]=
012+ string(13) Europe/London
013+ }
006- bool(false)
011- bool(false)
016- bool(false)
018+ object(DateTime)#3 (3) {
019+ [date]=
020+ string(19) 2009-01-31 14:28:41
021+ [timezone_type]=
022+ int(3)
023+ [timezone]=
024+ string(13) Europe/London
025+ }
021- bool(false)
030+ object(DateTime)#3 (3) {
031+ [date]=
032+ string(19) 2009-01-31 14:28:41
033+ [timezone_type]=
034+ int(3)
035+ [timezone]=
036+ string(13) Europe/London
037+ }
036- bool(false)
042+ object(DateTime)#3 (3) {
043+ [date]=
044+ string(19) 2009-01-31 14:28:41
045+ [timezone_type]=
046+ int(3)
047+ [timezone]=
048+ string(13) Europe/London
049+ }
064+ object(DateTime)#3 (3) {
065+ [date]=
066+ string(19) 2009-01-31 10:05:00
067+ [timezone_type]=
068+ int(3)
069+ [timezone]=
070+ string(13) Europe/London
071+ }
071- bool(false)
076- bool(false)
081- bool(false)
086- bool(false)
091- bool(false)
096- bool(false)
101- bool(false)
106+ object(DateTime)#3 (3) {
107+ [date]=
108+ string(19) 2009-01-31 00:05:00
109+ [timezone_type]=
110+ int(3)
111+ [timezone]=
112+ string(13) Europe/London
113+ }
106- bool(false)
111- bool(false)
116- bool(false)
118+ object(DateTime)#3 (3) {
119+ [date]=
120+ string(19) 2009-01-31 00:05:00
121+ [timezone_type]=
122+ int(3)
123+ [timezone]=
124+ string(13) Europe/London
125+ }
121- bool(false)
126- bool(false)
130+ object(DateTime)#3 (3) {
131+ [date]=
132+ string(19) 2009-01-31 00:05:00
133+ [timezone_type]=
134+ int(3)
135+ [timezone]=
136+ string(13) Europe/London
137+ }
131- bool(false)
141- bool(false)
142+ object(DateTime)#3 (3) {
143+ [date]=
144+ string(19) 2009-01-31 00:05:00
145+ [timezone_type]=
146+ int(3)
147+ [timezone]=
148+ string(13) Europe/London
149+ }
146- bool(false)
154+ object(DateTime)#3 (3) {
155+ [date]=
156+ string(19) 2009-01-31 00:05:00
157+ [timezone_type]=
158+ int(3)
159+ [timezone]=
160+ string(13) Europe/London
161+ }
166+ object(DateTime)#3 (3) {
167+ [date]=
168+ string(19) 2009-01-31 00:05:00
169+ [timezone_type]=
170+ int(3)
171+ [timezone]=
172+ string(13) Europe/London
173+ }
178+ object(DateTime)#3 (3) {
179+ [date]=
180+ string(19) 2009-01-31 00:05:00
181+ [timezone_type]=
182+ int(3)
183+ [timezone]=
184+ string(13) Europe/London
185+ }
190+ object(DateTime)#3 (3) {
191+ [date]=
192+ string(19) 2009-01-31 00:05:00
193+ [timezone_type]=
194+ int(3)
195+ [timezone]=
196+ string(13) Europe/London
197+ }
202+ object(DateTime)#3 (3) {
203+ [date]=
204+ string(19) 2009-01-31 00:05:00
205+ [timezone_type]=
206+ int(3)
207+ [timezone]=
208+ string(13) Europe/London
209+ }
214+ object(DateTime)#3 (3) {
215+ [date]=
216+ string(19) 2009-01-31 00:05:00
217+ [timezone_type]=
218+ int(3)
219+ [timezone]=
220+ string(13) Europe/London
221+ }
226+ object(DateTime)#3 (3) {
227+ [date]=
228+ string(19) 2009-01-31 00:05:00
229+ [timezone_type]=
230+ int(3)
231+ [timezone]=
232+ string(13) Europe/London
233+ }
238+ object(DateTime)#3 (3) {
239+ [date]=
240+ string(19) 2009-01-31 00:05:00
241+ [timezone_type]=
242+ int(3)
243+ [timezone]=
244+ string(13) Europe/London
245+ }
250+ object(DateTime)#3 (3) {
251+ [date]=
252+ string(19) 2009-01-31 00:05:00
253+ [timezone_type]=
254+ int(3)
255+ [timezone]=
256+ string(13) Europe/London
257+ }
267+ object(DateTime)#3 (3) {
268+ [date]=
269+ string(19) 2009-01-31 00:05:00
270+ [timezone_type]=
271+ int(3)
272+ [timezone]=
273+ string(13) Europe/London
274+ }
279+ object(DateTime)#3 (3) {
280+ [date]=
281+
