Bug #51307 [Asn]: php.exe error on command line
Edit report at http://bugs.php.net/bug.php?id=51307&edit=1 ID: 51307 User updated by:joerg dot klein at ifsam dot lu Reported by:joerg dot klein at ifsam dot lu Summary:php.exe error on command line Status: Assigned Type: Bug Package:Reproducible crash Operating System: win32 only - Windows Server 2003 PHP Version:5.3.6 Assigned To:pajoye Block user comment: N Private report: N New Comment: If it helps you to track down the problem, I can give you some more backtraces. For example using pear Previous Comments: [2011-03-18 13:46:10] joerg dot klein at ifsam dot lu Thread 0 - System ID 736 Entry point php_cgi!mainCRTStartup Create time 18.03.2011 12:18:32 Time spent in user mode 0 Days 0:0:0.31 Time spent in kernel mode 0 Days 0:0:0.156 Function Arg 1 Arg 2 Arg 3 Source php5ts!zend_register_internal_class_ex+ba7 003f5098 100e1075 01864590 php5ts!_efree+2e 01864590 003f2918 1021e045 php5ts!closelog+55 101d7ba4 0001 0013 php5ts!zm_deactivate_syslog+5 0001 0013 003f2918 php5ts!zm_deactivate_basic+e4 0001 0013 003f2918 php5ts!module_registry_cleanup+1b 0198d1b8 003f2918 003f2918 php5ts!zend_hash_reverse_apply+3f 1058b280 10006640 003f2918 php5ts!zend_deactivate_modules+61 003f2918 0002 003f2918 php5ts!php_request_shutdown+235 0040a4c8 0001 php_cgi!main+e89 0002 003f3f30 003f2f80 php_cgi!memset+160 7ffdd000 kernel32!ProcessIdToSessionId+209 00406a7a PHP5TS!ZEND_REGISTER_INTERNAL_CLASS_EX+BA7In php-cgi__PID__932__Date__03_18_2011__Time_12_18_35PM__387__Second_Chance_Exception_C005.dmp the assembly instruction at php5ts!zend_register_internal_class_ex+ba7 in C:\php\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x6aebadf8 on thread 0 Module Information Image Name: C:\php\php5ts.dll Symbol Type: PDB Base address: 0x1000 Time Stamp: Thu Mar 17 11:41:09 2011 Checksum: 0x005a6b72 Comments: COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Script Interpreter ISAPIFilter: False File Version: 5.3.6 Managed DLL: False Internal Name: PHP Script Interpreter VB DLL: False Legal Copyright: Copyright © 1997-2010 The PHP Group Loaded Image Name: php5ts.dll Legal Trademarks: PHP Mapped Image Name: Original filename: php5ts.dll Module name: php5ts Private Build: Single Threaded: False Product Name: PHP Module Size: 5,75 MBytes Product Version: 5.3.6 Symbol File Name: C:\php\php5ts.pdb Special Build: & [2011-03-18 10:14:18] paj...@php.net Please provide a new backtrace then, if it crashes somewhere else. But I still have little clue about what's happening :) [2011-03-18 10:11:41] joerg dot klein at ifsam dot lu I tested 5.3.6 VC9 today. The crash is still there, but it occurs in another file. I just removed one comment line and the file works without a problem! As I Stated in my last post, it is impossible to write a short reproduceable script. Even when it crashes on my site, it won't do on your site. [2010-08-18 14:41:40] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-08-18 14:27:30] joerg dot klein at ifsam dot lu I tried again with 5.3.3 final. The same script which produces the error in 5.3.2 works fine, but with some minimal changes (e.g. remove a comment line) the error occured again. A small reproduce script seems to be impossible. I also tried some different configurations. The result: adding just a comment line in the php.ini let the error disappear. 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
Bug #40068 [Com]: Warning: Unknown: failed to open stream: No such file or directory in Unknown..
Edit report at http://bugs.php.net/bug.php?id=40068&edit=1
ID: 40068
Comment by: mook at social dot crabdance dot com
Reported by:triphius at tripslair dot com
Summary:Warning: Unknown: failed to open stream: No such
file or directory in Unknown..
Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: FreeBSD 6.1
PHP Version:5.2.0
Block user comment: N
Private report: N
New Comment:
i broke the links. the new and hopefully more stable addresses are
http://nagual.crabdance.com
vs
http://nagual.crabdance.com/colors/red/
Previous Comments:
[2011-03-09 10:09:14] mook at social dot crabdance dot com
i can confirm the weirdness and roughly the error message. Hit refresh a
few
times here:
http://90.177.177.100/oldnagualnet.com/colors/red/
as opposed to here:
http://90.177.177.100/oldnagualnet.com/
colors being a directory with symlinks, red linking to ..
I ran wget in an endless loop on
http://90.177.177.100/oldnagualnet.com/colors/red/colors.php and it
errored
roughly 3 times per second. After a while stopped. It doesnt seem to
happen
when the php is accessed by its address directly, only when its accessed
thru a
symlinked directory.
This is:
Linux kook-desktop 2.6.32-5-xen-686 #1 SMP Mon Jan 17 10:49:18 UTC 2011
i686
GNU/Linux
root@kook-desktop:/var/www/oldnagualnet.com# php -v
PHP 5.3.3-1ubuntu9.3 with Suhosin-Patch (cli) (built: Jan 12 2011
16:08:14)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
thanks .. :)
http://90.177.177.100/oldnagualnet.com/colors.php:
body { background-color:; }
UntitledFrame-2.php:
(lots of html)
(lots of html)
echo "http://90.177.177.100/oldnagualnet.com/colors/$file\";
target=\"main\">$file\n";
}
closedir($handle);
}
?>
(some html)
[2010-10-23 22:52:46] ttibensky at gmail dot com
I use Dreamweaver 8
when i save an index (index.php), it will automaticly save it as php5
file, so i save it manualy as php4 and that error is gone
so it must be some king of bug in php5...
[2007-01-10 22:43:24] il...@php.net
Closing the bug as the problem is no longer reproducible
(presumed resolved).
[2007-01-10 05:40:42] triphius at tripslair dot com
I installed PHP from the CVS source as suggested, using the same
configure command as FreeBSD had previously generated. Then I used the
php5-extensions port to reinstall all the additional modules (as
previously listed).
I have yet to see the random error (knock knock), and assume that this
has fixed the issue. My guess is that there was a bug in the 5.2.0
release code used by the FreeBSD ports system.
I will update the bug report if I see any sign of the error. Thank you
for your assistance so far.
[2007-01-10 03:53:26] il...@php.net
Please update the report once you have the results from the
php-cvs run.
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
http://bugs.php.net/bug.php?id=40068
--
Edit this bug report at http://bugs.php.net/bug.php?id=40068&edit=1
Req #53037 [Opn]: activate FILTER_FLAG_EMPTY_STRING_NULL
Edit report at http://bugs.php.net/bug.php?id=53037&edit=1 ID: 53037 User updated by:jinmoku at hotmail dot com Reported by:jinmoku at hotmail dot com Summary:activate FILTER_FLAG_EMPTY_STRING_NULL Status: Open Type: Feature/Change Request Package:Filter related -PHP Version:5.3.3 +PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Added patch Previous Comments: [2010-10-10 18:13:04] jinmoku at hotmail dot com Description: Hi, there are any plan for FILTER_FLAG_EMPTY_STRING_NULL ? And why 'NULL' insteed 'FALSE' ? ;) Test script: --- $str = ''; $filter = filter_var($str, FILTER_DEFAULT, FILTER_FLAG_EMPTY_STRING_NULL); var_dump($filter); Expected result: NULL Actual result: -- string(0) "" -- Edit this bug report at http://bugs.php.net/bug.php?id=53037&edit=1
Bug #54415 [Opn]: php-cgi: linker error with Easysoft unixODBC integration
Edit report at http://bugs.php.net/bug.php?id=54415&edit=1 ID: 54415 User updated by:mark dot dalton at mail dot house dot gov Reported by:mark dot dalton at mail dot house dot gov -Summary:php-cgi: inker error with Easysoft unixODBC integration +Summary:php-cgi: linker error with Easysoft unixODBC integration Status: Open Type: Bug Package:Compile Failure Operating System: Solaris 10 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Corrected small spelling error in 'Summary' field. Previous Comments: [2011-03-29 00:05:44] mark dot dalton at mail dot house dot gov Description: This problem is with building PHP 5.3.5. I'm using SolarisStudio compiler and /usr/ccs/bin/ld as the linker. Input to configure: ./configure \ --prefix=/usr2/web/home/plugins/php-5.3.5 \ --bindir=/usr2/web/home/plugins/php-5.3.5/bin \ --libdir=/usr2/web/home/plugins/php-5.3.5/lib \ --libexecdir=/usr2/web/home/plugins/php-5.3.5/libexec \ --enable-debug \ --with-gnu-ld \ --oldincludedir=/usr/include \ --with-unixODBC=/usr/local/easysoft/unixODBC \ --enable-calendar Very tail-end nippet from 'make' (build) run: Undefined first referenced symbol in file _php_glob_stream_get_path ext/spl/spl_directory.o _php_glob_stream_get_count ext/spl/spl_directory.o php_glob_stream_ops ext/spl/spl_directory.o php_glob_stream_wrapper ext/standard/basic_functions.o ld: fatal: Symbol referencing errors. No output written to sapi/cgi/php-cgi *** Error code 2 make: Fatal error: Command failed for target `sapi/cgi/php-cgi' This error is not generated for the CLI PHP module nor does it occur if '--with-unixODBC=/usr/local/easysoft/unixODBC' is left out of the configure run. I tried to force inclusion of the required 'php_glob_stream' references by adding in '#include streams/php_stream_glob_wrapper.h' into the 2 C modules that were involved but that made no difference at all. Test script: --- Tail-end nippet from 'make' (build) run (lengthy): cc -m64 -I/usr/include -g ext/date/php_date.o ext/date/lib/astro.o ext/date/lib/dow.o ext/date/lib/parse_date.o ext/date/lib/parse_tz.o ext/date/lib/timelib.o ext/date/lib/tm2unixtime.o ext/date/lib/unixtime2tm.o ext/date/lib/parse_iso_intervals.o ext/date/lib/interval.o ext/ereg/ereg.o ext/ereg/regex/regcomp.o ext/ereg/regex/regexec.o ext/ereg/regex/regerror.o ext/ereg/regex/regfree.o ext/libxml/libxml.o ext/pcre/pcrelib/pcre_chartables.o ext/pcre/pcrelib/pcre_ucd.o ext/pcre/pcrelib/pcre_compile.o ext/pcre/pcrelib/pcre_config.o ext/pcre/pcrelib/pcre_exec.o ext/pcre/pcrelib/pcre_fullinfo.o ext/pcre/pcrelib/pcre_get.o ext/pcre/pcrelib/pcre_globals.o ext/pcre/pcrelib/pcre_info.o ext/pcre/pcrelib/pcre_maketables.o ext/pcre/pcrelib/pcre_newline.o ext/pcre/pcrelib/pcre_ord2utf8.o ext/pcre/pcrelib/pcre_refcount.o ext/pcre/pcrelib/pcre_study.o ext/pcre/pcrelib/pcre_tables.o ext/pcre/pcrelib/pcre_try_flipped.o ext/pcre/pcrelib/pcre_valid_utf8.o ext/pcre/pcrelib/pcre_version.o ext/pcre/pcrelib/pcre_xclass.o ext/pcre/php_pcre.o ext/sqlite3/sqlite3.o ext/sqlite3/libsqlite/sqlite3.o ext/calendar/calendar.o ext/calendar/dow.o ext/calendar/french.o ext/calendar/gregor.o ext/calendar/jewish.o ext/calendar/julian.o ext/calendar/easter.o ext/calendar/cal_unix.o ext/ctype/ctype.o ext/dom/php_dom.o ext/dom/attr.o ext/dom/document.o ext/dom/domerrorhandler.o ext/dom/domstringlist.o ext/dom/domexception.o ext/dom/namelist.o ext/dom/processinginstruction.o ext/dom/cdatasection.o ext/dom/documentfragment.o ext/dom/domimplementation.o ext/dom/element.o ext/dom/node.o ext/dom/string_extend.o ext/dom/characterdata.o ext/dom/documenttype.o ext/dom/domimplementationlist.o ext/dom/entity.o ext/dom/nodelist.o ext/dom/text.o ext/dom/comment.o ext/dom/domconfiguration.o ext/dom/domimplementationsource.o ext/dom/entityreference.o ext/dom/notation.o ext/dom/xpath.o ext/dom/dom_iterators.o ext/dom/typeinfo.o ext/dom/domerror.o ext/dom/domlocator.o ext/dom/namednodemap.o ext/dom/userdatahandler.o ext/fileinfo/fileinfo.o ext/fileinfo/libmagic/apprentice.o ext/fileinfo/libmagic/apptype.o ext/fileinfo/libmagic/ascmagic.o ext/fileinfo/libmagic/cdf.o ext/fileinfo/libmagic/cdf_time.o ext/fileinfo/libmagic/compress.o ext/fileinfo/libmagic/encoding.o ext/fileinfo/libmagic/fsmagic.o ext/fileinfo/libmagic/funcs.o ext/fileinfo/libmagic/is_tar.o ext/fileinfo/libmagic/magic.o ext/fileinfo/libmagic/print.o ext/fileinfo/libmagic/readcdf.o ext/fileinfo/libmagic/readelf.o ext/fileinfo/libmagic/softmagic.o ext/filter/filter.o ext/filter/sanitizing_filters.o ext/filter/logical_filters.o ext/filter/callback_filter.o ext/hash/hash.o ext/hash/hash_md.o ext/hash/
[PHP-BUG] Bug #54415 [NEW]: php-cgi: inker error with Easysoft unixODBC integration
From: Operating system: Solaris 10 PHP version: 5.3.6 Package: Compile Failure Bug Type: Bug Bug description:php-cgi: inker error with Easysoft unixODBC integration Description: This problem is with building PHP 5.3.5. I'm using SolarisStudio compiler and /usr/ccs/bin/ld as the linker. Input to configure: ./configure \ --prefix=/usr2/web/home/plugins/php-5.3.5 \ --bindir=/usr2/web/home/plugins/php-5.3.5/bin \ --libdir=/usr2/web/home/plugins/php-5.3.5/lib \ --libexecdir=/usr2/web/home/plugins/php-5.3.5/libexec \ --enable-debug \ --with-gnu-ld \ --oldincludedir=/usr/include \ --with-unixODBC=/usr/local/easysoft/unixODBC \ --enable-calendar Very tail-end nippet from 'make' (build) run: Undefined first referenced symbol in file _php_glob_stream_get_path ext/spl/spl_directory.o _php_glob_stream_get_count ext/spl/spl_directory.o php_glob_stream_ops ext/spl/spl_directory.o php_glob_stream_wrapper ext/standard/basic_functions.o ld: fatal: Symbol referencing errors. No output written to sapi/cgi/php-cgi *** Error code 2 make: Fatal error: Command failed for target `sapi/cgi/php-cgi' This error is not generated for the CLI PHP module nor does it occur if '--with-unixODBC=/usr/local/easysoft/unixODBC' is left out of the configure run. I tried to force inclusion of the required 'php_glob_stream' references by adding in '#include streams/php_stream_glob_wrapper.h' into the 2 C modules that were involved but that made no difference at all. Test script: --- Tail-end nippet from 'make' (build) run (lengthy): cc -m64 -I/usr/include -g ext/date/php_date.o ext/date/lib/astro.o ext/date/lib/dow.o ext/date/lib/parse_date.o ext/date/lib/parse_tz.o ext/date/lib/timelib.o ext/date/lib/tm2unixtime.o ext/date/lib/unixtime2tm.o ext/date/lib/parse_iso_intervals.o ext/date/lib/interval.o ext/ereg/ereg.o ext/ereg/regex/regcomp.o ext/ereg/regex/regexec.o ext/ereg/regex/regerror.o ext/ereg/regex/regfree.o ext/libxml/libxml.o ext/pcre/pcrelib/pcre_chartables.o ext/pcre/pcrelib/pcre_ucd.o ext/pcre/pcrelib/pcre_compile.o ext/pcre/pcrelib/pcre_config.o ext/pcre/pcrelib/pcre_exec.o ext/pcre/pcrelib/pcre_fullinfo.o ext/pcre/pcrelib/pcre_get.o ext/pcre/pcrelib/pcre_globals.o ext/pcre/pcrelib/pcre_info.o ext/pcre/pcrelib/pcre_maketables.o ext/pcre/pcrelib/pcre_newline.o ext/pcre/pcrelib/pcre_ord2utf8.o ext/pcre/pcrelib/pcre_refcount.o ext/pcre/pcrelib/pcre_study.o ext/pcre/pcrelib/pcre_tables.o ext/pcre/pcrelib/pcre_try_flipped.o ext/pcre/pcrelib/pcre_valid_utf8.o ext/pcre/pcrelib/pcre_version.o ext/pcre/pcrelib/pcre_xclass.o ext/pcre/php_pcre.o ext/sqlite3/sqlite3.o ext/sqlite3/libsqlite/sqlite3.o ext/calendar/calendar.o ext/calendar/dow.o ext/calendar/french.o ext/calendar/gregor.o ext/calendar/jewish.o ext/calendar/julian.o ext/calendar/easter.o ext/calendar/cal_unix.o ext/ctype/ctype.o ext/dom/php_dom.o ext/dom/attr.o ext/dom/document.o ext/dom/domerrorhandler.o ext/dom/domstringlist.o ext/dom/domexception.o ext/dom/namelist.o ext/dom/processinginstruction.o ext/dom/cdatasection.o ext/dom/documentfragment.o ext/dom/domimplementation.o ext/dom/element.o ext/dom/node.o ext/dom/string_extend.o ext/dom/characterdata.o ext/dom/documenttype.o ext/dom/domimplementationlist.o ext/dom/entity.o ext/dom/nodelist.o ext/dom/text.o ext/dom/comment.o ext/dom/domconfiguration.o ext/dom/domimplementationsource.o ext/dom/entityreference.o ext/dom/notation.o ext/dom/xpath.o ext/dom/dom_iterators.o ext/dom/typeinfo.o ext/dom/domerror.o ext/dom/domlocator.o ext/dom/namednodemap.o ext/dom/userdatahandler.o ext/fileinfo/fileinfo.o ext/fileinfo/libmagic/apprentice.o ext/fileinfo/libmagic/apptype.o ext/fileinfo/libmagic/ascmagic.o ext/fileinfo/libmagic/cdf.o ext/fileinfo/libmagic/cdf_time.o ext/fileinfo/libmagic/compress.o ext/fileinfo/libmagic/encoding.o ext/fileinfo/libmagic/fsmagic.o ext/fileinfo/libmagic/funcs.o ext/fileinfo/libmagic/is_tar.o ext/fileinfo/libmagic/magic.o ext/fileinfo/libmagic/print.o ext/fileinfo/libmagic/readcdf.o ext/fileinfo/libmagic/readelf.o ext/fileinfo/libmagic/softmagic.o ext/filter/filter.o ext/filter/sanitizing_filters.o ext/filter/logical_filters.o ext/filter/callback_filter.o ext/hash/hash.o ext/hash/hash_md.o ext/hash/hash_sha.o ext/hash/hash_ripemd.o ext/hash/hash_haval.o ext/hash/hash_tiger.o ext/hash/hash_gost.o ext/hash/hash_snefru.o ext/hash/hash_whirlpool.o ext/hash/hash_adler32.o ext/hash/hash_crc32.o ext/hash/hash_salsa.o ext/iconv/iconv.o ext/json/json.o ext/json/utf8_to_utf16.o ext/json/utf8_decode.o ext/json/JSON_parser.o ext/odbc/php_odbc.o ext/pdo/pdo.o ext/pdo/pdo_dbh.o ext/pdo/pdo_stmt.o ext/pdo/pdo_sql_parser.o ext/pdo/pdo_sqlstate.o ext/pdo_sqlite/pdo_sqlite.o ext/pdo_sqlite/sqlite_driver.o ext/pdo_sqlite/sqlite_statement.o ext/phar/util.o ext/phar/tar.o ext/phar/zip.o ext/phar/stream.o ext/phar/func_interceptors.o ex
Bug #41631 [Com]: default_socket_timeout does not work with SSL
Edit report at http://bugs.php.net/bug.php?id=41631&edit=1 ID: 41631 Comment by: arkadi dot shishlov at gmail dot com Reported by:david at acz dot org Summary:default_socket_timeout does not work with SSL Status: Assigned Type: Bug Package:OpenSSL related Operating System: * PHP Version:5.2, 5.3 Assigned To:pajoye Block user comment: N Private report: N New Comment: A simple solution is to use HAProxy to proxy SSL partner services. Works for me. defaults modetcp contimeout 5000 clitimeout 3 srvtimeout 3 listen service.gjensidigebaltic.lv 127.0.0.1:10001 dispatch 193.111.247.167:443 listen services.seesam.lv 127.0.0.1:10007 dispatch 217.28.49.7:443 Previous Comments: [2011-01-04 00:53:51] guyphp at yahoo dot com This bug has caused us a lot of headaches due to hung connections from partners stacking and eventually taking down entire webservers. During high traffic periods, it doesn't take long for these to reach critical mass. Is there any ETA on when this bug will find its way into stable builds? Like many, our managed hosting provider doesn't support patches - we need a stable build with the fix integrated. We are seeing this problem on 5.2.13, RHEL 5.5. [2010-11-19 15:43:21] chrisw at networkm dot co dot uk Cannot reproduce this on Windows Server 2003 R2 Enterprise/PHP 5.2.9-2 fopen() returns after $default_socket_timeout seconds if the server does not respond. [2010-06-13 15:12:55] fel...@php.net Pierre, doesn't the attached patch fix this issue? [2010-03-15 10:33:47] jason at kapoks dot co dot uk Had this issue over the weekend with 5.2.10. Essentially this means our entire service is vulnerable to Denial of Service. Linux localhost.localdomain 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 i686 i386 GNU/Linux CentOS release 5.3 (Final) PHP 5.2.10 (cli) (built: Jun 21 2009 11:10:43) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies [2010-01-18 19:16:42] wdierkes at 5dollarwhitebox dot org This is also reproducible on 5.2.12 as described. As mentioned previously, this has the potentially to have major effects (Denial of Servide) etc due to processes hanging and never timing out. # cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.4 (Tikanga) # php -v PHP 5.2.12 (cli) (built: Dec 17 2009 12:23:35) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies # uname -a Linux linux 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux 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 http://bugs.php.net/bug.php?id=41631 -- Edit this bug report at http://bugs.php.net/bug.php?id=41631&edit=1
Bug #54414 [Opn->Bgs]: Floating-Point Arithmetic Bug
Edit report at http://bugs.php.net/bug.php?id=54414&edit=1 ID: 54414 Updated by: dtajchre...@php.net Reported by:ejsexton82 at gmail dot com Summary:Floating-Point Arithmetic Bug -Status: Open +Status: Bogus Type: Bug Package:Math related Operating System: Windows Server 2003 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is, read this: http://www.floating-point-gui.de/ Thank you for your interest in PHP. Previous Comments: [2011-03-28 20:57:06] ejsexton82 at gmail dot com Description: The following calculation yields an unexpected result. Test script: --- $test = 625.0 - 661.7 + 37.0; var_dump($test); Expected result: 0.3 Actual result: -- 0.25 -- Edit this bug report at http://bugs.php.net/bug.php?id=54414&edit=1
Bug #54409 [Opn->Asn]: strtotime(): "this week" gives incorrect result for Sunday dates
Edit report at http://bugs.php.net/bug.php?id=54409&edit=1
ID: 54409
Updated by: der...@php.net
Reported by:1234 dot ia at gmail dot com
Summary:strtotime(): "this week" gives incorrect result for
Sunday dates
-Status: Open
+Status: Assigned
Type: Bug
Package:Date/time related
Operating System: Linux 2.6.36-hardened
PHP Version:5.3.6
-Assigned To:
+Assigned To:derick
Block user comment: N
Private report: N
Previous Comments:
[2011-03-28 17:20:20] 1234 dot ia at gmail dot com
Description:
When trying to get relative dates, strtotime() gives incorrect result
for relative format "{weekday} this week" when the base date is Sunday.
It should return the same day, as it does with other weekdays, but it
returns next week's day.
Test script:
---
Expected result:
Monday 2011/01/17
Monday 2011/01/17
Tuesday 2011/01/18
Tuesday 2011/01/18
Wednesday 2011/01/19
Wednesday 2011/01/19
Thursday 2011/01/20
Thursday 2011/01/20
Friday 2011/01/21
Friday 2011/01/21
Saturday 2011/01/22
Saturday 2011/01/22
Sunday 2011/01/23
Sunday 2011/01/23
Actual result:
--
Monday 2011/01/17
Monday 2011/01/17
Tuesday 2011/01/18
Tuesday 2011/01/18
Wednesday 2011/01/19
Wednesday 2011/01/19
Thursday 2011/01/20
Thursday 2011/01/20
Friday 2011/01/21
Friday 2011/01/21
Saturday 2011/01/22
Saturday 2011/01/22
Sunday 2011/01/23
Sunday 2011/01/30
--
Edit this bug report at http://bugs.php.net/bug.php?id=54409&edit=1
Bug #48866 [Com]: ldap.conf TLS_REQCERT directive fails for ldaps
Edit report at http://bugs.php.net/bug.php?id=48866&edit=1 ID: 48866 Comment by: ocala at udistrital dot edu dot co Reported by:dev at lechat dot org Summary:ldap.conf TLS_REQCERT directive fails for ldaps Status: Feedback Type: Bug Package:LDAP related Operating System: win32 only - windows server 2003 PHP Version:5.3.0 Assigned To:pajoye Block user comment: N Private report: N New Comment: OS: Windows 7 64 Bit. PHP Version 5.3.0 Apache Version 2.2.11 Blunded Like Wamp Wamp installed in C:\wamp Script running in G:\www\test.php LDAP Configuration file in C:\ldap.conf This settings allows a working ldaps:// connection to a Windows 2008 R2 Previous Comments: [2011-03-21 14:26:51] lorenz dot ulrich at phz dot ch In my Windows 7 machine with PHP 5.3.1, "TLS_REQCERT never" in a file "C:\ldap.conf" (was C:\openldap\sysconf\ldap.conf for PHP < 5.3) works fine for establishing StartTLS LDAP connections using port 389. [2011-01-27 12:10:46] julien dot moisan at agrostar dot fr Same trouble with PHP 5.3.0 with Windows when i move ldap.conf to c:/ that's work fine. [2010-11-10 16:53:06] tegwe002 at umn dot edu Based on other people's comments I did a little testing. Here's what I found out. System: PHP 5.3.3 Win32 vc6 x86 Windows server 2008 R2 Enterprise (no service pack) Apache 2.2.15 We too have our web-root (e) on a different drive than the system root (c). Since this machine is in production, I put one copy of the file in each location. I tried without reboot and had no joy. After reboot I was able to connect to ldap over ssl with no errors. Then I did a little testing to see which file was being used. I tried moving the test script between the c: and e: drives. The file must be in the root of the drive that the script is run from. So if you run scripts from more than one drive you'll need to copy the file to the root of each drive. I hope this helps someone else. [2010-06-18 09:40:25] paj...@php.net Please try 5.3.3RC1 [2010-04-28 10:55:09] paj...@php.net Yes, the bug is not in php itself but in the build of the ldap libraries. It will be fixed in the next release (5.3.3) while being available in the snapshots (I'm working on restoring them as well). The trick is to put it in the root of the current drive, not very clean but it can help to work around this problem. 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 http://bugs.php.net/bug.php?id=48866 -- Edit this bug report at http://bugs.php.net/bug.php?id=48866&edit=1
[PHP-BUG] Bug #54414 [NEW]: Floating-Point Arithmetic Bug
From: Operating system: Windows Server 2003 PHP version: 5.3.6 Package: Math related Bug Type: Bug Bug description:Floating-Point Arithmetic Bug Description: The following calculation yields an unexpected result. Test script: --- $test = 625.0 - 661.7 + 37.0; var_dump($test); Expected result: 0.3 Actual result: -- 0.25 -- Edit bug report at http://bugs.php.net/bug.php?id=54414&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54414&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54414&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54414&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54414&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54414&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54414&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54414&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54414&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54414&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54414&r=support Expected behavior: http://bugs.php.net/fix.php?id=54414&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54414&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54414&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54414&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54414&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54414&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54414&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54414&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54414&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54414&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54414&r=mysqlcfg
Bug #48465 [Asn->Csd]: sys_get_temp_dir() possibly inconsistent when using TMPDIR
Edit report at http://bugs.php.net/bug.php?id=48465&edit=1
ID: 48465
Updated by: paj...@php.net
Reported by:marcel dot esser at gmail dot com
Summary:sys_get_temp_dir() possibly inconsistent when using
TMPDIR
-Status: Assigned
+Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.*, 6CVS (2009-06-04)
Assigned To:pajoye
Block user comment: N
Private report: N
Previous Comments:
[2011-03-28 18:43:55] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=309792
Log: - Fixed bug #48465 (sys_get_temp_dir() possibly inconsistent,
windows fix
[2011-03-28 15:35:33] paj...@php.net
Not fixed on windows
[2009-06-24 12:21:54] il...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2009-06-04 11:57:05] j...@php.net
It's not MacOSX specific, you can always set TMPDIR whatever you want.
[2009-06-04 06:23:14] marcel dot esser at gmail dot com
Alternative patch:
--- php52/php5/main/php_open_temporary_file.c 2009-06-03
13:42:44.0 -0400
+++ /Users/marcelesser/php_open_temporary_file.c2009-06-04
02:19:29.0 -0400
@@ -200,9 +200,18 @@
{
char* s = getenv("TMPDIR");
if (s) {
- temporary_directory = strdup(s);
+ int last_char_idx = strlen(s) - 1;
+
+ /* on some systems (notably mac os x) TMPDIR has a
DIRECTORY_SEPARATOR appended */
+ if(s[last_char_idx] == DEFAULT_SLASH) {
+ temporary_directory =
tsrm_strndup(s,last_char_idx);
+ } else {
+ temporary_directory = strdup(s);
+ }
+
return temporary_directory;
}
+
}
#ifdef P_tmpdir
/* Use the standard default temporary directory. */
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
http://bugs.php.net/bug.php?id=48465
--
Edit this bug report at http://bugs.php.net/bug.php?id=48465&edit=1
[PHP-BUG] Bug #54411 [NEW]: PHP Unit fails with comment tags in strings
From:
Operating system: Ubuntu x86
PHP version: 5.3.6
Package: Unknown/Other Function
Bug Type: Bug
Bug description:PHP Unit fails with comment tags in strings
Description:
If you have a string that contains the characters /* in PHPUnit, all the
tests
after it will be ignored because for some reason it thinks that it is a
comment.
A quick workaround is to add a block comment immediately after it.
public function testOne(){
//make sure that the directory is currently empty
foreach(glob('/tmp/ftp/*') as $fn) {
unlink($fn);
}
/* */ //<- this line is a workaround
}
Test script:
---
public function testOne(){
//make sure that the directory is currently empty
foreach(glob('/tmp/ftp/*') as $fn) {
unlink($fn);
}
}
public function testTwo(){
//This test case will not show up in the test list
}
--
Edit bug report at http://bugs.php.net/bug.php?id=54411&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54411&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54411&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54411&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54411&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54411&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54411&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54411&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54411&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54411&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54411&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54411&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54411&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54411&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54411&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54411&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54411&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54411&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54411&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54411&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54411&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54411&r=mysqlcfg
[PHP-BUG] Bug #54410 [NEW]: Path-related magic constants empty when CLI invoked with -H switch
From: Operating system: FreeBSD 7.1 PHP version: 5.3.6 Package: CGI related Bug Type: Bug Bug description:Path-related magic constants empty when CLI invoked with -H switch Description: When invoking a script with CLI -H switch, __FILE__ and some other magic constants resolve to empty strings. Test script: --- # cat > /tmp/test.php ^D # php /tmp/test.php '/tmp/test.php' # php -H /tmp/test.php '' -- Edit bug report at http://bugs.php.net/bug.php?id=54410&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54410&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54410&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54410&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54410&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54410&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54410&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54410&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54410&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54410&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54410&r=support Expected behavior: http://bugs.php.net/fix.php?id=54410&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54410&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54410&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54410&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54410&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54410&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54410&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54410&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54410&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54410&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54410&r=mysqlcfg
[PHP-BUG] Bug #54409 [NEW]: strtotime(): "this week" gives incorrect result for Sunday dates
From:
Operating system: Linux 2.6.36-hardened
PHP version: 5.3.6
Package: Date/time related
Bug Type: Bug
Bug description:strtotime(): "this week" gives incorrect result for Sunday dates
Description:
When trying to get relative dates, strtotime() gives incorrect result for
relative format "{weekday} this week" when the base date is Sunday. It
should return the same day, as it does with other weekdays, but it returns
next week's day.
Test script:
---
Expected result:
Monday 2011/01/17
Monday 2011/01/17
Tuesday 2011/01/18
Tuesday 2011/01/18
Wednesday 2011/01/19
Wednesday 2011/01/19
Thursday 2011/01/20
Thursday 2011/01/20
Friday 2011/01/21
Friday 2011/01/21
Saturday 2011/01/22
Saturday 2011/01/22
Sunday 2011/01/23
Sunday 2011/01/23
Actual result:
--
Monday 2011/01/17
Monday 2011/01/17
Tuesday 2011/01/18
Tuesday 2011/01/18
Wednesday 2011/01/19
Wednesday 2011/01/19
Thursday 2011/01/20
Thursday 2011/01/20
Friday 2011/01/21
Friday 2011/01/21
Saturday 2011/01/22
Saturday 2011/01/22
Sunday 2011/01/23
Sunday 2011/01/30
--
Edit bug report at http://bugs.php.net/bug.php?id=54409&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54409&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54409&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54409&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54409&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54409&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54409&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54409&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54409&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54409&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54409&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54409&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54409&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54409&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54409&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54409&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54409&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54409&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54409&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54409&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54409&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54409&r=mysqlcfg
Bug #48607 [Com]: fwrite() doesn't check reply from ftp server before exiting
Edit report at http://bugs.php.net/bug.php?id=48607&edit=1
ID: 48607
Comment by: eric dot caron at gmail dot com
Reported by:karachi at mail dot ru
Summary:fwrite() doesn't check reply from ftp server before
exiting
Status: Closed
Type: Bug
Package:FTP related
Operating System: FreeBSD
PHP Version:5.2.10
Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
What are the steps involved in having this bug moved from SVN into the
current 5.3.x branch? It is a bug fix, no new features are added nor
does any functionality change, yet two 5.3.x releases have come out
since this bug was marked CLOSED and they don't include this fix.
Previous Comments:
[2010-12-13 17:53:37] il...@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/.
Thank you for the report, and for helping us make PHP better.
[2010-12-13 17:53:28] il...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=306342
Log: Fixed bug #48607 (fwrite() doesn't check reply from ftp server
before exiting)
[2010-10-14 19:41:54] eric dot caron at gmail dot com
I can reproduce this on my CentOS 5 box running PHP 5.3.3. It occurs
when sending a large file across a slow network. Wireshark reports
getting the QUIT before the FTP server sends TRANSFER COMPLETE. Adding
the sleep before the close fixes the issue.
Reproduce code:
--
wrapperdata;
-
+
+ /* For write modes close data stream first to signal EOF to
server */
+ if (strpbrk(stream->mode, "wa+")) {
+ if (stream && controlstream) {
+ php_stream_close(stream);
+ stream = NULL;
+
+ result = GET_FTP_RESULT(controlstream);
+ if (result != 226 && result != 250) {
+ php_error_docref(NULL TSRMLS_CC,
E_WARNING, "FTP server reports %s", tmp_line);
+ ret = EOF;
+ }
+ } else {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING,
"Broken streams to FTP server");
+ ret = EOF;
+ }
+ }
+
if (controlstream) {
php_stream_write_string(controlstream, "QUIT\r\n");
php_stream_close(controlstream);
- stream->wrapperdata = NULL;
+ if (stream)
+ stream->wrapperdata = NULL;
}
- return 0;
+ return ret;
}
Also make sure that I or somebody else afterwards really does not call
something on/in the streams after closing and probably freeing them
(didn't really check out the internals of _php_stream_free() et al. --
and the control stream sort of being embedded within the data stream
here, but me having to close them the other way round due to the FTP
protocol, didn't really help in understanding what might go wrong
somewhere deep in your API). But as I said, for me the patch works.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=48607
--
Edit this bug report at http://bugs.php.net/bug.php?id=48607&edit=1
Req #51254 [Com]: Use internal crypt() only for algorithms needed
Edit report at http://bugs.php.net/bug.php?id=51254&edit=1 ID: 51254 Comment by: ondrej at sury dot org Reported by:ondrej at sury dot org Summary:Use internal crypt() only for algorithms needed Status: Open Type: Feature/Change Request Package:*Encryption and hash functions Operating System: Linux PHP Version:5.3.2 Block user comment: N Private report: N New Comment: Hi, the issue is little bit more complicated than adding defined() around the statements. When compiling with --enable-maintainer-zts some header files are included in a way that crypt_r and struct crypt_data is unknown and the compilation fail. Unless you are willing to dig deeper, you can just drop the patch for your custom build. Previous Comments: [2011-03-28 15:12:41] php at rapsys dot eu I had a poblem with this patch in debian/ubuntu packages. With this patch the build with --enable-maintainer-zts the ubuntu php5_5.3.2-1ubuntu4.7 package. The problem seems to comes from #if used instead of #ifdef and incorrectly defined strings by your patch. Here is the build log : /home//php/php5-5.3.2/ext/standard/crypt.c:150:27: error: #if with no expression /home//php/php5-5.3.2/ext/standard/crypt.c:190:27: error: #if with no expression /home//php/php5-5.3.2/ext/standard/crypt.c:201:3: warning: #warning Using system MD5 crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:202:28: error: #if with no expression /home//php/php5-5.3.2/ext/standard/crypt.c:214:3: warning: #warning Using system SHA512 crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:215:28: error: #if with no expression /home//php/php5-5.3.2/ext/standard/crypt.c:227:3: warning: #warning Using system SHA256 crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:228:28: error: #if with no expression /home//php/php5-5.3.2/ext/standard/crypt.c:258:3: warning: #warning Using PHP BlowFish crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:272:3: warning: #warning Using PHP extended DES crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:279:3: warning: #warning Using system standard DES crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:280:28: error: #if with no expression make[1]: *** [ext/standard/crypt.lo] Error 1 make[1]: Leaving directory `/home//php/php5-5.3.2/apache2-build' make: *** [build-apache2-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 debuild: fatal error at line 1340: dpkg-buildpackage -rfakeroot -D -us -uc failed [2010-03-24 17:02:06] ondrej at sury dot org Hi Pierre, had a time to review this patch and provide a detailed explanation? Ondrej [2010-03-12 11:24:42] paj...@php.net Not sure I agree with these changes, they are not supposed to be valid. I don't have the time now to reply with a detailed explanation but we will do it asap. [2010-03-12 10:15:46] ondrej at sury dot org Hi, if you apply my patch, you'll need to apply the fix_crypt_unit_tests.patch, since I have fixed some routines, which you checked in those unit tests. 1. if you use '_' as a first character of the salt, but the salt is not 9 characters long => STD_DES is used. 2. if you use 00-03 or 32-39 as count in blowfish => STD_DES is used (as documented). [2010-03-10 08:09:46] ondrej at sury dot org Description: Attached patch changes crypt.c and accompanying m4 code so it selects only algorithms not supported by system library crypt() for candidates to use internal implementation of crypt(). It also unifies the code to one style (BF and MD5 used static output buffer, sha256,512 allocated the buffer dynamically, etc.), so it's easier to read and understand, which is needed due all #if statements there. Next it fixes some glitches in m4 code. Expected result: Use internal implementation only for missing or buggy support for algorithm in system library crypt() function. Actual result: -- Internal implementation of crypt() is always selected and used(), when BF or EXT_DES is missing. (Note that due misplaced check for HAVE_CRYPT_R, it will be used even if BF and EXT_DES is present in the system.) -- Edit this bug report at http://bugs.php.net/bug.php?id=51254&edit=1
Bug #48465 [Csd->Asn]: sys_get_temp_dir() possibly inconsistent when using TMPDIR
Edit report at http://bugs.php.net/bug.php?id=48465&edit=1
ID: 48465
Updated by: paj...@php.net
Reported by:marcel dot esser at gmail dot com
Summary:sys_get_temp_dir() possibly inconsistent when using
TMPDIR
-Status: Closed
+Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.*, 6CVS (2009-06-04)
-Assigned To:
+Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
Not fixed on windows
Previous Comments:
[2009-06-24 12:21:54] il...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2009-06-04 11:57:05] j...@php.net
It's not MacOSX specific, you can always set TMPDIR whatever you want.
[2009-06-04 06:23:14] marcel dot esser at gmail dot com
Alternative patch:
--- php52/php5/main/php_open_temporary_file.c 2009-06-03
13:42:44.0 -0400
+++ /Users/marcelesser/php_open_temporary_file.c2009-06-04
02:19:29.0 -0400
@@ -200,9 +200,18 @@
{
char* s = getenv("TMPDIR");
if (s) {
- temporary_directory = strdup(s);
+ int last_char_idx = strlen(s) - 1;
+
+ /* on some systems (notably mac os x) TMPDIR has a
DIRECTORY_SEPARATOR appended */
+ if(s[last_char_idx] == DEFAULT_SLASH) {
+ temporary_directory =
tsrm_strndup(s,last_char_idx);
+ } else {
+ temporary_directory = strdup(s);
+ }
+
return temporary_directory;
}
+
}
#ifdef P_tmpdir
/* Use the standard default temporary directory. */
[2009-06-04 06:00:13] ka...@php.net
Instead of two strlen() call, i could see it being defined to a value.
Adding something like int len = strlen(s); after the if and before the
first strdup, however im not on OSX so i wont touch it :)
[2009-06-03 17:53:46] marcel dot esser at gmail dot com
Pardon, I meant 5.2.9 CVS
Also, here is diff -u output:
--- main/php_open_temporary_file.c 2009-06-03 13:42:44.0 -0400
+++ /Users/marcelesser/php_open_temporary_file.c2009-06-03
13:43:48.0 -0400
@@ -200,9 +200,16 @@
{
char* s = getenv("TMPDIR");
if (s) {
- temporary_directory = strdup(s);
+ /* on some systems (notably mac os x) TMPDIR has a
DIRECTORY_SEPARATOR appended */
+ if(s[strlen(s)-1] == DEFAULT_SLASH) {
+ temporary_directory =
tsrm_strndup(s,strlen(s)-1);
+ } else {
+ temporary_directory = strdup(s);
+ }
+
return temporary_directory;
}
+
}
#ifdef P_tmpdir
/* Use the standard default temporary directory. */
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
http://bugs.php.net/bug.php?id=48465
--
Edit this bug report at http://bugs.php.net/bug.php?id=48465&edit=1
Req #51254 [Com]: Use internal crypt() only for algorithms needed
Edit report at http://bugs.php.net/bug.php?id=51254&edit=1 ID: 51254 Comment by: php at rapsys dot eu Reported by:ondrej at sury dot org Summary:Use internal crypt() only for algorithms needed Status: Open Type: Feature/Change Request Package:*Encryption and hash functions Operating System: Linux PHP Version:5.3.2 Block user comment: N Private report: N New Comment: I had a poblem with this patch in debian/ubuntu packages. With this patch the build with --enable-maintainer-zts the ubuntu php5_5.3.2-1ubuntu4.7 package. The problem seems to comes from #if used instead of #ifdef and incorrectly defined strings by your patch. Here is the build log : /home//php/php5-5.3.2/ext/standard/crypt.c:150:27: error: #if with no expression /home//php/php5-5.3.2/ext/standard/crypt.c:190:27: error: #if with no expression /home//php/php5-5.3.2/ext/standard/crypt.c:201:3: warning: #warning Using system MD5 crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:202:28: error: #if with no expression /home//php/php5-5.3.2/ext/standard/crypt.c:214:3: warning: #warning Using system SHA512 crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:215:28: error: #if with no expression /home//php/php5-5.3.2/ext/standard/crypt.c:227:3: warning: #warning Using system SHA256 crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:228:28: error: #if with no expression /home//php/php5-5.3.2/ext/standard/crypt.c:258:3: warning: #warning Using PHP BlowFish crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:272:3: warning: #warning Using PHP extended DES crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:279:3: warning: #warning Using system standard DES crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:280:28: error: #if with no expression make[1]: *** [ext/standard/crypt.lo] Error 1 make[1]: Leaving directory `/home//php/php5-5.3.2/apache2-build' make: *** [build-apache2-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 debuild: fatal error at line 1340: dpkg-buildpackage -rfakeroot -D -us -uc failed Previous Comments: [2010-03-24 17:02:06] ondrej at sury dot org Hi Pierre, had a time to review this patch and provide a detailed explanation? Ondrej [2010-03-12 11:24:42] paj...@php.net Not sure I agree with these changes, they are not supposed to be valid. I don't have the time now to reply with a detailed explanation but we will do it asap. [2010-03-12 10:15:46] ondrej at sury dot org Hi, if you apply my patch, you'll need to apply the fix_crypt_unit_tests.patch, since I have fixed some routines, which you checked in those unit tests. 1. if you use '_' as a first character of the salt, but the salt is not 9 characters long => STD_DES is used. 2. if you use 00-03 or 32-39 as count in blowfish => STD_DES is used (as documented). [2010-03-10 08:09:46] ondrej at sury dot org Description: Attached patch changes crypt.c and accompanying m4 code so it selects only algorithms not supported by system library crypt() for candidates to use internal implementation of crypt(). It also unifies the code to one style (BF and MD5 used static output buffer, sha256,512 allocated the buffer dynamically, etc.), so it's easier to read and understand, which is needed due all #if statements there. Next it fixes some glitches in m4 code. Expected result: Use internal implementation only for missing or buggy support for algorithm in system library crypt() function. Actual result: -- Internal implementation of crypt() is always selected and used(), when BF or EXT_DES is missing. (Note that due misplaced check for HAVE_CRYPT_R, it will be used even if BF and EXT_DES is present in the system.) -- Edit this bug report at http://bugs.php.net/bug.php?id=51254&edit=1
[PHP-BUG] Bug #54408 [NEW]: Unexpected behavior when using by-reference iteration
From:
Operating system: Win 7 x64, 2.6.18
PHP version: 5.3.6
Package: Arrays related
Bug Type: Bug
Bug description:Unexpected behavior when using by-reference iteration
Description:
I was sure that arrays are passed to functions by value, not by reference.
It looks like after by-reference iteration changes array not only isnide
foreach statement, but array remains changed even after iteration.
Test script:
---
&$v) {
myf($a, $k);
}
//myf($a, 3);
var_dump($a);
die();
Expected result:
array
0 => int 1
1 => int 2
2 => int 3
3 => int 4
Actual result:
--
array
0 => int 9
1 => int 9
2 => int 9
3 => &int 9
--
Edit bug report at http://bugs.php.net/bug.php?id=54408&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54408&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54408&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54408&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54408&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54408&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54408&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54408&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54408&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54408&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54408&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54408&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54408&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54408&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54408&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54408&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54408&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54408&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54408&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54408&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54408&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54408&r=mysqlcfg
[PHP-BUG] Bug #54407 [NEW]: Incorrectly defined NTDDI_VERSION macro
From: Operating system: Windows Server 2008 PHP version: 5.3.6 Package: Compile Failure Bug Type: Bug Bug description:Incorrectly defined NTDDI_VERSION macro Description: win32\build\config.w32.h.in file contains the following code: /* Define the minimum supported version */ #undef _WIN32_WINNT #undef NTDDI_VERSION #define _WIN32_WINNT 0x500 #define NTDDI_VERSION _WIN32_WIN2K Now look at some Windows Platform SDK file, for example ShlObj.h: #if (NTDDI_VERSION >= NTDDI_WIN2K) you see that NTDDI_VERSION is compared to NTDDI_WIN2K, but NTDDI_WIN2K is defined in the following way: #define NTDDI_WIN2K 0x0500 So, macro NTDDI_VERSION defined in php config.w32.h equals to 0x500 , but compared to 0x0500. This is incorrect behavior and should be fixed. Test script: --- Schematic script: #defined _WIN32_WINNT 0x500 #include "zend.h" #include "ShlObj.h" ... TCHAR ret[MAX_PATH + 1]; SHGetFolderPath(NULL, CSIDL_FLAG_CREATE, NULL, SHGFP_TYPE_CURRENT, ret); Expected result: NTDDI_VERSION is defined like: #define NTDDI_WIN2K 0x0500 OR do not unset _WIN32_WINNT and NTDDI_VERSION if they are defined. -- Edit bug report at http://bugs.php.net/bug.php?id=54407&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54407&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54407&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54407&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54407&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54407&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54407&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54407&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54407&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54407&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54407&r=support Expected behavior: http://bugs.php.net/fix.php?id=54407&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54407&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54407&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54407&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54407&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54407&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54407&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54407&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54407&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54407&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54407&r=mysqlcfg
[PHP-BUG] Bug #54406 [NEW]: imap_header crashes when too may To: addresses exist
From: Operating system: CentOS 64-bit PHP version: 5.3.6 Package: IMAP related Bug Type: Bug Bug description:imap_header crashes when too may To: addresses exist Description: Seems that bug http://bugs.php.net/19280 & http://bugs.php.net/bug.php?id=53292 is happening again. When I try to read a mail message with a long list of To: addresses PHP crashes every time. System Infomation: OS: CentOS 2.6.18 64-bit PHP: 5.3.6 Apache: 2.2.3 C-Client: 2.2.1 Test script: --- $mbox = imap_open($imapLocation.'INBOX', $user, $pass); $headerInfo = imap_header($mbox, $mailID); // Above will crash if the message being read has too many To: addresses Expected result: Should not crash, should parse as many To: addresses as possible Actual result: -- PHP crashed at imap_header() No error found in error_log -- Edit bug report at http://bugs.php.net/bug.php?id=54406&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54406&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54406&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54406&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54406&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54406&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54406&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54406&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54406&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54406&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54406&r=support Expected behavior: http://bugs.php.net/fix.php?id=54406&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54406&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54406&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54406&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54406&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54406&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54406&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54406&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54406&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54406&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54406&r=mysqlcfg
