Bug #64354 [Opn]: Unserialize array of objects whose class can't be autoloaded fail
Edit report at https://bugs.php.net/bug.php?id=64354&edit=1 ID: 64354 Updated by: larue...@php.net Reported by:alan at klestoff dot ru Summary:Unserialize array of objects whose class can't be autoloaded fail Status: Open Type: Bug Package:Scripting Engine problem Operating System: Debian PHP Version:5.3.22 Block user comment: N Private report: N New Comment: there is one thing I am not sure now. that is, if such exception threw, an notice of parse error will also be trigged which is a little confused. since it is not actually an unserializing error Previous Comments: [2013-03-05 08:08:05] larue...@php.net the similar problem maybe also exists in wakeup/sleep etc , will check them later [2013-03-05 08:07:07] larue...@php.net The following patch has been added/updated: Patch Name: bug64354.patch Revision: 1362470827 URL: https://bugs.php.net/patch-display.php?bug=64354&patch=bug64354.patch&revision=1362470827 [2013-03-05 08:06:37] larue...@php.net hmm, this is because one serializing triggered more than one exception. quick patch attached. [2013-03-05 07:27:04] alan at klestoff dot ru Description: We have serialized object of class A and array with 2 such objects Then we write autoload function which throws exception if can't find a file with class. And in first case - we have a normal behaviour (we can catch exception). In second we have uncaughted exception. Test script: --- https://bugs.php.net/bug.php?id=64354&edit=1
Bug #64349 [Fbk->Nab]: serialize don't work with class/object
Edit report at https://bugs.php.net/bug.php?id=64349&edit=1
ID: 64349
Updated by: ras...@php.net
Reported by:pprem at pprem dot net
Summary:serialize don't work with class/object
-Status: Feedback
+Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: Ubuntu 12.10
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
Nope, not a bug. From a security perspective it is safer to not output anything
when the input cannot be parsed. You were feeding it invalid UTF8. You should
always specify which charset your input is in when calling
htmlentities/htmlspecialchars
Previous Comments:
[2013-03-05 22:19:18] pprem at pprem dot net
Sorry Rasmus, I find the real problem and it's not unserialize or serialize.
I'm in France and my source files are by default in ISO-8859-1. New projects
are
in UTF-8, like yours by default I suppose.
I didn't see that htmlentities() has UTF-8 by default nor ISO-8859-1.
In the past,
encoded in ISO-8859-1 worked. Now, it didn't display anything (perhaps a bug in
htmlentities ?). If you encode in UTF-8, it works correctly.
I changed my program as this :
and all is good.
[2013-03-04 15:15:00] ras...@php.net
Your test script works fine here for me with PHP 5.4.13-dev
Do you have any special extensions loaded that might be affecting this?
Try it from the command line with php -n
[2013-03-04 14:54:48] pprem at pprem dot net
Description:
serialize don't work on stdClass anymore: nothing is get as return of
serialize($test) when $test is an object
Test script:
---
".htmlentities($start)."ok=".$nb_ok."nok=".$nb_nok."");
}
test_(5);
test_("254retet");
test_(array(54,7,687,"ihju",24,"","52s7"));
$test = new stdClass(); $test->bidule="57geré"; $test->truc=547;
$test->machin=54.47; $test->chose="dsf24sdg"; test_($test);
$test2 = new stdClass(); $test2->first="dflgid"; $test2->second=$test;
$test2->third=2; test_($test2);
?>
Expected result:
i:5;
ok=0
nok=100
s:8:"254retet";
ok=0
nok=100
a:7:
{i:0;i:54;i:1;i:7;i:2;i:687;i:3;s:4:"ihju";i:4;i:24;i:5;s:0:"";i:6;s:4:"52s7";}
ok=0
nok=100
O:8:"stdClass":4:
{s:6:"bidule";s:6:"57geré";s:4:"truc";i:547;s:6:"machin";d:54.469;s:
5:"chose";s:8:"dsf24sdg";}
ok=0
nok=100
O:8:"stdClass":3:{s:5:"first";s:6:"dflgid";s:6:"second";O:8:"stdClass":4:
{s:6:"bidule";s:6:"57geré";s:4:"truc";i:547;s:6:"machin";d:54.469;s:
5:"chose";s:8:"dsf24sdg";}s:5:"third";i:2;}
ok=0
nok=100
Actual result:
--
i:5;
ok=0
nok=100
s:8:"254retet";
ok=0
nok=100
a:7:
{i:0;i:54;i:1;i:7;i:2;i:687;i:3;s:4:"ihju";i:4;i:24;i:5;s:0:"";i:6;s:4:"52s7";}
ok=0
nok=100
ok=0
nok=100
ok=0
nok=100
--
Edit this bug report at https://bugs.php.net/bug.php?id=64349&edit=1
Bug #64349 [Com]: serialize don't work with class/object
Edit report at https://bugs.php.net/bug.php?id=64349&edit=1
ID: 64349
Comment by: pprem at pprem dot net
Reported by:pprem at pprem dot net
Summary:serialize don't work with class/object
Status: Feedback
Type: Bug
Package:Class/Object related
Operating System: Ubuntu 12.10
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
Sorry Rasmus, I find the real problem and it's not unserialize or serialize.
I'm in France and my source files are by default in ISO-8859-1. New projects
are
in UTF-8, like yours by default I suppose.
I didn't see that htmlentities() has UTF-8 by default nor ISO-8859-1.
In the past,
encoded in ISO-8859-1 worked. Now, it didn't display anything (perhaps a bug in
htmlentities ?). If you encode in UTF-8, it works correctly.
I changed my program as this :
and all is good.
Previous Comments:
[2013-03-04 15:15:00] ras...@php.net
Your test script works fine here for me with PHP 5.4.13-dev
Do you have any special extensions loaded that might be affecting this?
Try it from the command line with php -n
[2013-03-04 14:54:48] pprem at pprem dot net
Description:
serialize don't work on stdClass anymore: nothing is get as return of
serialize($test) when $test is an object
Test script:
---
".htmlentities($start)."ok=".$nb_ok."nok=".$nb_nok."");
}
test_(5);
test_("254retet");
test_(array(54,7,687,"ihju",24,"","52s7"));
$test = new stdClass(); $test->bidule="57geré"; $test->truc=547;
$test->machin=54.47; $test->chose="dsf24sdg"; test_($test);
$test2 = new stdClass(); $test2->first="dflgid"; $test2->second=$test;
$test2->third=2; test_($test2);
?>
Expected result:
i:5;
ok=0
nok=100
s:8:"254retet";
ok=0
nok=100
a:7:
{i:0;i:54;i:1;i:7;i:2;i:687;i:3;s:4:"ihju";i:4;i:24;i:5;s:0:"";i:6;s:4:"52s7";}
ok=0
nok=100
O:8:"stdClass":4:
{s:6:"bidule";s:6:"57geré";s:4:"truc";i:547;s:6:"machin";d:54.469;s:
5:"chose";s:8:"dsf24sdg";}
ok=0
nok=100
O:8:"stdClass":3:{s:5:"first";s:6:"dflgid";s:6:"second";O:8:"stdClass":4:
{s:6:"bidule";s:6:"57geré";s:4:"truc";i:547;s:6:"machin";d:54.469;s:
5:"chose";s:8:"dsf24sdg";}s:5:"third";i:2;}
ok=0
nok=100
Actual result:
--
i:5;
ok=0
nok=100
s:8:"254retet";
ok=0
nok=100
a:7:
{i:0;i:54;i:1;i:7;i:2;i:687;i:3;s:4:"ihju";i:4;i:24;i:5;s:0:"";i:6;s:4:"52s7";}
ok=0
nok=100
ok=0
nok=100
ok=0
nok=100
--
Edit this bug report at https://bugs.php.net/bug.php?id=64349&edit=1
Bug #60890 [Opn->Nab]: Can not read tgz file through Phar class, but related path works
Edit report at https://bugs.php.net/bug.php?id=60890&edit=1 ID: 60890 Updated by: ralphschind...@php.net Reported by:cornelius dot howl at gmail dot com Summary:Can not read tgz file through Phar class, but related path works -Status: Open +Status: Not a bug Type: Bug Package:PHAR related Operating System: Mac OS 10.6 PHP Version:5.3.9 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The filename passed to the first parameter of the Phar constructor must contain .phar in the file's extension to be created/opened. Previous Comments: [2012-01-26 12:04:29] cornelius dot howl at gmail dot com Description: Can not read tgz file with realpath, offsetGet works, offsetSet doesnt work. $p['file'] = 'content'; will fail. See: https://gist.github.com/1682446 Test script: --- https://gist.github.com/1682446 Actual result: -- See: https://gist.github.com/1682446 -- Edit this bug report at https://bugs.php.net/bug.php?id=60890&edit=1
[PHP-BUG] Req #64359 [NEW]: strftime crash with php/vc11
From: ab
Operating system: Windows
PHP version: Irrelevant
Package: Date/time related
Bug Type: Feature/Change Request
Bug description:strftime crash with php/vc11
Description:
PHP crashes only when compiled with VC11. I could track it back with 5.4.1
compiled with VC11. Another not obvious crash happens with 5.5/VC9 using
O+. Here's the backtrace 5.5/VC11:
msvcr110d.dll!_invoke_watson(const wchar_t * pszExpression, const wchar_t
* pszFunction, const wchar_t * pszFile, unsigned int nLine, unsigned int
pReserved) Line 131C++
msvcr110d.dll!_invoke_watson_if_error(int _ExpressionError, const wchar_t
* _Expression, const wchar_t * _Function, const wchar_t * _File, unsigned
int _Line, unsigned int _Reserved) Line 730C
msvcr110d.dll!_W_expandtime(localeinfo_struct * plocinfo, wchar_t
specifier, const tm * timeptr, wchar_t * * string, unsigned int * left,
__lc_time_data * lc_time, unsigned int alternate_form) Line 722C++
msvcr110d.dll!_Wcsftime_l(wchar_t * string, unsigned int maxsize, const
wchar_t * format, const tm * timeptr, void * lc_time_arg, localeinfo_struct
* plocinfo) Line 323C++
msvcr110d.dll!_Strftime_l(char * string, unsigned int maxsize, const char
* format, const tm * timeptr, void * lc_time_arg, localeinfo_struct *
plocinfo) Line 285C++
msvcr110d.dll!strftime(char * string, unsigned int maxsize, const char *
format, const tm * timeptr) Line 189C++
php5_debug.dll!php_strftime(int ht, _zval_struct * return_value,
_zval_struct * * return_value_ptr, _zval_struct * this_ptr, int
return_value_used, int gmt) Line 1631C
php5_debug.dll!zif_strftime(int ht, _zval_struct * return_value,
_zval_struct * * return_value_ptr, _zval_struct * this_ptr, int
return_value_used) Line 1657C
php5_debug.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data *
execute_data) Line 542C
php5_debug.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data *
execute_data) Line 2321C
php5_debug.dll!execute_ex(_zend_execute_data * execute_data) Line 356C
php5_debug.dll!zend_execute(_zend_op_array * op_array) Line 381C
php5_debug.dll!zend_eval_stringl(char * str, int str_len, _zval_struct *
retval_ptr, char * string_name) Line 1181C
php5_debug.dll!zend_eval_stringl_ex(char * str, int str_len, _zval_struct
* retval_ptr, char * string_name, int handle_exceptions) Line 1228C
php5_debug.dll!zend_eval_string_ex(char * str, _zval_struct * retval_ptr,
char * string_name, int handle_exceptions) Line 1239C
php.exe!do_cli(int argc, char * * argv) Line 1028C
php.exe!main(int argc, char * * argv) Line 1364C
php.exe!__tmainCRTStartup() Line 536C
php.exe!mainCRTStartup() Line 377C
kernel32.dll!@BaseThreadInitThunk@12 ()Unknown
ntdll.dll!___RtlUserThreadStart@8 ()Unknown
ntdll.dll!__RtlUserThreadStart@8 ()Unknown
Test script:
---
ext/date/tests/009_win32.phpt
or this snippet
var_dump(strftime('%a %A %b %B %c %d %H %I %j %m %M %p %S %U %W %w %x %X %y
%Y %Z %z %%', mktime(0,0,0, 6, 27, 2013)));
Expected result:
no crash
Actual result:
--
PHP crash
--
Edit bug report at https://bugs.php.net/bug.php?id=64359&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64359&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64359&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64359&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64359&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64359&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64359&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64359&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64359&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64359&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64359&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64359&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64359&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64359&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64359&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64359&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64359&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64359&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64359&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64359&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64359&r=mysqlcfg
Bug #55514 [Nab]: Can't install PHP 5.2.17. Error code 2738
Edit report at https://bugs.php.net/bug.php?id=55514&edit=1
ID: 55514
Updated by: re...@php.net
Reported by:Chris_Walsh at Prodigy dot bet
Summary:Can't install PHP 5.2.17. Error code 2738
Status: Not a bug
Type: Bug
Package:Unknown/Other Function
Operating System: Windows Vista
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
@iamjahid your question seems nothing to do with the bug report.
PS: please refer: http://www.w3schools.com/tags/att_option_selected.asp
for what you looking for.
Previous Comments:
[2013-03-05 16:25:32] iamjahid at gmail dot com
Plz Help. In drop down menu it always show year 2005. But i want to set default
year.
echo"DATE";echo " ";
echo "";
for( $i=1;$i<=31;$i++)
echo "".$i."";
echo"";echo " ";
echo "";
$months =
array("January","February","March","April","May","June","July","Auguest","September","October","November","December");
foreach( $months as $month )
{
echo "".$month."";
};
echo"";
echo " ";
echo "";
for( $year=2005;$year<=2020;$year++)
echo "".$year."";
echo"";
[2011-08-26 22:56:48] johan...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
The current version is 5.3.8. Windows downloads are on
http://windows.php.net/download/
[2011-08-26 21:34:54] Chris_Walsh at Prodigy dot net
Did I commit a typo in my email address?? should be "dot net" not "dot bet" of
course.
[2011-08-26 21:23:34] Chris_Walsh at Prodigy dot bet
Description:
I have seen other bugs categorized as being in the "Windows Installer" package
but I don't have that option in the dropdown menu so I have put it as
"unknown/other"
I am trying to install 5.2.17 because, according to
http://windows.php.net/download/ it is what I need to use with Apache. (I don't
see a later version for Windows that looks usable) The "PHP version" drop-down
implies I should be using something more recent that 5.2.x but the Windows
download page doesn't give me the options to use something more current.
I want to install php-5.2.17-Win32-VC6-x86.msi (as opposed to the "nts"
version) because it has the option for Apache 2.2 in the Web Server Setup
options.
If I need to use a more recent version, then the info at
http://windows.php.net/download/ is misleading at best: "Which version do I
choose? If you are using PHP with Apache 1 or Apache2 from apache.org you need
to use the VC6 versions of PHP"
Here's my situation:
I get most of the way through the installation and I get an error pop-up saying
"the installer has encountered an unexpected error installing this package.
This may indicate a problem with this package. The error code is 2738"
I have done a great deal of searching on this and have found many references
recommending doing some registry changes. This page in particular seems to
explain well what to do:
http://blogs.msdn.com/b/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx
I have done what it recommends yet I still get the error.
The keys mentioned are not in HKCU, which I checked using regedit.
VBScript, B54F3741-5B07-11CF-A4B0-00AA004A55E8 is in HKEY_LOCAL_MACHINE
This dll is the one that causes the 2738 error, apparently.
JScript, F414C260-6AC0-11CF-B6D1-00AA0058 is HKEY_CLASSES_ROOT, which I
mention because it is referenced in the link I cite above.
I have tried deleting and re-registering the dlls ("regsvr32 vbscript.dll) and
that didn't help.
I have hit a dead end.
Expected result:
Would like to be able to get php installed on my Vista PC.
Actual result:
--
Error
--
Edit this bug report at https://bugs.php.net/bug.php?id=55514&edit=1
Bug #64343 [Opn]: PharData::extractTo fails for tarball created by BSD tar
Edit report at https://bugs.php.net/bug.php?id=64343&edit=1
ID: 64343
Updated by: ralphschind...@php.net
Reported by:njh at aelius dot com
Summary:PharData::extractTo fails for tarball created by BSD
tar
Status: Open
Type: Bug
Package:PHAR related
Operating System: Mac OS 10.7.5
PHP Version:5.4.12
-Assigned To:
+Assigned To:ralphschindler
Block user comment: N
Private report: N
New Comment:
How did you create these tar files? On mac (10.8.2), I did:
tar cvf my-bsd.tar test.txt
This created a ustar format tar file. Yours seems to be a pax format tar file,
which I can't see how that is the default format on mac?
Previous Comments:
[2013-03-03 19:52:02] njh at aelius dot com
Description:
The extractTo() method in Phar doesn't seem to work with tar archives generated
using the BSD version of the tar tool, which is the version that comes pre-
installed on Mac OS X.
I have uploaded two sample tar files, which both contain a single test.txt file:
http://www.aelius.com/njh/tmp/tartest/test-bsd.tar.gz
http://www.aelius.com/njh/tmp/tartest/test-gnu.tar.gz
When run the GNU generated tar file works correctly but the BSD generated tar
file fails.
This problem came up with trying to install dependencies using composer, that
had been generated using BSD tar on Mac OS X:
https://github.com/composer/composer/issues/1492
Test script:
---
extractTo('extracted-gnu');
$phar = new PharData('test-bsd.tar.gz');
$phar->extractTo('extracted-bsd');
Expected result:
Both the test-bsd.tar.gz and test-gnu.tar.gz should extract the test.txt file.
Actual result:
--
Fatal error: Uncaught exception 'UnexpectedValueException' with message 'phar
error: "/tmp/tartest/test-bsd.tar.gz" is a corrupted tar file (checksum
mismatch
of file "18 uid=1451698731
20 ctime=1362335175
20 atime=1362335267
24 SCHILY.dev=234881029
23 SCHILY.ino=1224")' in /tmp/tartest/test.php:5
Stack trace:
#0 /tmp/tartest/test.php(5): PharData->__construct('test-bsd.tar.gz')
#1 {main}
thrown in /tmp/tartest/test.php on line 5
--
Edit this bug report at https://bugs.php.net/bug.php?id=64343&edit=1
Bug #55514 [Com]: Can't install PHP 5.2.17. Error code 2738
Edit report at https://bugs.php.net/bug.php?id=55514&edit=1
ID: 55514
Comment by: iamjahid at gmail dot com
Reported by:Chris_Walsh at Prodigy dot bet
Summary:Can't install PHP 5.2.17. Error code 2738
Status: Not a bug
Type: Bug
Package:Unknown/Other Function
Operating System: Windows Vista
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Plz Help. In drop down menu it always show year 2005. But i want to set default
year.
echo"DATE";echo " ";
echo "";
for( $i=1;$i<=31;$i++)
echo "".$i."";
echo"";echo " ";
echo "";
$months =
array("January","February","March","April","May","June","July","Auguest","September","October","November","December");
foreach( $months as $month )
{
echo "".$month."";
};
echo"";
echo " ";
echo "";
for( $year=2005;$year<=2020;$year++)
echo "".$year."";
echo"";
Previous Comments:
[2011-08-26 22:56:48] johan...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
The current version is 5.3.8. Windows downloads are on
http://windows.php.net/download/
[2011-08-26 21:34:54] Chris_Walsh at Prodigy dot net
Did I commit a typo in my email address?? should be "dot net" not "dot bet" of
course.
[2011-08-26 21:23:34] Chris_Walsh at Prodigy dot bet
Description:
I have seen other bugs categorized as being in the "Windows Installer" package
but I don't have that option in the dropdown menu so I have put it as
"unknown/other"
I am trying to install 5.2.17 because, according to
http://windows.php.net/download/ it is what I need to use with Apache. (I don't
see a later version for Windows that looks usable) The "PHP version" drop-down
implies I should be using something more recent that 5.2.x but the Windows
download page doesn't give me the options to use something more current.
I want to install php-5.2.17-Win32-VC6-x86.msi (as opposed to the "nts"
version) because it has the option for Apache 2.2 in the Web Server Setup
options.
If I need to use a more recent version, then the info at
http://windows.php.net/download/ is misleading at best: "Which version do I
choose? If you are using PHP with Apache 1 or Apache2 from apache.org you need
to use the VC6 versions of PHP"
Here's my situation:
I get most of the way through the installation and I get an error pop-up saying
"the installer has encountered an unexpected error installing this package.
This may indicate a problem with this package. The error code is 2738"
I have done a great deal of searching on this and have found many references
recommending doing some registry changes. This page in particular seems to
explain well what to do:
http://blogs.msdn.com/b/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx
I have done what it recommends yet I still get the error.
The keys mentioned are not in HKCU, which I checked using regedit.
VBScript, B54F3741-5B07-11CF-A4B0-00AA004A55E8 is in HKEY_LOCAL_MACHINE
This dll is the one that causes the 2738 error, apparently.
JScript, F414C260-6AC0-11CF-B6D1-00AA0058 is HKEY_CLASSES_ROOT, which I
mention because it is referenced in the link I cite above.
I have tried deleting and re-registering the dlls ("regsvr32 vbscript.dll) and
that didn't help.
I have hit a dead end.
Expected result:
Would like to be able to get php installed on my Vista PC.
Actual result:
--
Error
--
Edit this bug report at https://bugs.php.net/bug.php?id=55514&edit=1
Bug #64333 [Dup]: Can´t configure with LDAP
Edit report at https://bugs.php.net/bug.php?id=64333&edit=1 ID: 64333 User updated by:hudson dot melo at fazenda dot mg dot gov dot br Reported by:hudson dot melo at fazenda dot mg dot gov dot br Summary:Can´t configure with LDAP Status: Duplicate Type: Bug Package:LDAP related Operating System: Solaris 10 PHP Version:5.3.22 Block user comment: N Private report: N New Comment: Unfortunately, don´t work. I tried to compile without OCI, but the error continue. Look: ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-config-file-path=/usr/local/apache2/conf --enable-sigchild --enable-mbstring --with-gd --with-openssl=/usr/local/ssl --with-curl=/usr/local/bin/curl --with-ldap=/usr --with-xmlrpc Error: checking for LDAP support... yes checking for LDAP Cyrus SASL support... no checking for 3 arg ldap_set_rebind_proc... yes checking for ldap_parse_result... no checking for ldap_parse_reference... no checking for ldap_start_tls_s... no checking for ldap_bind_s... no configure: error: LDAP build check failed. Please check config.log for more information. Previous Comments: [2013-03-01 19:34:44] s...@php.net See https://bugs.php.net/bug.php?id=61450 [2013-03-01 19:32:33] s...@php.net See https://github.com/php/php-src/pull/19 [2013-03-01 18:21:11] hudson dot melo at fazenda dot mg dot gov dot br Description: Hi, in any version 5.3.x of php with solaris 10 sparc/x86 appear the same ERROR. I need help. checking for ldap_parse_result... no checking for ldap_parse_reference... no checking for ldap_start_tls_s... no checking for ldap_bind_s... no configure: error: LDAP build check failed. Please check config.log for more information. My environment: SunOS geia 5.10 Generic_118833-36 sun4v sparc SUNW,Sun-Fire-T200 or SunOS amicoz2 5.10 Generic_147441-01 i86pc i386 i86pc LD_LIBRARY_PATH=/oracle/app/oracle/product/instantclient_10.2.0.3:/usr/local/lib:/usr/sfw/lib:/usr/local/ssl/lib PATH=/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/bin:/usr/local/BerkeleyDB.4.2:/usr/local/ssl/bin:/usr/sfw/bin:/usr/ccs/bin command line PHP: ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-config-file-path=/usr/local/apache2/conf --with-oci8=instantclient,/oracle/app/oracle/product/instantclient_10.2.0.3 --enable-sigchild --enable-mbstring --with-gd --with-openssl=/usr/local/ssl --with-curl=/usr/local/bin/curl --with-ldap=/usr --with-xmlrpc Thanks. Hudson Actual result: -- checking for ldap_parse_result... no checking for ldap_parse_reference... no checking for ldap_start_tls_s... no checking for ldap_bind_s... no configure: error: LDAP build check failed. Please check config.log for more information. -- Edit this bug report at https://bugs.php.net/bug.php?id=64333&edit=1
Bug #52312 [Com]: PHP safe_mode/open_basedir - lstat performance problem
Edit report at https://bugs.php.net/bug.php?id=52312&edit=1 ID: 52312 Comment by: Terry at ellisons dot org dot uk Reported by:v dot damore at gmail dot com Summary:PHP safe_mode/open_basedir - lstat performance problem Status: Analyzed Type: Bug Package:Safe Mode/open_basedir Operating System: Linux PHP Version:5.2.13 Block user comment: N Private report: N New Comment: Rasmus, picking up our 2013-02-22 23:17 / 23:26 UTC conversation, I've thought about this some further and gone through some test cases on the debugger. Having walked through these call stacks, my view is that the PHP / Zend path scanning, file checking and opening is a tangled mess. A typical open goes through sometimes 7 seven wrapping layers each of which can do compound path resolution. The only reason that this doesn't end up slugging performance is because the lowest level tsrm_realparth_r() uses a resolution cache and short-circuits the actual I/O requests 95+% of the time. The CVE-2006-5178 advisory really to a vulerability in the open_basedir checks. The root issue was that a key check in php_check_specific_open_basedir() was using this cached path resolution; this introduced the vulnerability because the caching enabled a race condition. The fix was to turn of ALL realpath resolution caching. Yes this addressed the vulnerability, but at the price of killing performance in the typical usecase where open_basedir might be used. This was unnecessary overkill. If you think about it realpath caching itself doesn't introduce any vulnerability. The issue is that the open itself -- or in this case the preceding php_check_specific_open_basedir() check must disable any caching for that one check alone. Consider an example there the base dir is /a/b/c and some path needs to be checked by php_check_specific_open_basedir(). There's not vulnerability introduced by any previous resolution being used. This will result in one of two scenarios: * The resolved path is not of the form /a/b/c in which case the error is thrown * The resolved path is of the form /a/b/c... but the actual path might contain raced symlinks, so it must be scanned (by tsrm_realparth_r) to ensure that no links are extant immediately prior to the open. There is also a sound case for curtailing this scan on a root-owned directory, but this of second order. Implementing this is a small code change. (i) First drop the open_basedir predicated clearing of CWDG(realpath_cache_size_limit) = 0 in main/main.c:php_module_startup(). (ii) introduce a per-call mechanism for disabling the cache. This could be done by adding a flag to realpath, but the two variants (ZTS and none-ZTS) and the wide use of the wrapper VCWD_REALPATH() macro might complicate this. An alternative would be to add another flag to the PG() structure, checking this in tsrm_realparth_r() and setting it in php_check_specific_open_basedir() around the VCWD_REALPATH(path_tmp, resolved_name) call. Reactions / Thoughts? Is it worth me proposing a patch? Previous Comments: [2013-02-23 16:06:50] Terry at ellisons dot org dot uk Yes Rasmus. We both know that; but this won't be address without something like an LPC-style file-based cache to preserve context across image activations, but all this isn't that relevant to #52312 -- "PHP safe_mode/open_basedir - lstat performance problem". What is relevant are my points about a require_once 6 sub-directories down taking 13 stats and 1 open with open_basedir unset and 60 stats and 1 open if it is set, and that the security requirement could still be implemented within the former stat number if done correctly. This isn't a material problem for single source file scripts, but MediaWiki, Wordpress and the like typically load in ~100 modules generating ~6K stats per request. And this does become a problem. [2013-02-23 15:22:59] ras...@php.net First-request cli isn't going to have a populated realpath cache no matter what we do since this cache is per-process and in no way shared nor persistent across different processes. [2013-02-23 13:20:03] Terry at ellisons dot org dot uk The above discussion was largely about the I/O overheads with open_basedir specified, so my figures where in that context, and dd2.inc is just an empty class, but this isnt relevant to its inclusion. Try: echo "">dummy.inc pwd strace -tt -o /tmp/strace.log \ php -d realpath_cache_ttl= -d open_basedir=$(pwd) \ -r '$x="./dummy.inc"; require_once($x);' to see what I mean (I did this from 6 dir levels down which is pretty typical of web set ups.) sinc
Bug #43817 [Asn]: opendir() fails on Windows directories with parent directory unaccessible
Edit report at https://bugs.php.net/bug.php?id=43817&edit=1 ID: 43817 Updated by: paj...@php.net Reported by:losd at mail dot dk Summary:opendir() fails on Windows directories with parent directory unaccessible Status: Assigned Type: Bug Package:Directory function related Operating System: win32 only - Windows Server 2003 PHP Version:5.3.0beta1 Assigned To:pajoye Block user comment: N Private report: N New Comment: @mindless at mindless999 dot net That's correct, I forgot to add this info to this bug report (present in another one). It is required to allow the underlying Windows API to get through the directories while it won't allow the user to access it. Previous Comments: [2013-03-05 12:08:05] mindless at mindless999 dot net Issue still exists in 5.3.22 Workaround is to give the user under which the website is running (advanced) "list folder / read data" permissions on the parent folder. this is the only permission required. [2013-01-16 09:20:16] paj...@php.net It does matter. The reasons are: 1. Windows support case sensitive filesystems (in any modern versions) 2. the real path stat cache is case sensitive, for portability and performance, by design. However, no matter how the case is, you have to set the attributes permissions. If it is not allowed to read the attributes, php won't be able to load that file or path. And again, it has absolutely nothing do with case sensitive paths. Last but not least, if you see the bug status, it is still open as a bug, but it is about other issues caused by FindFirstFile, not the case sensitivity. [2013-01-16 06:42:04] d at hp23c dot dk In Windows, it _does not matter_ if it is C:\fOo or c:\foo. If you do not lowercase (or uppercase, or whatever) to compare, it is a bug. [2013-01-14 11:26:46] paj...@php.net Ok, the actual issue is about setting the right permissions. It is possible to block read&write and other operations but the read of the attribute of a given path must be allowed. It is used by almost all file functions(Find*, GetLong/ShortPathName, etc.). Without the permissions allowing to read attributes, we won't be able to fetch the actual name (ie: c:\Foo is given but the actual name is c:\fOo). We used the actual to store it in the real cache and avoid to have to lower case all paths before each file operation. Can you try to set the perms correctly and tell me if it works out for you? Should work on any windows supported version. [2013-01-10 12:34:52] paj...@php.net Quick notice to help to understand the problem describe here: The main problem here is that FindFirstFile requires access to all elements of a given path, which is not the case here. To work around this limitation while keeping the realpath cache working nicely is not that easy. 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=43817 -- Edit this bug report at https://bugs.php.net/bug.php?id=43817&edit=1
Bug #43817 [Com]: opendir() fails on Windows directories with parent directory unaccessible
Edit report at https://bugs.php.net/bug.php?id=43817&edit=1 ID: 43817 Comment by: mindless at mindless999 dot net Reported by:losd at mail dot dk Summary:opendir() fails on Windows directories with parent directory unaccessible Status: Assigned Type: Bug Package:Directory function related Operating System: win32 only - Windows Server 2003 PHP Version:5.3.0beta1 Assigned To:pajoye Block user comment: N Private report: N New Comment: Issue still exists in 5.3.22 Workaround is to give the user under which the website is running (advanced) "list folder / read data" permissions on the parent folder. this is the only permission required. Previous Comments: [2013-01-16 09:20:16] paj...@php.net It does matter. The reasons are: 1. Windows support case sensitive filesystems (in any modern versions) 2. the real path stat cache is case sensitive, for portability and performance, by design. However, no matter how the case is, you have to set the attributes permissions. If it is not allowed to read the attributes, php won't be able to load that file or path. And again, it has absolutely nothing do with case sensitive paths. Last but not least, if you see the bug status, it is still open as a bug, but it is about other issues caused by FindFirstFile, not the case sensitivity. [2013-01-16 06:42:04] d at hp23c dot dk In Windows, it _does not matter_ if it is C:\fOo or c:\foo. If you do not lowercase (or uppercase, or whatever) to compare, it is a bug. [2013-01-14 11:26:46] paj...@php.net Ok, the actual issue is about setting the right permissions. It is possible to block read&write and other operations but the read of the attribute of a given path must be allowed. It is used by almost all file functions(Find*, GetLong/ShortPathName, etc.). Without the permissions allowing to read attributes, we won't be able to fetch the actual name (ie: c:\Foo is given but the actual name is c:\fOo). We used the actual to store it in the real cache and avoid to have to lower case all paths before each file operation. Can you try to set the perms correctly and tell me if it works out for you? Should work on any windows supported version. [2013-01-10 12:34:52] paj...@php.net Quick notice to help to understand the problem describe here: The main problem here is that FindFirstFile requires access to all elements of a given path, which is not the case here. To work around this limitation while keeping the realpath cache working nicely is not that easy. [2012-10-18 11:49:00] y dot korotia at hotmail dot com are you going to fix it for Windows or not? I've wasted about 4 hours because of this bug! installed ZendServer with 5.3x To access folder I must give access to its parent. what a f..? 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=43817 -- Edit this bug report at https://bugs.php.net/bug.php?id=43817&edit=1
Bug #64340 [ReO]: sockets tests failed
Edit report at https://bugs.php.net/bug.php?id=64340&edit=1 ID: 64340 Updated by: larue...@php.net Reported by:re...@php.net Summary:sockets tests failed Status: Re-Opened Type: Bug Package:Sockets related Operating System: Mac OSX 10.8 PHP Version:5.5.0alpha5 Assigned To:laruence Block user comment: N Private report: N New Comment: there is one workaround: #ifdef __APPLE__ #define IPV6_PKTINFOIPV6_2292PKTINFO #define IPV6_HOPLIMIT IPV6_2292HOPLIMIT #define IPV6_NEXTHOPIPV6_2292NEXTHOP #define IPV6_HOPOPTSIPV6_2292HOPOPTS #define IPV6_DSTOPTSIPV6_2292DSTOPTS #define IPV6_RTHDR IPV6_2292RTHDR #define IPV6_PKTOPTIONS IPV6_2292PKTOPTIONS #endif will keep finding more better solution Previous Comments: [2013-03-05 10:47:57] re...@php.net Hi, the attached patch is intend to fix IPV6_PKTINFO failure, the commit didn't contain all of the fix. but only the macro define. The patch isn't break build. but the partially applied patch. only define __APPLE_USE_RFC is not enough. the rest of the changes should be applied too. I couldn't figure out a better solution which didn't require header inclusion order, since the macro itself required to be defined first. [2013-03-05 06:05:33] larue...@php.net I revert the previous fix, since the build broken. I am wondering, if don't fix that, what's the problem is? thanks [2013-03-05 06:04:06] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=3f67d5ae434236be1db2ee54baf85725ac7b6a56 Log: Revert "Fixed Bug #64340 (sockets tests failed) Patch by Reeze" [2013-03-05 05:58:56] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=3f67d5ae434236be1db2ee54baf85725ac7b6a56 Log: Revert "Fixed Bug #64340 (sockets tests failed) Patch by Reeze" [2013-03-04 18:21:21] re...@php.net Hi, cataphract The macro __APPLE_USE_RFC_3542 must be defined before including netinet/in.h, but not all of the our c files include php_sockets.h in the topmost, but by indirectly include other header files. eg: $ head -n 1 conversions.c sockaddr_conv.h $ header -n 5 sockaddr_conv.h ... #include #include "php_sockets.h" /* php_socket */ php_network.h wil be included before the macro defined. and php_network.h has to been included before php_sockets.h, so I have to move conversion.h up instead. in the mean time, in convesion.h was included before php_sockets.h too, so I have to move it up to meet the requirement of the macro. The current partial patch breaks the build because of missing the left part: Undefined symbols for architecture x86_64: "_from_zval_write_in6_pktinfo", referenced from: _init_ancillary_registry in sendrecvmsg.o _php_do_setsockopt_ipv6_rfc3542 in sendrecvmsg.o "_to_zval_read_in6_pktinfo", referenced from: _init_ancillary_registry in sendrecvmsg.o _php_do_getsockopt_ipv6_rfc3542 in sendrecvmsg.o ld: symbol(s) not found for architecture x86_64 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=64340 -- Edit this bug report at https://bugs.php.net/bug.php?id=64340&edit=1
Bug #53437 [PATCH]: Crash when using unserialized DatePeriod instance
Edit report at https://bugs.php.net/bug.php?id=53437&edit=1 ID: 53437 Patch added by: a...@php.net Reported by:from dot php dot net at brainbox dot cz Summary:Crash when using unserialized DatePeriod instance Status: Assigned Type: Bug Package:Date/time related Operating System: Windows XP SP3 PHP Version:5.3.3 Assigned To:derick Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: glopes_date_5.4.patch Revision: 1362482416 URL: https://bugs.php.net/patch-display.php?bug=53437&patch=glopes_date_5.4.patch&revision=1362482416 Previous Comments: [2013-03-05 11:19:39] a...@php.net The following patch has been added/updated: Patch Name: glopes_date_5.3.patch Revision: 1362482379 URL: https://bugs.php.net/patch-display.php?bug=53437&patch=glopes_date_5.3.patch&revision=1362482379 [2013-03-04 12:43:19] a...@php.net Here's the corresponding BT on windows, php5.dll!timelib_time_clone(timelib_time * orig) Line 52C php5.dll!date_period_it_rewind(_zend_object_iterator * iter) Line 1910C php5.dll!ZEND_FE_RESET_SPEC_CV_HANDLER(_zend_execute_data * execute_data) Line 22777C php5.dll!execute(_zend_op_array * op_array) Line 107C php5.dll!zend_execute_scripts(int type, _zval_struct * * retval, int file_count, ...) Line 1259C php5.dll!php_execute_script(_zend_file_handle * primary_file) Line 2316C php.exe!00b3246e()Unknown [Frames below may be incorrect and/or missing, no symbols loaded for php.exe] ntdll.dll!_RtlpHeapFindListLookupEntry@20 ()Unknown ntdll.dll!_RtlpFindEntry@8 ()Unknown 024d2608()Unknown msvcr90.dll!__getptd_noexit ()Unknown msvcr90.dll!__getptd ()Unknown msvcr90.dll!_LocaleUpdate::_LocaleUpdate(struct localeinfo_struct *)Unknown msvcr90.dll!__ismbcalpha ()Unknown msvcr90.dll!__ismbblead ()Unknown msvcr90.dll!__lock ()Unknown msvcr90.dll!__setargv ()Unknown msvcr90.dll!___getmainargs ()Unknown php.exe!00b32ca6()Unknown php.exe!00b32dca()Unknown kernel32.dll!@BaseThreadInitThunk@12 ()Unknown ntdll.dll!___RtlUserThreadStart@8 ()Unknown ntdll.dll!__RtlUserThreadStart@8 ()Unknown [2011-12-21 15:10:35] tony2...@php.net <@Cataphrac> (the Date(Period|Interval) serialization patch is here btw: http://nebm.ist.utl.pt/~glopes/misc/date_period_interval_ser.diff ) [2011-12-06 06:07:24] der...@php.net Automatic comment from SVN on behalf of derick Revision: http://svn.php.net/viewvc/?view=revision&revision=320479 Log: - Added a test case for #53437. [2011-01-09 06:00:35] cataphr...@php.net Reassigning to Derick, as the patch I've written is under his consideration. 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=53437 -- Edit this bug report at https://bugs.php.net/bug.php?id=53437&edit=1
Bug #53437 [PATCH]: Crash when using unserialized DatePeriod instance
Edit report at https://bugs.php.net/bug.php?id=53437&edit=1 ID: 53437 Patch added by: a...@php.net Reported by:from dot php dot net at brainbox dot cz Summary:Crash when using unserialized DatePeriod instance Status: Assigned Type: Bug Package:Date/time related Operating System: Windows XP SP3 PHP Version:5.3.3 Assigned To:derick Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: glopes_date_5.3.patch Revision: 1362482379 URL: https://bugs.php.net/patch-display.php?bug=53437&patch=glopes_date_5.3.patch&revision=1362482379 Previous Comments: [2013-03-04 12:43:19] a...@php.net Here's the corresponding BT on windows, php5.dll!timelib_time_clone(timelib_time * orig) Line 52C php5.dll!date_period_it_rewind(_zend_object_iterator * iter) Line 1910C php5.dll!ZEND_FE_RESET_SPEC_CV_HANDLER(_zend_execute_data * execute_data) Line 22777C php5.dll!execute(_zend_op_array * op_array) Line 107C php5.dll!zend_execute_scripts(int type, _zval_struct * * retval, int file_count, ...) Line 1259C php5.dll!php_execute_script(_zend_file_handle * primary_file) Line 2316C php.exe!00b3246e()Unknown [Frames below may be incorrect and/or missing, no symbols loaded for php.exe] ntdll.dll!_RtlpHeapFindListLookupEntry@20 ()Unknown ntdll.dll!_RtlpFindEntry@8 ()Unknown 024d2608()Unknown msvcr90.dll!__getptd_noexit ()Unknown msvcr90.dll!__getptd ()Unknown msvcr90.dll!_LocaleUpdate::_LocaleUpdate(struct localeinfo_struct *)Unknown msvcr90.dll!__ismbcalpha ()Unknown msvcr90.dll!__ismbblead ()Unknown msvcr90.dll!__lock ()Unknown msvcr90.dll!__setargv ()Unknown msvcr90.dll!___getmainargs ()Unknown php.exe!00b32ca6()Unknown php.exe!00b32dca()Unknown kernel32.dll!@BaseThreadInitThunk@12 ()Unknown ntdll.dll!___RtlUserThreadStart@8 ()Unknown ntdll.dll!__RtlUserThreadStart@8 ()Unknown [2011-12-21 15:10:35] tony2...@php.net <@Cataphrac> (the Date(Period|Interval) serialization patch is here btw: http://nebm.ist.utl.pt/~glopes/misc/date_period_interval_ser.diff ) [2011-12-06 06:07:24] der...@php.net Automatic comment from SVN on behalf of derick Revision: http://svn.php.net/viewvc/?view=revision&revision=320479 Log: - Added a test case for #53437. [2011-01-09 06:00:35] cataphr...@php.net Reassigning to Derick, as the patch I've written is under his consideration. [2010-12-01 21:50:03] fel...@php.net Duplicated of #52113 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=53437 -- Edit this bug report at https://bugs.php.net/bug.php?id=53437&edit=1
Req #29812 [Com]: rename() don't overwrite existing files at windows (as at linux)
Edit report at https://bugs.php.net/bug.php?id=29812&edit=1 ID: 29812 Comment by: tom at r dot je Reported by:melker at kuh dot at Summary:rename() don't overwrite existing files at windows (as at linux) Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: winxp PHP Version:4.3.8 Block user comment: N Private report: N New Comment: This isn't restricted to Windows XP but also affects other versions. I've tested Windows Vista and Windows Server 2008, both have this same problem. Previous Comments: [2004-08-24 12:36:20] melker at kuh dot at Description: Hi, rename ( 'file1', 'file2' ); behaviour at linux: If there is a 'file2', the file2 will be overwritten by file1. at windows xp: If there is a 'file2', a warning is given and the file2 isn't overwritten with file1. Reproduce code: --- rename ( 'file1', 'file2' ); Expected result: I would expect, that rename() works with the same behaviour at all operating systems. So, please overwrite existing files or give a warning at all os. Actual result: -- rename() at linux, existing files will be overwritten, at winxp, the rename-process fails, a php-warning is given. -- Edit this bug report at https://bugs.php.net/bug.php?id=29812&edit=1
Bug #64340 [Csd->ReO]: sockets tests failed
Edit report at https://bugs.php.net/bug.php?id=64340&edit=1 ID: 64340 Updated by: re...@php.net Reported by:re...@php.net Summary:sockets tests failed -Status: Closed +Status: Re-Opened Type: Bug Package:Sockets related Operating System: Mac OSX 10.8 PHP Version:5.5.0alpha5 Assigned To:laruence Block user comment: N Private report: N New Comment: Hi, the attached patch is intend to fix IPV6_PKTINFO failure, the commit didn't contain all of the fix. but only the macro define. The patch isn't break build. but the partially applied patch. only define __APPLE_USE_RFC is not enough. the rest of the changes should be applied too. I couldn't figure out a better solution which didn't require header inclusion order, since the macro itself required to be defined first. Previous Comments: [2013-03-05 06:05:33] larue...@php.net I revert the previous fix, since the build broken. I am wondering, if don't fix that, what's the problem is? thanks [2013-03-05 06:04:06] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=3f67d5ae434236be1db2ee54baf85725ac7b6a56 Log: Revert "Fixed Bug #64340 (sockets tests failed) Patch by Reeze" [2013-03-05 05:58:56] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=3f67d5ae434236be1db2ee54baf85725ac7b6a56 Log: Revert "Fixed Bug #64340 (sockets tests failed) Patch by Reeze" [2013-03-04 18:21:21] re...@php.net Hi, cataphract The macro __APPLE_USE_RFC_3542 must be defined before including netinet/in.h, but not all of the our c files include php_sockets.h in the topmost, but by indirectly include other header files. eg: $ head -n 1 conversions.c sockaddr_conv.h $ header -n 5 sockaddr_conv.h ... #include #include "php_sockets.h" /* php_socket */ php_network.h wil be included before the macro defined. and php_network.h has to been included before php_sockets.h, so I have to move conversion.h up instead. in the mean time, in convesion.h was included before php_sockets.h too, so I have to move it up to meet the requirement of the macro. The current partial patch breaks the build because of missing the left part: Undefined symbols for architecture x86_64: "_from_zval_write_in6_pktinfo", referenced from: _init_ancillary_registry in sendrecvmsg.o _php_do_setsockopt_ipv6_rfc3542 in sendrecvmsg.o "_to_zval_read_in6_pktinfo", referenced from: _init_ancillary_registry in sendrecvmsg.o _php_do_getsockopt_ipv6_rfc3542 in sendrecvmsg.o ld: symbol(s) not found for architecture x86_64 [2013-03-03 02:55:50] larue...@php.net 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 I commmitted, since reeze doesn't has PHP karma. please verify the fix. 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=64340 -- Edit this bug report at https://bugs.php.net/bug.php?id=64340&edit=1
[PHP-BUG] Bug #64357 [NEW]: PHP mangles expires header when session.cache_limiter is used
From: abxccd at msn dot com Operating system: Ubuntu 12.10 PHP version: 5.4.12 Package: Output Control Bug Type: Bug Bug description:PHP mangles expires header when session.cache_limiter is used Description: If session.cache_limiter in php.ini has any of these values: public, private, or nocache, the expires header will be mangled if we try to set one at a later stage. To replication, first, set your session.cache_limiter to private or any of the above values, or do it using session_cache_limiter. Then, run the test script. Then, inspect the response headers with a tool like FireBug. Test script: --- https://bugs.php.net/bug.php?id=64357&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64357&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64357&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64357&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64357&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64357&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64357&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64357&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64357&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64357&r=support Expected behavior: https://bugs.php.net/fix.php?id=64357&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64357&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64357&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64357&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64357&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64357&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64357&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64357&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64357&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64357&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64357&r=mysqlcfg
Bug #64354 [Opn]: Unserialize array of objects whose class can't be autoloaded fail
Edit report at https://bugs.php.net/bug.php?id=64354&edit=1 ID: 64354 Updated by: larue...@php.net Reported by:alan at klestoff dot ru Summary:Unserialize array of objects whose class can't be autoloaded fail Status: Open Type: Bug Package:Scripting Engine problem Operating System: Debian PHP Version:5.3.22 Block user comment: N Private report: N New Comment: the similar problem maybe also exists in wakeup/sleep etc , will check them later Previous Comments: [2013-03-05 08:07:07] larue...@php.net The following patch has been added/updated: Patch Name: bug64354.patch Revision: 1362470827 URL: https://bugs.php.net/patch-display.php?bug=64354&patch=bug64354.patch&revision=1362470827 [2013-03-05 08:06:37] larue...@php.net hmm, this is because one serializing triggered more than one exception. quick patch attached. [2013-03-05 07:27:04] alan at klestoff dot ru Description: We have serialized object of class A and array with 2 such objects Then we write autoload function which throws exception if can't find a file with class. And in first case - we have a normal behaviour (we can catch exception). In second we have uncaughted exception. Test script: --- https://bugs.php.net/bug.php?id=64354&edit=1
Bug #64354 [PATCH]: Unserialize array of objects whose class can't be autoloaded fail
Edit report at https://bugs.php.net/bug.php?id=64354&edit=1 ID: 64354 Patch added by: larue...@php.net Reported by:alan at klestoff dot ru Summary:Unserialize array of objects whose class can't be autoloaded fail Status: Open Type: Bug Package:Scripting Engine problem Operating System: Debian PHP Version:5.3.22 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug64354.patch Revision: 1362470827 URL: https://bugs.php.net/patch-display.php?bug=64354&patch=bug64354.patch&revision=1362470827 Previous Comments: [2013-03-05 08:06:37] larue...@php.net hmm, this is because one serializing triggered more than one exception. quick patch attached. [2013-03-05 07:27:04] alan at klestoff dot ru Description: We have serialized object of class A and array with 2 such objects Then we write autoload function which throws exception if can't find a file with class. And in first case - we have a normal behaviour (we can catch exception). In second we have uncaughted exception. Test script: --- https://bugs.php.net/bug.php?id=64354&edit=1
Bug #64354 [Opn]: Unserialize array of objects whose class can't be autoloaded fail
Edit report at https://bugs.php.net/bug.php?id=64354&edit=1 ID: 64354 Updated by: larue...@php.net Reported by:alan at klestoff dot ru Summary:Unserialize array of objects whose class can't be autoloaded fail Status: Open Type: Bug Package:Scripting Engine problem Operating System: Debian PHP Version:5.3.22 Block user comment: N Private report: N New Comment: hmm, this is because one serializing triggered more than one exception. quick patch attached. Previous Comments: [2013-03-05 07:27:04] alan at klestoff dot ru Description: We have serialized object of class A and array with 2 such objects Then we write autoload function which throws exception if can't find a file with class. And in first case - we have a normal behaviour (we can catch exception). In second we have uncaughted exception. Test script: --- https://bugs.php.net/bug.php?id=64354&edit=1
