Bug #48610 [Com]: Accessing ssl:// results in immediate SSL: connection timeout error
Edit report at http://bugs.php.net/bug.php?id=48610edit=1
ID: 48610
Comment by: arkadi at hosting dot lv
Reported by: arkadi at hosting dot lv
Summary: Accessing ssl:// results in immediate SSL: connection
timeout error
Status: Bogus
Type: Bug
Package: Streams related
Operating System: Linux
PHP Version: 5.2.10
New Comment:
The solution for me was to remove -fpmath=sse flag (32-bit build).
Previous Comments:
[2010-03-12 00:06:16] ben at sixg dot com
We're seeing this with PHP 5.2.12 on Red Hat 5.4. (It's a Rackspace
build of PHP
rather than a Red Hat build, but I'd expect that it was built with RH5's
gcc, so
probably RH's gcc-4.1.2-46 or so.)
This is not bogus. Even if it's a GCC bug, if it's present in GCC 4.3,
it's not
likely to be fixed any time soon on that side. Can't PHP work around
it?
Arkadi, did you end up patching your xp_ssl.c to work around this, or
did you find
a version of GCC that doesn't have the bug?
[2009-06-25 20:43:02] arkadi at hosting dot lv
It is a GCC -fpmath=sse bug (i486-linux-gnu 4.3.2 [Debian 4.3.2-1.1)]
that miscompiles
timeout -= (tve.tv_sec + (float) tve.tv_usec / 100) -
(tvs.tv_sec+ (float) tvs.tv_usec / 100);
from xp_ssl.c.
[2009-06-19 18:38:37] arkadi at hosting dot lv
Description:
The problem was already reported in bug #47791 but the bug was closed as
Bogus. This is also probably related to bug #45016.
When trying to establish SSL connection the SSL: connection timeout
error is raised _immediately_ regardless of timeout specified.
You can try to access the script running on PHP 4.4.9
http://iron.hosting.lv/ssl.php - that produces correct result - an XML
fragment
and PHP 5.2.10
http://iron-php5.hosting.lv/ssl.php
which immediately prints (0).
Stracing the process shows that connection is established and initial
SSL negotiation packet is sent, but then it waits less than a second for
the reply (which is not arriving in such short time), then connection is
closed.
I believe the problem appeared after 5.2.6, and definitely present in
5.2.9.
Reproduce code:
---
?php
$fp = fsockopen(ssl://polise.if.lv , 443, $errno, $errstr, 30);
if (!$fp) {
echo $errstr ($errno)br /\n;
} else {
$out = GET /PartnerWS/OCTA/PArtner/PremiumCalculator.asmx?WSDL
HTTP/1.1\r\n;
$out .= Host: polise.if.lv\r\n;
$out .= Connection: Close\r\n\r\n;
fwrite($fp, $out);
while (!feof($fp)) {
echo fgets($fp, 128);
}
fclose($fp);
}
?
Expected result:
XML fragment fetched from remote server
Actual result:
--
(0)
--
Edit this bug report at http://bugs.php.net/bug.php?id=48610edit=1
[PHP-BUG] Req #51281 [NEW]: Json-like alternative syntax for arrays
From:
Operating system:
PHP version: 5.3.2
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:Json-like alternative syntax for arrays
Description:
Json-like alternative syntax for arrays feature request.
It's much shorter, and don't have conflicts with current tokens.
Test script:
---
$a = [1,2];
$a = ['a':1,'b':2];
$a = array('a':1,'b':2);
$a = array('a'=1,'b'=2);
$a = ['a'=1,'b'=2];
--
Edit bug report at http://bugs.php.net/bug.php?id=51281edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51281r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51281r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51281r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51281r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51281r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51281r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51281r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51281r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51281r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51281r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51281r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51281r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51281r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51281r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51281r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51281r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51281r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51281r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51281r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51281r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51281r=mysqlcfg
Req #51281 [Opn]: Json-like alternative syntax for arrays
Edit report at http://bugs.php.net/bug.php?id=51281edit=1
ID: 51281
User updated by: olamedia at gmail dot com
Reported by: olamedia at gmail dot com
Summary: Json-like alternative syntax for arrays
Status: Open
Type:Feature/Change Request
-Package: *General Issues
+Package: Arrays related
PHP Version: 5.3.2
New Comment:
Changing package
Previous Comments:
[2010-03-12 09:18:17] olamedia at gmail dot com
Description:
Json-like alternative syntax for arrays feature request.
It's much shorter, and don't have conflicts with current tokens.
Test script:
---
$a = [1,2];
$a = ['a':1,'b':2];
$a = array('a':1,'b':2);
$a = array('a'=1,'b'=2);
$a = ['a'=1,'b'=2];
--
Edit this bug report at http://bugs.php.net/bug.php?id=51281edit=1
Req #51254 [Opn]: Use internal crypt() only for algorithms needed
Edit report at http://bugs.php.net/bug.php?id=51254edit=1 ID: 51254 User updated 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 New Comment: 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). Previous Comments: [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=51254edit=1
Bug #48697 [Com]: mb_internal_encoding() value gets reset by parse_str()
Edit report at http://bugs.php.net/bug.php?id=48697edit=1 ID: 48697 Comment by: jan dot hancic at gmail dot com Reported by: glen at delfi dot ee Summary: mb_internal_encoding() value gets reset by parse_str() Status: Closed Type: Bug Package: mbstring related Operating System: PLD Linux PHP Version: 5.2.10 Assigned To: moriyoshi New Comment: This bug is still present in version 5.2.10 (FreeBSD 7.2-RELEASE FreeBSD 7.2- RELEASE #0: Fri May 1 07:18:07 UTC 2009 r...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64). Previous Comments: [2009-09-14 05:20:41] glen at delfi dot ee nevermind, disregard my last post, seems commit is posted to bug, just not mailed to bug subscribers... [2009-09-14 05:18:41] glen at delfi dot ee blah, why you never include scm commit in the bug? would be helpful instead have to dig myself [2009-09-14 04:12:54] moriyo...@php.net Changed the summary again as it turned out mb_parse_str() has nothing to do with this. [2009-09-14 04:11:48] moriyo...@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. [2009-09-14 04:11:29] s...@php.net Automatic comment from SVN on behalf of moriyoshi Revision: http://svn.php.net/viewvc/?view=revisionrevision=288301 Log: - Looks like bug #48697 has already been fixed in RC1. 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=48697 -- Edit this bug report at http://bugs.php.net/bug.php?id=48697edit=1
[PHP-BUG] Bug #51282 [NEW]: crypt() result different between PHP 5.3.1 and PHP 5.3.2
From: Operating system: Mac, Linux PHP version: 5.3.2 Package: *Encryption and hash functions Bug Type: Bug Bug description:crypt() result different between PHP 5.3.1 and PHP 5.3.2 Description: I use crypt() to store and validate passwords using the « Standard DES » hash, and after upgrading to 5.3.2, the hashed password of an account is not the same as the one generated with PHP 5.3.1 : With PHP 5.3.1 : $ php -r 'print crypt(anakeen, A^).\n;' A^1ul2Jf7VS2M After upgrading to PHP 5.3.2 : $ php -r 'print crypt(anakeen, A^).\n;' A^/ImZ5hqd2VU I tested both on Mac (macports) and on Linux (rawhide), and the hash result was different on both platform. On Mac OS X (10.5), the Perl (or C) crypt gives me the same results as PHP 5.3.1 : $ perl -e 'print crypt(anakeen, A^).\n;' A^1ul2Jf7VS2M While on Linux, the Perl script gives me the same result as PHP 5.3.2. It appears that there is a difference in the crypt() function, between these platforms, regarding the presence of non alpha-num chars in the salt : Mac OS X with A- salt = different hashes : $ php -r 'print crypt(anakeen, A-).\n;' A-75An91LCLEM $ perl -e 'print crypt(anakeen, A-).\n'; A-1ul2Jf7VS2M Mac OS X with A9 salt = same hashes : $ perl -e 'print crypt(anakeen, A9).\n'; A9Pf3.gAayQMM $ php -r 'print crypt(anakeen, A9).\n;' A9Pf3.gAayQMM Maybe I should not have used non alpha-num chars for my salt in the first place ? -- Edit bug report at http://bugs.php.net/bug.php?id=51282edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51282r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51282r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51282r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51282r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51282r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51282r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51282r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51282r=needscript Try newer version: http://bugs.php.net/fix.php?id=51282r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51282r=support Expected behavior: http://bugs.php.net/fix.php?id=51282r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51282r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51282r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51282r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51282r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51282r=dst IIS Stability: http://bugs.php.net/fix.php?id=51282r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51282r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51282r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51282r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51282r=mysqlcfg
Req #51254 [Opn]: Use internal crypt() only for algorithms needed
Edit report at http://bugs.php.net/bug.php?id=51254edit=1 ID: 51254 Updated by: paj...@php.net 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 New Comment: 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. Previous Comments: [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=51254edit=1
Bug #51216 [Com]: Segmentation fault when compiling PHP with PHAR
Edit report at http://bugs.php.net/bug.php?id=51216edit=1 ID: 51216 Comment by: jedibc at free dot fr Reported by: dtm2mcs at gmail dot com Summary: Segmentation fault when compiling PHP with PHAR Status: Open Type: Bug Package: PHAR related Operating System: Ubuntu 6.04 + CentOS 5.4 PHP Version: 5.3.2 New Comment: Same issue on debian lenny x86 : Generating phar.php /bin/sh: line 1: 16624 Segmentation fault ` if test -x /root/php-5.3.2/sapi/cli/php; then /root/php-5.3.2/build/shtool echo -n -- /root/php-5.3.2/sapi/cli/php -n; if test x != x; then /root/php-5.3.2/build/shtool echo -n -- -d extension_dir=/root/php-5.3.2/modules; for i in bz2 zlib phar; do if test -f /root/php-5.3.2/modules/$i.la; then . /root/php-5.3.2/modules/$i.la; /root/php-5.3.2/build/shtool echo -n -- -d extension=$dlname; fi; done; fi; else /root/php-5.3.2/build/shtool echo -n -- /root/php-5.3.2/sapi/cli/php; fi;` -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' -d phar.readonly=0 -d 'safe_mode=0' /root/php-5.3.2/ext/phar/build_precommand.php ext/phar/phar.php make: *** [ext/phar/phar.php] Error 139 Previous Comments: [2010-03-10 12:38:52] fsk141 at gmail dot com I'm having the same issue trying to compile on Arch Linux on the ARM platform... :( make: *** [ext/phar/phar.php] Error 139 [2010-03-06 11:34:55] dtm2mcs at gmail dot com Since i can't compile it on CentOS 5.4 either, it does not seem to be a problem of this older Ubuntu release. [2010-03-06 10:44:32] ras...@php.net That's a really old Ubuntu. 4+ years. Does Ubuntu even support that anymore? Works perfectly fine on x86_64 Ubuntu 9.10. [2010-03-06 10:07:03] dtm2mcs at gmail dot com Some lines before the segmentation fault: /bin/sh /root/php-5.3.2/libtool --silent --preserve-dup-deps --mode=compile /root/php-5.3.2/meta_ccld -IZend/ -I/root/php-5.3.2/Zend/ -DPHP_ATOM_INC -I/root/php-5.3.2/include -I/root/php-5.3.2/main -I/root/php-5.3.2 -I/root/php-5.3.2/ext/date/lib -I/root/php-5.3.2/ext/ereg/regex -I/usr/include/libxml2 -I/usr/kerberos/include -I/usr/include/freetype2 -I/root/php-5.3.2/ext/mbstring/oniguruma -I/root/php-5.3.2/ext/mbstring/libmbfl -I/root/php-5.3.2/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/root/php-5.3.2/ext/sqlite3/libsqlite -I/root/php-5.3.2/TSRM -I/root/php-5.3.2/Zend -D_REENTRANT -I/usr/include -g -O2 -fvisibility=hidden -pthread -DZTS -c /root/php-5.3.2/Zend/zend_objects.c -o Zend/zend_objects.lo /bin/sh /root/php-5.3.2/libtool --silent --preserve-dup-deps --mode=compile /root/php-5.3.2/meta_ccld -IZend/ -I/root/php-5.3.2/Zend/ -DPHP_ATOM_INC -I/root/php-5.3.2/include -I/root/php-5.3.2/main -I/root/php-5.3.2 -I/root/php-5.3.2/ext/date/lib -I/root/php-5.3.2/ext/ereg/regex -I/usr/include/libxml2 -I/usr/kerberos/include -I/usr/include/freetype2 -I/root/php-5.3.2/ext/mbstring/oniguruma -I/root/php-5.3.2/ext/mbstring/libmbfl -I/root/php-5.3.2/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/root/php-5.3.2/ext/sqlite3/libsqlite -I/root/php-5.3.2/TSRM -I/root/php-5.3.2/Zend -D_REENTRANT -I/usr/include -g -O2 -fvisibility=hidden -pthread -DZTS -c /root/php-5.3.2/Zend/zend_object_handlers.c -o Zend/zend_object_handlers.lo /bin/sh /root/php-5.3.2/libtool --silent --preserve-dup-deps --mode=compile /root/php-5.3.2/meta_ccld -IZend/ -I/root/php-5.3.2/Zend/ -DPHP_ATOM_INC -I/root/php-5.3.2/include -I/root/php-5.3.2/main -I/root/php-5.3.2 -I/root/php-5.3.2/ext/date/lib -I/root/php-5.3.2/ext/ereg/regex -I/usr/include/libxml2 -I/usr/kerberos/include -I/usr/include/freetype2 -I/root/php-5.3.2/ext/mbstring/oniguruma -I/root/php-5.3.2/ext/mbstring/libmbfl -I/root/php-5.3.2/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/root/php-5.3.2/ext/sqlite3/libsqlite -I/root/php-5.3.2/TSRM -I/root/php-5.3.2/Zend -D_REENTRANT -I/usr/include -g -O2 -fvisibility=hidden -pthread -DZTS -c /root/php-5.3.2/Zend/zend_objects_API.c -o Zend/zend_objects_API.lo /bin/sh /root/php-5.3.2/libtool --silent --preserve-dup-deps --mode=compile /root/php-5.3.2/meta_ccld -IZend/ -I/root/php-5.3.2/Zend/ -DPHP_ATOM_INC -I/root/php-5.3.2/include -I/root/php-5.3.2/main -I/root/php-5.3.2 -I/root/php-5.3.2/ext/date/lib -I/root/php-5.3.2/ext/ereg/regex -I/usr/include/libxml2 -I/usr/kerberos/include -I/usr/include/freetype2 -I/root/php-5.3.2/ext/mbstring/oniguruma -I/root/php-5.3.2/ext/mbstring/libmbfl -I/root/php-5.3.2/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/root/php-5.3.2/ext/sqlite3/libsqlite -I/root/php-5.3.2/TSRM -I/root/php-5.3.2/Zend -D_REENTRANT -I/usr/include -g -O2 -fvisibility=hidden -pthread -DZTS -c
Bug #51270 [Opn-Fbk]: Apache cannot start
Edit report at http://bugs.php.net/bug.php?id=51270edit=1 ID: 51270 Updated by: paj...@php.net Reported by: jamone_95134 at yahoo dot com Summary: Apache cannot start -Status: Open +Status: Feedback Type: Bug Package: Apache2 related -Operating System: win32 only +Operating System: Windows XP SP3 PHP Version: 5.3.2 New Comment: Ok, which PHP version did you fetch (vc6/vc9) and which Apache version do you use (from apache.org or apachelounge.com)? @Jani Operating system is important and saying only win32 is as useless as saying linux. Previous Comments: [2010-03-11 18:43:58] jamone_95134 at yahoo dot com [2010-03-11 13:13 UTC] paj...@php.net Remove php.ini in your systems or be sure to disable all extensions and try again. As I mentioned earlier, I disabled all the extensions in my php.ini, then enabling them one by one to see if any would allow the Apache to start, but the Apache crashed every time. If I comment out the PHPIniDir line but not the LoadModule Apache still does not start, similarly if I comment out the LoadModule line but not the PHPIniDir, the Apache does not start. Apache only starts if both lines are commented out. [2010-03-11 15:13:43] paj...@php.net Remove php.ini in your systems or be sure to disable all extensions and try again. [2010-03-11 14:21:22] a at liveb dot ru Have the same problem. apache doesn't work as a service. But works from console. When I try to start the service I get an error. szAppName : httpd.exe szAppVer : 2.2.15.0 szModName : unknown szModVer : 0.0.0.0 offset : 0073d729 [2010-03-11 02:30:07] jamone_95134 at yahoo dot com Description: php was installed and works correctly, php 5.3.2 thread safe VC6 version. Apache version 2.2.15 with openssl. The Apache was installed and works. However, when I try to have Apache run and recognize the PHP, the Apache does not start and displays the following message: httpd.exe - Application Error The instruction at 0x00788ce1 referenced memory at 0x0006. The memory could not be read. If I comment out the lines referring to the PHP in the httpd.conf file, then Apache starts with no problems. #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL #PHPIniDir C:/Program Files/PHP/ #LoadModule php5_module C:/Program Files/PHP/php5apache2_2.dll #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL If either line is mot commented, then the Apache crashes. I have tried commenting out the different extensions in the php.ini file, but the problem exists. Can someone please explain why this is crashing and what to do to fix it. Expected result: Apache to start up and recognize php scripting. Actual result: -- httpd.exe - Application Error The instruction at 0x00788ce1 referenced memory at 0x0006. The memory could not be read. -- Edit this bug report at http://bugs.php.net/bug.php?id=51270edit=1
Bug #51128 [Asn]: imagefill() doesn't work with large images
Edit report at http://bugs.php.net/bug.php?id=51128edit=1 ID: 51128 User updated by: admin-team at suresupport dot com Reported by: admin-team at suresupport dot com Summary: imagefill() doesn't work with large images Status: Assigned Type: Bug Package: GD related Operating System: Linux Debian 64bit PHP Version: 5.2.12 Assigned To: pajoye New Comment: I applied the suggested patch from http://bugs.libgd.org/?do=detailstask_id=177. And I confirm that my issue is fixed. Pajoye does the PHP team have plans to integrate that patch in the PHP bundled GD library ? Thank you Previous Comments: [2010-03-09 15:33:52] tm at del dot bg It seems that the following patch fixes the problem: http://bugs.libgd.org/?do=detailstask_id=177 [2010-03-02 09:01:50] admin-team at suresupport dot com Hello, this is the info regarding the GD configuration for both servers: Debian Server 64bit: GD Support enabled GD Version bundled (2.0.34 compatible) FreeType Supportenabled FreeType Linkagewith freetype FreeType Version2.2.1 T1Lib Support enabled GIF Read Supportenabled GIF Create Support enabled JPG Support enabled PNG Support enabled WBMP Supportenabled XBM Support enabled RedHat Server 32bit: GD Support enabled GD Version bundled (2.0.34 compatible) FreeType Supportenabled FreeType Linkagewith freetype FreeType Version2.1.3 T1Lib Support enabled GIF Read Supportenabled GIF Create Support enabled JPG Support enabled PNG Support enabled WBMP Supportenabled XBM Support enabled [2010-03-01 21:42:06] paj...@php.net Can you paste the GD section of phpinfo of both servers please? [2010-02-24 15:51:20] admin-team at suresupport dot com Hello Pajoye, Thank you for your anwser! The code in test1.php test2.php is taken from official documentation of the function: http://php.net/manual/en/function.imagefill.php The problem described in my first post doesn't exist on another type of server - RedHat Linux 32bit - I get 2 red rectangles. Thank you [2010-02-23 21:15:55] paj...@php.net Please allocate a background and then a color to use for the fill. 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=51128 -- Edit this bug report at http://bugs.php.net/bug.php?id=51128edit=1
Bug #51270 [Fbk-Opn]: Apache cannot start
Edit report at http://bugs.php.net/bug.php?id=51270edit=1 ID: 51270 User updated by: jamone_95134 at yahoo dot com Reported by: jamone_95134 at yahoo dot com Summary: Apache cannot start -Status: Feedback +Status: Open Type: Bug Package: Apache2 related Operating System: Windows XP SP3 PHP Version: 5.3.2 New Comment: As stated before: php was installed and works correctly, php 5.3.2 thread safe VC6 version. Apache version 2.2.15 with openssl, downloaded from apache.org works correctly when the PHPIniDir and LoadModule lines are commented out of the httpd.conf file. The OS is windows XP with SP3. Previous Comments: [2010-03-12 11:39:33] paj...@php.net Ok, which PHP version did you fetch (vc6/vc9) and which Apache version do you use (from apache.org or apachelounge.com)? @Jani Operating system is important and saying only win32 is as useless as saying linux. [2010-03-11 18:43:58] jamone_95134 at yahoo dot com [2010-03-11 13:13 UTC] paj...@php.net Remove php.ini in your systems or be sure to disable all extensions and try again. As I mentioned earlier, I disabled all the extensions in my php.ini, then enabling them one by one to see if any would allow the Apache to start, but the Apache crashed every time. If I comment out the PHPIniDir line but not the LoadModule Apache still does not start, similarly if I comment out the LoadModule line but not the PHPIniDir, the Apache does not start. Apache only starts if both lines are commented out. [2010-03-11 15:13:43] paj...@php.net Remove php.ini in your systems or be sure to disable all extensions and try again. [2010-03-11 14:21:22] a at liveb dot ru Have the same problem. apache doesn't work as a service. But works from console. When I try to start the service I get an error. szAppName : httpd.exe szAppVer : 2.2.15.0 szModName : unknown szModVer : 0.0.0.0 offset : 0073d729 [2010-03-11 02:30:07] jamone_95134 at yahoo dot com Description: php was installed and works correctly, php 5.3.2 thread safe VC6 version. Apache version 2.2.15 with openssl. The Apache was installed and works. However, when I try to have Apache run and recognize the PHP, the Apache does not start and displays the following message: httpd.exe - Application Error The instruction at 0x00788ce1 referenced memory at 0x0006. The memory could not be read. If I comment out the lines referring to the PHP in the httpd.conf file, then Apache starts with no problems. #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL #PHPIniDir C:/Program Files/PHP/ #LoadModule php5_module C:/Program Files/PHP/php5apache2_2.dll #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL If either line is mot commented, then the Apache crashes. I have tried commenting out the different extensions in the php.ini file, but the problem exists. Can someone please explain why this is crashing and what to do to fix it. Expected result: Apache to start up and recognize php scripting. Actual result: -- httpd.exe - Application Error The instruction at 0x00788ce1 referenced memory at 0x0006. The memory could not be read. -- Edit this bug report at http://bugs.php.net/bug.php?id=51270edit=1
Bug-Doc #51282 [Opn-Asn]: crypt() result different between PHP 5.3.1 and PHP 5.3.2
Edit report at http://bugs.php.net/bug.php?id=51282edit=1 ID: 51282 Updated by: j...@php.net Reported by: jerome dot auge at anakeen dot com Summary: crypt() result different between PHP 5.3.1 and PHP 5.3.2 -Status: Open +Status: Assigned -Type: Bug +Type: Documentation Problem Package: *Encryption and hash functions Operating System: Mac, Linux PHP Version: 5.3.2 -Assigned To: +Assigned To: joey Previous Comments: [2010-03-12 10:54:22] jerome dot auge at anakeen dot com Description: I use crypt() to store and validate passwords using the « Standard DES » hash, and after upgrading to 5.3.2, the hashed password of an account is not the same as the one generated with PHP 5.3.1 : With PHP 5.3.1 : $ php -r 'print crypt(anakeen, A^).\n;' A^1ul2Jf7VS2M After upgrading to PHP 5.3.2 : $ php -r 'print crypt(anakeen, A^).\n;' A^/ImZ5hqd2VU I tested both on Mac (macports) and on Linux (rawhide), and the hash result was different on both platform. On Mac OS X (10.5), the Perl (or C) crypt gives me the same results as PHP 5.3.1 : $ perl -e 'print crypt(anakeen, A^).\n;' A^1ul2Jf7VS2M While on Linux, the Perl script gives me the same result as PHP 5.3.2. It appears that there is a difference in the crypt() function, between these platforms, regarding the presence of non alpha-num chars in the salt : Mac OS X with A- salt = different hashes : $ php -r 'print crypt(anakeen, A-).\n;' A-75An91LCLEM $ perl -e 'print crypt(anakeen, A-).\n'; A-1ul2Jf7VS2M Mac OS X with A9 salt = same hashes : $ perl -e 'print crypt(anakeen, A9).\n'; A9Pf3.gAayQMM $ php -r 'print crypt(anakeen, A9).\n;' A9Pf3.gAayQMM Maybe I should not have used non alpha-num chars for my salt in the first place ? -- Edit this bug report at http://bugs.php.net/bug.php?id=51282edit=1
Req #51281 [Com]: Json-like alternative syntax for arrays
Edit report at http://bugs.php.net/bug.php?id=51281edit=1
ID: 51281
Comment by: olamedia at gmail dot com
Reported by: olamedia at gmail dot com
Summary: Json-like alternative syntax for arrays
Status: Open
Type:Feature/Change Request
Package: Arrays related
PHP Version: 5.3.2
New Comment:
Found in wiki a declined patch:
http://wiki.php.net/rfc/shortsyntaxforarrays
But I really want
$a = [[],[],[],[],[]]
instead of
$a = array(array(),array(),array(),array(),array());
Previous Comments:
[2010-03-12 09:31:56] olamedia at gmail dot com
Changing package
[2010-03-12 09:18:17] olamedia at gmail dot com
Description:
Json-like alternative syntax for arrays feature request.
It's much shorter, and don't have conflicts with current tokens.
Test script:
---
$a = [1,2];
$a = ['a':1,'b':2];
$a = array('a':1,'b':2);
$a = array('a'=1,'b'=2);
$a = ['a'=1,'b'=2];
--
Edit this bug report at http://bugs.php.net/bug.php?id=51281edit=1
Bug #40508 [Com]: Namespace xpath doesn't work for nested elements
Edit report at http://bugs.php.net/bug.php?id=40508edit=1 ID: 40508 Comment by: kkezmg at gmail dot com Reported by: vr...@php.net Summary: Namespace xpath doesn't work for nested elements Status: Bogus Type: Bug Package: SimpleXML related Operating System: Windows PHP Version: 5.2.1 Assigned To: helly New Comment: So, has this been fixed? Previous Comments: [2007-03-26 20:22:03] rricha...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php XPath context is per SimpleXMLElement object, so although the register in nested element looks like it would work, that too uses different objects. Thanks for the report though as it did expose a bug with the node being used for the XPath context node though. [2007-02-16 13:21:46] vr...@php.net Description: Registering XPath namespace works only for XPath queries from root element. Reproduce code: --- $text = 'a xmlns=http://example.org;bctest/c/b/a'; $xml = simplexml_load_string($text); // register in root $xml-registerXPathNamespace(x, http://example.org;); print_r($xml-b-xpath(x:c)); // register in nested element $xml-b-registerXPathNamespace(x, http://example.org;); print_r($xml-b-xpath(x:c)); Expected result: At least once: Array ( [0] = SimpleXMLElement Object ( [0] = test ) ) Actual result: -- Warning: SimpleXMLElement::xpath(): Undefined namespace prefix Warning: SimpleXMLElement::xpath(): Undefined namespace prefix -- Edit this bug report at http://bugs.php.net/bug.php?id=40508edit=1
[PHP-BUG] Bug #51283 [NEW]: defect stringconcatination with if term
From:
Operating system: windows 2008 linux
PHP version: 5.3.2
Package: *General Issues
Bug Type: Bug
Bug description:defect stringconcatination with if term
Description:
if i concat some strings like $string .= ' ' . (true)? asd : foo ;
the whitespace is always missing..
see code snipped!
Test script:
---
?php
class test {
public $data = array();
public function __construct() {
$this-data[sort] = erstellt;
$this-data[order] = 1;
$order = null;
if (isset($this-data[sort])) {
$order = $this-data[sort];
if (isset($this-data[order])) $order .= ' ' .
($this-data[order] == 1) ? desc : asc;
}
echo $order;
//returns erstelltdesc
echo \n--\n;
$order = null;
if (isset($this-data[sort])) {
$order = $this-data[sort];
if (isset($this-data[order])) {
$order .= ' ';
$order .= ($this-data[order] == 1) ? desc : asc;
}
}
echo $order;
//returns erstellt desc
}
}
new test()
?
Expected result:
erstellt desc
--
erstellt desc
Actual result:
--
erstelltdesc
--
erstellt desc
--
Edit bug report at http://bugs.php.net/bug.php?id=51283edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51283r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51283r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51283r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51283r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51283r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51283r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51283r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51283r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51283r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51283r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51283r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51283r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51283r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51283r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51283r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51283r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51283r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51283r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51283r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51283r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51283r=mysqlcfg
[PHP-BUG] Bug #51284 [NEW]: foreach distroys objects in array
From:
Operating system: MacOSX, Linux, ...
PHP version: Irrelevant
Package: Class/Object related
Bug Type: Bug
Bug description:foreach distroys objects in array
Description:
I have a script which tries to create configured objects of classes. The
method creating the object of the named class will generate a unique
identifier to be able to identify the invocation later in the class. This
unique_id is basically calculated by adding the class name and all
constructor parameters into a :-seperetaed list. For doing this i used
This all functions well as long as there is not the following very special
combination of parameters and class-parameterlist. If one of the parameters
is an object, and this object is passed to the class as reference
($object).
In such a case, the foreach loop destroys somehow the $parameter array. As
the $parameter array is not altered in the loop, there is no explanation to
my way the loop influence the array.
To prove that the loop is causing this problem i changed the loop from
foreach() to for(). As you can see in the test script there are 2 methods
in
the OM class. The get_object_OK() uses the for()-loop to generate the ID
and
the get_object_NOK() method uses the foreach()-loop to generate it.
With the for()-loop the script runs without any troubles. But with the
foreach()-loop the script returns an error while invocating the object.
This
error causes the object to be not created.
The error message which can be found in the webserver's / php's logfile is
the following:
[error] [client 127.0.0.1] PHP Warning: Invocation of test_obj2's
constructor failed in /.../test.php on line 183, referer:
http://127.0.0.1:8080/
... The line references to $obj =
$reflection_obj-newInstanceArgs($parameter); at the get_object_NOK.()
function.
Test script:
---
class test_obj
{
var $test = abc;
function __construct($str)
{
$this-test = $str;
}
function get()
{
echo get_class($this). - string=.$this-test.br /\n;
}
function set($str)
{
$test = $str;
}
}
class test_obj2
{
var $test = abc;
function __construct($string1, $object)
{
echo get_class($this). - string1=$string1br /\n;
$object-get();
}
}
//include_once(dirname(__FILE__).'/object_manager.class.php');
//include_once(dirname(__FILE__).'/element_container.class.php');
//
// Test execution
//
echo PHP Version: .phpversion().br /br /\n;
$om = new OM();
$t1 = new test_obj(init-text-object-1);
$t1-get();
echo Object of class 'Test_CLass' ... Finished.br /\n;
$t2 = $om-get_object_OK(test_obj2, object-text-2, $t1);
echo Object of class 'Test_CLass2' with for() loop ... Finished.br
/\n;
$t2 = $om-get_object_NOK(test_obj2, object-text-2, $t1);
echo Object of class 'Test_CLass2' with foreach() loop ... Finished.br
/\n;
//
// A short testing code from a much biger function / Class to
// demonstrate the behaviour
//
class OM
{
function get_object_OK()
{
$parameter = func_get_args();
$type = array_shift($parameter);
//
// create unique identifier for this object creation.
// Used in the original class to identify the object later in the
class.
//
$unique_id = $type:;
// loop through all parameters
for($i=0; $i count($parameter); $i++)
{
// if parameter is an object, get only the object name
if(is_object($parameter[$i]) === TRUE)
{
$unique_id .= get_class($parameter[$i]).':';
continue;
}
// get the variable content as string to the identifier-string
$unique_id .= gettype($parameter[$i]).':';
}
//
// Creating the object by name
//
$reflection_obj = new ReflectionClass($type);
$obj = $reflection_obj-newInstanceArgs($parameter);
// return the created object
return $obj;
}
function get_object_NOK()
{
$parameter = func_get_args();
$type = array_shift($parameter);
//
// create unique identifier for this object creation.
// Used in the original class to identify the object later in the
class.
//
$unique_id = $type:;
// loop through all parameters
foreach($parameter as $key = $param)
{
// if parameter is an object, get only the object name
if(is_object($param) === TRUE)
{
$unique_id .= get_class($param).':';
continue;
}
// get the variable content as string to the identifier-string
$unique_id .= gettype($param).':';
Bug #51283 [Opn-Bgs]: defect stringconcatination with if term
Edit report at http://bugs.php.net/bug.php?id=51283edit=1
ID: 51283
Updated by: johan...@php.net
Reported by: easteregg at verfriemelt dot org
Summary: defect stringconcatination with if term
-Status: Open
+Status: Bogus
Type: Bug
Package: *General Issues
Operating System: windows 2008 linux
PHP Version: 5.3.2
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
Please see php.net7operators for the Operator Precedence.What happensis
that in
$order .= ' ' . ($this-data[order] == 1) ? desc : asc;
The expression
' ' . ($this-data[order] == 1)
will be evaluated first. Depending on the result desc orasc will be
evaluated and returned.
Use parenthesis:
$order .= ' ' . (($this-data[order] == 1) ? desc : asc);
Previous Comments:
[2010-03-12 13:26:12] easteregg at verfriemelt dot org
Description:
if i concat some strings like $string .= ' ' . (true)? asd : foo ;
the whitespace is always missing..
see code snipped!
Test script:
---
?php
class test {
public $data = array();
public function __construct() {
$this-data[sort] = erstellt;
$this-data[order] = 1;
$order = null;
if (isset($this-data[sort])) {
$order = $this-data[sort];
if (isset($this-data[order])) $order .= ' ' .
($this-data[order] == 1) ? desc : asc;
}
echo $order;
//returns erstelltdesc
echo \n--\n;
$order = null;
if (isset($this-data[sort])) {
$order = $this-data[sort];
if (isset($this-data[order])) {
$order .= ' ';
$order .= ($this-data[order] == 1) ? desc : asc;
}
}
echo $order;
//returns erstellt desc
}
}
new test()
?
Expected result:
erstellt desc
--
erstellt desc
Actual result:
--
erstelltdesc
--
erstellt desc
--
Edit this bug report at http://bugs.php.net/bug.php?id=51283edit=1
Bug #51283 [Com]: defect stringconcatination with if term
Edit report at http://bugs.php.net/bug.php?id=51283edit=1
ID: 51283
Comment by: easteregg at verfriemelt dot org
Reported by: easteregg at verfriemelt dot org
Summary: defect stringconcatination with if term
Status: Bogus
Type: Bug
Package: *General Issues
Operating System: windows 2008 linux
PHP Version: 5.3.2
New Comment:
but this behaviour isnt always the same, before i reported this here, i
discussed this in a forum and some people got the right results with
php5.3.1 and me not.
but thanks for this quick reply
Previous Comments:
[2010-03-12 13:44:43] johan...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Please see php.net7operators for the Operator Precedence.What happensis
that in
$order .= ' ' . ($this-data[order] == 1) ? desc : asc;
The expression
' ' . ($this-data[order] == 1)
will be evaluated first. Depending on the result desc orasc will be
evaluated and returned.
Use parenthesis:
$order .= ' ' . (($this-data[order] == 1) ? desc : asc);
[2010-03-12 13:26:12] easteregg at verfriemelt dot org
Description:
if i concat some strings like $string .= ' ' . (true)? asd : foo ;
the whitespace is always missing..
see code snipped!
Test script:
---
?php
class test {
public $data = array();
public function __construct() {
$this-data[sort] = erstellt;
$this-data[order] = 1;
$order = null;
if (isset($this-data[sort])) {
$order = $this-data[sort];
if (isset($this-data[order])) $order .= ' ' .
($this-data[order] == 1) ? desc : asc;
}
echo $order;
//returns erstelltdesc
echo \n--\n;
$order = null;
if (isset($this-data[sort])) {
$order = $this-data[sort];
if (isset($this-data[order])) {
$order .= ' ';
$order .= ($this-data[order] == 1) ? desc : asc;
}
}
echo $order;
//returns erstellt desc
}
}
new test()
?
Expected result:
erstellt desc
--
erstellt desc
Actual result:
--
erstelltdesc
--
erstellt desc
--
Edit this bug report at http://bugs.php.net/bug.php?id=51283edit=1
Req #50692 [Com]: Don't count 0-bytes files towards the max_file_uploads limit
Edit report at http://bugs.php.net/bug.php?id=50692edit=1 ID: 50692 Comment by: mariusads at helpedia dot com Reported by: john dot peterson10 at gmail dot com Summary: Don't count 0-bytes files towards the max_file_uploads limit Status: Open Type: Feature/Change Request Package: Feature/Change Request Operating System: Windows PHP Version: 5.2.12 New Comment: Those people with websites showing 40 input boxes could just as easy increase the value of the limit in the php.ini or pass it on a case by case basic through .htaccess (if possible, i don't know) Don't see the point of this... Previous Comments: [2010-01-08 07:42:43] john dot peterson10 at gmail dot com Description: Suggestion: Don't count 0-bytes files (that comes from input type=file elements that don't have any file specified) towards the max_file_uploads limit. (And don't create a blank temporary file for them to avoid the problems with file-system overload mentioned in CVE-2009-4017.) Reason for suggestion: That way a small limit for max_file_uploads will cause less website restrictions. For example: I have seen some designs with lists of 40 or 50 rows where every row has a input type=file for the sake of the design of the page. But where typically only one or two files are submitted in a POST because the majority of the input type=file elements has no file specified. Currently all these designs will be limited (to for example 20 rows with the default settings) because even 0-byte files count towards the max_file_uploads limit. Issues with suggestion: The site will need javascript to control the rare exception where more than for example 20 input type=file has a value before submit. But that should not be a big problem. Reproduce code: --- HTML POST request with input type=file elements where the value is blank (no file specified) so that $_FILES[#]['size'] is 0 (and $_FILES[#]['tmp_name'] is blank). Expected result: input type=file elements where no file is specified doesn't count towards the max_file_uploads limit Actual result: -- input type=file elements where no file is specified counts towards the max_file_uploads limit -- Edit this bug report at http://bugs.php.net/bug.php?id=50692edit=1
Bug #51265 [Opn]: Segfault because of wrong memory allocation
Edit report at http://bugs.php.net/bug.php?id=51265edit=1
ID: 51265
User updated by: gotwig at papaya-cms dot com
Reported by: gotwig at papaya-cms dot com
Summary: Segfault because of wrong memory allocation
Status: Open
Type: Bug
Package: Reproducible crash
Operating System: Debian GNU/Linux 4.0
PHP Version: 5.2SVN-2010-03-10 (SVN)
New Comment:
Hallo,
my assumption about a wrong sized block allocation has not confirmed, I
have the source of the problem now:
- it occurs in preg_replace_impl function,
- our php code use preg_replace_callback with a static callback to a
non-static object method,
- this raise an E_STRICT warning where an user defined error handler
will be called,
- this call reallocates argument stack where some pointers to the
previous argument stack frame are already saved in preg_replace_impl and
will be used a bit later.
Our PHP code likes as following:
class PapayaUtilStringUtf8 {
...
preg_replace_callback(
$pattern,
array('PapayaUtilStringUtf8', 'ensureCharCallback'),
(string)$string
);
...
function ensureCharCallback($charMatch) {
...
}
}
Actual backtrace from reallocation call, where p=0xb70318b0 is
argument_stack :
#0 _zend_mm_realloc_int (heap=0x81de2a0, p=0xb70318b0, size=516) at
/data/extern/php_svn/php-src-5.2/Zend/zend_alloc.c:2005
#1 0xb76d02e9 in zend_call_function (fci=0xbfad9d84, fci_cache=0x0) at
/data/extern/php_svn/php-src-5.2/Zend/zend_ptr_stack.h:99
#2 0xb76d191e in call_user_function_ex (function_table=0x812b088,
object_pp=0x0, function_name=0xb6bedd0c, retval_ptr_ptr=0xbfad9e00,
param_count=5, params=0xb6bed450,
no_separation=1, symbol_table=0x0) at
/data/extern/php_svn/php-src-5.2/Zend/zend_execute_API.c:640
#3 0xb76dbfe8 in zend_error (type=2048, format=0xb780ba78 Non-static
method %s::%s() cannot be called statically) at
/data/extern/php_svn/php-src-5.2/Zend/zend.c:1041
#4 0xb76e18fe in zend_is_callable_check_func (check_flags=value
optimized out, zobj_ptr_ptr=0xbfad9eb8, ce_org=0xb6d1dda0,
callable=0xb6b349f8, ce_ptr=0xbfad9ec4,
fptr_ptr=0xbfad9ebc) at
/data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2204
#5 0xb76e1cac in zend_is_callable_ex (callable=0xb6b349e0,
check_flags=value optimized out, callable_name=0xbfad9f44,
callable_name_len=0x0, ce_ptr=0xbfad9ec4,
fptr_ptr=0xbfad9ebc, zobj_ptr_ptr=0xbfad9eb8) at
/data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2332
#6 0xb76e1f97 in zend_is_callable (callable=0xb6b349e0, check_flags=0,
callable_name=0xbfad9f44) at
/data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2363
#7 0xb751f2a4 in preg_replace_impl (ht=3, return_value=0xb6b34cac,
return_value_ptr=value optimized out, this_ptr=0x0,
return_value_used=1,
is_callable_replace=1 '\001') at
/data/extern/php_svn/php-src-5.2/ext/pcre/php_pcre.c:1319
Previous Comments:
[2010-03-10 18:43:40] gotwig at papaya-cms dot com
Description:
Hallo,
I have found a bug in _emalloc logic where an allocation returns a
pointer to a cached block smaller than requested; when this block is
used some memory after that goes corrupted and we get a segfault.
The problem is reproducible with our project code, that is a version of
papaya cms, but I am not able to reconstruct all circumstances with an
example script to send you, sorry. I am debugging it itself, but need
perhaps some help from you to understand how exact does memory
allocation works here and where will be such one error possible: such a
wrong pointer comes from the case on Lines 1778...1790 in zend_alloc.c
:
if (EXPECTED(heap-cache[index] != NULL)) { ...
also, that is a previously freed cached block, but I have actually no
idea where should I look any further. Please, give me some advice.
My configuration:
PHP Version from
http://svn.php.net/repository/php/php-src/branches/PHP_5_2
Revision: 296029
compiled with ./configure --disable-cli --disable-cgi --disable-fastcgi
--with-apxs2=/usr/bin/apxs2 --enable-debug --with-mysql --with-xsl
OS: Debian GNU/Linux 4.0
I have also tested this problem on a build from actually 5.3 branch, but
was not able to reproduce, perhaps because of many changes in another
logic there. But if this bug really comes from _zend_mm_alloc_int
function their code did not changed in 5.3 and the problem may also
occur there.
The bug is not critical for our company, we have found a workaround
where this will not be triggered any more, but this is of course not a
solution an I want to repair it at the source.
Thank you in advance,
Viktor Gotwig.
Actual result:
Doc #51056 [Fbk]: fread() on blocking stream will block even if data is available
Edit report at http://bugs.php.net/bug.php?id=51056edit=1
ID: 51056
Updated by: lbarn...@php.net
Reported by: magical...@php.net
Summary: fread() on blocking stream will block even if data is
available
Status: Feedback
Type: Documentation Problem
Package: Streams related
Operating System: Linux Gentoo 2.6.32
PHP Version: 5.3.1
New Comment:
I see your point in wanting read() behavior. Whether or not to implement
fread() or read() one is arguable. However the specific behavior you are
asking for is not reliable for several reasons, and IMHO (I may be
wrong) you want this behavior for bad reasons. Let me explain this :
By the way using nonblocking mode makes no sense with provided
example. It would just make the program use 100% cpu.
This is why you don't want to use non-blocking streams. If you use
stream_select() you will never end up using 100% CPU : Your PHP process
will only do an idle wait in stream_select() and consume no CPU at all.
Example :
stream_set_blocking($stream, 0);
while (stream_select($r,$w,$e, $stream, $sec, $usec)) { /* block until
data is available for read and/or write in $stream. */
$data = fread($stream, 8192); /* read all available data, up to 8192
bytes. Returns only 1 byte if only 1 byte is available and never blocks.
*/
}
If end of email is reached while a read is in progress and a new read
is called, it will block until the server closes connections
With your patch (or with the read behavior you want) it will still
block. And it will block randomly, in an unpredictable manner.
Please see the following example :
Say the buffer has 250 bytes in it.
fread(100) - buffer.length-=100, buffer.length == 100
fread(100) - buffer.length-=100, buffer.length == 50
fread(100) - with your patch it would return the last 50 available
bytes
Now this other example with a buffer with only 200 bytes in it :
Say the buffer has 200 bytes in it.
fread(100) - buffer.length-=100, buffer.length == 100
fread(100) - buffer.mength-=100, buffer.length == 0
fread(100) - buffer is 0, this blocks, and you can't control this (you
don't control the buffer, and don't know anything about it in a php
script)
Please see 51056-3.phpt.
With current behavior it will block too, but in a predictable maner.
Previous Comments:
[2010-03-12 03:12:35] magical...@php.net
So, it is normal for php's fread() to return immediatly when less data
than asked is available, unless this data arrived while a previous call
of fread() was done and there was
too much data ?
Let me just state that this doesn't makes sense.
I tested stdc's fread() and could confirm that its behaviour is
consistent: it will only return when it has collected the data it
needed, when EOF is reached or when an error
occurs.
It seems that PHP's php_stream_read() is closer to read() syscall than
to stdc's fread(), except for this one specific behaviour.
It follows fread() behavior since years and I believe it should not
change.
I believe the problem comes from the new streams api which is an attempt
to make the socket api obsolete. In fact stream functions (including
fread()) behave the same way the
old socket counterpart did when passed a socket.
The correct behaviour (as defined by common sense, and confirmed by PHP
4.4.9) :
Testing PHP version: 4.4.9
socket_read took 0.06ms to read 8 bytes
socket_read took 5.08ms to read 256 bytes
socket_read took 0.01ms to read 45 bytes
socket_read took 0.08ms to read 8 bytes
socket_read took 5.06ms to read 256 bytes
socket_read took 0.01ms to read 45 bytes
socket_read took 0.07ms to read 8 bytes
socket_read took 5.05ms to read 256 bytes
socket_read took 0.01ms to read 45 bytes
socket_read took 0.08ms to read 8 bytes
Testing with PHP 5.1.0 (first version containing stream_socket_pair())
exhibits a change of behaviour due to the new stream api.
Both tests 51056.phpt and 51056-2.phpt pass on PHP 4.4.9.
By the way using nonblocking mode makes no sense with provided example.
It would just make the program use 100% cpu. For example a PHP program
reading an email from a POP3
server might lockdown because of this bug in blocking mode. If end of
email is reached while a read is in progress and a new read is called,
it will block until the server
closes connections (expected behaviour = return remaining data).
As a PHP sockets programmer (I believe my experience when it comes to
php and sockets is not negligeable) I say once more that *this*
fread()'s behaviour is not consistent.
fread() in blocking mode should block until it has enough bytes or
return as soon as some bytes are avaialble. Blocking should not depend
on when data has arrived.
[2010-03-11 22:03:51] lbarn...@php.net
I
[PHP-BUG] Req #51285 [NEW]: pgettext() and variants support for PHP
From: Operating system: PHP version: 5.3.2 Package: Gettext related Bug Type: Feature/Change Request Bug description:pgettext() and variants support for PHP Description: Newer gettext libraries provide Contexts to translate words that could be need context based translation in other languages. http://www.gnu.org/software/gettext/manual/gettext.html#Contexts PHP's gettext library doesn't support those. -- Edit bug report at http://bugs.php.net/bug.php?id=51285edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51285r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51285r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51285r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51285r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51285r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51285r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51285r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51285r=needscript Try newer version: http://bugs.php.net/fix.php?id=51285r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51285r=support Expected behavior: http://bugs.php.net/fix.php?id=51285r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51285r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51285r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51285r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51285r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51285r=dst IIS Stability: http://bugs.php.net/fix.php?id=51285r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51285r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51285r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51285r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51285r=mysqlcfg
Bug #31234 [Com]: apxs:Error: Command failed with rc=65536
Edit report at http://bugs.php.net/bug.php?id=31234edit=1 ID: 31234 Comment by: wreyes_robles at hotmail dot com Reported by: junk at fishgills dot net Summary: apxs:Error: Command failed with rc=65536 Status: Closed Type: Bug Package: Compile Failure Operating System: Fedora 3 X86_64 PHP Version: 5.0.3 New Comment: Hi all. The perfect bureaucrat everywhere is the man who manages to make no decisions and escape all responsibility. Help me! Could you help me find sites on the: Window coverings blinds. I found only this - a href=http://window-covering-store.biz/;window coverings magazine/a. Window covering, we have a case of how our country should be, how our prince should be, how requirements should pressure us, how neural home we should be using, what expedition we should have, etc. redwolfcomputerforensics from people say that the witness has a galactic certification with one aft preparation - around the ferry. Window covering, quinten has closed into a naive market. Thanks :mad:. Zero from Republic. Previous Comments: [2004-12-22 05:40:16] junk at fishgills dot net I just fixed it. Edited the libtool and added /usr/lib64 to the path. Sorry for anyone's time. Maybe release a 5.0.3_x86_64 patch for people? Thanks though, I love php! [2004-12-21 23:37:12] junk at fishgills dot net Description: I have searched and read all the other bug reports mentioning the same error and found all to be not very helpful. This is on a x86_64 linux distribution with x86_64 libraries of MySQL and everything else. When I run the configure script like so: ./configure --with-apxs2=/www/bin/apxs --with-mysqli The configure script works fine. Then during the make command, everything seems to run find except for a small warning during the linking stage: *** Warning: This system can not link to static lib archive /usr/lib64/mysql/libmysqlclient.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. The compilation itself finishes fine. Then I run make install and get the following error: Installing PHP SAPI module: apache2handler /www/build/instdso.sh SH_LIBTOOL='/www/build/libtool' libphp5.la /www/modules /www/build/libtool --mode=install cp libphp5.la /www/modules/ cp .libs/libphp5.lai /www/modules/libphp5.la cp .libs/libphp5.a /www/modules/libphp5.a ranlib /www/modules/libphp5.a chmod 644 /www/modules/libphp5.a libtool: install: warning: remember to run `libtool --finish /download/php-5.0.3/libs' Warning! dlname not found in /www/modules/libphp5.la. Assuming installing a .so rather than a libtool archive. chmod 755 /www/modules/libphp5.so chmod: cannot access `/www/modules/libphp5.so': No such file or directory apxs:Error: Command failed with rc=65536 . make: *** [install-sapi] Error 1 Reproduce code: --- ./configure --with-apxs2=/www/bin/apxs --with-mysqli make make install Expected result: I expect PHP 5 to be compiled for Apache and isntalled in the modules directory and to...well... work. ;) Actual result: -- Installing PHP SAPI module: apache2handler /www/build/instdso.sh SH_LIBTOOL='/www/build/libtool' libphp5.la /www/modules /www/build/libtool --mode=install cp libphp5.la /www/modules/ cp .libs/libphp5.lai /www/modules/libphp5.la cp .libs/libphp5.a /www/modules/libphp5.a ranlib /www/modules/libphp5.a chmod 644 /www/modules/libphp5.a libtool: install: warning: remember to run `libtool --finish /download/php-5.0.3/libs' Warning! dlname not found in /www/modules/libphp5.la. Assuming installing a .so rather than a libtool archive. chmod 755 /www/modules/libphp5.so chmod: cannot access `/www/modules/libphp5.so': No such file or directory apxs:Error: Command failed with rc=65536 . make: *** [install-sapi] Error 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=31234edit=1
Bug #51265 [Opn-Fbk]: Segfault because of wrong memory allocation
Edit report at http://bugs.php.net/bug.php?id=51265edit=1
ID: 51265
Updated by: paj...@php.net
Reported by: gotwig at papaya-cms dot com
Summary: Segfault because of wrong memory allocation
-Status: Open
+Status: Feedback
Type: Bug
Package: Reproducible crash
Operating System: Debian GNU/Linux 4.0
PHP Version: 5.2SVN-2010-03-10 (SVN)
New Comment:
Do you have a script to reproduce this problem?
Previous Comments:
[2010-03-12 14:45:12] gotwig at papaya-cms dot com
Hallo,
my assumption about a wrong sized block allocation has not confirmed, I
have the source of the problem now:
- it occurs in preg_replace_impl function,
- our php code use preg_replace_callback with a static callback to a
non-static object method,
- this raise an E_STRICT warning where an user defined error handler
will be called,
- this call reallocates argument stack where some pointers to the
previous argument stack frame are already saved in preg_replace_impl and
will be used a bit later.
Our PHP code likes as following:
class PapayaUtilStringUtf8 {
...
preg_replace_callback(
$pattern,
array('PapayaUtilStringUtf8', 'ensureCharCallback'),
(string)$string
);
...
function ensureCharCallback($charMatch) {
...
}
}
Actual backtrace from reallocation call, where p=0xb70318b0 is
argument_stack :
#0 _zend_mm_realloc_int (heap=0x81de2a0, p=0xb70318b0, size=516) at
/data/extern/php_svn/php-src-5.2/Zend/zend_alloc.c:2005
#1 0xb76d02e9 in zend_call_function (fci=0xbfad9d84, fci_cache=0x0) at
/data/extern/php_svn/php-src-5.2/Zend/zend_ptr_stack.h:99
#2 0xb76d191e in call_user_function_ex (function_table=0x812b088,
object_pp=0x0, function_name=0xb6bedd0c, retval_ptr_ptr=0xbfad9e00,
param_count=5, params=0xb6bed450,
no_separation=1, symbol_table=0x0) at
/data/extern/php_svn/php-src-5.2/Zend/zend_execute_API.c:640
#3 0xb76dbfe8 in zend_error (type=2048, format=0xb780ba78 Non-static
method %s::%s() cannot be called statically) at
/data/extern/php_svn/php-src-5.2/Zend/zend.c:1041
#4 0xb76e18fe in zend_is_callable_check_func (check_flags=value
optimized out, zobj_ptr_ptr=0xbfad9eb8, ce_org=0xb6d1dda0,
callable=0xb6b349f8, ce_ptr=0xbfad9ec4,
fptr_ptr=0xbfad9ebc) at
/data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2204
#5 0xb76e1cac in zend_is_callable_ex (callable=0xb6b349e0,
check_flags=value optimized out, callable_name=0xbfad9f44,
callable_name_len=0x0, ce_ptr=0xbfad9ec4,
fptr_ptr=0xbfad9ebc, zobj_ptr_ptr=0xbfad9eb8) at
/data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2332
#6 0xb76e1f97 in zend_is_callable (callable=0xb6b349e0, check_flags=0,
callable_name=0xbfad9f44) at
/data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2363
#7 0xb751f2a4 in preg_replace_impl (ht=3, return_value=0xb6b34cac,
return_value_ptr=value optimized out, this_ptr=0x0,
return_value_used=1,
is_callable_replace=1 '\001') at
/data/extern/php_svn/php-src-5.2/ext/pcre/php_pcre.c:1319
[2010-03-10 18:43:40] gotwig at papaya-cms dot com
Description:
Hallo,
I have found a bug in _emalloc logic where an allocation returns a
pointer to a cached block smaller than requested; when this block is
used some memory after that goes corrupted and we get a segfault.
The problem is reproducible with our project code, that is a version of
papaya cms, but I am not able to reconstruct all circumstances with an
example script to send you, sorry. I am debugging it itself, but need
perhaps some help from you to understand how exact does memory
allocation works here and where will be such one error possible: such a
wrong pointer comes from the case on Lines 1778...1790 in zend_alloc.c
:
if (EXPECTED(heap-cache[index] != NULL)) { ...
also, that is a previously freed cached block, but I have actually no
idea where should I look any further. Please, give me some advice.
My configuration:
PHP Version from
http://svn.php.net/repository/php/php-src/branches/PHP_5_2
Revision: 296029
compiled with ./configure --disable-cli --disable-cgi --disable-fastcgi
--with-apxs2=/usr/bin/apxs2 --enable-debug --with-mysql --with-xsl
OS: Debian GNU/Linux 4.0
I have also tested this problem on a build from actually 5.3 branch, but
was not able to reproduce, perhaps because of many changes in another
logic there. But if this bug really comes from _zend_mm_alloc_int
function their code did not changed in 5.3 and the problem may also
occur there.
The bug is not critical for our company, we have found a
Bug #51207 [Opn]: imageTTFText: misalignment of characters which extend beyond their left margin
Edit report at http://bugs.php.net/bug.php?id=51207edit=1 ID: 51207 User updated by: penkert at yahoo dot com Reported by: penkert at yahoo dot com Summary: imageTTFText: misalignment of characters which extend beyond their left margin Status: Open Type: Bug Package: GD related Operating System: Linux Windows XP PHP Version: 5.2.13 New Comment: Any chance you could provide the font you're using to the PHP team? We're using the commercial font Pirouette Text by Linotype which I obviously can't just hand out freely. Of course, this makes it very difficult for a third party to reproduce my bug. Hence, another reproducibly bug scenario would probably be immensely helpful... Previous Comments: [2010-03-11 15:51:25] dbrow75 at yahoo dot com sorry flipped flopped FreeType versions, should be http://tools.sorellajewelry.com/broken.png (5.2.13, FreeType 2.2.1) http://tools.sorellajewelry.com/Correct.png (5.2.9, FreeType 2.1.9) [2010-03-11 15:29:16] dbrow75 at yahoo dot com Example of broken image and correct image, same underlying code only difference is PHP version (and GD library FreeType which got upgraded in PHP upgrade) http://tools.sorellajewelry.com/broken.png (5.2.13, FreeType 2.1.9) http://tools.sorellajewelry.com/Correct.png (5.2.9, FreeType 2.2.1) [2010-03-11 15:21:36] dbrow75 at yahoo dot com I too am seeing issues since my HOST upgraded to PHP 5.2.13. We use a Monogram font to create and image and the center character is now mis-aligned as well circle that should be surrounding all the character is missing. http://tools.sorellajewelry.com/text_to_png.php?font=7text=aAa You can see the middle character is shifted right and the outer circle is missing. I have on running on a PHP 5.2.6 dev system with no issues. [2010-03-06 20:07:00] penkert at yahoo dot com BTW, about my Win32 testbed: PHP 5.2.11, GD bundled (2.0.34 compatible), FreeType 2.1.9 = OK PHP 5.2.13, GD bundled (2.0.34 compatible), FreeType 2.1.9 = buggy result Debian production system: PHP 5.2.13, GD bundled (2.0.34 compatible), FreeType 2.2.1 = buggy result (can't go back to older PHP version there) [2010-03-06 19:44:06] penkert at yahoo dot com I had a look at those two bugs before writing up my report. In fact, their seem to be quite a number of similar bugs concerning imageTTFText. But the thing is that the bug I'm describing was not present in PHP 5.2.11. So, even though all of these bugs are probably related in some way or other I decided they can't actually be one and the same. 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=51207 -- Edit this bug report at http://bugs.php.net/bug.php?id=51207edit=1
Bug #51265 [Fbk-Opn]: Segfault because of wrong memory allocation
Edit report at http://bugs.php.net/bug.php?id=51265edit=1
ID: 51265
User updated by: gotwig at papaya-cms dot com
Reported by: gotwig at papaya-cms dot com
Summary: Segfault because of wrong memory allocation
-Status: Feedback
+Status: Open
Type: Bug
Package: Reproducible crash
Operating System: Debian GNU/Linux 4.0
PHP Version: 5.2SVN-2010-03-10 (SVN)
New Comment:
sorry, I have actually no idea how to exactly reproduce a stack
reallocation inside of preg_replace_callback with a custom script to
help you. I must think about, perhaps some days later.
Previous Comments:
[2010-03-12 16:03:39] paj...@php.net
Do you have a script to reproduce this problem?
[2010-03-12 14:45:12] gotwig at papaya-cms dot com
Hallo,
my assumption about a wrong sized block allocation has not confirmed, I
have the source of the problem now:
- it occurs in preg_replace_impl function,
- our php code use preg_replace_callback with a static callback to a
non-static object method,
- this raise an E_STRICT warning where an user defined error handler
will be called,
- this call reallocates argument stack where some pointers to the
previous argument stack frame are already saved in preg_replace_impl and
will be used a bit later.
Our PHP code likes as following:
class PapayaUtilStringUtf8 {
...
preg_replace_callback(
$pattern,
array('PapayaUtilStringUtf8', 'ensureCharCallback'),
(string)$string
);
...
function ensureCharCallback($charMatch) {
...
}
}
Actual backtrace from reallocation call, where p=0xb70318b0 is
argument_stack :
#0 _zend_mm_realloc_int (heap=0x81de2a0, p=0xb70318b0, size=516) at
/data/extern/php_svn/php-src-5.2/Zend/zend_alloc.c:2005
#1 0xb76d02e9 in zend_call_function (fci=0xbfad9d84, fci_cache=0x0) at
/data/extern/php_svn/php-src-5.2/Zend/zend_ptr_stack.h:99
#2 0xb76d191e in call_user_function_ex (function_table=0x812b088,
object_pp=0x0, function_name=0xb6bedd0c, retval_ptr_ptr=0xbfad9e00,
param_count=5, params=0xb6bed450,
no_separation=1, symbol_table=0x0) at
/data/extern/php_svn/php-src-5.2/Zend/zend_execute_API.c:640
#3 0xb76dbfe8 in zend_error (type=2048, format=0xb780ba78 Non-static
method %s::%s() cannot be called statically) at
/data/extern/php_svn/php-src-5.2/Zend/zend.c:1041
#4 0xb76e18fe in zend_is_callable_check_func (check_flags=value
optimized out, zobj_ptr_ptr=0xbfad9eb8, ce_org=0xb6d1dda0,
callable=0xb6b349f8, ce_ptr=0xbfad9ec4,
fptr_ptr=0xbfad9ebc) at
/data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2204
#5 0xb76e1cac in zend_is_callable_ex (callable=0xb6b349e0,
check_flags=value optimized out, callable_name=0xbfad9f44,
callable_name_len=0x0, ce_ptr=0xbfad9ec4,
fptr_ptr=0xbfad9ebc, zobj_ptr_ptr=0xbfad9eb8) at
/data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2332
#6 0xb76e1f97 in zend_is_callable (callable=0xb6b349e0, check_flags=0,
callable_name=0xbfad9f44) at
/data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2363
#7 0xb751f2a4 in preg_replace_impl (ht=3, return_value=0xb6b34cac,
return_value_ptr=value optimized out, this_ptr=0x0,
return_value_used=1,
is_callable_replace=1 '\001') at
/data/extern/php_svn/php-src-5.2/ext/pcre/php_pcre.c:1319
[2010-03-10 18:43:40] gotwig at papaya-cms dot com
Description:
Hallo,
I have found a bug in _emalloc logic where an allocation returns a
pointer to a cached block smaller than requested; when this block is
used some memory after that goes corrupted and we get a segfault.
The problem is reproducible with our project code, that is a version of
papaya cms, but I am not able to reconstruct all circumstances with an
example script to send you, sorry. I am debugging it itself, but need
perhaps some help from you to understand how exact does memory
allocation works here and where will be such one error possible: such a
wrong pointer comes from the case on Lines 1778...1790 in zend_alloc.c
:
if (EXPECTED(heap-cache[index] != NULL)) { ...
also, that is a previously freed cached block, but I have actually no
idea where should I look any further. Please, give me some advice.
My configuration:
PHP Version from
http://svn.php.net/repository/php/php-src/branches/PHP_5_2
Revision: 296029
compiled with ./configure --disable-cli --disable-cgi --disable-fastcgi
--with-apxs2=/usr/bin/apxs2 --enable-debug --with-mysql --with-xsl
OS: Debian GNU/Linux 4.0
I have also tested this problem on a build
Bug #44396 [Com]: class compilation notices refer to wrong line number
Edit report at http://bugs.php.net/bug.php?id=44396edit=1
ID: 44396
Comment by: sebastian at sebsoft dot nl
Reported by: frase at cs dot wisc dot edu
Summary: class compilation notices refer to wrong line number
Status: Bogus
Type: Bug
Package: Class/Object related
Operating System: Ubuntu 7.10
PHP Version: 5.2.5
New Comment:
Would it be possible to add a check or enforcing a check for this?
I imagine you don't want something like this in a production
environment, but it might be good to create some kind of ini setting for
this.
It might help with debugging.
I do agree this might be 'won't fix' for production environments, but
for development, I really would like to see a solution for this issue.
Previous Comments:
[2008-03-10 23:30:25] frase at cs dot wisc dot edu
Yes, I understand that, and I agree that performance and
constant-definition-order-flexibility are more important than the
accuracy of this error message. As I said, I do not necessarily expect
an immediate patch for this.
However, I would still petition that this report is not bogus, because
bogus implies that there is no mistake to fix. But this message is,
in fact, incorrect, since the undefined constant does not occur on the
line indicated -- the fact that it may not be worth fixing at this time
does not change the validity of that observation.
A will not fix or fix deferred indefinitely or some such designation
seems more appropriate to me. That way, if some future change to PHP's
internals makes this easier to solve, this report will remain as a
reminder.
[2008-03-10 21:07:15] johan...@php.net
Checking this during compilation would require to lookup the constant
during compilation, but we don't enforce the declaration order to allow
more flexible code, yes the message is not perfect but that can't be
changed without major changes which break PHP's current behviour.
[2008-03-10 19:18:01] frase at cs dot wisc dot edu
Thanks for the reply. That explains /why/ it happens, but it still is
not ideal behavior; in a very large class, it could take someone a long,
long time to track down the origin of this message, since the line
number attached to it is meaningless.
I suppose I'm not expecting a quick patch to fix this, since it is a
relatively minor problem and I imagine the constant-reference tracking
necessary to solve it would have larger performance implications. But I
thought it worth noting at least, in case some future change to PHP's
internals makes it viable to address this.
[2008-03-10 18:58:57] col...@php.net
The problem here is that the constant is evaluated just in time, which
means it will only be looked for when you instantiate the class. Your
example may be reduced to :
class A {
public $a = FOOBAR;
}
$a = new A; // Error will be triggered at this point.
Currently the line at which the constant is actually used is not
tracked.
[2008-03-10 18:00:58] frase at cs dot wisc dot edu
Description:
If a class definition generates a notice, the line number printed with
the notice corresponds to the first line in which the class is
instantiated, and NOT the line which truly gives rise to the notice.
Reproduce code:
---
class OtherClass {
// etc...
}
class TestClass {
static $linkedClass = OtherClass;
function __construct() {
echo I am linked to . self::$linkedClass;
}
}
$obj = new TestClass();
Expected result:
I am linked to OtherClass
Actual result:
--
Notice: Use of undefined constant OtherClass - assumed 'OtherClass' in
test.php on line 10
I am linked to OtherClass
Line 10 does not contain the phrase 'OtherClass' to begin with, as an
undefined constant or otherwise, so the notice is confusing. The line
on which the notice actually arises is line 5, where the class' static
member is incorrectly initialized (it should, in fact, have been a
string).
Disclaimer: The need to have one class refer to another by name, as in
this example, may seem odd but is irrelevant to this bug report (it
arose for me because of a more complicated class inheritance need). I
suspect any notice arising during a class' static member initialization
will have the same wrong line-number; errors other than E_NOTICE might
as well, I haven't taken the time to check exhaustively.
--
Edit this bug report at http://bugs.php.net/bug.php?id=44396edit=1
Bug #51207 [Com]: imageTTFText: misalignment of characters which extend beyond their left margin
Edit report at http://bugs.php.net/bug.php?id=51207edit=1 ID: 51207 Comment by: dbrow75 at yahoo dot com Reported by: penkert at yahoo dot com Summary: imageTTFText: misalignment of characters which extend beyond their left margin Status: Open Type: Bug Package: GD related Operating System: Linux Windows XP PHP Version: 5.2.13 New Comment: Hi, both paid fonts as well. HMSNMW__.TTF (HM Snowflake MonogramsWhite)and vinemsb_.ttf (Vine Monograms Solid Bold) were both affected. Both are from Harold's Fonts which can be found at http://www.fontbros.com/cgi-bin/commerce.cgi?search=actioncategory=1210 Previous Comments: [2010-03-12 16:24:08] penkert at yahoo dot com Any chance you could provide the font you're using to the PHP team? We're using the commercial font Pirouette Text by Linotype which I obviously can't just hand out freely. Of course, this makes it very difficult for a third party to reproduce my bug. Hence, another reproducibly bug scenario would probably be immensely helpful... [2010-03-11 15:51:25] dbrow75 at yahoo dot com sorry flipped flopped FreeType versions, should be http://tools.sorellajewelry.com/broken.png (5.2.13, FreeType 2.2.1) http://tools.sorellajewelry.com/Correct.png (5.2.9, FreeType 2.1.9) [2010-03-11 15:29:16] dbrow75 at yahoo dot com Example of broken image and correct image, same underlying code only difference is PHP version (and GD library FreeType which got upgraded in PHP upgrade) http://tools.sorellajewelry.com/broken.png (5.2.13, FreeType 2.1.9) http://tools.sorellajewelry.com/Correct.png (5.2.9, FreeType 2.2.1) [2010-03-11 15:21:36] dbrow75 at yahoo dot com I too am seeing issues since my HOST upgraded to PHP 5.2.13. We use a Monogram font to create and image and the center character is now mis-aligned as well circle that should be surrounding all the character is missing. http://tools.sorellajewelry.com/text_to_png.php?font=7text=aAa You can see the middle character is shifted right and the outer circle is missing. I have on running on a PHP 5.2.6 dev system with no issues. [2010-03-06 20:07:00] penkert at yahoo dot com BTW, about my Win32 testbed: PHP 5.2.11, GD bundled (2.0.34 compatible), FreeType 2.1.9 = OK PHP 5.2.13, GD bundled (2.0.34 compatible), FreeType 2.1.9 = buggy result Debian production system: PHP 5.2.13, GD bundled (2.0.34 compatible), FreeType 2.2.1 = buggy result (can't go back to older PHP version there) 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=51207 -- Edit this bug report at http://bugs.php.net/bug.php?id=51207edit=1
Bug #10886 [Com]: Warning: _oci_open_server: ORA-12154: TNS:no se ha podido resolver el nombre de
Edit report at http://bugs.php.net/bug.php?id=10886edit=1 ID: 10886 Comment by: amontero at improsa dot com Reported by: webssi at 123mail dot cl Summary: Warning: _oci_open_server: ORA-12154: TNS:no se ha podido resolver el nombre de Status: Closed Type: Bug Package: OCI8 related Operating System: NT SERVER 4.0 APACHE 1.3.14 PHP Version: 4.0.5 New Comment: i had the same error Warning: ocilogon(): _oci_open_server: ORA-12154: TNS:could not resolve the connect identifier specified in /opt/Apache13/htdocs/intranet/prueba.php on line 3 my enviroment variables ORACLE_SID=DBXX ORACLE_BASE=/opt/oracle/product/10.2.0 TNS_ADMIN=/opt/oracle/product/10.2.0/db_1/network/admin/tnsnames.ora ORACLE_HOME=/opt/oracle/product/10.2.0/db_1 my php version is 4.3.9 with Apache 1.3.42 please need help Previous Comments: [2002-04-13 08:28:43] th...@php.net make sure your environment is setup correctly and that you can connect via sqlplus. [2001-05-15 15:46:31] webssi at 123mail dot cl Warning: _oci_open_server: ORA-12154: TNS:no se ha podido resolver el nombre del servicio in c:\web\apache\htdocs\orac.php on line 2 have all, the parameters ok is one bugs in the php, exist solutioin the respect please nedd help -- Edit this bug report at http://bugs.php.net/bug.php?id=10886edit=1
[PHP-BUG] Bug #51288 [NEW]: null pointer deref when methodName is not set
From: geissert Operating system: * PHP version: Irrelevant Package: XMLRPC-EPI related Bug Type: Bug Bug description:null pointer deref when methodName is not set Description: This is CVE-2010-0397, originally reported by Auke van Slooten at http://bugs.debian.org/573573 When processing an invalid (one without a methodName, required by the specs) XML-RPC request, the extension doesn't check for the NULL value returned by the xmlrpc library. This NULL is then passed to estrdup which dereferences the pointer, leading to a segmentation fault. This can easily be used to perform DoS attacks by crashing the server. I've already notified secur...@php.net, but since the issue is public there's no point in hiding it or the patch. The attached patch fixes the problem, which can also be found at: http://git.debian.org/?p=pkg-php/php.git;a=blob;f=debian/patches/CVE-2010-0397.patch;h=186b2166644c066f28f1ffb9195ffa9f5744a604;hb=HEAD Test script: --- ?php $method = ''; $req = '?xml version=1.0?methodCall/methodCall'; var_dump(xmlrpc_decode_request($req, $method)); var_dump($method); echo Done\n; ? Expected result: NULL NULL Done Actual result: -- Segmentation fault -- Edit bug report at http://bugs.php.net/bug.php?id=51288edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51288r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51288r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51288r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51288r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51288r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51288r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51288r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51288r=needscript Try newer version: http://bugs.php.net/fix.php?id=51288r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51288r=support Expected behavior: http://bugs.php.net/fix.php?id=51288r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51288r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51288r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51288r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51288r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51288r=dst IIS Stability: http://bugs.php.net/fix.php?id=51288r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51288r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51288r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51288r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51288r=mysqlcfg
Bug #51288 [PATCH]: null pointer deref when methodName is not set
Edit report at http://bugs.php.net/bug.php?id=51288edit=1 ID: 51288 Patch added by: geiss...@php.net Reported by: geiss...@php.net Summary: null pointer deref when methodName is not set Status: Open Type: Bug Package: XMLRPC-EPI related Operating System: * PHP Version: Irrelevant New Comment: The following patch has been added/updated: Patch Name: CVE-2009-3765 Revision: 1268446854 URL: http://bugs.php.net/patch-display.php?bug=51288patch=CVE-2009-3765revision=1268446854 Previous Comments: [2010-03-13 03:20:02] geiss...@php.net Description: This is CVE-2010-0397, originally reported by Auke van Slooten at http://bugs.debian.org/573573 When processing an invalid (one without a methodName, required by the specs) XML-RPC request, the extension doesn't check for the NULL value returned by the xmlrpc library. This NULL is then passed to estrdup which dereferences the pointer, leading to a segmentation fault. This can easily be used to perform DoS attacks by crashing the server. I've already notified secur...@php.net, but since the issue is public there's no point in hiding it or the patch. The attached patch fixes the problem, which can also be found at: http://git.debian.org/?p=pkg-php/php.git;a=blob;f=debian/patches/CVE-2010-0397.patch;h=186b2166644c066f28f1ffb9195ffa9f5744a604;hb=HEAD Test script: --- ?php $method = ''; $req = '?xml version=1.0?methodCall/methodCall'; var_dump(xmlrpc_decode_request($req, $method)); var_dump($method); echo Done\n; ? Expected result: NULL NULL Done Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/bug.php?id=51288edit=1
Bug #37276 [Com]: problems witch $_POST array
Edit report at http://bugs.php.net/bug.php?id=37276edit=1 ID: 37276 Comment by: rookiecracker at gmail dot com Reported by: puovils at gmail dot com Summary: problems witch $_POST array Status: Closed Type:Bug Package: *General Issues PHP Version: 5.1.3 Assigned To: dmitry New Comment: A href=http://www.eluxuryin.com/; target=_blankLouis Vuitton/A A href=http://www.eluxuryin.com/; target=_blankLV/A A href=http://www.eluxuryin.com/; target=_blanklouis vuitton bags/A Previous Comments: [2006-05-03 11:48:07] dmi...@php.net Fixed in CVS HEAD and PHP_5_1. [2006-05-03 11:05:16] kervala at jpopdb dot net I just looked in PHP code and I think problem is in php_register_variable_ex function in main/php_variables.c file. [2006-05-03 10:34:15] daffy at evil dot lt Concerning phpMyAdmin : http://sourceforge.net/forum/message.php?msg_id=3711167 The same problem exists on win32 too. [2006-05-03 10:30:43] judas dot iscariote at gmail dot com Yes, there is something very wrong, I have experienced this problem with phpmyadmin but neglected to report here :-( [2006-05-03 10:16:33] kervala at jpopdb dot net I forgot to add that phpMyAdmin isn't working anymore and put Array strings almost everywhere instead of correct datas... 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=37276 -- Edit this bug report at http://bugs.php.net/bug.php?id=37276edit=1
Bug #37276 [Com]: problems witch $_POST array
Edit report at http://bugs.php.net/bug.php?id=37276edit=1 ID: 37276 Comment by: rookiecracker at gmail dot com Reported by: puovils at gmail dot com Summary: problems witch $_POST array Status: Closed Type:Bug Package: *General Issues PHP Version: 5.1.3 Assigned To: dmitry New Comment: [url=http://www.linkslondonsale.com/]links of london[/url] [url=http://www.linkslondonsale.com/]links london[/url] [url=http://www.linkslondonsale.com/]links of london jewellery[/url] [url=http://www.linkslondonsale.com/]links of london charms[/url] [url=http://www.linkslondonsale.com/]links of london on sale[/url] [url=http://www.linkslondonsale.com/]friendship bracelets[/url] [url=http://www.linkslondonsale.com/]links of london bracelets[/url] [url=http://www.linkslondonsale.com/]links of london charms[/url] [url=http://www.linkslondonsale.com/]links of london charms bracelets[/url] [url=http://www.linkslondonsale.com/]links of london necklace[/url] [url=http://www.linkslondonsale.com/]Links of London Earrings[/url] [url=http://www.linkslondonsale.com/]Links of London Rings[/url] [url=http://www.linkslondonsale.com/]links of london watches[/url] [url=http://www.linkslondonsale.com/]links of london accessories[/url] [url=http://www.linkslondonsale.com/]links of london sweetie bracelets[/url] [url=http://www.eluxuryin.com/]Louis Vuitton[/url] [url=http://www.eluxuryin.com/]LV[/url] [url=http://www.eluxuryin.com/]louis vuitton bags[/url] [url=http://www.eluxuryin.com/]LV bags[/url] Previous Comments: [2010-03-13 04:12:07] rookiecracker at gmail dot com A href=http://www.eluxuryin.com/; target=_blankLouis Vuitton/A A href=http://www.eluxuryin.com/; target=_blankLV/A A href=http://www.eluxuryin.com/; target=_blanklouis vuitton bags/A [2006-05-03 11:48:07] dmi...@php.net Fixed in CVS HEAD and PHP_5_1. [2006-05-03 11:05:16] kervala at jpopdb dot net I just looked in PHP code and I think problem is in php_register_variable_ex function in main/php_variables.c file. [2006-05-03 10:34:15] daffy at evil dot lt Concerning phpMyAdmin : http://sourceforge.net/forum/message.php?msg_id=3711167 The same problem exists on win32 too. [2006-05-03 10:30:43] judas dot iscariote at gmail dot com Yes, there is something very wrong, I have experienced this problem with phpmyadmin but neglected to report here :-( 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=37276 -- Edit this bug report at http://bugs.php.net/bug.php?id=37276edit=1
[PHP-BUG] Bug #51289 [NEW]: unaligned memory access in enchant.c
From: geissert Operating system: linux ia64 PHP version: 5.3.2 Package: *Spelling functions Bug Type: Bug Bug description:unaligned memory access in enchant.c Description: ext/enchant/tests/bug13181.php triggers an unaligned memory access in enchant.c's enchant_dict_suggest(). enchant_dict_quick_check() is also affected, so adding a test case (the one from the documentation but simply count()ing the returned array for 0, for example) is a good idea. Attached patch fixes the first case. Expected result: resource(5) of type (enchant_dict) resource(5) of type (enchant_dict) resource(6) of type (enchant_broker) resource(6) of type (enchant_broker) resource(7) of type (enchant_dict) resource(7) of type (enchant_dict) Actual result: -- resource(5) of type (enchant_dict) resource(5) of type (enchant_dict) Bus error -- Edit bug report at http://bugs.php.net/bug.php?id=51289edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51289r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51289r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51289r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51289r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51289r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51289r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51289r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51289r=needscript Try newer version: http://bugs.php.net/fix.php?id=51289r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51289r=support Expected behavior: http://bugs.php.net/fix.php?id=51289r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51289r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51289r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51289r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51289r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51289r=dst IIS Stability: http://bugs.php.net/fix.php?id=51289r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51289r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51289r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51289r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51289r=mysqlcfg
Bug #51289 [PATCH]: unaligned memory access in enchant.c
Edit report at http://bugs.php.net/bug.php?id=51289edit=1 ID: 51289 Patch added by: geiss...@php.net Reported by: geiss...@php.net Summary: unaligned memory access in enchant.c Status: Open Type: Bug Package: *Spelling functions Operating System: linux ia64 PHP Version: 5.3.2 New Comment: The following patch has been added/updated: Patch Name: enchant_unaligned_memory_access.patch Revision: 1268451320 URL: http://bugs.php.net/patch-display.php?bug=51289patch=enchant_unaligned_memory_access.patchrevision=1268451320 Previous Comments: [2010-03-13 04:26:14] geiss...@php.net Description: ext/enchant/tests/bug13181.php triggers an unaligned memory access in enchant.c's enchant_dict_suggest(). enchant_dict_quick_check() is also affected, so adding a test case (the one from the documentation but simply count()ing the returned array for 0, for example) is a good idea. Attached patch fixes the first case. Expected result: resource(5) of type (enchant_dict) resource(5) of type (enchant_dict) resource(6) of type (enchant_broker) resource(6) of type (enchant_broker) resource(7) of type (enchant_dict) resource(7) of type (enchant_dict) Actual result: -- resource(5) of type (enchant_dict) resource(5) of type (enchant_dict) Bus error -- Edit this bug report at http://bugs.php.net/bug.php?id=51289edit=1
