#41190 [Com]: Two proposed patches for sybase_ct module
ID: 41190 Comment by: remi dot astier at bnpparibas dot com Reported By: nick at marden dot org Status: No Feedback Bug Type: Feature/Change Request Operating System: (any) PHP Version: 5.3 Assigned To: thekid New Comment: That fix would make my life easier ! How soon can it be implemented ? Previous Comments: [2009-04-09 17:06:49] e dot vinot at cegetel dot net Hello Is there any chance to get these 2 Fixes included in close releases of PHP 5 ? In my case I'm very interested by the function sybase_return_status() The sybase_output_params() will very useful as well Thanks Emmanuel [2008-11-18 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-11-10 12:05:48] the...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Sorry, finally been able to take care of ext/sybase_ct again. New box, can't find the patch anymore. Unfortunately, the URLs yield a "File not found" page and even Google doesn't hold a cached version. [2007-07-24 21:06:43] nick at marden dot org I've spiffed up the patch to make it patch 100% cleanly with PHP 5.2.3. The patch is still at: http://www.marden.org/php-sybase-ct/php5-sybase_ct.return_status-and- output_params.patch [2007-05-22 12:14:35] the...@php.net Unfortunately your patch doesn't apply against current CVS (PHP_5_2) $ patch < php5-sybase_ct.return_status-and-output_params.patch patching file php_sybase_ct.h patching file php_sybase_ct.c Hunk #3 succeeded at 177 with fuzz 2 (offset 16 lines). Hunk #4 FAILED at 1044. Hunk #5 succeeded at 1147 (offset 5 lines). Hunk #6 succeeded at 1224 (offset 2 lines). Hunk #7 succeeded at 1265 (offset 2 lines). Hunk #8 succeeded at 1366 (offset 2 lines). Hunk #9 succeeded at 1375 (offset 2 lines). Hunk #10 succeeded at 1520 (offset 2 lines). Hunk #11 succeeded at 1547 (offset 2 lines). Hunk #12 succeeded at 1726 (offset 2 lines). Hunk #13 succeeded at 1849 (offset 2 lines). Hunk #14 succeeded at 1886 (offset 2 lines). Hunk #15 succeeded at 2003 (offset 2 lines). Hunk #16 succeeded at 2129 (offset 2 lines). Hunk #17 succeeded at 2164 (offset 2 lines). Hunk #18 succeeded at 2368 (offset 2 lines). 1 out of 18 hunks FAILED -- saving rejects to file php_sybase_ct.c.rej I tried to correct the affected places manually but that lead to segfaults all over the place. I'll keep trying:) 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/41190 -- Edit this bug report at http://bugs.php.net/?id=41190&edit=1
#47942 [Opn->Bgs]: dynamic library suhosin.so could not be loaded
ID: 47942 Updated by: ka...@php.net Reported By: rajesh dot mohan at asia dot bnpparibas dot com -Status: Open +Status: Bogus Bug Type: Dynamic loading Operating System: AIX 5.3 PHP Version: 5.2CVS-2009-04-10 (snap) New Comment: Your php.ini tries to load an extension that does not exist on your system, check that you have set the extension_dir & extension directives correctly. For more help on that paticular extension, contact the extension authors of suhosin. Previous Comments: [2009-04-10 03:48:45] rajesh dot mohan at asia dot bnpparibas dot com Description: After installation of PHP 5.2.6 on AIX 5.3, i tried to test it in the command line through php -v and php -r "phpinfo()" and both fails with the reason suhosin.so could not be loaded as below: $UAT>/opt/pware/bin>php -r "phpinfo()" PHP Warning: PHP Startup: Unable to load dynamic library './suhosin.so' - Could not load module .. System error: No such file or directory in Unknown on line 0 PHP Parse error: syntax error, unexpected $end in Command line code on line 1 $UAT>/opt/pware/bin>php -v PHP Warning: PHP Startup: Unable to load dynamic library './suhosin.so' - Could not load module .. System error: No such file or directory in Unknown on line 0 PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Dec 26 2008 09:14:36) Copyright (c) 1997-2008 The PHP Group -- Edit this bug report at http://bugs.php.net/?id=47942&edit=1
#41190 [Com]: Two proposed patches for sybase_ct module
ID: 41190 Comment by: karim dot garchi at bnpparibas dot com Reported By: nick at marden dot org Status: No Feedback Bug Type: Feature/Change Request Operating System: (any) PHP Version: 5.3 Assigned To: thekid New Comment: this issue is very important for our developpment, if we don't have solution we are going to migrate to jsp Previous Comments: [2009-04-10 07:56:52] remi dot astier at bnpparibas dot com That fix would make my life easier ! How soon can it be implemented ? [2009-04-09 17:06:49] e dot vinot at cegetel dot net Hello Is there any chance to get these 2 Fixes included in close releases of PHP 5 ? In my case I'm very interested by the function sybase_return_status() The sybase_output_params() will very useful as well Thanks Emmanuel [2008-11-18 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-11-10 12:05:48] the...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Sorry, finally been able to take care of ext/sybase_ct again. New box, can't find the patch anymore. Unfortunately, the URLs yield a "File not found" page and even Google doesn't hold a cached version. [2007-07-24 21:06:43] nick at marden dot org I've spiffed up the patch to make it patch 100% cleanly with PHP 5.2.3. The patch is still at: http://www.marden.org/php-sybase-ct/php5-sybase_ct.return_status-and- output_params.patch 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/41190 -- Edit this bug report at http://bugs.php.net/?id=41190&edit=1
#47944 [NEW]: summary
From: bies22 at poczta dot onet dot pl Operating system: windows PHP version: 5.2.9 PHP Bug Type: MSSQL related Bug description: summary Description: When I execute SQL with function mssql_query, after 3 execute is error. The same SQL command executed with function odbc_do is correct. Reproduce code: --- $sql = "INSERT INTO cdn.EL_SS_ZSElemTmp VALUES (7,48,'PCW Okno Zendow Kolor x1',1.000,535.93,535.93,'A','ZLC/9/02700-TEST','ZLC/9/02700-TEST','3392/2009','14')"; $rst_mssql = mssql_query($sql,$conn); Actual result: -- Warning: mssql_query() [function.mssql-query]: message: Incorrect syntax near '&'. (severity 15) Warning: mssql_query() [function.mssql-query]: message: Unclosed quotation mark after the character string ')'. (severity 15) Warning: mssql_query() [function.mssql-query]: Query failed -- Edit bug report at http://bugs.php.net/?id=47944&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47944&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47944&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47944&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47944&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47944&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47944&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47944&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47944&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47944&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47944&r=support Expected behavior: http://bugs.php.net/fix.php?id=47944&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47944&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47944&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47944&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47944&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47944&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47944&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47944&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47944&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47944&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47944&r=mysqlcfg
#47941 [Opn->Bgs]: PHP has encountered an Access Violation at 00838493
ID: 47941 Updated by: paj...@php.net Reported By: keithdavis at pridedallas dot com -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Windows Vista (and XP) PHP Version: 5.2.9 New Comment: Please report it to the xdebug project. There is also an upcoming release there which may fix that. Previous Comments: [2009-04-09 23:57:37] keithdavis at pridedallas dot com After further testing, it appears to be xDebug that cause this. Even when not debugging, but if it is even loaded via php.ini. As far as sample code, that's hard to do. It doesn't happen on simple code, but only on my very complex applications. [2009-04-09 22:59: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. [2009-04-09 22:53:54] keithdavis at pridedallas dot com Description: I was running an XP (SP3) machine and started having this problem. I installed Vista instead (SP2 RC), but the error occurred almost immediately. It only appears to be while our site is running on this machine, but it is always reproducable, and occurs for the localhost, or remote hosts. I get this error first, repeatedly: PHP has encountered an Access Violation at 00838493 (on XP, I think it was a different number, but always the same number repeatedly.) Then I get a 500 Internal Error. -- Edit this bug report at http://bugs.php.net/?id=47941&edit=1
#47945 [NEW]: ini_set("open_basedir") does not work on multiple reload (mod_php)
From: elapouya at gmail dot com
Operating system: Ubuntu 8.10
PHP version: 5.3.0RC1
PHP Bug Type: Safe Mode/open_basedir
Bug description: ini_set("open_basedir") does not work on multiple reload
(mod_php)
Description:
If you put an
ini_set("open_basedir","/var/www/mydir");
in your code,
the first time it will work, put if you reload the page quickly, you will
get a "open_basedir restriction in effect" on a jammed directory !
If I wait 1 minute, it works again for the first time and no more the next
times : looks like a cache problem.
I do not have APC, xdebug etc...
Nothing in php.ini except the error_reporting turned to On.
the configure :
'./configure' '--with-apxs2=/usr/bin/apxs2' '--disable-short-tags'
'--with-openssl' '--with-zlib' '--enable-bcmath' '--with-bz2=/bin/bzip2'
'--enable-calendar' '--with-curl' '--with-curlwrappers' '--enable-exif'
'--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/lib'
'--with-png-dir=/usr/lib' '--with-xpm-dir=/usr/lib' '--with-ttf'
'--with-t1lib' '--enable-gd-native-ttf' '--enable-gd-jis-conv'
'--with-gettext' '--with-imap' '--with-imap-ssl' '--with-ldap'
'--with-ldap-sasl' '--enable-mbstring' '--with-mcrypt' '--with-mhash'
'--with-ming' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd'
'--with-ncurses' '--with-pdo-mysql' '--with-pspell' '--with-readline'
'--with-snmp' '--enable-soap' '--enable-sockets' '--without-sqlite'
'--enable-sqlite-utf8' '--with-tidy' '--enable-wddx' '--with-xmlrpc'
'--with-xsl' '--enable-zip' '--with-pear' '--with-kerberos'
Note : I use PHP as a Apache module
Reproduce code:
---
In /var/www/elapouya, I create the file open_basedir.php :
Expected result:
no error
Actual result:
--
First time : No error,
Next times :
Warning: Unknown: open_basedir restriction in effect.
File(/var/www/elapouya/open_basedir.php) is not within the allowed path(s):
(ä£Â¸/www/elapouya) in Unknown on line 0
Warning: Unknown: failed to open stream: Operation not permitted in
Unknown on line 0
Fatal error: Unknown: Failed opening required
'/var/www/elapouya/open_basedir.php' (include_path='.:/usr/local/lib/php')
in Unknown on line 0
--
Edit bug report at http://bugs.php.net/?id=47945&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47945&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47945&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47945&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47945&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47945&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47945&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47945&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47945&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47945&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47945&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47945&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47945&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47945&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47945&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47945&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47945&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47945&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47945&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47945&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47945&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47945&r=mysqlcfg
#46289 [Com]: PDO execute causes apache.exe to crash
ID: 46289
Comment by: djingo at free dot fr
Reported By: asylow at free dot fr
Status: Open
Bug Type: PDO related
Operating System: Windows XP SP3
PHP Version: 5.2.6
New Comment:
I think I have the same problem with the same DLL
"szAppName : httpd.exe
szAppVer : 2.2.11.0
szModName : php5ts.dll
szModVer : 5.2.9.9 offset : ac7a
On a Windows XP machine yesterday I insatlled :
MySQL (mysqld Ver 5.1.33-community for Win32 on ia32)
PHP - last version (php-5.2.9-2-win32-installer.msi)
Apache - last version (apache_2.2.11-win32-x86-no_ssl.msi)
and the WebCollab (http://webcollab.sourceforge.net)
All was perfectly installed, but when I try to configure the WebCollab
site I had this error.
There is no error message in the Apache and MySQL logs.
So if you have some idea ...
Previous Comments:
[2009-02-20 03:23:12] michael dot cordover+php at gmail dot com
I also get this issue on WinXP SP2 (5.1 build 2600) running Apache
2.2.11.0 (from xampplite 1.7.0).
Interestingly this occurs with executing a PDO::prepare()d SELECT
statement but not on UPDATE or INSERT. This happens even when
PDOStatement::bindValue / bindParam is not used.
I cannot reproduce the "subtle change makes it work" described by
asylow.
I am unable to provide a backtrace.
--Code--
$dbConn = new PDO(DBDSN, DBUSER, DBPASS);
// Connection is definitely valid
$q = $dbConn->prepare('SELECT * FROM people');
$q->execute();
--Crash report--
AppName: apache.exe
AppVer: 2.2.11.0
ModName: php_pdo_mysql.dll
ModVer: 5.2.9.9
Offset: 249a
--PHP Version-- [per phpinfo()]
Was occurring on 5.2.8 and also on snapshot:
PHP Version 5.2.9RC3-dev
System Windows NT 18315XP 5.1 build 2600
Build Date Feb 18 2009 23:39:16
Configure Command cscript /nologo configure.js
"--enable-snapshot-build" "--enable-debug-pack"
"--with-snapshot-template=d:\php-sdk\bin\\..\snap_5_2\vc6\x86\template"
"--with-php-build=d:\php-sdk\bin\\..\snap_5_2\vc6\x86\php_build"
"--with-pdo-oci=D:\php-sdk\oracle\instantclient10\sdk,shared"
"--with-oci8=D:\php-sdk\oracle\instantclient10\sdk,shared"
--PDO Version-- [per phpinfo()]
pdo_mysql PDO Driver for MySQL, client library version 5.1.30
--MySQL Version--
C:\xampplite\mysql\bin>mysqld.exe --version
mysqld.exe Ver 5.1.30-community for Win32 on ia32 (MySQL Community
Server (GPL))
[2008-10-14 13:13:30] asylow at free dot fr
The same happens with PHP Version 5.2.7RC2-dev - Oct 14 2008 01:38:31
The Call Stack debug is :
PHP5TS! 0096c9a3()
PHP5TS! 0096d28b()
free_statement(_pdo_stmt_t * 0x062d21d0, void * * * 0x01ec7d58) line
2396 + 19 bytes
php_pdo_stmt_delref(_pdo_stmt_t * 0x062d21d0, void * * * 0x01ec7d58)
line 2426 + 13 bytes
pdo_dbstmt_free_storage(_pdo_stmt_t * 0x062d21d0, void * * *
0x01ec7d58) line 2432 + 13 bytes
PHP5TS! 009f3253()
PHP5TS! 009f3061()
PHP5TS! 009ff42d()
PHP5TS! 009d75df()
PHP5TS! 009d6d59()
PHP5TS! 009dc53c()
PHP5TS! 00982176()
PHP5TS! 00981a4f()
PHP5TS! 009819a0()
PHP5TS! 00963651()
PHP5TS! 00a06b2d()
PHP5APACHE2! 003e34fd()
LIBHTTPD! 6ff0268e()
LIBHTTPD! 6ff02b6e()
LIBHTTPD! 6ff138a0()
LIBHTTPD! 6ff0e317()
LIBHTTPD! 6ff060fe()
LIBHTTPD! 6ff064ec()
LIBHTTPD! 6ff27e4c()
MSVCR71! 7c349565()
KERNEL32! 7c80b713()
[2008-10-14 12:23:03] fel...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-10-14 09:39:38] asylow at free dot fr
Description:
Hi,
I get an apache crash when executing the "execute" on a prepared
query.
"L'instruction à "0x0096ac76" emploie l'adresse mémoire "0X07a0a410".
La mémoire ne peut pas être "read"
PHP 5.2.6
Apache 2.2.9
The problem also happened using Aug 06, 2008 04:30 UTC Snapshot.
Reproduce code:
---
The minimal code that causes the crash is :
db = new PDO
("mssql:host=localhost\SQLEXPRESS;dbname=test","sa","toto");
}
function foo() {
$sql = 'SELECT oidObject FROM otIncidentspec WHERE
oidObject=:ndossier AND oidArticle=277247835';
$sth_activiteincident = $this->db->prepare($sql);
$extract[] = array("abc"=>29);
$extract[] = array("def"=>20);
$sth_activiteincident->execute(array(':ndossier'=>277248289));
$sth_activiteincident->execute(array(':ndossier'=>277248290));
}
}
$erp = new myclass();
$erp->foo();
?>
Actual result:
--
Strangely minimal changes to the code avoids the problem.
ie : removing the $extract[] definitions OR removing "AND
oidArticle=277247835" in the query OR defining $this->db in the foo
function instead of in the __construct.
I ma
#47564 [Com]: unpacking unsigned long 32bit bit endian returns wrong result
ID: 47564
Comment by: vivekanandan8 at yahoo dot com
Reported By: laacz at laacz dot lv
Status: Open
Bug Type: Strings related
Operating System: 6.1-STABLE FreeBSD (amd64)
PHP Version: 5.2.9
New Comment:
Hi,
Generally the Zend engine holds any variable as zval which holds
the integer as long data type only.
32 bit Platform: long => 4 byte = 32 bit
64 bit Platform: long => 8 byte = 64 bit
64 bit Platform: unsigned int => 4 byte = 32 bit
Hence in the 64 bit platform, we have to convert from long to unsigned
int only in 64 bit Platform.
Hence in php source php5.3-200903301230/ext/standard/pack.c
In PHP_FUNCTION(unpack) place, add this convertion immediate
after php_unpack function as folows.
v |= php_unpack(&input[inputpos], 4, issigned, map);
if (sizeof(long) > 4) { v = (unsigned int) v; }
I tested in both 32 & 64 bit platform ,it works fine , please close
this Bug
Regards,
vivekanandan
Previous Comments:
[2009-03-04 16:43:21] laacz at laacz dot lv
Description:
Unpacking unsigned long (32bit; always big endian; "N") on 64bit
system returns 64bit signed int instead of 32bit.
You can do & 0x on unpacked value, and get desired result,
but that's still a bug.
Reproduce code:
---
Expected result:
2147483657
0x8009
Actual result:
--
1.8446744071562E+19
0x8009
--
Edit this bug report at http://bugs.php.net/?id=47564&edit=1
#47564 [Com]: unpacking unsigned long 32bit bit endian returns wrong result
ID: 47564
Comment by: vivekanandan8 at yahoo dot com
Reported By: laacz at laacz dot lv
Status: Open
Bug Type: Strings related
Operating System: 6.1-STABLE FreeBSD (amd64)
PHP Version: 5.2.9
New Comment:
Hi,
Regarding the bug fix, This is tested in Version PHP 5.3 and works
fine,for any one needs full source code :
http://www.gnudeveloper.com/software/php/pack.c
Regards,
vivekanandan.
Previous Comments:
[2009-04-10 10:46:57] vivekanandan8 at yahoo dot com
Hi,
Generally the Zend engine holds any variable as zval which holds
the integer as long data type only.
32 bit Platform: long => 4 byte = 32 bit
64 bit Platform: long => 8 byte = 64 bit
64 bit Platform: unsigned int => 4 byte = 32 bit
Hence in the 64 bit platform, we have to convert from long to unsigned
int only in 64 bit Platform.
Hence in php source php5.3-200903301230/ext/standard/pack.c
In PHP_FUNCTION(unpack) place, add this convertion immediate
after php_unpack function as folows.
v |= php_unpack(&input[inputpos], 4, issigned, map);
if (sizeof(long) > 4) { v = (unsigned int) v; }
I tested in both 32 & 64 bit platform ,it works fine , please close
this Bug
Regards,
vivekanandan
[2009-03-04 16:43:21] laacz at laacz dot lv
Description:
Unpacking unsigned long (32bit; always big endian; "N") on 64bit
system returns 64bit signed int instead of 32bit.
You can do & 0x on unpacked value, and get desired result,
but that's still a bug.
Reproduce code:
---
Expected result:
2147483657
0x8009
Actual result:
--
1.8446744071562E+19
0x8009
--
Edit this bug report at http://bugs.php.net/?id=47564&edit=1
#47945 [Opn->Fbk]: ini_set("open_basedir") does not work on multiple reload (mod_php)
ID: 47945
Updated by: j...@php.net
Reported By: elapouya at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Safe Mode/open_basedir
Operating System: Ubuntu 8.10
PHP Version: 5.3.0RC1
New Comment:
Does this happen with PHP 5.2.9 ?
Previous Comments:
[2009-04-10 09:02:09] elapouya at gmail dot com
Description:
If you put an
ini_set("open_basedir","/var/www/mydir");
in your code,
the first time it will work, put if you reload the page quickly, you
will get a "open_basedir restriction in effect" on a jammed directory !
If I wait 1 minute, it works again for the first time and no more the
next times : looks like a cache problem.
I do not have APC, xdebug etc...
Nothing in php.ini except the error_reporting turned to On.
the configure :
'./configure' '--with-apxs2=/usr/bin/apxs2' '--disable-short-tags'
'--with-openssl' '--with-zlib' '--enable-bcmath' '--with-bz2=/bin/bzip2'
'--enable-calendar' '--with-curl' '--with-curlwrappers' '--enable-exif'
'--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/lib'
'--with-png-dir=/usr/lib' '--with-xpm-dir=/usr/lib' '--with-ttf'
'--with-t1lib' '--enable-gd-native-ttf' '--enable-gd-jis-conv'
'--with-gettext' '--with-imap' '--with-imap-ssl' '--with-ldap'
'--with-ldap-sasl' '--enable-mbstring' '--with-mcrypt' '--with-mhash'
'--with-ming' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd'
'--with-ncurses' '--with-pdo-mysql' '--with-pspell' '--with-readline'
'--with-snmp' '--enable-soap' '--enable-sockets' '--without-sqlite'
'--enable-sqlite-utf8' '--with-tidy' '--enable-wddx' '--with-xmlrpc'
'--with-xsl' '--enable-zip' '--with-pear' '--with-kerberos'
Note : I use PHP as a Apache module
Reproduce code:
---
In /var/www/elapouya, I create the file open_basedir.php :
Expected result:
no error
Actual result:
--
First time : No error,
Next times :
Warning: Unknown: open_basedir restriction in effect.
File(/var/www/elapouya/open_basedir.php) is not within the allowed
path(s): (ä£Â¸/www/elapouya) in Unknown on line 0
Warning: Unknown: failed to open stream: Operation not permitted in
Unknown on line 0
Fatal error: Unknown: Failed opening required
'/var/www/elapouya/open_basedir.php'
(include_path='.:/usr/local/lib/php') in Unknown on line 0
--
Edit this bug report at http://bugs.php.net/?id=47945&edit=1
#47939 [Opn->Fbk]: imagestring() csrf
ID: 47939
Updated by: j...@php.net
-Summary: imagestring() csrf php version == (PHP 4, PHP 5)
Reported By: elmasterlow at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: *
PHP Version: 5.3CVS-2009-04-09 (CVS)
New Comment:
With which PHP version did you test this?
Previous Comments:
[2009-04-09 21:10:10] elmasterlow at gmail dot com
Description:
With this vulnerability we could do any function in php on image.
In this case the vulnerability can be used to do a CSRF attack.
We can insert the img in BB tags at random forum for example.
I think there is any possible way to make a js code...
Reproduce code:
---
'bar', 'foo2' => 'bar2');
$data = http_build_query($data);
$context_options = array ('http' => array(
'method' => 'POST',
'header'=> "Content-type:
application/x-www-form-urlencoded\r\n"."Content-Length:
".strlen($data)."\r\n",
'content' => $data
));
$context = stream_context_create($context_options);
$fp = fopen('http://example.com/admin.php', 'r', false, $context);
imagestring($im, 1, 5, 5, fpassthru($fp) . $img, $tc);
imagepng($im);
imagedestroy($im);
?>
Expected result:
Insert [img]http://attacker/image.php[/img] on target site to do any
function in image.
--
Edit this bug report at http://bugs.php.net/?id=47939&edit=1
#47939 [Fbk->Bgs]: imagestring() csrf
ID: 47939
Updated by: paj...@php.net
Reported By: elmasterlow at gmail dot com
-Status: Feedback
+Status: Bogus
Bug Type: GD related
Operating System: *
PHP Version: 5.3CVS-2009-04-09 (CVS)
New Comment:
Why is it a imagestring problem? You can build attacks using php or any
other languages.
imagestring will simply draw a text using the number of characters sent
by fpassthru, which will be executed before imagestring. That's the same
as doing:
header('Content-Type: image/png');
fpassthru($fp);
// create an image, draw something, sent it
// ...
imagepng($im);
Previous Comments:
[2009-04-10 12:28:18] j...@php.net
With which PHP version did you test this?
[2009-04-09 21:10:10] elmasterlow at gmail dot com
Description:
With this vulnerability we could do any function in php on image.
In this case the vulnerability can be used to do a CSRF attack.
We can insert the img in BB tags at random forum for example.
I think there is any possible way to make a js code...
Reproduce code:
---
'bar', 'foo2' => 'bar2');
$data = http_build_query($data);
$context_options = array ('http' => array(
'method' => 'POST',
'header'=> "Content-type:
application/x-www-form-urlencoded\r\n"."Content-Length:
".strlen($data)."\r\n",
'content' => $data
));
$context = stream_context_create($context_options);
$fp = fopen('http://example.com/admin.php', 'r', false, $context);
imagestring($im, 1, 5, 5, fpassthru($fp) . $img, $tc);
imagepng($im);
imagedestroy($im);
?>
Expected result:
Insert [img]http://attacker/image.php[/img] on target site to do any
function in image.
--
Edit this bug report at http://bugs.php.net/?id=47939&edit=1
#46508 [Com]: getColumnMeta returns 'LONG','VAR_STRING','BLOB' as php native_type
ID: 46508
Comment by: php at displague dot com
Reported By: marques at displague dot com
Status: Assigned
Bug Type:PDO related
PHP Version: 5.2.6
Assigned To: mysql
New Comment:
This should probably be the topic of another bug, but TINYINT doesn't
return a native_type (I'm guessing because TINY is used everywhere, but
not TINYINT - maybe another constant is needed).
mysql://u...@host/db> show columns from table like 'disable' \G;
*** 1. row ***
Field: disable
Type: tinyint(4)
Null: NO
Key:
Default: 0
Extra:
1 row in set (0.00 sec)
getColumnMeta (php 5.2.9) returns:
Array
(
[flags] => Array
(
[0] => not_null
)
[table] => promo_item
[name] => disable
[len] => 4
[precision] => 0
[pdo_type] => 2
)
native_type is missing.
Is there any chance this correction will make it into 5.2.x?
Previous Comments:
[2008-11-07 16:24:52] fel...@php.net
Hi Marques, good observation! I've updated the patch. ;)
Thanks.
[2008-11-07 16:02:59] marques at displague dot com
The values that are currently being reported may belong in the
getmetacolumn array member 'driver:decl_type' (per the getColumnMeta
documentation example).
[2008-11-07 15:49:25] fel...@php.net
Patch: http://felipe.ath.cx/diff/bug46508.diff (5.3)
[2008-11-06 15:05:57] marques at displague dot com
I put my expected and actual results in the wrong boxes.
The capitalized native_types are not what I would expect because they
are not php native types per the PHP documentation on types and the
getColumnMeta example.
[2008-11-06 15:02:20] marques at displague dot com
Description:
Using the pdo_mysql driver, when I do a getColumnMeta on an int(11)
NULL field, the native_type returned is 'LONG'. I expect 'integer'.
Also, the pdo_type returned on this column is PDO::PARAM_STR, not
PDO::PARAM_INT as I would expect.
http://php.net/manual/en/pdostatement.getcolumnmeta.php defines
native_type as "The PHP native type used to represent the column
value.". The example on that page shows a return value of 'integer'..
This would seem to mesh with the PHP types defined here:
http://php.net/manual/en/function.gettype.php
If this is just a documentation bug due to recent changes, perhaps
someone should consider leaving native_type intact as php native type,
and using 'type' or something for these new values.
Reproduce code:
---
// MySQL: create table `table` (`i` int default null, `s` varchar(32),
`b` text, `t` timestamp, `d` datetime);
$pdo= new PDO("mysql:host=localhost;dbname=somedb","user","pass");
$stmt=$pdo->query("SELECT * from `table` limit 0");
for($i=0;$i<5;$i++) print_r($stmt->getColumnMeta($i));
Expected result:
Array
(
[native_type] => LONG
[flags] => Array
(
)
[table] => table
[name] => i
[len] => 11
[precision] => 0
[pdo_type] => 1
)
Array
(
[native_type] => VAR_STRING
[flags] => Array
(
)
[table] => table
[name] => s
[len] => 32
[precision] => 0
[pdo_type] => 2
)
Array
(
[native_type] => BLOB
[flags] => Array
(
[0] => blob
)
[table] => table
[name] => b
[len] => 65535
[precision] => 0
[pdo_type] => 2
)
Array
(
[native_type] => TIMESTAMP
[flags] => Array
(
[0] => not_null
)
[table] => table
[name] => t
[len] => 19
[precision] => 0
[pdo_type] => 2
)
Array
(
[native_type] => DATETIME
[flags] => Array
(
)
[table] => table
[name] => d
[len] => 19
[precision] => 0
[pdo_type] => 2
)
Actual result:
--
Array
(
[native_type] => integer
[flags] => Array
(
)
[table] => table
[name] => i
[len] => 11
[precision] => 0
[pdo_type] => 1
)
Array
(
[native_type] => string
[flags] => Array
(
)
[table] => table
[name] => s
[len] => 32
[precision] => 0
[pdo_type] => 2
)
Array
(
[native_type] => string
[flags] => Array
(
[0] => blob
)
[table] => table
[name] => b
[len] => 65535
[precision] => 0
[pdo_type] => 2
)
Array
(
[native_type] => string
[flags] => Array
(
[0] => not_null
)
[table] => table
[name] => t
[len] => 19
[precision] => 0
[pdo_type] => 2
)
Array
(
[native_type] => string
[flags] => Array
(
)
[table] => table
[name] =>
#41190 [NoF->Opn]: Two proposed patches for sybase_ct module
ID: 41190
User updated by: nick at marden dot org
Reported By: nick at marden dot org
-Status: No Feedback
+Status: Open
Bug Type: Feature/Change Request
Operating System: (any)
PHP Version: 5.3
Assigned To: thekid
New Comment:
Here is a patch against PHP 5.2.0. I have only run some very basic
tests against it, so please do testing of your own before using this in
production.
--- php-5.2.0-orig/ext/sybase_ct/php_sybase_ct.h2006-01-01
04:50:16.0 -0800
+++ php-5.2.0/ext/sybase_ct/php_sybase_ct.h 2007-04-24
12:55:36.0 -0700
@@ -56,6 +56,8 @@
PHP_FUNCTION(sybase_min_client_severity);
PHP_FUNCTION(sybase_min_server_severity);
PHP_FUNCTION(sybase_fetch_field);
+PHP_FUNCTION(sybase_return_status);
+PHP_FUNCTION(sybase_output_params);
PHP_FUNCTION(sybase_set_message_handler);
PHP_FUNCTION(sybase_deadlock_retry_count);
@@ -96,11 +98,15 @@
} sybase_field;
typedef struct {
- zval **data;
+ pval **data;
sybase_field *fields;
sybase_link *sybase_ptr;
int cur_row,cur_field;
int num_rows,num_fields;
+int return_status;
+int return_status_set;
+int num_output_params;
+pval *output_params;
/* For unbuffered reads */
CS_INT *lengths;
--- php-5.2.0-orig/ext/sybase_ct/php_sybase_ct.c2006-07-25
02:20:32.0 -0700
+++ php-5.2.0/ext/sybase_ct/php_sybase_ct.c 2007-04-24
12:55:36.0 -0700
@@ -61,6 +61,8 @@
PHP_FE(sybase_field_seek, NULL)
PHP_FE(sybase_result, NULL)
PHP_FE(sybase_affected_rows, NULL)
+ PHP_FE(sybase_return_status, NULL)
+ PHP_FE(sybase_output_params, NULL)
PHP_FE(sybase_min_client_severity, NULL)
PHP_FE(sybase_min_server_severity, NULL)
PHP_FE(sybase_set_message_handler, NULL)
@@ -86,6 +88,8 @@
PHP_FALIAS(mssql_field_seek, sybase_field_seek, NULL)
PHP_FALIAS(mssql_result, sybase_result, NULL)
PHP_FALIAS(mssql_affected_rows, sybase_affected_rows, NULL)
+ PHP_FALIAS(mssql_return_status, sybase_return_status, NULL)
+ PHP_FALIAS(mssql_output_params, sybase_output_params, NULL)
PHP_FALIAS(mssql_min_client_severity, sybase_min_client_severity,
NULL)
PHP_FALIAS(mssql_min_server_severity, sybase_min_server_severity,
NULL)
PHP_FALIAS(mssql_set_message_handler, sybase_set_message_handler,
NULL)
@@ -157,6 +161,10 @@
efree(result->fields);
}
+if( result->output_params ) {
+pval_destructor( result->output_params );
+}
+
efree(result);
}
@@ -1020,24 +1028,32 @@
/* }}} */
-static int php_sybase_finish_results(sybase_result *result TSRMLS_DC)
+void _cleanup_sybase_result_temp( sybase_result *result ) {
+int i;
+TSRMLS_FETCH();
+efree(result->datafmt);
+efree(result->lengths);
+efree(result->indicators);
+efree(result->numerics);
+efree(result->types);
+for (i=0; inum_fields; i++) {
+efree(result->tmp_buffer[i]);
+}
+efree(result->tmp_buffer);
+
+/* Indicate we have read all rows */
+result->sybase_ptr->active_result_index= 0;
+
+}
+
+static int php_sybase_finish_results (sybase_result *result TSRMLS_DC)
{
int i, fail;
CS_RETCODE retcode;
CS_INT restype;
-
- efree(result->datafmt);
- efree(result->lengths);
- efree(result->indicators);
- efree(result->numerics);
- efree(result->types);
- for (i=0; inum_fields; i++) {
- efree(result->tmp_buffer[i]);
- }
- efree(result->tmp_buffer);
- /* Indicate we have read all rows */
- result->sybase_ptr->active_result_index= 0;
+/* Clear up any temporary space used during query processing
*/
+_cleanup_sybase_result_temp( result );
/* The only restype we should get now is CS_CMD_DONE, possibly
* followed by a CS_STATUS_RESULT/CS_CMD_SUCCEED/CS_CMD_DONE
@@ -1126,7 +1142,7 @@
ZVAL_STRINGL(&result, buf, length- 1, 1); \
}
-static int php_sybase_fetch_result_row (sybase_result *result, int
numrows)
+static int php_sybase_fetch_result_row (sybase_result *result, int
numrows, int cleanup )
{
int i, j;
CS_INT retcode;
@@ -1206,7 +1222,9 @@
result->last_retcode= retcode;
switch (retcode) {
case CS_END_DATA:
- retcode = php_sybase_finish_results(result TSRMLS_CC);
+if( cleanup ) {
+ retcode = php_sybase_finish_results(result
TSRMLS_CC);
+}
break;
case CS_ROW_FAIL:
@@ -1245,6 +1263,10 @@
result->sybase_ptr = sybase_ptr;
result->cur_field=result->cur_row=result->num_rows=0;
result->num_fields = num_fields;
+result->n
#47945 [Fbk->Opn]: ini_set("open_basedir") does not work on multiple reload (mod_php)
ID: 47945
User updated by: elapouya at gmail dot com
Reported By: elapouya at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Safe Mode/open_basedir
Operating System: Ubuntu 8.10
PHP Version: 5.3.0RC1
New Comment:
It is a new feature for 5.3 : One can now set open_basedir at runtime
(not only in php.ini / php_value as a per dir basis).
So, to answer you, 5.2.9 in not relevant.
Previous Comments:
[2009-04-10 12:27:14] j...@php.net
Does this happen with PHP 5.2.9 ?
[2009-04-10 09:02:09] elapouya at gmail dot com
Description:
If you put an
ini_set("open_basedir","/var/www/mydir");
in your code,
the first time it will work, put if you reload the page quickly, you
will get a "open_basedir restriction in effect" on a jammed directory !
If I wait 1 minute, it works again for the first time and no more the
next times : looks like a cache problem.
I do not have APC, xdebug etc...
Nothing in php.ini except the error_reporting turned to On.
the configure :
'./configure' '--with-apxs2=/usr/bin/apxs2' '--disable-short-tags'
'--with-openssl' '--with-zlib' '--enable-bcmath' '--with-bz2=/bin/bzip2'
'--enable-calendar' '--with-curl' '--with-curlwrappers' '--enable-exif'
'--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/lib'
'--with-png-dir=/usr/lib' '--with-xpm-dir=/usr/lib' '--with-ttf'
'--with-t1lib' '--enable-gd-native-ttf' '--enable-gd-jis-conv'
'--with-gettext' '--with-imap' '--with-imap-ssl' '--with-ldap'
'--with-ldap-sasl' '--enable-mbstring' '--with-mcrypt' '--with-mhash'
'--with-ming' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd'
'--with-ncurses' '--with-pdo-mysql' '--with-pspell' '--with-readline'
'--with-snmp' '--enable-soap' '--enable-sockets' '--without-sqlite'
'--enable-sqlite-utf8' '--with-tidy' '--enable-wddx' '--with-xmlrpc'
'--with-xsl' '--enable-zip' '--with-pear' '--with-kerberos'
Note : I use PHP as a Apache module
Reproduce code:
---
In /var/www/elapouya, I create the file open_basedir.php :
Expected result:
no error
Actual result:
--
First time : No error,
Next times :
Warning: Unknown: open_basedir restriction in effect.
File(/var/www/elapouya/open_basedir.php) is not within the allowed
path(s): (ä£Â¸/www/elapouya) in Unknown on line 0
Warning: Unknown: failed to open stream: Operation not permitted in
Unknown on line 0
Fatal error: Unknown: Failed opening required
'/var/www/elapouya/open_basedir.php'
(include_path='.:/usr/local/lib/php') in Unknown on line 0
--
Edit this bug report at http://bugs.php.net/?id=47945&edit=1
#47907 [Opn->Bgs]: Segmentation fault during many preg_matches
ID: 47907 Updated by: nlop...@php.net Reported By: tafkad at web dot de -Status: Open +Status: Bogus Bug Type: PCRE related Operating System: Linux Debian Lenny PHP Version: 5.2.9 New Comment: It doesn't crash for me. It seems you need to increase the stack size (with ulimit -s). Previous Comments: [2009-04-06 13:02:29] tafkad at web dot de Description: I use a class(phpcc) to transform a searchstring into an SQL where clause. If it has many options like brackets or operators or if it is a very long string php ends in a segmentation fault. I've tested it with two php version 5.2.6 and 5.2.9. I use the cli version. I've created a test script with a for loop that generates a simple searchstatement with 2000 searchterms. If I run this script it crash. When I'll decrase the amount of searchterms to 1000 it will run clean. GDB shows preg_match as last execute, thats why I think there must be an error. The script uses a very huge amount of memory(I've configured php.ini with 1024M). php.ini changes from against default(debian) max_execution_time = 3 ; 30 ; Maximum execution time of each script, in seconds max_input_time = 6 ; 60 ; Maximum amount of time each script may spend parsing request data ;max_input_nesting_level = 64 ; Maximum input variable nesting level memory_limit = 1024M ; 32M ; Maximum amount of memory a script may consume (32MB) Active modules (php -m) [PHP Modules] bcmath,bz2,calendar,ctype,curl,date,dba,dbase,dom,exif,ffmpeg,filter,ftp,gd,gettext,hash,iconv,json,libxml,mbstring,mime_magic,mysql,mysqli,ncurses,openssl,pcntl,pcre,PDO,pdo_mysql,posix,readline,Reflection,session,shmop,SimpleXML,soap,sockets,SPL,standard,sysvmsg,sysvsem,sysvshm,tidy,tokenizer,wddx,xml,xmlreader,xmlwriter,zip,zlib Reproduce code: --- Code is to long. Under http://paste.root-zone.info/debug.tar.gz is a dir with the class and an testscript. Expected result: Before the script can finish, php crashes. Actual result: -- #23 0x004783db in match (eptr=0x0, ecode=0x107108e8 "'TESTSTR1160' or OR_ID = 'TESTSTR1161' or OR_ID = 'TESTSTR1162' or OR_ID = 'TESTSTR1163' or OR_ID = 'TESTSTR1164' or OR_ID = 'TESTSTR1165' or OR_ID = 'TESTSTR1166' or OR_ID"..., mstart=0x2 , offset_top=32767, md=0x0, ims=15, eptrb=0x47a157, flags=0, rdepth=0) at /usr/src/php5/source/php5-5.2.9/ext/pcre/pcrelib/pcre_exec.c:1184 #24 0x0047a157 in match (eptr=0x1 , ecode=0x107108e8 "'TESTSTR1160' or OR_ID = 'TESTSTR1161' or OR_ID = 'TESTSTR1162' or OR_ID = 'TESTSTR1163' or OR_ID = 'TESTSTR1164' or OR_ID = 'TESTSTR1165' or OR_ID = 'TESTSTR1166' or OR_ID"..., mstart=0x2 , offset_top=32767, md=0x0, ims=3, eptrb=0x4803f4, flags=0, rdepth=0) at /usr/src/php5/source/php5-5.2.9/ext/pcre/pcrelib/pcre_exec.c:714 #25 0x004803f4 in match (eptr=0x2ed1fe5 "", ecode=0x107108e8 "'TESTSTR1160' or OR_ID = 'TESTSTR1161' or OR_ID = 'TESTSTR1162' or OR_ID = 'TESTSTR1163' or OR_ID = 'TESTSTR1164' or OR_ID = 'TESTSTR1165' or OR_ID = 'TESTSTR1166' or OR_ID"..., mstart=0x27c2b71e0 , offset_top=32767, md=0x0, ims=45889320, eptrb=0x481f97, flags=0, rdepth=0) at /usr/src/php5/source/php5-5.2.9/ext/pcre/pcrelib/pcre_exec.c:2035 #26 0x00481f97 in php_pcre_exec (argument_re=0x10716821, extra_data=0x2ed2016, subject=0x20 , length=275843303, start_offset=0, options=275843304, offsets=0x488020, offsetcount=275614368) at /usr/src/php5/source/php5-5.2.9/ext/pcre/pcrelib/pcre_exec.c:4844 #27 0x00488020 in php_pcre_match_impl (pce=0x107108e8, subject=0x5f390048662f , subject_len=0, return_value=0x10718550, subpats=0xc106f7fd0, global=0, use_flags=4753947, flags=0, start_offset=0) at /usr/src/php5/source/php5-5.2.9/ext/pcre/php_pcre.c:621 #28 0x00488a1b in php_do_pcre_match (ht=3, return_value=0x106f7fd0, return_value_ptr=0x7fff7c2b31a0, this_ptr=0x7fff7c2b31b0, return_value_used=208324, global=0) at /usr/src/php5/source/php5-5.2.9/ext/pcre/php_pcre.c:513 #29 0x006c01ad in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff7c2b7b60) at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:200 #30 0x006ac6a4 in execute (op_array=0x2be9420) at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:92 #31 0x006bfabe in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff7c2b8410) at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:234 #32 0x006ac6a4 in execute (op_array=0x2bbd4e8) at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:92 #33 0x006bfabe in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff7c2b9110) at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:234 #34 0x006ac6a4 in execute (op_array=0x2be08b8) at /usr/src
#47689 [Opn->Asn]: crash with certain regular expression
ID: 47689
Updated by: nlop...@php.net
Reported By: vr...@php.net
-Status: Open
+Status: Assigned
Bug Type: PCRE related
-Operating System: Windows
+Operating System: Windows only
-PHP Version: 5.2.9
+PHP Version: *
-Assigned To:
+Assigned To: pajoye
New Comment:
this is the usual stack problem.
Since we now use the stack for PCRE recursion on Windows, I think we
could increase the stack size. The default (1 MB) is a little short..
Pierre: can you please increase the stack size on windows binaries to
e.g. 8 MB? It's a matter of adding one parameter to the compile
arguments.
More details at:
http://msdn.microsoft.com/en-us/library/tdkhxaks(VS.71).aspx
Previous Comments:
[2009-03-19 10:22:04] vr...@php.net
Both configuration directives are on the default value 10.
I've found out that with much longer input (600 lines) the script
crashes also in CLI.
There's no crash in PHP 5.2.8, only PHP 5.2.9 is affected.
[2009-03-18 23:16:14] fel...@php.net
Hi Jakub,
please check the pcre.backtrack_limit and pcre.recursion_limit value.
[2009-03-18 13:10:15] vr...@php.net
I've uploaded the backtrace analysis to
http://www.vrana.cz/phpbug47689.zip
[2009-03-17 13:57:03] vr...@php.net
Description:
Apache 2.2.11 crashes with PHP 5.2.9-1 on the following code. The same
script run from CLI executes without crash.
Reproduce code:
---
http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/';
// shortest possible example, omitting last line causes no crash
$contents = preg_replace('@/\\*(?:.|[\\n\\r])*?\\*/@', '', $contents);
?>
Expected result:
Empty string in $contents.
Actual result:
--
Apache crash.
--
Edit this bug report at http://bugs.php.net/?id=47689&edit=1
#47662 [Opn->Asn]: Crash with more that 127 named Subpattern
ID: 47662 Updated by: nlop...@php.net Reported By: gmblar+php at gmail dot com -Status: Open +Status: Assigned Bug Type: PCRE related Operating System: MacOSX 10.5 PHP Version: 5.2.9 -Assigned To: +Assigned To: nlopess New Comment: there's something wrong with the pcre library. I'll take a look. Previous Comments: [2009-04-06 23:19:27] gmblar+php at gmail dot com PCRE fails with more that 127 Subpattern if PHP compiled as 64-Bit- Binary [2009-04-06 23:17:11] gmblar+php at gmail dot com Problem only appears if PHP is compiled with 64-bit Support (x86_64) $ gdb ./php GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 UTC 2008) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries .. done (gdb) run ./test.php Starting program: /Users/Blar/Sites/php/php-5.2.9/sapi/cli/php ./test.php warning: posix_spawn failed, trying execvp, error: 86 Reading symbols for shared libraries +.. done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00010079ae10 0x00010002308f in make_subpats_table (num_subpats=257, pce=0x101008b60) at /Users/Blar/Sites/php/php- 5.2.9/ext/pcre/php_pcre.c:213 213 subpat_names[name_idx] = name_table + 2; (gdb) bt #0 0x00010002308f in make_subpats_table (num_subpats=257, pce=0x101008b60) at /Users/Blar/Sites/php/php- 5.2.9/ext/pcre/php_pcre.c:213 #1 0x0001000243b7 in php_pcre_match_impl (pce=0x101008b60, subject=0x10071a998 "foobar", subject_len=6, return_value=0x10071ad10, subpats=0x0, global=0, use_flags=0, flags=0, start_offset=0) at /Users/Blar/Sites/php/php- 5.2.9/ext/pcre/php_pcre.c:598 #2 0x000100024196 in php_do_pcre_match (ht=2, return_value=0x10071ad10, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, global=0) at /Users/Blar/Sites/php/php- 5.2.9/ext/pcre/php_pcre.c:513 #3 0x000100025017 in zif_preg_match (ht=2, return_value=0x10071ad10, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /Users/Blar/Sites/php/php- 5.2.9/ext/pcre/php_pcre.c:762 #4 0x0001002f0803 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff5fbfebd0) at zend_vm_execute.h:200 #5 0x0001002f72b3 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fff5fbfebd0) at zend_vm_execute.h:1729 #6 0x0001002f0223 in execute (op_array=0x1007198d0) at zend_vm_execute.h:92 #7 0x0001002c599b in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /Users/Blar/Sites/php/php-5.2.9/Zend/zend.c:1134 #8 0x000100263d28 in php_execute_script (primary_file=0x7fff5fbff5c0) at /Users/Blar/Sites/php/php- 5.2.9/main/main.c:2023 #9 0x000100351d7c in main (argc=2, argv=0x7fff5fbff728) at /Users/Blar/Sites/php/php-5.2.9/sapi/cli/php_cli.c:1133 [2009-04-06 21:00:31] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2009-03-26 15:02:00] mmcnicklebugs at googlemail dot com I can't replicate on Linux/Ubuntu 8.04 with 5.3CVS or 5.2.* When I increase the number of patterns to a large number (say 6) I get a suitable warning: Warning: preg_match(): Compilation failed: too many named subpatterns (maximum 1) at offset 148903 in /home/martin/php_bugs/pcre/47622/test.php on line 10 [2009-03-15 14:37:22] gmblar+php at gmail dot com Description: With more than 63 Subpattern in a Regular-Expression, PHP crashes with a Segmention-Fault. Reproduce code: --- ))'; } $regex .= '@'; preg_match($regex, 'foobar'); ?> Expected result: Nothing Actual result: -- $ php foobar.php Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=47662&edit=1
#47662 [Asn->Csd]: Crash with more that 127 named Subpattern
ID: 47662 Updated by: nlop...@php.net Reported By: gmblar+php at gmail dot com -Status: Assigned +Status: Closed Bug Type: PCRE related Operating System: MacOSX 10.5 PHP Version: 5.2.9 Assigned To: nlopess New Comment: 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. Previous Comments: [2009-04-10 15:31:14] nlop...@php.net there's something wrong with the pcre library. I'll take a look. [2009-04-06 23:19:27] gmblar+php at gmail dot com PCRE fails with more that 127 Subpattern if PHP compiled as 64-Bit- Binary [2009-04-06 23:17:11] gmblar+php at gmail dot com Problem only appears if PHP is compiled with 64-bit Support (x86_64) $ gdb ./php GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 UTC 2008) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries .. done (gdb) run ./test.php Starting program: /Users/Blar/Sites/php/php-5.2.9/sapi/cli/php ./test.php warning: posix_spawn failed, trying execvp, error: 86 Reading symbols for shared libraries +.. done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00010079ae10 0x00010002308f in make_subpats_table (num_subpats=257, pce=0x101008b60) at /Users/Blar/Sites/php/php- 5.2.9/ext/pcre/php_pcre.c:213 213 subpat_names[name_idx] = name_table + 2; (gdb) bt #0 0x00010002308f in make_subpats_table (num_subpats=257, pce=0x101008b60) at /Users/Blar/Sites/php/php- 5.2.9/ext/pcre/php_pcre.c:213 #1 0x0001000243b7 in php_pcre_match_impl (pce=0x101008b60, subject=0x10071a998 "foobar", subject_len=6, return_value=0x10071ad10, subpats=0x0, global=0, use_flags=0, flags=0, start_offset=0) at /Users/Blar/Sites/php/php- 5.2.9/ext/pcre/php_pcre.c:598 #2 0x000100024196 in php_do_pcre_match (ht=2, return_value=0x10071ad10, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, global=0) at /Users/Blar/Sites/php/php- 5.2.9/ext/pcre/php_pcre.c:513 #3 0x000100025017 in zif_preg_match (ht=2, return_value=0x10071ad10, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /Users/Blar/Sites/php/php- 5.2.9/ext/pcre/php_pcre.c:762 #4 0x0001002f0803 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff5fbfebd0) at zend_vm_execute.h:200 #5 0x0001002f72b3 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fff5fbfebd0) at zend_vm_execute.h:1729 #6 0x0001002f0223 in execute (op_array=0x1007198d0) at zend_vm_execute.h:92 #7 0x0001002c599b in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /Users/Blar/Sites/php/php-5.2.9/Zend/zend.c:1134 #8 0x000100263d28 in php_execute_script (primary_file=0x7fff5fbff5c0) at /Users/Blar/Sites/php/php- 5.2.9/main/main.c:2023 #9 0x000100351d7c in main (argc=2, argv=0x7fff5fbff728) at /Users/Blar/Sites/php/php-5.2.9/sapi/cli/php_cli.c:1133 [2009-04-06 21:00:31] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2009-03-26 15:02:00] mmcnicklebugs at googlemail dot com I can't replicate on Linux/Ubuntu 8.04 with 5.3CVS or 5.2.* When I increase the number of patterns to a large number (say 6) I get a suitable warning: Warning: preg_match(): Compilation failed: too many named subpatterns (maximum 1) at offset 148903 in /home/martin/php_bugs/pcre/47622/test.php on line 10 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47662 -- Edit this bug report at http://bug
#47526 [Opn->Bgs]: PCRE fails on Unicode surrogates
ID: 47526
Updated by: nlop...@php.net
Reported By: phpwnd at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: PCRE related
Operating System: *
PHP Version: 5.3CVS-2009-02-28 (CVS)
New Comment:
As far as I understand that codepoint is invalid in UTF-8.
If you call preg_last_error() after preg_match() it will return
PREG_BAD_UTF8_ERROR, confirming my hipothesis.
So no bug here.
Previous Comments:
[2009-02-28 08:51:18] phpwnd at gmail dot com
Description:
According to http://docs.php.net/manual/en/regexp.reference.php PCRE
functions should be able to match surrogates in Unicode mode. However,
it is my understanding that surrogates are not allowed in UTF-8, which
is the encoding used by the Unicode mode. That would explain why
preg_match() and preg_replace() fail when operating on UTF-8-encoded
surrogates.
Note that both functions fail in a different way. preg_match() returns
0 whereas preg_replace() returns NULL.
I'm not sure what the fix should be. Being able to match surrogates
would make my life easier, but if it's not valid UTF-8 then it might be
more consistent (albeit in a twisted way) to return NULL, as that's what
PCRE functions do on invalid UTF-8.
Reproduce code:
---
// \xED\xA0\x80 is character 0xD800 in UTF-8
var_dump(preg_match('#.#u', ".\xED\xA0\x80"));
var_dump(preg_replace('#\p{Cs}#u', '', ".\xED\xA0\x80"));
Expected result:
int(1)
string(1) "."
Actual result:
--
int(0)
NULL
--
Edit this bug report at http://bugs.php.net/?id=47526&edit=1
#47586 [Opn->Bgs]: preg_replace_callback crashes on static method call that are NOT defined static
ID: 47586
Updated by: nlop...@php.net
Reported By: didier dot peereboom at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: PCRE related
Operating System: linux
PHP Version: 5.2.9
New Comment:
works here with 5.3-cvs.
Previous Comments:
[2009-03-10 10:34:07] j...@php.net
Note: Your script does not crash for me with PHP 5.2.9.
[2009-03-06 12:17:39] didier dot peereboom at gmail dot com
Description:
preg_replace_callback can be passed a method, including static
methods.
However if said function is not declared with the keyword static then
it crashes hard. This is NOT the same as the behavior call_user_func
which continues happily no matter what the function has been declared
as.
Either call_user_func is wrong in working with incorrect code or
preg_replace_callback is wrong in not working. The hard crash itself can
hardly be intended behavior in either case.
Reproduce code:
---
ToBeCalledStatic('Regular');
testing::ToBeCalledStatic('Static call');
$var = "Method passed as array";
$var1 = "Method passed as static string";
$func = array('testing','ToBeCalledStatic');
$func1 = 'testing::ToBeCalledStatic';
call_user_func($func, $var);
preg_replace_callback('/.*/', $func , $var);
call_user_func($func1, $var1);
preg_replace_callback('/.*/', $func1 , $var1);
}
function ToBeCalledStatic($msg) {
echo "Been called with [{$msg}]\n";
}
}
$tmp1 = new testing();
$tmp1->Main();
?>
Expected result:
Either an error message in both cases that the function should be
declared static OR to work in both cases.
Not to work for call_user_func and fail for preg_replace_callback.
Perhaps with the update to the static notiation option
preg_replace_callback was overlooked?
Actual result:
--
Been called with [Regular]
Been called with [Static call]
Been called with [Method passed as array]
Been called with [Array]
Been called with [Array]
Warning: call_user_func(testing::ToBeCalledStatic): First argument is
expected to be a valid callback in /home/didier/test.php on line 12
Call Stack:
0.0002 115008 1. {main}() /home/didier/test.php:0
0.0002 115384 2. testing->Main() /home/didier/test.php:20
0.0004 118432 3. call_user_func() /home/didier/test.php:12
Dump $_SERVER
Dump $_GET
Dump $_POST
Dump $_COOKIE
Dump $_FILES
Dump $_ENV
Dump $_SESSION
Dump $_REQUEST
Warning: preg_replace_callback(): Requires argument 2,
'testing::ToBeCalledStatic', to be a valid callback in
/home/didier/test.php on line 13
Call Stack:
0.0002 115008 1. {main}() /home/didier/test.php:0
0.0002 115384 2. testing->Main() /home/didier/test.php:20
0.0005 119104 3. preg_replace_callback()
/home/didier/test.php:13
--
Edit this bug report at http://bugs.php.net/?id=47586&edit=1
#47526 [Bgs]: PCRE fails on Unicode surrogates
ID: 47526
User updated by: phpwnd at gmail dot com
Reported By: phpwnd at gmail dot com
Status: Bogus
Bug Type: PCRE related
Operating System: *
PHP Version: 5.3CVS-2009-02-28 (CVS)
New Comment:
My point exactly. Why do we have an escape sequence for surrogates when
they are invalid and it doesn't work anyway? \p{Cs} appears in the
manual (http://docs.php.net/manual/en/regexp.reference.php) under
"Supported property codes"
Also, why do preg_match() and preg_replace() fail differently?
preg_match returns 0, which lets the user believe the input was valid
but didn't match, whereas preg_replace() returns NULL, which indicates
the input was invalid. I cannot verify what preg_last_error() says right
now as I'm having trouble with latest CVS.
Previous Comments:
[2009-04-10 15:58:31] nlop...@php.net
As far as I understand that codepoint is invalid in UTF-8.
If you call preg_last_error() after preg_match() it will return
PREG_BAD_UTF8_ERROR, confirming my hipothesis.
So no bug here.
[2009-02-28 08:51:18] phpwnd at gmail dot com
Description:
According to http://docs.php.net/manual/en/regexp.reference.php PCRE
functions should be able to match surrogates in Unicode mode. However,
it is my understanding that surrogates are not allowed in UTF-8, which
is the encoding used by the Unicode mode. That would explain why
preg_match() and preg_replace() fail when operating on UTF-8-encoded
surrogates.
Note that both functions fail in a different way. preg_match() returns
0 whereas preg_replace() returns NULL.
I'm not sure what the fix should be. Being able to match surrogates
would make my life easier, but if it's not valid UTF-8 then it might be
more consistent (albeit in a twisted way) to return NULL, as that's what
PCRE functions do on invalid UTF-8.
Reproduce code:
---
// \xED\xA0\x80 is character 0xD800 in UTF-8
var_dump(preg_match('#.#u', ".\xED\xA0\x80"));
var_dump(preg_replace('#\p{Cs}#u', '', ".\xED\xA0\x80"));
Expected result:
int(1)
string(1) "."
Actual result:
--
int(0)
NULL
--
Edit this bug report at http://bugs.php.net/?id=47526&edit=1
#47946 [NEW]: ImageConvolution overwrites background (fix included)
From: jcolby at acsol dot net Operating system: openSuse, CentOS, FreeBSD PHP version: 5.2.9 PHP Bug Type: GD related Bug description: ImageConvolution overwrites background (fix included) Description: When using imageconvolution on an image containing alpha, the background color on the resource image will be replaced with opaque black regardless of any alpha or background settings. This is because of the gdimagecopy internal to the function without the proper savealpha flags being set & no transparent image fill after gdimagecreatetruecolor is used inside the function. This is similar to bug #34992 but I've had a chance to break it open and actually fix it. This affects all versions of php 5, up to the latest 5.2.9 stable build, and I wouldn't doubt it currently affects 6 as well. Now, I managed to fix it in my own build, but I don't know how to get it advanced from there. This is not my realm of experience, I just had to repair it. Patch: php-5.2.9\ext\gd\libgd\gd.c Add in var initialization: /* patch */ gdImagePtr srctrans; /* patch */ Add after "srcback = gdImageCreateTrueColor..." /* patch */ srcback->saveAlphaFlag = 1; srctrans = gdImageColorAllocateAlpha(srcback, 0, 0, 0, 127); gdImageFill(srcback, 0, 0, srctrans); /* end patch */ Thats all it requires. Reproduce code: --- Expected result: Convolutionmatrix should apply to all opaque or semi opaque pixels, and background should remain unchanged. Actual result: -- Convolutionmatrix applies to all opaque and semi opaque pixels, background reverts to solid opaque black regardless of any external settings. -- Edit bug report at http://bugs.php.net/?id=47946&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47946&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47946&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47946&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47946&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47946&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47946&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47946&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47946&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47946&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47946&r=support Expected behavior: http://bugs.php.net/fix.php?id=47946&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47946&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47946&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47946&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47946&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47946&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47946&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47946&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47946&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47946&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47946&r=mysqlcfg
#47689 [Asn->Fbk]: crash with certain regular expression
ID: 47689
Updated by: paj...@php.net
Reported By: vr...@php.net
-Status: Assigned
+Status: Feedback
Bug Type: PCRE related
Operating System: Windows only
PHP Version: *
Assigned To: pajoye
New Comment:
Please try using 5.3.0 VC9 snapshots(ts or NTS): http://windows.php.net
Previous Comments:
[2009-04-10 15:15:15] nlop...@php.net
this is the usual stack problem.
Since we now use the stack for PCRE recursion on Windows, I think we
could increase the stack size. The default (1 MB) is a little short..
Pierre: can you please increase the stack size on windows binaries to
e.g. 8 MB? It's a matter of adding one parameter to the compile
arguments.
More details at:
http://msdn.microsoft.com/en-us/library/tdkhxaks(VS.71).aspx
[2009-03-19 10:22:04] vr...@php.net
Both configuration directives are on the default value 10.
I've found out that with much longer input (600 lines) the script
crashes also in CLI.
There's no crash in PHP 5.2.8, only PHP 5.2.9 is affected.
[2009-03-18 23:16:14] fel...@php.net
Hi Jakub,
please check the pcre.backtrack_limit and pcre.recursion_limit value.
[2009-03-18 13:10:15] vr...@php.net
I've uploaded the backtrace analysis to
http://www.vrana.cz/phpbug47689.zip
[2009-03-17 13:57:03] vr...@php.net
Description:
Apache 2.2.11 crashes with PHP 5.2.9-1 on the following code. The same
script run from CLI executes without crash.
Reproduce code:
---
http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/';
// shortest possible example, omitting last line causes no crash
$contents = preg_replace('@/\\*(?:.|[\\n\\r])*?\\*/@', '', $contents);
?>
Expected result:
Empty string in $contents.
Actual result:
--
Apache crash.
--
Edit this bug report at http://bugs.php.net/?id=47689&edit=1
#47945 [Opn->Bgs]: tightened "open_basedir" setting persists between requests
ID: 47945
Updated by: j...@php.net
Reported By: elapouya at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Safe Mode/open_basedir
Operating System: Ubuntu 8.10
PHP Version: 5.3.0RC1
New Comment:
See also bug #46934 of which this is duplicate -> bogus.
Previous Comments:
[2009-04-10 15:02:06] elapouya at gmail dot com
It is a new feature for 5.3 : One can now set open_basedir at runtime
(not only in php.ini / php_value as a per dir basis).
So, to answer you, 5.2.9 in not relevant.
[2009-04-10 12:27:14] j...@php.net
Does this happen with PHP 5.2.9 ?
[2009-04-10 09:02:09] elapouya at gmail dot com
Description:
If you put an
ini_set("open_basedir","/var/www/mydir");
in your code,
the first time it will work, put if you reload the page quickly, you
will get a "open_basedir restriction in effect" on a jammed directory !
If I wait 1 minute, it works again for the first time and no more the
next times : looks like a cache problem.
I do not have APC, xdebug etc...
Nothing in php.ini except the error_reporting turned to On.
the configure :
'./configure' '--with-apxs2=/usr/bin/apxs2' '--disable-short-tags'
'--with-openssl' '--with-zlib' '--enable-bcmath' '--with-bz2=/bin/bzip2'
'--enable-calendar' '--with-curl' '--with-curlwrappers' '--enable-exif'
'--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/lib'
'--with-png-dir=/usr/lib' '--with-xpm-dir=/usr/lib' '--with-ttf'
'--with-t1lib' '--enable-gd-native-ttf' '--enable-gd-jis-conv'
'--with-gettext' '--with-imap' '--with-imap-ssl' '--with-ldap'
'--with-ldap-sasl' '--enable-mbstring' '--with-mcrypt' '--with-mhash'
'--with-ming' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd'
'--with-ncurses' '--with-pdo-mysql' '--with-pspell' '--with-readline'
'--with-snmp' '--enable-soap' '--enable-sockets' '--without-sqlite'
'--enable-sqlite-utf8' '--with-tidy' '--enable-wddx' '--with-xmlrpc'
'--with-xsl' '--enable-zip' '--with-pear' '--with-kerberos'
Note : I use PHP as a Apache module
Reproduce code:
---
In /var/www/elapouya, I create the file open_basedir.php :
Expected result:
no error
Actual result:
--
First time : No error,
Next times :
Warning: Unknown: open_basedir restriction in effect.
File(/var/www/elapouya/open_basedir.php) is not within the allowed
path(s): (ä£Â¸/www/elapouya) in Unknown on line 0
Warning: Unknown: failed to open stream: Operation not permitted in
Unknown on line 0
Fatal error: Unknown: Failed opening required
'/var/www/elapouya/open_basedir.php'
(include_path='.:/usr/local/lib/php') in Unknown on line 0
--
Edit this bug report at http://bugs.php.net/?id=47945&edit=1
#46934 [Opn]: Unable to untighten open_basedir restriction
ID: 46934 Updated by: j...@php.net Reported By: kristof dot coomans at telenet dot be Status: Open Bug Type: Feature/Change Request Operating System: Windows XP PHP Version: 5.3CVS-2008-12-23 (snap) New Comment: See also bug #47945 Previous Comments: [2008-12-27 23:46:10] bj...@php.net I don't think the plan was to allow un-tightening it again.. [2008-12-23 08:55:33] kristof dot coomans at telenet dot be Description: I'm testing the new feature introduced lately, namely "tightening" the open_basedir setting. This might be a very good security measure, to prevent relative directory traversal exploits. However, sometimes it is useful to tighten the path only for certain code, and untighten it again afterward to its original value. This doesn't seem to work currently. Reproduce code: --- Expected result: The last call should be allowed, and a file test.txt should have been created in the same directory as the script. Actual result: -- Warning: file_put_contents(): open_basedir restriction in effect. File(C:\sites\ trunk\test.txt) is not within the allowed path(s): (░δç☺♀) in ... Warning: file_put_contents(C:\sites\trunk\test.txt): failed to open stream: Operation not permitted in ... -- Edit this bug report at http://bugs.php.net/?id=46934&edit=1
#46934 [Opn->Asn]: Unable to untighten open_basedir restriction
ID: 46934 Updated by: j...@php.net Reported By: kristof dot coomans at telenet dot be -Status: Open +Status: Assigned Bug Type: Feature/Change Request Operating System: * PHP Version: 5.3CVS-2008-12-23 (snap) -Assigned To: +Assigned To: pollita New Comment: Sara, can you either confirm or fix it what Hannes said above? Previous Comments: [2009-04-10 17:46:35] j...@php.net See also bug #47945 [2008-12-27 23:46:10] bj...@php.net I don't think the plan was to allow un-tightening it again.. [2008-12-23 08:55:33] kristof dot coomans at telenet dot be Description: I'm testing the new feature introduced lately, namely "tightening" the open_basedir setting. This might be a very good security measure, to prevent relative directory traversal exploits. However, sometimes it is useful to tighten the path only for certain code, and untighten it again afterward to its original value. This doesn't seem to work currently. Reproduce code: --- Expected result: The last call should be allowed, and a file test.txt should have been created in the same directory as the script. Actual result: -- Warning: file_put_contents(): open_basedir restriction in effect. File(C:\sites\ trunk\test.txt) is not within the allowed path(s): (░δç☺♀) in ... Warning: file_put_contents(C:\sites\trunk\test.txt): failed to open stream: Operation not permitted in ... -- Edit this bug report at http://bugs.php.net/?id=46934&edit=1
#47946 [Opn]: ImageConvolution overwrites background (fix included)
ID: 47946
User updated by: jcolby at acsol dot net
Reported By: jcolby at acsol dot net
Status: Open
Bug Type: GD related
Operating System: openSuse, CentOS, FreeBSD
PHP Version: 5.2.9
New Comment:
Missing function from test case:
function array_flatten($array) {
(array)$tempArray = array();
foreach ( $array as $value ) {
if ( is_array($value) ) {
$tempArray = array_merge($tempArray, array_flatten($value));
} else {
$tempArray[] = $value;
}
}
return $tempArray;
}
Previous Comments:
[2009-04-10 16:26:01] jcolby at acsol dot net
Description:
When using imageconvolution on an image containing alpha, the
background color on the resource image will be replaced with opaque
black regardless of any alpha or background settings. This is because of
the gdimagecopy internal to the function without the proper savealpha
flags being set & no transparent image fill after gdimagecreatetruecolor
is used inside the function.
This is similar to bug #34992 but I've had a chance to break it open
and actually fix it.
This affects all versions of php 5, up to the latest 5.2.9 stable
build, and I wouldn't doubt it currently affects 6 as well.
Now, I managed to fix it in my own build, but I don't know how to get
it advanced from there. This is not my realm of experience, I just had
to repair it.
Patch: php-5.2.9\ext\gd\libgd\gd.c
Add in var initialization:
/* patch */
gdImagePtr srctrans;
/* patch */
Add after "srcback = gdImageCreateTrueColor..."
/* patch */
srcback->saveAlphaFlag = 1;
srctrans = gdImageColorAllocateAlpha(srcback, 0, 0, 0, 127);
gdImageFill(srcback, 0, 0, srctrans);
/* end patch */
Thats all it requires.
Reproduce code:
---
Expected result:
Convolutionmatrix should apply to all opaque or semi opaque pixels, and
background should remain unchanged.
Actual result:
--
Convolutionmatrix applies to all opaque and semi opaque pixels,
background reverts to solid opaque black regardless of any external
settings.
--
Edit this bug report at http://bugs.php.net/?id=47946&edit=1
#46812 [Opn->Fbk]: get_class_vars() does not include visible private variable looking at subclass
ID: 46812
Updated by: j...@php.net
Reported By: phpbug dot classvars at sub dot noloop dot net
-Status: Open
+Status: Feedback
Bug Type: Class/Object related
Operating System: Linux
PHP Version: 5.2.8
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2008-12-12 14:33:21] msara...@php.net
ZEND_FUNCTION(get_class_vars)
{
char *class_name;
int class_name_len;
zend_class_entry **pce;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &class_name,
&class_name_len) == FAILURE) {
return;
}
if (zend_lookup_class(class_name, class_name_len, &pce TSRMLS_CC) ==
FAILURE) {
RETURN_FALSE;
} else {
array_init(return_value);
zend_update_class_constants(*pce TSRMLS_CC);
if ((*pce)->parent) {
add_class_vars((*pce)->parent,
&(*pce)->parent->default_properties,
return_value TSRMLS_CC);
add_class_vars((*pce)->parent,
CE_STATIC_MEMBERS((*pce)->parent),
return_value TSRMLS_CC)
}
else {
add_class_vars(*pce, &(*pce)->default_properties, return_value
TSRMLS_CC);
add_class_vars(*pce, CE_STATIC_MEMBERS(*pce), return_value
TSRMLS_CC);
}
}
}
[2008-12-09 10:13:30] phpbug dot classvars at sub dot noloop dot net
Description:
Even after bug #45862, #46761 and #46795 there is something really
weird going on with get_class_vars(). It seems to be the consensus of
the developers that get_class_vars() should return all properties of the
given class that are _visible_ from the context calling get_class_vars()
(nevermind that the docs claim "returns ... public properties of the
class" (see #46795)). (Also, #31543 seems to contradict everything else)
But get_class_vars() does not return visible private properties when
invoked on a subclass.
In the attached code, the second call to dumpClass should return
'private_a', as $private_a would still be visible in methods in A, even
if the object in question actually is of type B.
As a side note, I find it a bit strange that the behaviour of
get_class_vars() function changed between 5.2.6 and 5.2.7 (it broke a
real-world inhouse app here, for example) :)
Reproduce code:
---
)
Array
(
[private_a] =>
)
Actual result:
--
Array
(
[private_a] =>
)
Array
(
)
--
Edit this bug report at http://bugs.php.net/?id=46812&edit=1
#47323 [Asn->Csd]: strotime warnings in make install
ID: 47323 Updated by: du...@php.net Reported By: frozenfire at thefrozenfire dot com -Status: Assigned +Status: Closed Bug Type: PHAR related Operating System: Ubuntu 8.10 2.6.27-11-generic PHP Version: 5.3.0RC1 Assigned To: dufuz New Comment: PEAR 1.8.0 stable has been released and phars should now be synced up and all fine. Previous Comments: [2009-03-26 13:59:13] cel...@php.net the bug will be fixed when PEAR 1.8.0 is released, which will be very soon, Helgi is hard at work. You are correct that this should not be closed until the phar archive is released, but Helgi is also correct in that this was fixed in the CVS of PEAR. Complicated stuff. [2009-03-26 08:25:19] phi...@php.net This bug still exists with 5.3.0RC1 so should remain open until that changes. [2009-02-16 00:48:39] du...@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. This will be fixed when the next release of the PEAR installer goes live [2009-02-06 03:46:33] frozenfire at thefrozenfire dot com Description: I've configured a vanilla install of PHP 5.3 Beta 1, using ./configure --prefix=/usr/local/php-5.3 --program-suffix=53 After configuring (And resolving some missing dependencies), I did a make, and then a make test (Results submitted). Next, I did a make install, which produced: Warning: strtotime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PST/-8.0/no DST' instead in phar:///home/myuser/php-5.3.0beta1/pear/install-pear-nozlib.phar/PEAR/Validate.php on line 489 About a dozen times during "Installing PEAR environment: /usr/local/php-5.3/lib/php/" I don't know if it's related, but the interactive mode in PHP doesn't work (php53 -a). It prints out "Interactive mode enabled" and then allows input, but doesn't process it in any way, including "exit." Reproduce code: --- sudo ./configure --prefix=/usr/local/php-5.3 --program-suffix=53 sudo make sudo make test sudo make install Expected result: For the make install, I expected none of the warning messages. Actual result: -- Full make install output: http://pastebin.ca/1328662 -- Edit this bug report at http://bugs.php.net/?id=47323&edit=1
#47948 [NEW]: call_user_func_array with autoload causes crash
From: ehassler at synapsestudios dot com Operating system: Vista, CentOS PHP version: 5.2.9 PHP Bug Type: Reproducible crash Bug description: call_user_func_array with autoload causes crash Description: In Vista with PHP 5.2.6 and 5.2.9 and in CentOS with PHP 5.2.6 we encountered an error where, a call_user_func_array without class_exists called before it causes the following error message: Fatal error: Possible integer overflow in memory allocation (4 * 3080682076 + 0) In the windows environment, it just crashes our local instances of Apache, but in Linux we get this error message. Prefacing the call_user_func_array with a class_exists causes the crash/error to not occur. If we do not preface it, or if we add the extra argument to not autoload, then the crash/error occurs again. We tried to reproduce the error by having two files, one with the class, the other with an autoload function and the call to call_user_func_array, and this did NOT cause a crash. In our environment where the error actually occurred, the autoloaded file would have causes several other classes to autoload, so perhaps this is more relevant to the bug than simple autoloading. Actual result: -- Fatal error: Possible integer overflow in memory allocation (4 * 3080682076 + 0) in /var/www/phxphp.com/svn/trunk/application/models/upload_type.php on line 49 -- Edit bug report at http://bugs.php.net/?id=47948&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47948&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47948&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47948&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47948&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47948&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47948&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47948&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47948&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47948&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47948&r=support Expected behavior: http://bugs.php.net/fix.php?id=47948&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47948&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47948&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47948&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47948&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47948&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47948&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47948&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47948&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47948&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47948&r=mysqlcfg
#47945 [Bgs]: tightened "open_basedir" setting persists between requests
ID: 47945
User updated by: elapouya at gmail dot com
Reported By: elapouya at gmail dot com
Status: Bogus
Bug Type: Safe Mode/open_basedir
Operating System: Ubuntu 8.10
PHP Version: 5.3.0RC1
New Comment:
Yes it looks like the same root cause.
But in my case, I was not thighten/untighten open_basedir.
I was just *setting* open_basedir at runtime (open_basedir is blank in
php.ini and httpd.conf)
I made another test by putting "open_basedir = /var/www" in php.ini and
use the same open_basedir.php as in my example to only "tighten"
open_basedir : the effect is the same : First time is OK, but if you
reload the page quickly,the same error occurs :
I think that the path stored internally for open_basedir is not the
good one (look at the weird chars into the path in the error message for
open_basedir)
Previous Comments:
[2009-04-10 17:46:11] j...@php.net
See also bug #46934 of which this is duplicate -> bogus.
[2009-04-10 15:02:06] elapouya at gmail dot com
It is a new feature for 5.3 : One can now set open_basedir at runtime
(not only in php.ini / php_value as a per dir basis).
So, to answer you, 5.2.9 in not relevant.
[2009-04-10 12:27:14] j...@php.net
Does this happen with PHP 5.2.9 ?
[2009-04-10 09:02:09] elapouya at gmail dot com
Description:
If you put an
ini_set("open_basedir","/var/www/mydir");
in your code,
the first time it will work, put if you reload the page quickly, you
will get a "open_basedir restriction in effect" on a jammed directory !
If I wait 1 minute, it works again for the first time and no more the
next times : looks like a cache problem.
I do not have APC, xdebug etc...
Nothing in php.ini except the error_reporting turned to On.
the configure :
'./configure' '--with-apxs2=/usr/bin/apxs2' '--disable-short-tags'
'--with-openssl' '--with-zlib' '--enable-bcmath' '--with-bz2=/bin/bzip2'
'--enable-calendar' '--with-curl' '--with-curlwrappers' '--enable-exif'
'--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/lib'
'--with-png-dir=/usr/lib' '--with-xpm-dir=/usr/lib' '--with-ttf'
'--with-t1lib' '--enable-gd-native-ttf' '--enable-gd-jis-conv'
'--with-gettext' '--with-imap' '--with-imap-ssl' '--with-ldap'
'--with-ldap-sasl' '--enable-mbstring' '--with-mcrypt' '--with-mhash'
'--with-ming' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd'
'--with-ncurses' '--with-pdo-mysql' '--with-pspell' '--with-readline'
'--with-snmp' '--enable-soap' '--enable-sockets' '--without-sqlite'
'--enable-sqlite-utf8' '--with-tidy' '--enable-wddx' '--with-xmlrpc'
'--with-xsl' '--enable-zip' '--with-pear' '--with-kerberos'
Note : I use PHP as a Apache module
Reproduce code:
---
In /var/www/elapouya, I create the file open_basedir.php :
Expected result:
no error
Actual result:
--
First time : No error,
Next times :
Warning: Unknown: open_basedir restriction in effect.
File(/var/www/elapouya/open_basedir.php) is not within the allowed
path(s): (ä£Â¸/www/elapouya) in Unknown on line 0
Warning: Unknown: failed to open stream: Operation not permitted in
Unknown on line 0
Fatal error: Unknown: Failed opening required
'/var/www/elapouya/open_basedir.php'
(include_path='.:/usr/local/lib/php') in Unknown on line 0
--
Edit this bug report at http://bugs.php.net/?id=47945&edit=1
