#48949 [Fbk->Opn]: max_execution_time from php.ini ignored
ID: 48949 User updated by: giunta dot gaetano at gmail dot com Reported By: giunta dot gaetano at gmail dot com -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: vista sp2 PHP Version: 5.3.0 New Comment: max_execution_time=300 in php.ini (using apache sapi btw) Previous Comments: [2009-07-16 22:24:20] paj...@php.net And what's the value set in php.ini? [2009-07-16 22:17:27] giunta dot gaetano at gmail dot com Description: On windows vista, with apache 2.2.11, php 5.3.0 vc9 threadsafe, the max_execution_time ini parameter is read correctly (as shown by ini_get() and phpinfo()) but never used. After 60 secs, the script times out with the message "Fatal error: Maximum execution time of 60 seconds exceeded". Adding a set_time_limit() or ini_set() call solves the problem. -- Edit this bug report at http://bugs.php.net/?id=48949&edit=1
#48942 [Opn->Asn]: open_basedir no working with [PATH=] in php.ini
ID: 48942 Updated by: paj...@php.net Reported By: marcos dot neves at gmail dot com -Status: Open +Status: Assigned Bug Type: CGI related Operating System: debian PHP Version: 5.3.0 -Assigned To: +Assigned To: pajoye New Comment: It should work in the main php.ini and in some extend in the .user.ini (using the new restricted open_basedir). I will take a look at it while fixing some other .user.ini issues. Previous Comments: [2009-07-17 04:17:20] marcos dot neves at gmail dot com playing more, I found that the same bug happens if I configure open_basedir on .user.ini file. It look likes that open_basedir can't be configured in a context way, only in a global way. If thats true, I would be very sad, cause that could be a great feature for hosting companies. [2009-07-16 18:51:23] marcos dot neves at gmail dot com the bug happens using both spawn-fcgi or php-fpm. The php is different for each other. For example, with spawn-fcgi, I am using dotdeb.org php5.3 version, installed using apt-get. With php-fpm, I am using php5.3 Build from source. For webserver, I am using nginx. I both ways, if I change to configuration to this one, every things back to normal: [PATH=/var/www/my.domain.com] open_basedir=/var/www [2009-07-16 13:35:47] j...@php.net And exactly how is everything else configured? Like the path to the script you're accessing? [2009-07-16 12:16:19] marcos dot neves at gmail dot com Description: I got "No input file specified." from fcgi when used open_basedir inside [PATH=] php.ini Reproduce code: --- create an entry on php.ini with open_basedir pointing to your domain root, example: open_basedir=/var/www/my.domain.com restart fcgi and check if it all works fine. (it should) Now add this like above open_basedir: [PATH=/var/www/my.domain.com] open_basedir=/var/www/my.domain.com restart fcgi and now you will get "No input file specified." Expected result: should work as before. Actual result: -- got "No input file specified." fcgi response. -- Edit this bug report at http://bugs.php.net/?id=48942&edit=1
#48894 [Opn]: Occasional crashes with Apache 1.3.41
ID: 48894
User updated by: php at anders dot fupp dot net
Reported By: php at anders dot fupp dot net
Status: Open
Bug Type: Apache related
Operating System: FreeBSD/amd64 7.2-RELEASE
PHP Version: 5.2.10
New Comment:
Yes, the Apache ticket specifically mentions that the bug is in the
caller, which is PHP. Are you or anyone going to look at this other than
keep pointing at Apache or suggesting alternatives? I submitted this
ticket to possibly have the problem fixed, that is the only reason I
bothered to do it. It's annoying to keep have to mentioning where the
problem (probably) is, I start to wonder whether it is useful to submit
tickets at bugs.php.net at all.
Previous Comments:
[2009-07-15 12:14:47] j...@php.net
Note: There is good analysis on that Apache bug what the problem is.
Workaround: Use lighttpd + PHP-fcgi :)
[2009-07-12 20:13:03] php at anders dot fupp dot net
Someone report this as an Apache bug, which was closed in their bug
tracking system:
https://issues.apache.org/bugzilla/show_bug.cgi?id=47070
[2009-07-12 20:08:10] php at anders dot fupp dot net
Description:
Apache 1.3.41 crashes now and then due to problems in PHP 5.2.10
mod_php module:
Jul 12 18:44:59 master kernel: pid 58886 (httpd), uid 80: exited on
signal 10 (core dumped)
Jul 12 19:06:31 master kernel: pid 60864 (httpd), uid 80: exited on
signal 10 (core dumped)
Jul 12 19:08:30 master kernel: pid 61302 (httpd), uid 80: exited on
signal 11 (core dumped)
Jul 12 20:27:43 master kernel: pid 67077 (httpd), uid 80: exited on
signal 11 (core dumped)
Jul 12 20:50:14 master kernel: pid 69216 (httpd), uid 80: exited on
signal 11 (core dumped)
Jul 12 21:07:00 master kernel: pid 71457 (httpd), uid 80: exited on
signal 10 (core dumped)
Jul 12 21:10:18 master kernel: pid 70542 (httpd), uid 80: exited on
signal 11 (core dumped)
Jul 12 21:38:28 master kernel: pid 77041 (httpd), uid 80: exited on
signal 11 (core dumped)
I use these extensions:
php5-ctype-5.2.10
php5-curl-5.2.10
php5-dom-5.2.10
php5-gd-5.2.10
php5-gettext-5.2.10
php5-iconv-5.2.10
php5-imap-5.2.10
php5-mbstring-5.2.10
php5-mcrypt-5.2.10
php5-mhash-5.2.10
php5-mysql-5.2.10
php5-openssl-5.2.10
php5-pcre-5.2.10
php5-posix-5.2.10
php5-pspell-5.2.10
php5-session-5.2.10
php5-simplexml-5.2.10
php5-spl-5.2.10
php5-tokenizer-5.2.10
php5-xml-5.2.10
php5-zlib-5.2.10
Also, I have gd 2.0.35 and imap-uw 2007e installed.
Reproduce code:
---
N/A. It happens occasionally. I run one fairly big WordPress site
(http://neppe.no/) and a forum on http://motorpsycho.fix.no. But I can't
find out exactly what provokes the crash.
Actual result:
--
GDB backtrace:
(gdb) bt full
#0 0x004249e4 in ap_rflush (r=0x805d61c38) at
http_protocol.c:2823
No locals.
#1 0x000801c92efc in sapi_apache_flush
(server_context=0x805d61c38)
at /usr/ports/lang/php5/work/php-5.2.10/sapi/apache/mod_php5.c:119
No locals.
#2 0x000801bc652f in sapi_flush ()
at /usr/ports/lang/php5/work/php-5.2.10/main/SAPI.c:922
No locals.
#3 0x0008016d in php_module_shutdown ()
at /usr/ports/lang/php5/work/php-5.2.10/main/main.c:1906
module_number = 0
#4 0x00080131 in php_module_shutdown_wrapper (
sapi_globals=0x801e43c00)
at /usr/ports/lang/php5/work/php-5.2.10/main/main.c:1879
No locals.
#5 0x000801c945c0 in php_child_exit_handler (s=0x800b05060,
p=0x800b31018)
at /usr/ports/lang/php5/work/php-5.2.10/sapi/apache/mod_php5.c:928
No locals.
#6 0x004119f0 in ap_child_exit_modules (p=0x800b31018,
s=0x800b05060)
at http_config.c:1634
m = (module *) 0x801e43d20
#7 0x00419df6 in clean_child_exit (code=0) at http_main.c:542
No locals.
#8 0x0041d16a in child_main (child_num_arg=5) at
http_main.c:4633
conn_io = (BUFF *) 0x805dcb080
r = (request_rec *) 0x805d60060
clen = 16
sa_server = {sa_len = 16 '\020', sa_family = 2 '\002',
sa_data = "\000PP[$\024\000\000\000\000\000\000\000"}
sa_client = {sa_len = 16 '\020', sa_family = 2 '\002',
sa_data = "\bÄW\232ã\027\000\000\000\000\000\000\000"}
lr = (listen_rec *) 0x0
#9 0x0041d734 in make_child (s=0x800b05060, slot=5,
now=1247427429)
at http_main.c:5055
pid = 0
#10 0x0041db6b in perform_idle_server_maintenance ()
at http_main.c:5256
i = 0
to_kill = 1
idle_count = 2
pid = -1
ss = (short_score *) 0x80058e410
now = 1247427429
free_length = 1
free_slots = {5, 6, 10, 11, 16, 17, 18, 19, -4976, 32767,
4305748, 0,
98677480, 8, 4451364, 0, -4960, 32767, 4254904, 0, 5824512, 8, 1, 0,
-4912,
32767, 4305748, 0, -4912, 32767, 4316501, 4}
#44872 [Com]: canary mismatch on efree() - heap overflow detected
ID: 44872
Comment by: emiel dot molenaar at gmail dot com
Reported By: mattr at shoplet dot com
Status: No Feedback
Bug Type: MySQLi related
Operating System: FreeBSD 6.2
PHP Version: 5.2.5
New Comment:
Any news about this one? Having the same issue here on Debian:
PHP 5.2.10-2 with Suhosin-Patch 0.9.7 (cli) (built: Jul 10 2009
01:47:03)
Previous Comments:
[2009-05-06 14:16:33] j dot vd dot broek at home dot nl
This solution I saw on another website might help fixing it in a next
build of PHP or at least show people with the same problem a way out of
it:
http://chrisblunt.com/blog/2009/05/01/php-fixing-mismatched-canaries-how-to-remove-suhosin-from-debianubuntu-packages/
[2009-05-03 13:48:10] ewilded at gmail dot com
Same situation on PHP 5.2.9 with Suhosin-Patch 0.9.7 (cli) (built: May
2 2009 14:51:38), OS: Slackware 12, i'm connecting to Oracle DB on
remote machine using PDO, script gets killed while trying to execute
simple SELECT statement without any params (same code works fine with
MySQL).
[2009-04-21 14:39:12] fr33z at inmail dot cz
I have the same issue with PHP Version 5.2.9-pl2-gentoo
'./configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu'
'--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info'
'--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64'
'--with-pcre-regex=/usr' '--enable-maintainer-zts' '--disable-cli'
'--with-apxs2=/usr/sbin/apxs2'
'--with-config-file-path=/etc/php/apache2-php5'
'--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active'
'--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar'
'--with-curl' '--with-curlwrappers' '--disable-dbase' '--enable-exif'
'--without-fbsql' '--without-fdftk' '--enable-ftp' '--with-gettext'
'--without-gmp' '--disable-ipv6' '--disable-json' '--without-kerberos'
'--enable-mbstring' '--with-mcrypt' '--with-mhash' '--without-msql'
'--without-mssql' '--with-ncurses' '--with-openssl'
'--with-openssl-dir=/usr' '--disable-pcntl' '--without-pgsql'
'--without-pspell' '--without-recode' '--disable-shmop' '--without-snmp'
'--disable-soap' '--enable-sockets' '--without-sybase'
'--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem'
'--disable-sysvshm' '--without-tidy' '--disable-wddx' '--without-xmlrpc'
'--with-xsl' '--enable-zip' '--with-zlib' '--disable-debug'
'--enable-dba' '--without-cdb' '--with-db4' '--disable-flatfile'
'--with-gdbm' '--without-qdbm' '--with-freetype-dir=/usr'
'--with-t1lib=/usr' '--disable-gd-jis-conv' '--with-jpeg-dir=/usr'
'--with-png-dir=/usr' '--without-xpm-dir' '--with-gd'
'--with-mysql=/usr' '--with-mysql-sock=/var/run/mysqld/mysqld.sock'
'--without-mysqli' '--without-pdo-dblib' '--with-pdo-mysql=/usr'
'--without-pdo-odbc' '--without-pdo-pgsql' '--without-pdo-sqlite'
'--with-readline' '--without-libedit' '--without-mm' '--without-sqlite'
'--with-pic'
[2009-03-22 19:38:40] mr dot jony at gmail dot com
i have this same problem in a fresh install of ubuntu 8.04 lts
and i dont have the suhosin patch
please help
[2009-03-11 09:17:40] dballance at roydshall dot org
I have the same error when running certain queries with mssql_query().
There seems to be no way to predict which queries will run and which
fail - although if a query fails it always fails and if it runs then it
alway runs. The more complex the query, the more likely to fail.
I am running PHP Version 5.2.4-2ubuntu5.5 with Suhosin Patch 0.9.6.2.
Example code that trips the switch:
$dbhandle = mssql_connect($myServer, $myUser, $myPass);
$selected = mssql_select_db($myDB, $dbhandle);
$query = "SELECT * FROM sims.curr_group INNER JOIN
sims.curr_class_period ON sims.curr_group.base_group_id =
sims.curr_class_period.base_group_id INNER JOIN sims.sims_person ON
sims.sims_person.person_id = sims.curr_class_period.person_id
WHERE (sims.curr_group.short_name = '9b/It1')";
$result = mssql_query($query);
while($row = mssql_fetch_array($result)) {
print_r($row);
}
//close the connection
mssql_close($dbhandle);
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/44872
--
Edit this bug report at http://bugs.php.net/?id=44872&edit=1
#48778 [Opn->Asn]: Files on NTFS Mounted Volumes (Junctions) inaccessible
ID: 48778 Updated by: paj...@php.net Reported By: cs at koch-aplsystems dot de -Status: Open +Status: Assigned Bug Type: *General Issues Operating System: win32 only - XP SP3 PHP Version: 5.3.0 -Assigned To: +Assigned To: pajoye Previous Comments: [2009-07-09 20:38:23] Steve at b-en-e dot com Confirmed here. 5.2.8 does not have this problem, but 5.2.10 does, so it was introduced in the previous versions. Removing the junction from the picture solves the problem. Note that it is not only the source files: if the error log is directed to a junctioned folder apache ends the request with a connection reset by peer. [2009-07-02 15:18:33] cs at koch-aplsystems dot de Description: Apache 2.2 DocumentRoot is on a NTFS drive with a Mounted Volume (NTFS Junction) Partition. All files the seem inaccessible to PHP 5.3.x (5.2.x version do not show this problem) Changing Apache DocumentRoot to a "real" directory on c: works around the problem. Reproduce code: --- not needed Expected result: php script loading Actual result: -- Fatal error: Unknown: Failed opening required 'C:/Web/apache-root/my_file.php' (include_path='.') in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=48778&edit=1
#48955 [NEW]: different namespace passing to autoloader
From: schunke at gmx dot net Operating system: all PHP version: 5.3.0 PHP Bug Type: Scripting Engine problem Bug description: different namespace passing to autoloader Description: Theres a difference in namespace passing to an autoloader. That may cause several problems and it should be the same. Reproduce code: --- Expected result: Same passing of namespace to autoloader as new \ns\className -> ns\className and $a = "\ns\className"; new $a; -> ns\className Actual result: -- new \ns\className -> autoloader gets ns\className $a = "\ns\className"; new $a;-> autoloader gets \ns\className (the first backslash is the problem) -- Edit bug report at http://bugs.php.net/?id=48955&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48955&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48955&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48955&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48955&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48955&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48955&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48955&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48955&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48955&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48955&r=support Expected behavior: http://bugs.php.net/fix.php?id=48955&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48955&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48955&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48955&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48955&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48955&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48955&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48955&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48955&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48955&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48955&r=mysqlcfg
#48852 [Opn]: php windows save file to remote share strange access denied
ID: 48852 User updated by: trutas dot ctx at gmail dot com Reported By: trutas dot ctx at gmail dot com Status: Open Bug Type: IIS related Operating System: Windows Server 2003 x64 IIS6.0 PHP Version: 5.3.0 New Comment: don't know if it helps, but here are some example details from phpinfo(); _SERVER["APPL_MD_PATH"] /LM/W3SVC/1897346991/Root/webservices/Cacher _SERVER["APPL_PHYSICAL_PATH"] \\ptlisi020dat\intraroot$\CIO\Webservices\Cacher\ I haven't tried using APPL_MD_PATH, but with APPL_PHYSICAL_PATH it doesn't work. Previous Comments: [2009-07-08 15:56:48] trutas dot ctx at gmail dot com i have installed and configured as recommended at http://learn.iis.net/page.aspx/247/using-fastcgi-to-host-php-applications-on-iis-60/ can i further configure the FastCGI/PHP user anywhere else? IIS user is configured correctly (- home directory with Run as trustedDomain\iisuser) and the destination folder has trustedDomain\iisuser modify and everyone modify . Regards, [2009-07-08 15:18:27] paj...@php.net Be sure that you configured the user correctly or that the user has the correct access. [2009-07-08 15:15:19] trutas dot ctx at gmail dot com FastCGI [2009-07-08 15:13:50] trutas dot ctx at gmail dot com Note: test.php is located at \\share\intraroot$\site\ i've just tested it further and tryed a few workarounds: - it doesn't work with relative path (since both files are within the same share) "..\\folder\\file.txt"; - it doesn't work with dirname(__FILE__)."\\..\\folder\\file.txt"; - does not work with forward slashes //share/... - the error is "permission denied" even if the destination folder doesn't exist - i've found this because at a time i had wrongly typed share\\intraroot$folder\\file.txt - that does not exist; I'm guessing it has something to do with the home directory in IIS being on a remote share - the production servers are clustered... Every other technology (vbscript, .NET) on IIS accesses the shares normally. [2009-07-08 15:03:05] paj...@php.net How did you install php? FCGI or ISAPI? 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/48852 -- Edit this bug report at http://bugs.php.net/?id=48852&edit=1
#48744 [Com]: Segmentation fault with open_basedir enabled
ID: 48744
Comment by: rs at qcm dot cz
Reported By: tom at ideaweb dot de
Status: Feedback
Bug Type: Safe Mode/open_basedir
Operating System: Linux Debian Etch
PHP Version: 5.3.0
Assigned To: fb-req-jani
New Comment:
Hello everyone!
I'm experiencing similar problems using PHP 5.3.0 final on 64-bit
CentOS with Apache 2.2.3.
I'm not actually getting segfaults but defining "php_admin_value
open_basedir /home/webs/" anywhere in httpd.conf results in open_basedir
errors that look like these:
Warning: Unknown: open_basedir restriction in effect.
File(/home/webs/_devel/public/index2.php) is not within the allowed
path(s): (0óûÇË*) in Unknown on line 0 Warning: Unknown: failed to
open stream: Operation not permitted in Unknown on line 0
The open_basedir variable value is distorted in a weird way and the
string remains the same until Apache is reloaded. Then it changes to a
different set of random characters.
>From what I've tried disabling all PHP extensions didn't make any
difference, the only thing that helps is defining open_basedir in
php.ini instead.
I'm running Apache in prefork mode and PHP with Thread Safety disabled.
Previous Comments:
[2009-07-17 04:05:57] dougcsd at yahoo dot com
Here is more info on this.
I ran into this earlier while running 5.3 Alpha snapshots.
The Snapshot: php5.3-200810090430 (Alpha 3) did not seem to have this
problem yet, and works ok. I have reproduced the problem on two
machines and multiple operating systems. I see the scrambled open
basedir paths in the apache logs when a simple phpinfo() fails.
Both systems were running Slackware 12.1 (one 32 bit, and one 64 bit)
BlueWhite64 for the 12.1 64 bit.
I recently upgraded to Slackware 12.2 on the 32 bit machine to upgrade
the libc to a newer version and see if it helped, but the problem
persists.
I first saw this problem in php5.3-200903230730, and assumed it was a
development bug that would work itself out in time, and simply reverted
back. However the problem has carried over to 5.3.0 release.
I have done a bit of digging and it appears that both PHP and Apache
are using pthreads on these machines. Because of the randomness of when
the corruption occurs, I believe this may be related to a threading
issue, but I have yet to discover any additional details.
[2009-07-16 13:08:25] j...@php.net
Have you figured out the differences between the working and
non-working servers running 5.3 yet? That's propably the only way to
debug this. Otherwise, just let this rot.
[2009-07-15 07:29:24] tom at ideaweb dot de
Sorry for the delay, the test server was in use...
Seems to be the same =(
(gdb) run -X -d /www/apache/current/
Starting program: /www/apache/2.2.11/bin/httpd -X -d
/www/apache/current/
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1212967232 (LWP 27684)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212967232 (LWP 27684)]
0xb755848f in OnUpdateBaseDir (entry=0x824fbb8,
new_value=0x83b5070
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, mh_arg1=0x48, mh_arg2=0xb7b37e80,
mh_arg3=0x0, stage=4)
at /www/src/php5.3-200907101630/main/fopen_wrappers.c:103
103 if (!*p || !**p) {
(gdb)
[2009-07-10 22:15:18] j...@php.net
Is the backtrace the same?
[2009-07-10 18:46:07] tom at ideaweb dot de
Keeps crashing with php5.3-200907101630 =(
[Fri Jul 10 20:41:45 2009] [notice] child pid 13862 exit signal
Segmentation fault (11)
[Fri Jul 10 20:41:47 2009] [notice] child pid 13863 exit signal
Segmentation fault (11)
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/48744
--
Edit this bug report at http://bugs.php.net/?id=48744&edit=1
#48955 [Opn]: different namespace passing to autoloader
ID: 48955 Updated by: j...@php.net Reported By: schunke at gmx dot net Status: Open Bug Type: Scripting Engine problem -Operating System: all +Operating System: * PHP Version: 5.3.0 New Comment: I don't know OS called "all".. :) Previous Comments: [2009-07-17 09:53:21] schunke at gmx dot net Description: Theres a difference in namespace passing to an autoloader. That may cause several problems and it should be the same. Reproduce code: --- Expected result: Same passing of namespace to autoloader as new \ns\className -> ns\className and $a = "\ns\className"; new $a; -> ns\className Actual result: -- new \ns\className -> autoloader gets ns\className $a = "\ns\className"; new $a;-> autoloader gets \ns\className (the first backslash is the problem) -- Edit this bug report at http://bugs.php.net/?id=48955&edit=1
#48744 [Com]: Segmentation fault with open_basedir enabled
ID: 48744
Comment by: rs at qcm dot cz
Reported By: tom at ideaweb dot de
Status: Feedback
Bug Type: Safe Mode/open_basedir
Operating System: Linux Debian Etch
PHP Version: 5.3.0
Assigned To: fb-req-jani
New Comment:
Ok, I think I've ran into some kind of overflow game here. This is my
test PHP setup in httpd.conf:
php_admin_value safe_mode 0
php_admin_value upload_tmp_dirsomepath1_123456
php_admin_value session.save_path somepath2_123456
php_admin_value open_basedir /home/webs/
php_admin_value include_path
.:/usr/share/misc:/usr/share:/home/webs/.libs:/home/webs/.libs/php-pear
php_admin_value display_errorsOn
To be able to see what path is being looked for in open_basedir I'm
including a file that is not within the /home/webs directory.
This is the result as expected:
Warning: include_once(): open_basedir restriction in effect.
File(/tmp/something) is not within the allowed path(s): (/home/webs/) in
/home/webs/_devel/public/index2.php on line 13 Call Stack: 0. 616224
1. {main}()
Note that the upload_tmp_dir and session.save_path variables are
exactly 16 chars long. Now let's shorten the second one a little bit:
php_admin_value upload_tmp_dirsomepath1_123456
php_admin_value session.save_path somepath2_12345
php_admin_value open_basedir /home/webs/
And what I got here:
Warning: include_once(): open_basedir restriction in effect.
File(/tmp/something) is not within the allowed path(s):
(somepath2_12345) in /home/webs/_devel/public/index2.php on line 13 Call
Stack: 0. 616184 1. {main}()
Oops? Is that path really what I have set? Let's shorten the next one:
php_admin_value upload_tmp_dirsomepath1_12345
php_admin_value session.save_path somepath2_12345
php_admin_value open_basedir /home/webs/
And here we go:
Warning: include_once(): open_basedir restriction in effect.
File(/tmp/something) is not within the allowed path(s):
(somepath1_12345) in /home/webs/_devel/public/index2.php on line 13 Call
Stack: 0. 616176 1. {main}()
Looks like for three different setups there different strings slip into
the open_basedir variable. Silly.
I hope this helps a bit in finding the bug.
Previous Comments:
[2009-07-17 10:19:30] rs at qcm dot cz
Hello everyone!
I'm experiencing similar problems using PHP 5.3.0 final on 64-bit
CentOS with Apache 2.2.3.
I'm not actually getting segfaults but defining "php_admin_value
open_basedir /home/webs/" anywhere in httpd.conf results in open_basedir
errors that look like these:
Warning: Unknown: open_basedir restriction in effect.
File(/home/webs/_devel/public/index2.php) is not within the allowed
path(s): (0óûÇË*) in Unknown on line 0 Warning: Unknown: failed to
open stream: Operation not permitted in Unknown on line 0
The open_basedir variable value is distorted in a weird way and the
string remains the same until Apache is reloaded. Then it changes to a
different set of random characters.
>From what I've tried disabling all PHP extensions didn't make any
difference, the only thing that helps is defining open_basedir in
php.ini instead.
I'm running Apache in prefork mode and PHP with Thread Safety disabled.
[2009-07-17 04:05:57] dougcsd at yahoo dot com
Here is more info on this.
I ran into this earlier while running 5.3 Alpha snapshots.
The Snapshot: php5.3-200810090430 (Alpha 3) did not seem to have this
problem yet, and works ok. I have reproduced the problem on two
machines and multiple operating systems. I see the scrambled open
basedir paths in the apache logs when a simple phpinfo() fails.
Both systems were running Slackware 12.1 (one 32 bit, and one 64 bit)
BlueWhite64 for the 12.1 64 bit.
I recently upgraded to Slackware 12.2 on the 32 bit machine to upgrade
the libc to a newer version and see if it helped, but the problem
persists.
I first saw this problem in php5.3-200903230730, and assumed it was a
development bug that would work itself out in time, and simply reverted
back. However the problem has carried over to 5.3.0 release.
I have done a bit of digging and it appears that both PHP and Apache
are using pthreads on these machines. Because of the randomness of when
the corruption occurs, I believe this may be related to a threading
issue, but I have yet to discover any additional details.
[2009-07-16 13:08:25] j...@php.net
Have you figured out the differences between the working and
non-working servers running 5.3 yet? That's propably the only way to
debug this. Otherwise, just let this rot.
[2009-07-15 07:29:24] tom at ideaweb dot de
Sorry for the delay, the test server was in use...
Seems to be the same =(
(gdb) run -X -d /w
#46367 [Com]: fputcsv does not add the correct newline character on Windows
ID: 46367
Comment by: chris dot tatedavies at inflightproductions dot com
Reported By: jmer...@php.net
Status: Open
Bug Type: Feature/Change Request
Operating System: Windows XP
PHP Version: 5.2.6
New Comment:
How long does the voting last? I need to know if this is going to be
fixed. Or if it has been already. I've looked through the changelog to
no avail. Its been over 8 months since the original report.
Thanks, Chris
Previous Comments:
[2008-11-06 13:49:51] jmer...@php.net
Updated earlier patch:
Index: file.c
===
RCS file: /repository/php-src/ext/standard/file.c,v
retrieving revision 1.530
diff -u -r1.530 file.c
--- file.c 21 Oct 2008 22:06:48 - 1.530
+++ file.c 22 Oct 2008 21:21:42 -
@@ -2104,7 +2104,7 @@
}
}
- smart_str_appendc(&csvline, '\n');
+ smart_str_appendl(&csvline, PHP_EOL, sizeof(PHP_EOL));
smart_str_0(&csvline);
ret = php_stream_write(stream, csvline.c, csvline.len);
Also below is a test case for this bug. Should fail currently on
Windows.
--TEST--
Bug #46367 - fputcsv does not add the correct newline character on
Windows
--FILE--
--EXPECT--
bool(true)
Done
[2008-10-22 17:00:52] jmer...@php.net
Description:
Per the documentation for the fputcsv() function, it adds a newline to
the end of the csv string it returns. However, it is hardcoded to be
'\n' ( default for unix newline ), while Windows uses \r\n. PHP should
do this as well.
Below is a patch to fix this issue; it uses the constant PHP_EOL to get
the correct newline to use on the current platform:
Index: php-src/ext/standard/file.c
===
RCS file: /repository/php-src/ext/standard/file.c,v
retrieving revision 1.530
diff -r1.530 file.c
2107c2107
< smart_str_appendc(&csvline, '\n');
---
> smart_str_appendc(&csvline, PHP_EOL);
Reproduce code:
---
$array1 = array("a","b","c");
$array2 = array("d","e","f");
echo fputcsv($array1).fputcsv($array2);
Expected result:
"a","b","c"
"d","e","f"
Actual result:
--
"a","b","c""d","e","f"
--
Edit this bug report at http://bugs.php.net/?id=46367&edit=1
#48958 [NEW]: bug in the define() funtion
From: wolff at ironshark dot de
Operating system: Linux
PHP version: 5.2.10
PHP Bug Type: *General Issues
Bug description: bug in the define() funtion
Description:
it is possible to overwrite defined variables
Reproduce code:
---
define('FOO','bar',true);
echo FOO; // will print "bar"
define('FOO','bar',true);
define('FOO','stuff',true);
echo FOO; // will print "bar"
define('FOO','bar',true);
define('FOO','stuff'); // <<< here is the bug
echo FOO; // will print "stuff"
Expected result:
FOO won't be overwritten
Actual result:
--
it will printed out "stuff"
--
Edit bug report at http://bugs.php.net/?id=48958&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48958&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48958&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48958&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48958&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48958&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48958&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48958&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48958&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48958&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48958&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48958&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48958&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48958&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48958&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48958&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48958&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48958&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48958&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48958&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48958&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48958&r=mysqlcfg
#48761 [Com]: php crashes on start - getaddrinfo could not be located
ID: 48761 Comment by: jet5y at hotmail dot co dot uk Reported By: aheckmann at m-s dot de Status: Assigned Bug Type: Reproducible crash Operating System: win32 only - Windows 2000 SP4 PHP Version: 5.3.0 Assigned To: pajoye New Comment: However, considering that most servers running it would either be 2000 or 2003 and not XP then a workaround would seem more sensible at the slight detriment for now of XP SP2 systems. Previous Comments: [2009-07-02 23:48:19] ka...@php.net The problem with fixing this (by doing an include to emulate the functions on systems without it (Windows 2000, XP prior SP2) is that it will slow down for other system that already got it, as it will attempt to load the ws2_32 library and search for the symbol locations, which is just slowing us down for no *real* reason. The question whether to fix this is trival, Me, Pierre and the others will discuss this and how to deal with it. [2009-07-02 17:08:20] jon dot harrell at gmail dot com If PHP support for w2k remains then use of GetAddrInfoW must be woked around. The article above explains very plainly that this function is XP SP2+ ONLY. Currently PHP 5.3 is not compatible with w2k-XP SP1. "The GetAddrInfoW function is the Unicode version of getaddrinfo. The GetAddrInfoW function was added to the Ws2_32.dll in Windows XP with Service Pack 2 (SP2). The GetAddrInfoW function cannot be used on versions of Windows earlier than Windows XP with SP2." [2009-07-02 10:18:42] johan...@php.net Win 2000 is the required minimum version, or should be, while I don't know about required service packs and other patches. Pierre? [2009-07-01 22:23:39] aheckmann at m-s dot de In my opinion this document from microsoft describes the solution to fix the problem for older windows versions that don't have the getaddrinfo function with an inline function: http://msdn.microsoft.com/en-us/library/ms738520%28VS.85%29.aspx Support for getaddrinfo on older versions of Windows The getaddrinfo function was added to the Ws2_32.dll on Windows XP and later. To execute an application that uses this function on earlier versions of Windows, then you need to include the Ws2tcpip.h and Wspiapi.h files. When the Wspiapi.h include file is added, the getaddrinfo function is defined to the WspiapiGetAddrInfo inline function in the Wspiapi.h file. At runtime, the WspiapiGetAddrInfo function is implemented in such a way that if the Ws2_32.dll or the Wship6.dll (the file containing getaddrinfo in the IPv6 Technology Preview for Windows 2000) does not include getaddrinfo, then a version of getaddrinfo is implemented inline based on code in the Wspiapi.h header file. This inline code will be used on older Windows platforms that do not natively support the getaddrinfo function. Will this be fixed, or is Win2k support dropped for php 5.3.x? The windows release notes for 5.3 only mentioned that pre-windows 2000 support is dropped. Thanks [2009-07-01 22:19:11] aheckmann at m-s dot de Description: Tested with VC6 and VC9 (+vcredist_x86.exe) Version of PHP 5.3.0 PHP does not start an produces the following error message: php.exe - Entry Point Not Found : The procedure entry point getaddrinfo could not be located in the dynamic link library WS2_32.dll Reproduce code: --- php.exe -v Expected result: php shows version info Actual result: -- Php does not start an shows the following error: php.exe - Entry Point Not Found : The procedure entry point getaddrinfo could not be located in the dynamic link library WS2_32.dll -- Edit this bug report at http://bugs.php.net/?id=48761&edit=1
#48959 [NEW]: is_readable() and filezise() do not return correctly
From: trutas dot ctx at gmail dot com
Operating system: Windows Server 2003 x64 IIS6.0
PHP version: 5.3.0
PHP Bug Type: Filesystem function related
Bug description: is_readable() and filezise() do not return correctly
Description:
is_readable() returns false for temporary file (just created)
"C:\WINDOWS\Temp\dom373.tmp" and filezise() fails too.
fopen() and get_file_contents() both work for the same file.
as a workaround i'm using fopen() instead of is_readable() and
fseek($fopen_instance, 0, SEEK_END); instead of filesize()
Reproduce code:
---
//temporary location
$resolved_url = tempnam(DOMPDF_TEMP_DIR, "dompdf_img_");
//get source
$image=my_file_get_contents("http://9tree.net/favicon.ico";);
//save it
file_put_contents($resolved_url, $image);
//tests
if(is_readable($resolved_url)) print "file readable, ";
if(filesize($resolved_url)) print "filezise found.\n";
die("all done.");
Expected result:
file readable, filezise found.
all done.
Actual result:
--
all done.
--
Edit bug report at http://bugs.php.net/?id=48959&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48959&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48959&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48959&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48959&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48959&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48959&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48959&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48959&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48959&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48959&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48959&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48959&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48959&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48959&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48959&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48959&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48959&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48959&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48959&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48959&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48959&r=mysqlcfg
#48947 [Opn->Csd]: vcsclean should remove .lo and .la files
ID: 48947 Updated by: j...@php.net Reported By: s...@php.net -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Ubuntu 8.10 (32bit) PHP Version: 5.3CVS-2009-07-16 (CVS) New Comment: Fixed in all branches. And if you really want to do clean builds, build outside source tree. Previous Comments: [2009-07-16 16:50:57] s...@php.net Description: The files removed by vcsclean are only a subset of the files removed by 'make clean'. File extensions .lo .la .gcno .gcda are not removed by vcsclean. Using the sequence 'cd php53; svn up; ./vcsclean; ./configure ...; make' fails to find some .o files. Some .o's get built but link fails with a bunch of errors of the form: gcc: ext//.libs/.o: No such file or directory The vcsclean command removes the ext/*/.libs directories but doesn't remove ext/*.lo files. This causes C files to be skipped for recompilation and no .libs/*.o files are created. A patch is to add .lo to the extension list in build/build.mk. Index: build.mk === --- build.mk(revision 284190) +++ build.mk(working copy) @@ -67,12 +67,12 @@ cvsclean-work: @for i in `find . -name .cvsignore`; do \ - (cd `dirname $$i` 2>/dev/null && rm -rf `cat .cvsignore | grep -v config.nice | sed 's/[[:space:]]/ /g'` *.o *.a .libs || true); \ + (cd `dirname $$i` 2>/dev/null && rm -rf `cat .cvsignore | grep -v config.nice | sed 's/[[:space:]]/ /g'` *.lo *.o *.a .libs || true); \ done svnclean-work: @for i in `find . -type d -not -path '*/.svn/*' | grep -v '.svn'`; do \ - (cd `dirname $$i` 2>/dev/null && rm -rf `svn propget svn:ignore . | grep -v config.nice` *.o *.a .libs || true); \ + (cd `dirname $$i` 2>/dev/null && rm -rf `svn propget svn:ignore . | grep -v config.nice` *.o *.lo *.a .libs || true); \ done gitclean-work: Also, adding '.la .gcno .gcda' in addition to '.lo' would make vcsclean consistent with 'make clean'. A secondary bug is that .o files are not recreated from existing .lo files. -- Edit this bug report at http://bugs.php.net/?id=48947&edit=1
#48943 [Opn->Bgs]: Connection Reset
ID: 48943 Updated by: j...@php.net Reported By: guillermog at tricuspide dot com -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: Windows 7 RC PHP Version: 5.3.0 New Comment: So this is same bug as bug #48754 -> bogus. Previous Comments: [2009-07-16 14:13:12] guillermog at tricuspide dot com In brief, if no link Identifier is given to mysql_close() the function makes apache crash. regards, Guillermo [2009-07-16 13:56:17] guillermog at tricuspide dot com Thanks Jani, I debugged my script trying to find if there's any command that could make this happen. I could isolated the problem so the code that reproduces the error is: Comment out mysql_close() and no error will happen. Guillermo [2009-07-16 13:28:03] j...@php.net You need to come up with a simple script that shows the problem. Most likely it has to do with mysql stuff. Search this bug db for mysql* related issues for PHP 5.3 and you'll propably find the real problem. [2009-07-16 13:22:00] guillermog at tricuspide dot com I really privided all the information I have. I think this is a real problem. Do you need anything else in specific? I really want to help to have this solved! [2009-07-16 13:01:44] j...@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. 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/48943 -- Edit this bug report at http://bugs.php.net/?id=48943&edit=1
#47767 [NoF->Asn]: include_once does not resolve windows symlinks or junctions
ID: 47767 Updated by: paj...@php.net Reported By: lukemoynihan at gmail dot com -Status: No Feedback +Status: Assigned Bug Type: Scripting Engine problem Operating System: win32 only - Windows Vista PHP Version: 5.2.9 Assigned To: pajoye Previous Comments: [2009-07-12 01:00:00] 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". [2009-07-07 02:54:55] mario at unosquare dot com 5.3 does not support folder junctions. It used to be fine in 5.2.9-2 but now, with 5.3 it is not resolving the includes/requires. [2009-06-25 01:00:00] 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". [2009-06-21 18:59:58] martin at curlybracket dot de I've tryed symlinked files and that is working for me, you're right. So, maybe the symlinked directory thing is another but related bug, right? I've also tryed the latest snapshot, but the problem is the same for me. [2009-06-17 19:37:30] paj...@php.net Does it work for you for symlinked files? Or does it fail too? 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/47767 -- Edit this bug report at http://bugs.php.net/?id=47767&edit=1
#48958 [Opn->Bgs]: bug in the define() funtion
ID: 48958
Updated by: j...@php.net
Reported By: wolff at ironshark dot de
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: Linux
PHP Version: 5.2.10
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
Previous Comments:
[2009-07-17 11:57:27] wolff at ironshark dot de
Description:
it is possible to overwrite defined variables
Reproduce code:
---
define('FOO','bar',true);
echo FOO; // will print "bar"
define('FOO','bar',true);
define('FOO','stuff',true);
echo FOO; // will print "bar"
define('FOO','bar',true);
define('FOO','stuff'); // <<< here is the bug
echo FOO; // will print "stuff"
Expected result:
FOO won't be overwritten
Actual result:
--
it will printed out "stuff"
--
Edit this bug report at http://bugs.php.net/?id=48958&edit=1
#48949 [Opn->Bgs]: max_execution_time from php.ini ignored
ID: 48949 Updated by: j...@php.net Reported By: giunta dot gaetano at gmail dot com -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: vista sp2 PHP Version: 5.3.0 New Comment: Your php.ini isn't loaded. Use phpinfo() output to figure out which one is actually used. No bug here. Previous Comments: [2009-07-17 07:32:26] giunta dot gaetano at gmail dot com max_execution_time=300 in php.ini (using apache sapi btw) [2009-07-16 22:24:20] paj...@php.net And what's the value set in php.ini? [2009-07-16 22:17:27] giunta dot gaetano at gmail dot com Description: On windows vista, with apache 2.2.11, php 5.3.0 vc9 threadsafe, the max_execution_time ini parameter is read correctly (as shown by ini_get() and phpinfo()) but never used. After 60 secs, the script times out with the message "Fatal error: Maximum execution time of 60 seconds exceeded". Adding a set_time_limit() or ini_set() call solves the problem. -- Edit this bug report at http://bugs.php.net/?id=48949&edit=1
#48960 [NEW]: converting to ErrorException cuts the "message"
From: shakertest at live dot no
Operating system: OS X & Ubuntu
PHP version: 5.3.0
PHP Bug Type: *General Issues
Bug description: converting to ErrorException cuts the "message"
Description:
The exception message of an error that has been converted to an
ErrorException is getting cut so important information is missing,
Reproduce code:
---
function error_handler($code, $message, $file, $line)
{
throw new ErrorException($message, $code, 0, $file, $line);
}
set_error_handler('error_handler');
function hint(array $foo) {}
try
{
hint(123);
}
catch(Exception $e)
{
echo $e->getMessage();
}
Expected result:
Argument 1 passed to hint() must be an array, integer given, called in
test.php on line 14 and defined in test.php on line 10
Actual result:
--
Argument 1 passed to hint() must be an array, integer given, called in
test.php on line 14 and defined
--
Edit bug report at http://bugs.php.net/?id=48960&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48960&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48960&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48960&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48960&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48960&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48960&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48960&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48960&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48960&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48960&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48960&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48960&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48960&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48960&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48960&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48960&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48960&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48960&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48960&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48960&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48960&r=mysqlcfg
#48949 [Bgs]: max_execution_time from php.ini ignored
ID: 48949
User updated by: giunta dot gaetano at gmail dot com
Reported By: giunta dot gaetano at gmail dot com
Status: Bogus
Bug Type: *General Issues
Operating System: vista sp2
PHP Version: 5.3.0
New Comment:
Thanks for the tip, but I would not have opened the issue without
checking first phpinfo().
As stated in the initial report, even ini_get('max_execution_time')
reports the value of 300
Previous Comments:
[2009-07-17 12:41:51] j...@php.net
Your php.ini isn't loaded. Use phpinfo() output to figure out which one
is actually used. No bug here.
[2009-07-17 07:32:26] giunta dot gaetano at gmail dot com
max_execution_time=300 in php.ini (using apache sapi btw)
[2009-07-16 22:24:20] paj...@php.net
And what's the value set in php.ini?
[2009-07-16 22:17:27] giunta dot gaetano at gmail dot com
Description:
On windows vista, with apache 2.2.11, php 5.3.0 vc9 threadsafe, the
max_execution_time ini parameter is read correctly (as shown by
ini_get() and phpinfo()) but never used.
After 60 secs, the script times out with the message
"Fatal error: Maximum execution time of 60 seconds exceeded".
Adding a set_time_limit() or ini_set() call solves the problem.
--
Edit this bug report at http://bugs.php.net/?id=48949&edit=1
#48949 [Bgs]: max_execution_time from php.ini ignored
ID: 48949
User updated by: giunta dot gaetano at gmail dot com
Reported By: giunta dot gaetano at gmail dot com
Status: Bogus
Bug Type: *General Issues
Operating System: vista sp2
PHP Version: 5.3.0
New Comment:
here's the script to reproduce the test:
and here follows the output:
timeout: 300
0. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37.
38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55.
56. 57. 58. 59.
Fatal error: Maximum execution time of 60 seconds exceeded in
D:\htdocs\y.php on line 9
Previous Comments:
[2009-07-17 12:52:12] giunta dot gaetano at gmail dot com
Thanks for the tip, but I would not have opened the issue without
checking first phpinfo().
As stated in the initial report, even ini_get('max_execution_time')
reports the value of 300
[2009-07-17 12:41:51] j...@php.net
Your php.ini isn't loaded. Use phpinfo() output to figure out which one
is actually used. No bug here.
[2009-07-17 07:32:26] giunta dot gaetano at gmail dot com
max_execution_time=300 in php.ini (using apache sapi btw)
[2009-07-16 22:24:20] paj...@php.net
And what's the value set in php.ini?
[2009-07-16 22:17:27] giunta dot gaetano at gmail dot com
Description:
On windows vista, with apache 2.2.11, php 5.3.0 vc9 threadsafe, the
max_execution_time ini parameter is read correctly (as shown by
ini_get() and phpinfo()) but never used.
After 60 secs, the script times out with the message
"Fatal error: Maximum execution time of 60 seconds exceeded".
Adding a set_time_limit() or ini_set() call solves the problem.
--
Edit this bug report at http://bugs.php.net/?id=48949&edit=1
#48960 [Opn->Bgs]: converting to ErrorException cuts the "message"
ID: 48960
Updated by: ka...@php.net
Reported By: shakertest at live dot no
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: OS X & Ubuntu
PHP Version: 5.3.0
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
This is because some errors are meant to be formatted together with a
filename and line number to give most sense
Previous Comments:
[2009-07-17 12:46:17] shakertest at live dot no
Description:
The exception message of an error that has been converted to an
ErrorException is getting cut so important information is missing,
Reproduce code:
---
function error_handler($code, $message, $file, $line)
{
throw new ErrorException($message, $code, 0, $file, $line);
}
set_error_handler('error_handler');
function hint(array $foo) {}
try
{
hint(123);
}
catch(Exception $e)
{
echo $e->getMessage();
}
Expected result:
Argument 1 passed to hint() must be an array, integer given, called in
test.php on line 14 and defined in test.php on line 10
Actual result:
--
Argument 1 passed to hint() must be an array, integer given, called in
test.php on line 14 and defined
--
Edit this bug report at http://bugs.php.net/?id=48960&edit=1
#48951 [Opn->Fbk]: calling get_defined_constans with any paramenter results in sigsev
ID: 48951
Updated by: j...@php.net
Reported By: rajivk at sparklit dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Debian Linux
PHP Version: 5.2.10, 5.3.0
New Comment:
I can not reproduce this with current PHP_5_2 / PHP_5_3 or HEAD
branches. Exactly what was your configure line? What compiler and
version? Can you reproduce it using CLI:
# php -n -r 'var_dump(get_defined_constants(false));'
Previous Comments:
[2009-07-16 22:59:21] rajivk at sparklit dot com
Description:
Calling get_defined_constants with a parameter causes a segfault. The
occurs in 5.2.10 and 5.3.0
Reproduce code:
---
=== case 1 causes crash ==
=
=== case 2 also causes crash ==
=
=== case 3 NO CRASH ==
=
Expected result:
no crash
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb73b1910 (LWP 15496)]
0xb77a2b01 in kill () from /lib/libc.so.6
(gdb) bt
#0 0xb77a2b01 in kill () from /lib/libc.so.6
#1 0x0810ace9 in zend_mm_panic (message=0x84d1d40 "zend_mm_heap
corrupted") at /usr/src/2009july15/php-5.2.10/Zend/zend_alloc.c:94
#2 0x0810d45f in _zend_mm_alloc_int (heap=0x89f7b70, size=44,
__zend_filename=0x84d57d8
"/usr/src/2009july15/php-5.2.10/Zend/zend_hash.c", __zend_lineno=247,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/usr/src/2009july15/php-5.2.10/Zend/zend_alloc.c:1895
#3 0x0810e6d6 in _emalloc (size=44, __zend_filename=0x84d57d8
"/usr/src/2009july15/php-5.2.10/Zend/zend_hash.c", __zend_lineno=247,
__zend_orig_filename=0x0,
__zend_orig_lineno=0) at
/usr/src/2009july15/php-5.2.10/Zend/zend_alloc.c:2300
#4 0x08135f7b in _zend_hash_add_or_update (ht=0x87cb62c,
arKey=0x89d9fc0 "E_STRICT", nKeyLength=9, pData=0xbfcc367c, nDataSize=4,
pDest=0x0, flag=1,
__zend_filename=0x84d4f30
"/usr/src/2009july15/php-5.2.10/Zend/zend_hash.h", __zend_lineno=341) at
/usr/src/2009july15/php-5.2.10/Zend/zend_hash.c:247
#5 0x0812e86d in zend_symtable_update (ht=0x87cb62c, arKey=0x89d9fc0
"E_STRICT", nKeyLength=9, pData=0xbfcc367c, nDataSize=4, pDest=0x0)
at /usr/src/2009july15/php-5.2.10/Zend/zend_hash.h:341
#6 0x0812ecb4 in add_assoc_zval_ex (arg=0x87e5838, key=0x89d9fc0
"E_STRICT", key_len=9, value=0x87e4ccc) at
/usr/src/2009july15/php-5.2.10/Zend/zend_API.c:1056
#7 0x0813f211 in zif_get_defined_constants (ht=1,
return_value=0x87e58e0, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1)
at
/usr/src/2009july15/php-5.2.10/Zend/zend_builtin_functions.c:1674
#8 0x0814e496 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfcc3818) at
/usr/src/2009july15/php-5.2.10/Zend/zend_vm_execute.h:200
#9 0x08153ead in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xbfcc3818) at
/usr/src/2009july15/php-5.2.10/Zend/zend_vm_execute.h:1739
#10 0x0814dffa in execute (op_array=0x87c19b8) at
/usr/src/2009july15/php-5.2.10/Zend/zend_vm_execute.h:92
#11 0x0812b810 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/2009july15/php-5.2.10/Zend/zend.c:1134
#12 0x080e4ad1 in php_execute_script (primary_file=0xbfcc5aec) at
/usr/src/2009july15/php-5.2.10/main/main.c:2025
#13 0x081a47c1 in apache_php_module_main (r=0x87822bc,
display_source_mode=0) at
/usr/src/2009july15/php-5.2.10/sapi/apache/sapi_apache.c:53
#14 0x080d8792 in send_php ()
#15 0x080d87dd in send_parsed_php ()
#16 0x08468875 in ap_invoke_handler ()
#17 0x0847fe6d in process_request_internal ()
#18 0x0847feca in ap_process_request ()
#19 0x084760c0 in child_main ()
#20 0x084763f4 in make_child ()
#21 0x084767e2 in perform_idle_server_maintenance ()
#22 0x08476eb7 in standalone_main ()
#23 0x08477562 in main ()
(gdb) frame 10
#10 0x0814dffa in execute (op_array=0x87c19b8) at
/usr/src/2009july15/php-5.2.10/Zend/zend_vm_execute.h:92
92 if (EX(opline)->handler(&execute_data
TSRMLS_CC) > 0) {
(gdb) print (char
*)(executor_globals.function_state_ptr->function)->common.function_name
$1 = 0x84d5d1b "get_defined_constants"
(gdb) print (char *)executor_globals.active_op_array->function_name
$2 = 0x0
(gdb) print (char *)executor_globals.active_op_array->filename
$3 = 0x87c6284
"/home/rajivk/dev/webroot/forum/www/forum.sparklit.com/foobar.spark"
(gdb)
--
Edit this bug report at http://bugs.php.net/?id=48951&edit=1
#48960 [Bgs]: converting to ErrorException cuts the "message"
ID: 48960
User updated by: shakertest at live dot no
Reported By: shakertest at live dot no
Status: Bogus
Bug Type: *General Issues
Operating System: OS X & Ubuntu
PHP Version: 5.3.0
New Comment:
How is it not a bug when the message string gets cut?
Previous Comments:
[2009-07-17 13:05:04] ka...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
This is because some errors are meant to be formatted together with a
filename and line number to give most sense
[2009-07-17 12:46:17] shakertest at live dot no
Description:
The exception message of an error that has been converted to an
ErrorException is getting cut so important information is missing,
Reproduce code:
---
function error_handler($code, $message, $file, $line)
{
throw new ErrorException($message, $code, 0, $file, $line);
}
set_error_handler('error_handler');
function hint(array $foo) {}
try
{
hint(123);
}
catch(Exception $e)
{
echo $e->getMessage();
}
Expected result:
Argument 1 passed to hint() must be an array, integer given, called in
test.php on line 14 and defined in test.php on line 10
Actual result:
--
Argument 1 passed to hint() must be an array, integer given, called in
test.php on line 14 and defined
--
Edit this bug report at http://bugs.php.net/?id=48960&edit=1
#48959 [Opn]: is_readable() and filezise() do not return correctly
ID: 48959
User updated by: trutas dot ctx at gmail dot com
Reported By: trutas dot ctx at gmail dot com
Status: Open
Bug Type: Filesystem function related
Operating System: win32 - Windows Server 2003 x64
PHP Version: 5.3.0
New Comment:
Just tested - file_exists() returns false incorrectly too.
I´ve worked around it all with checking for fopen($file, 'r') and
forcing file_get_contents() - it works, file exists, is readable and
returns the content.
Previous Comments:
[2009-07-17 12:10:10] trutas dot ctx at gmail dot com
Description:
is_readable() returns false for temporary file (just created)
"C:\WINDOWS\Temp\dom373.tmp" and filezise() fails too.
fopen() and get_file_contents() both work for the same file.
as a workaround i'm using fopen() instead of is_readable() and
fseek($fopen_instance, 0, SEEK_END); instead of filesize()
Reproduce code:
---
//temporary location
$resolved_url = tempnam(DOMPDF_TEMP_DIR, "dompdf_img_");
//get source
$image=my_file_get_contents("http://9tree.net/favicon.ico";);
//save it
file_put_contents($resolved_url, $image);
//tests
if(is_readable($resolved_url)) print "file readable, ";
if(filesize($resolved_url)) print "filezise found.\n";
die("all done.");
Expected result:
file readable, filezise found.
all done.
Actual result:
--
all done.
--
Edit this bug report at http://bugs.php.net/?id=48959&edit=1
#48959 [Opn->Fbk]: is_readable() and filezise() do not return correctly
ID: 48959
Updated by: paj...@php.net
Reported By: trutas dot ctx at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: win32 - Windows Server 2003 x64
PHP Version: 5.3.0
-Assigned To:
+Assigned To: pajoye
New Comment:
Cannot reproduce on 2k8, vista and win7. Pls note that I replaced the
my_file_... with the normal file_get_contents function.
Can you paste a working script pls?
Previous Comments:
[2009-07-17 15:08:28] trutas dot ctx at gmail dot com
Just tested - file_exists() returns false incorrectly too.
I´ve worked around it all with checking for fopen($file, 'r') and
forcing file_get_contents() - it works, file exists, is readable and
returns the content.
[2009-07-17 12:10:10] trutas dot ctx at gmail dot com
Description:
is_readable() returns false for temporary file (just created)
"C:\WINDOWS\Temp\dom373.tmp" and filezise() fails too.
fopen() and get_file_contents() both work for the same file.
as a workaround i'm using fopen() instead of is_readable() and
fseek($fopen_instance, 0, SEEK_END); instead of filesize()
Reproduce code:
---
//temporary location
$resolved_url = tempnam(DOMPDF_TEMP_DIR, "dompdf_img_");
//get source
$image=my_file_get_contents("http://9tree.net/favicon.ico";);
//save it
file_put_contents($resolved_url, $image);
//tests
if(is_readable($resolved_url)) print "file readable, ";
if(filesize($resolved_url)) print "filezise found.\n";
die("all done.");
Expected result:
file readable, filezise found.
all done.
Actual result:
--
all done.
--
Edit this bug report at http://bugs.php.net/?id=48959&edit=1
#48959 [Fbk->Opn]: is_readable() and filezise() do not return correctly
ID: 48959
User updated by: trutas dot ctx at gmail dot com
Reported By: trutas dot ctx at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: win32 - Windows Server 2003 x64
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
The environment could be the problem here,
I'm using Windows 2003 x64 with PHP x64 via fastcgi.
These are two IIS Servers with load balancer and a separate cluster
that serves the actual run files.
PHP is installed on D:\PHP on each IIS machine.
The problem came up using the library dompdf - it saves document
images content to temporary files in order to build the final pdf
document.
I've reduced the problem to the test code i've attached.
DOMPDF_TEMP_DIR is /tmp and writes to C:\Windows\tmp ...
- Please note that this problem does not happen in local folder to the
execution base (eg. "tmp_sub_folder/" ) - this only happens in the
system tmp folder in this setup.
This is the same setup environment as the one reported in the bug
48852 (about file_put_contents)
Regards,
Previous Comments:
[2009-07-17 15:34:47] paj...@php.net
Cannot reproduce on 2k8, vista and win7. Pls note that I replaced the
my_file_... with the normal file_get_contents function.
Can you paste a working script pls?
[2009-07-17 15:08:28] trutas dot ctx at gmail dot com
Just tested - file_exists() returns false incorrectly too.
I´ve worked around it all with checking for fopen($file, 'r') and
forcing file_get_contents() - it works, file exists, is readable and
returns the content.
[2009-07-17 12:10:10] trutas dot ctx at gmail dot com
Description:
is_readable() returns false for temporary file (just created)
"C:\WINDOWS\Temp\dom373.tmp" and filezise() fails too.
fopen() and get_file_contents() both work for the same file.
as a workaround i'm using fopen() instead of is_readable() and
fseek($fopen_instance, 0, SEEK_END); instead of filesize()
Reproduce code:
---
//temporary location
$resolved_url = tempnam(DOMPDF_TEMP_DIR, "dompdf_img_");
//get source
$image=my_file_get_contents("http://9tree.net/favicon.ico";);
//save it
file_put_contents($resolved_url, $image);
//tests
if(is_readable($resolved_url)) print "file readable, ";
if(filesize($resolved_url)) print "filezise found.\n";
die("all done.");
Expected result:
file readable, filezise found.
all done.
Actual result:
--
all done.
--
Edit this bug report at http://bugs.php.net/?id=48959&edit=1
#48962 [NEW]: cURL does not upload files with specified filename
From: alexei dot svitkine at gmail dot com
Operating system: Linux
PHP version: 5.2.10
PHP Bug Type: cURL related
Bug description: cURL does not upload files with specified filename
Description:
Currently, using cURL from PHP, it is not possible to specify a custom
filename on the file sent with the POST. PHP always tells cURL to send
the full path from the filesystem to the server.
However, it is possible to do this from the command-line using:
curl -F 'file=@/tmp/myfile;filename=foo.zip' http://example.com
This bug is similar to:
http://bugs.php.net/bug.php?id=46696
In that bug (which is now fixed), PHP ignored the 'type' parameter
which was passed in a similar way as 'filename' above, but was fixed
to detect it.
Reproduce code:
---
# File test1.php
$data = array('file' => '@/tmp/myfile;filename=foobar');
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'http://localhost/upload.php');
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
curl_exec($ch);
echo curl_error($ch);
# File test2.php
$data = array('file' =>
'@/tmp/myfile;filename=foobar;type=application/zip');
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'http://localhost/upload.php');
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
curl_exec($ch);
echo curl_error($ch);
# File upload.php
print_r($_FILES);
Expected result:
# Result of test1.php
Array
(
[item_file] => Array
(
[name] => foobar
[type] => application/octet-stream
[tmp_name] => /var/tmp/phpCEVFto
[error] => 0
[size] => 36257
)
)
# Result of test1.php
Array
(
[item_file] => Array
(
[name] => foobar
[type] => application/zip
[tmp_name] => /var/tmp/phpCEVFto
[error] => 0
[size] => 36257
)
)
Actual result:
--
The ";filename=foobar" part is either treated as part of the file path
(in test1.php), so the file is not found, and curl_exec() fails, or it
is treated as part of the 'type' (in test2.php), so incorrect
information is sent.
In either case, PHP currently does not look for the 'filename' parameter
as it does for the 'type' parameter, and handles it incorrectly. The fix
should be made to the "case CURLOPT_POSTFIELDS:" code in
ext/curl/interface.c, similar to how 'type' is already handled there.
This report applies to PHP 5.2.10 and PHP 5.3.0.
--
Edit bug report at http://bugs.php.net/?id=48962&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48962&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48962&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48962&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48962&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48962&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48962&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48962&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48962&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48962&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48962&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48962&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48962&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48962&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48962&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48962&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48962&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48962&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48962&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48962&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48962&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48962&r=mysqlcfg
#48959 [Opn->Asn]: is_readable() and filezise() do not return correctly
ID: 48959
Updated by: fel...@php.net
Reported By: trutas dot ctx at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: Filesystem function related
Operating System: win32 - Windows Server 2003 x64
PHP Version: 5.3.0
Assigned To: pajoye
Previous Comments:
[2009-07-17 16:09:18] trutas dot ctx at gmail dot com
The environment could be the problem here,
I'm using Windows 2003 x64 with PHP x64 via fastcgi.
These are two IIS Servers with load balancer and a separate cluster
that serves the actual run files.
PHP is installed on D:\PHP on each IIS machine.
The problem came up using the library dompdf - it saves document
images content to temporary files in order to build the final pdf
document.
I've reduced the problem to the test code i've attached.
DOMPDF_TEMP_DIR is /tmp and writes to C:\Windows\tmp ...
- Please note that this problem does not happen in local folder to the
execution base (eg. "tmp_sub_folder/" ) - this only happens in the
system tmp folder in this setup.
This is the same setup environment as the one reported in the bug
48852 (about file_put_contents)
Regards,
[2009-07-17 15:34:47] paj...@php.net
Cannot reproduce on 2k8, vista and win7. Pls note that I replaced the
my_file_... with the normal file_get_contents function.
Can you paste a working script pls?
[2009-07-17 15:08:28] trutas dot ctx at gmail dot com
Just tested - file_exists() returns false incorrectly too.
I´ve worked around it all with checking for fopen($file, 'r') and
forcing file_get_contents() - it works, file exists, is readable and
returns the content.
[2009-07-17 12:10:10] trutas dot ctx at gmail dot com
Description:
is_readable() returns false for temporary file (just created)
"C:\WINDOWS\Temp\dom373.tmp" and filezise() fails too.
fopen() and get_file_contents() both work for the same file.
as a workaround i'm using fopen() instead of is_readable() and
fseek($fopen_instance, 0, SEEK_END); instead of filesize()
Reproduce code:
---
//temporary location
$resolved_url = tempnam(DOMPDF_TEMP_DIR, "dompdf_img_");
//get source
$image=my_file_get_contents("http://9tree.net/favicon.ico";);
//save it
file_put_contents($resolved_url, $image);
//tests
if(is_readable($resolved_url)) print "file readable, ";
if(filesize($resolved_url)) print "filezise found.\n";
die("all done.");
Expected result:
file readable, filezise found.
all done.
Actual result:
--
all done.
--
Edit this bug report at http://bugs.php.net/?id=48959&edit=1
#48963 [NEW]: Unexpected results when converting from Gregorian Date to Julian Day and back
From: satovey at yahoo dot com Operating system: Windows XP Sp3 Xamp Apache PHP version: 5.2.10 PHP Bug Type: *Calendar problems Bug description: Unexpected results when converting from Gregorian Date to Julian Day and back Description: When converting Gregorian date to Julian day and then back to the Gregorian date, unexpected results can occur if the year being two digits such as (26) is entered as a four digit (0026). This produces a four year difference of 1461 days. The quick solution to this is to enter four digit years such as 0026 as a literal '0026'. Reproduce code: --- $month=3; $day=18; $year=26; $gregToJd=gregoriantojd($month,$day,$year); $gregDateFromJd=JdToGregorian($gregToJd); echo "month: $month, day: $day, year: $year "; echo "JulianDay from gregorian date: $gregToJd "; echo "GregorianDate from julian day: $gregDateFromJd "; $month=3; $day=18; $year=0026; $gregToJd=gregoriantojd($month,$day,$year); $gregDateFromJd=JdToGregorian($gregToJd); echo "month: $month, day: $day, year: $year "; echo "JulianDay from gregorian date: $gregToJd "; echo "GregorianDate from julian day: $gregDateFromJd "; $month=3; $day=18; $year='0026'; $gregToJd=gregoriantojd($month,$day,$year); $gregDateFromJd=JdToGregorian($gregToJd); echo "month: $month, day: $day, year: $year "; echo "JulianDay from gregorian date: $gregToJd "; echo "GregorianDate from julian day: $gregDateFromJd "; Expected result: One would expect the following output from the code: month: 3, day: 18, year: 26 JulianDay from gregorian date: 1730633 GregorianDate from julian day: 3/18/26 month: 3, day: 18, year: 22 JulianDay from gregorian date: 1730633 GregorianDate from julian day: 3/18/26 month: 3, day: 18, year: 0026 JulianDay from gregorian date: 1730633 GregorianDate from julian day: 3/18/26 Actual result: -- The actual output of the code is as follows: month: 3, day: 18, year: 26 JulianDay from gregorian date: 1730633 GregorianDate from julian day: 3/18/26 month: 3, day: 18, year: 22 JulianDay from gregorian date: 1729172 GregorianDate from julian day: 3/18/22 month: 3, day: 18, year: 0026 JulianDay from gregorian date: 1730633 GregorianDate from julian day: 3/18/26 -- Edit bug report at http://bugs.php.net/?id=48963&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48963&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48963&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48963&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48963&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48963&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48963&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48963&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48963&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48963&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48963&r=support Expected behavior: http://bugs.php.net/fix.php?id=48963&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48963&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48963&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48963&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48963&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48963&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48963&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48963&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48963&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48963&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48963&r=mysqlcfg
#48963 [Opn->Bgs]: Unexpected results when converting from Gregorian Date to Julian Day and back
ID: 48963 Updated by: j...@php.net Reported By: satovey at yahoo dot com -Status: Open +Status: Bogus Bug Type: Date/time related Operating System: Windows XP Sp3 Xamp Apache PHP Version: 5.2.10 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 $ php -r '$i = 0026; var_dump($i);' int(22) Previous Comments: [2009-07-17 17:26:47] satovey at yahoo dot com Description: When converting Gregorian date to Julian day and then back to the Gregorian date, unexpected results can occur if the year being two digits such as (26) is entered as a four digit (0026). This produces a four year difference of 1461 days. The quick solution to this is to enter four digit years such as 0026 as a literal '0026'. Reproduce code: --- $month=3; $day=18; $year=26; $gregToJd=gregoriantojd($month,$day,$year); $gregDateFromJd=JdToGregorian($gregToJd); echo "month: $month, day: $day, year: $year "; echo "JulianDay from gregorian date: $gregToJd "; echo "GregorianDate from julian day: $gregDateFromJd "; $month=3; $day=18; $year=0026; $gregToJd=gregoriantojd($month,$day,$year); $gregDateFromJd=JdToGregorian($gregToJd); echo "month: $month, day: $day, year: $year "; echo "JulianDay from gregorian date: $gregToJd "; echo "GregorianDate from julian day: $gregDateFromJd "; $month=3; $day=18; $year='0026'; $gregToJd=gregoriantojd($month,$day,$year); $gregDateFromJd=JdToGregorian($gregToJd); echo "month: $month, day: $day, year: $year "; echo "JulianDay from gregorian date: $gregToJd "; echo "GregorianDate from julian day: $gregDateFromJd "; Expected result: One would expect the following output from the code: month: 3, day: 18, year: 26 JulianDay from gregorian date: 1730633 GregorianDate from julian day: 3/18/26 month: 3, day: 18, year: 22 JulianDay from gregorian date: 1730633 GregorianDate from julian day: 3/18/26 month: 3, day: 18, year: 0026 JulianDay from gregorian date: 1730633 GregorianDate from julian day: 3/18/26 Actual result: -- The actual output of the code is as follows: month: 3, day: 18, year: 26 JulianDay from gregorian date: 1730633 GregorianDate from julian day: 3/18/26 month: 3, day: 18, year: 22 JulianDay from gregorian date: 1729172 GregorianDate from julian day: 3/18/22 month: 3, day: 18, year: 0026 JulianDay from gregorian date: 1730633 GregorianDate from julian day: 3/18/26 -- Edit this bug report at http://bugs.php.net/?id=48963&edit=1
#48634 [Opn->Fbk]: Calling ob_get_flush() inside an output handler causes crashes
ID: 48634 Updated by: j...@php.net Reported By: gwy...@php.net -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Darwin9 (MacOS X 10.5) PHP Version: 5.3CVS-2009-06-22 (CVS) New Comment: Does this happen with PHP_5_2 and/or HEAD? (if so, update the version properly) Previous Comments: [2009-06-22 00:34:03] gwy...@php.net Description: The subject kind of says most of it. Under both GDB and Valgrind, PHP enters a massive recursion until it finally crashes by overrunning the stack, which is expected, according to a comment in a test that a fix needs to be backported from HEAD. So this bug is mostly about "please backport this fix", I suppose. Reproduce code: --- See tests/output/ob_11.phpt Expected result: A fatal error saying "you can't do that". Actual result: -- Endless recursion. -- Edit this bug report at http://bugs.php.net/?id=48634&edit=1
#48633 [Opn->Fbk]: str_pad() with giant lenth value and no memory limit infinite-loops or crashes
ID: 48633 Updated by: j...@php.net Reported By: gwy...@php.net -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Darwin9 (MacOS X 10.5) PHP Version: 5.3CVS-2009-06-22 (CVS) New Comment: Does this happen with PHP_5_2 and/or HEAD? (if so, update the version properly) Previous Comments: [2009-06-22 00:09:12] gwy...@php.net Description: Calling str_pad($anything, PHP_INT_MAX) causes one of four symptoms: 1) If memory_limit is set below 2GB, a fatal error is thrown saying the memory limit is exhausted with an attempt to allocate 2GB. This appears to be the expected result. 2) If memory_limit is set above 2GB, or is unset, PHP (in or out of GDB) enters a massive CPU-eating swap-file-smashing loop. 3) If PHP is being run under valgrind, PHP exits quickly with a memory allocation failure because valgrind's malloc() replacement refuses the "nonsense" allocation request. 4) If PHP is being run under valgrind *and* run-tests.php, PHP crashes with a NULL pointer reference. This is caused by two problems in the str_pad code: 1) The value of num_pad_chars is not bounds-checked in ext/standard/string.c:4830 2) The return value of emalloc() is not checked for NULL on the same line. Reproduce code: --- 1) $ sapi/cli/php ext/standard/tests/string/str_pad_variation5.phpt 2) $ sapi/cli/php -dmemory_limit=1 ext/standard/tests/string/str_pad_variation5.phpt 3) $ valgrind sapi/cli/php -dmemory_limit=1 ext/standard/tests/string/str_pad_variation5.phpt 4) $ PHP_TEST_EXECUTABLE=`pwd`/sapi/cli/php sapi/cli/php run-tests.php -m ext/standard/tests/string/str_pad_variation5.phpt Expected result: In all cases, str_pad() should recognize that its argument is ridiculous and return without trying to make the allocation. Actual result: -- 1) *** Testing str_pad() function: with large value for for 'pad_length' argument *** Fatal error: Allowed memory size of 134217728 bytes exhausted at ext/standard/string.c:4830 (tried to allocate 2147483648 bytes) in ext/standard/tests/strings/str_pad_variation5.phpt on line 25 2) PHP starts running at 100% CPU and eating huge amounts of swap space. 3) *** Testing str_pad() function: with large value for for 'pad_length' argument *** ==31081== Warning: silly arg (-2147221504) to malloc() Fatal error: Out of memory (allocated 524288) at ext/standard/string.c:4830 (tried to allocate 2147483648 bytes) in ext/standard/tests/strings/str_pad_variation5.phpt on line 25 4) ==31145== Warning: silly arg (-2147483648) to malloc() ==31145== Invalid write of size 1 ==31145==at 0x823B13: memcpy (mc_replace_strmem.c:482) ==31145==by 0x2B3F92: zif_str_pad (string.c:4855) ==31145==by 0x3E2D98: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:313) ==31145==by 0x3E9151: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1601) ==31145==by 0x3E1B59: execute (zend_vm_execute.h:104) ==31145==by 0x3AE947: zend_execute_scripts (zend.c:1188) ==31145==by 0x31E6CC: php_execute_script (main.c:2196) ==31145==by 0x499E5F: main (php_cli.c:1188) ==31145== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==31145== ==31145== Process terminating with default action of signal 10 (SIGBUS) ==31145== Non-existent physical address at address 0x0 ==31145==at 0x823B13: memcpy (mc_replace_strmem.c:482) ==31145==by 0x2B3F92: zif_str_pad (string.c:4855) ==31145==by 0x3E2D98: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:313) ==31145==by 0x3E9151: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1601) ==31145==by 0x3E1B59: execute (zend_vm_execute.h:104) ==31145==by 0x3AE947: zend_execute_scripts (zend.c:1188) ==31145==by 0x31E6CC: php_execute_script (main.c:2196) ==31145==by 0x499E5F: main (php_cli.c:1188) -- Edit this bug report at http://bugs.php.net/?id=48633&edit=1
#48964 [NEW]: GMP not included in VC6 build of PHP 5.3.0
From: miquelfire at gmail dot com Operating system: Windows PHP version: 5.3.0 PHP Bug Type: GNU MP related Bug description: GMP not included in VC6 build of PHP 5.3.0 Description: The Windows binary for PHP 5.3.0 VC6 (both ts and nts) do not include the php_gmp.dll file. I have apps that require GMP but the Apache on the machines using them are the Apache.org provided version. I also don't see a VC6 build for 5.3.1 either so I can't check to see if it will show there. (Do have some 2.0 servers) -- Edit bug report at http://bugs.php.net/?id=48964&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48964&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48964&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48964&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48964&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48964&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48964&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48964&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48964&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48964&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48964&r=support Expected behavior: http://bugs.php.net/fix.php?id=48964&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48964&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48964&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48964&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48964&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48964&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48964&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48964&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48964&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48964&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48964&r=mysqlcfg
#48872 [Ana]: string.c: errors: duplicate case values
ID: 48872 Updated by: ka...@php.net Reported By: nospam at hjcms dot de Status: Analyzed Bug Type: Compile Failure Operating System: Linux PHP Version: 5.3.0 New Comment: I guess something in the way of this should do: Index: string.c === --- string.c(revision 284196) +++ string.c(working copy) @@ -587,14 +587,12 @@ #endif #ifdef DECIMAL_POINT case DECIMAL_POINT: -#endif -#ifdef RADIXCHAR +#elif defined(RADIXCHAR) case RADIXCHAR: #endif #ifdef THOUSANDS_SEP case THOUSANDS_SEP: -#endif -#ifdef THOUSEP +#elif defined(THOUSEP) case THOUSEP: #endif #ifdef GROUPING Previous Comments: [2009-07-10 18:45:42] j...@php.net >From http://www.gnu.org/s/libc/manual/html_node/The-Elegant-and-Fast- Way.html: " DECIMAL_POINT RADIXCHAR The same as the value returned by localeconv in the decimal_point element of the struct lconv. The name RADIXCHAR is a deprecated alias still used in Unix98. THOUSANDS_SEP THOUSEP The same as the value returned by localeconv in the thousands_sep element of the struct lconv. The name THOUSEP is a deprecated alias still used in Unix98. " For some reason these aren't handled with #ifdef's in the code.. [2009-07-09 15:32:20] nospam at hjcms dot de Description: -c /usr/src/packages/BUILD/php-5.3.0/ext/standard/string.c -o ext/standard/string.lo /usr/src/packages/BUILD/php-5.3.0/ext/standard/string.c: In function 'zif_nl_langinfo': /usr/src/packages/BUILD/php-5.3.0/ext/standard/string.c:592: error: duplicate case value /usr/src/packages/BUILD/php-5.3.0/ext/standard/string.c:589: error: previously used here /usr/src/packages/BUILD/php-5.3.0/ext/standard/string.c:598: error: duplicate case value /usr/src/packages/BUILD/php-5.3.0/ext/standard/string.c:595: error: previously used here gmake: *** [ext/standard/string.lo] Fehler 1 Reproduce code: --- #ifdef DECIMAL_POINT case DECIMAL_POINT: #endif #ifdef RADIXCHAR case RADIXCHAR: #endif #ifdef THOUSANDS_SEP case THOUSANDS_SEP: #endif #ifdef THOUSEP case THOUSEP: #endif Expected result: case mismatch with glibc 2.10.1 rpm -qf /usr/include/langinfo.h glibc-devel-2.10.1-2009154 Actual result: -- grep --color=auto -e DECIMAL_POINT -e RADIXCHAR -e THOUSANDS_SEP -e THOUSEP /usr/include/langinfo.h __MON_DECIMAL_POINT, # define MON_DECIMAL_POINT __MON_DECIMAL_POINT __MON_THOUSANDS_SEP, # define MON_THOUSANDS_SEP __MON_THOUSANDS_SEP _NL_MONETARY_DECIMAL_POINT_WC, _NL_MONETARY_THOUSANDS_SEP_WC, __DECIMAL_POINT = _NL_ITEM (__LC_NUMERIC, 0), # define DECIMAL_POINT __DECIMAL_POINT RADIXCHAR = __DECIMAL_POINT, #define RADIXCHAR RADIXCHAR __THOUSANDS_SEP, # define THOUSANDS_SEP __THOUSANDS_SEP THOUSEP = __THOUSANDS_SEP, #define THOUSEP THOUSEP _NL_NUMERIC_DECIMAL_POINT_WC, _NL_NUMERIC_THOUSANDS_SEP_WC, -- Edit this bug report at http://bugs.php.net/?id=48872&edit=1
#48804 [Opn->Bgs]: Overriding results in declaration error
ID: 48804
Updated by: fel...@php.net
Reported By: christian dot achatz at adventure-php-framework
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: CentOS 5.3 (final)
PHP Version: 5.3.0
New Comment:
This error is due the default value required for the param., not
because the variable name.
Previous Comments:
[2009-07-05 15:49:34] christian dot achatz at adventure-php-framework
Description:
As of PHP 5.3.0 my custom class (PageControllerInputFilter) is not
compiling any more. Reason for this is:
Declaration of PageControllerInputFilter::filter() should be compatible
with that of AbstractFilter::filter().
Rewriting the filter() function to signature
"filter($filterInstruction,$input = null)" would solve the problem, but
this is no implementation of the filter() method (e.g. interface
behaviour) on PageControllerInputFilter, but overriding. Hence, the name
of the variables must not be spellt equally. Even in JAVA, you can
freely choose your variable names when overriding a method from a
super-class.
Tests were executed using PHP compiled from source on my centos machine
using
[r...@centos53 ~]# md5sum /root/php53-source/php-5.3.0.tar.bz2
846760cd655c98dfd86d6d97c3d964b0 /root/php53-source/php-5.3.0.tar.bz2
[r...@centos53 ~]# ./configure --with-apxs2=$(which apxs)
--prefix=/root/php53/ --with-zlib --without-pear
[r...@centos53 ~]# make
[r...@centos53 ~]# make install
Reproduce code:
---
abstract class AbstractFilter extends coreObject {
function AbstractFilter(){
}
function filter($filterInstruction,$input = null){
return $input;
}
}
class PageControllerInputFilter extends AbstractFilter {
function PageControllerInputFilter(){
}
function filter($instruction,$content){
return $content;
}
}
Definition of the class coreObject can be seen here:
http://adventurephpfra.svn.sourceforge.net/viewvc/adventurephpfra/branches/php5/1.10/core/pagecontroller/pagecontroller.php?revision=573&view=markup
Expected result:
No fatal, no declaration warning.
Actual result:
--
Declaration of PageControllerInputFilter::filter() should be compatible
with that of AbstractFilter::filter().
Fatal error: Class 'PageControllerInputFilter' not found in
/var/www/html/php53/apps/core/filter/PageControllerInputFilter.php on
line 82.
Package to test this behaviour can be found here:
http://media.adventure-php-framework.org/php53/adventure-demopack-1.10-RC1-2009-07-05-1404-php5.tar.gz.
Just extract into document root and call via browser.
--
Edit this bug report at http://bugs.php.net/?id=48804&edit=1
#48633 [Fbk->Opn]: str_pad() with giant lenth value and no memory limit infinite-loops or crashes
ID: 48633 Updated by: gwy...@php.net Reported By: gwy...@php.net -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Darwin9 (MacOS X 10.5) -PHP Version: 5.3CVS-2009-06-22 (CVS) +PHP Version: 5.2SVN 5.3SVN HEAD SVN New Comment: Yes, it happens in all three branches. Previous Comments: [2009-07-17 17:40:29] j...@php.net Does this happen with PHP_5_2 and/or HEAD? (if so, update the version properly) [2009-06-22 00:09:12] gwy...@php.net Description: Calling str_pad($anything, PHP_INT_MAX) causes one of four symptoms: 1) If memory_limit is set below 2GB, a fatal error is thrown saying the memory limit is exhausted with an attempt to allocate 2GB. This appears to be the expected result. 2) If memory_limit is set above 2GB, or is unset, PHP (in or out of GDB) enters a massive CPU-eating swap-file-smashing loop. 3) If PHP is being run under valgrind, PHP exits quickly with a memory allocation failure because valgrind's malloc() replacement refuses the "nonsense" allocation request. 4) If PHP is being run under valgrind *and* run-tests.php, PHP crashes with a NULL pointer reference. This is caused by two problems in the str_pad code: 1) The value of num_pad_chars is not bounds-checked in ext/standard/string.c:4830 2) The return value of emalloc() is not checked for NULL on the same line. Reproduce code: --- 1) $ sapi/cli/php ext/standard/tests/string/str_pad_variation5.phpt 2) $ sapi/cli/php -dmemory_limit=1 ext/standard/tests/string/str_pad_variation5.phpt 3) $ valgrind sapi/cli/php -dmemory_limit=1 ext/standard/tests/string/str_pad_variation5.phpt 4) $ PHP_TEST_EXECUTABLE=`pwd`/sapi/cli/php sapi/cli/php run-tests.php -m ext/standard/tests/string/str_pad_variation5.phpt Expected result: In all cases, str_pad() should recognize that its argument is ridiculous and return without trying to make the allocation. Actual result: -- 1) *** Testing str_pad() function: with large value for for 'pad_length' argument *** Fatal error: Allowed memory size of 134217728 bytes exhausted at ext/standard/string.c:4830 (tried to allocate 2147483648 bytes) in ext/standard/tests/strings/str_pad_variation5.phpt on line 25 2) PHP starts running at 100% CPU and eating huge amounts of swap space. 3) *** Testing str_pad() function: with large value for for 'pad_length' argument *** ==31081== Warning: silly arg (-2147221504) to malloc() Fatal error: Out of memory (allocated 524288) at ext/standard/string.c:4830 (tried to allocate 2147483648 bytes) in ext/standard/tests/strings/str_pad_variation5.phpt on line 25 4) ==31145== Warning: silly arg (-2147483648) to malloc() ==31145== Invalid write of size 1 ==31145==at 0x823B13: memcpy (mc_replace_strmem.c:482) ==31145==by 0x2B3F92: zif_str_pad (string.c:4855) ==31145==by 0x3E2D98: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:313) ==31145==by 0x3E9151: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1601) ==31145==by 0x3E1B59: execute (zend_vm_execute.h:104) ==31145==by 0x3AE947: zend_execute_scripts (zend.c:1188) ==31145==by 0x31E6CC: php_execute_script (main.c:2196) ==31145==by 0x499E5F: main (php_cli.c:1188) ==31145== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==31145== ==31145== Process terminating with default action of signal 10 (SIGBUS) ==31145== Non-existent physical address at address 0x0 ==31145==at 0x823B13: memcpy (mc_replace_strmem.c:482) ==31145==by 0x2B3F92: zif_str_pad (string.c:4855) ==31145==by 0x3E2D98: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:313) ==31145==by 0x3E9151: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1601) ==31145==by 0x3E1B59: execute (zend_vm_execute.h:104) ==31145==by 0x3AE947: zend_execute_scripts (zend.c:1188) ==31145==by 0x31E6CC: php_execute_script (main.c:2196) ==31145==by 0x499E5F: main (php_cli.c:1188) -- Edit this bug report at http://bugs.php.net/?id=48633&edit=1
#48634 [Fbk->Opn]: Calling ob_get_flush() inside an output handler causes crashes
ID: 48634 Updated by: gwy...@php.net Reported By: gwy...@php.net -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Darwin9 (MacOS X 10.5) -PHP Version: 5.3CVS-2009-06-22 (CVS) +PHP Version: 5.2SVN, 5.3SVN, HEAD SVN New Comment: Yes, it happens in all three branches. Previous Comments: [2009-07-17 17:40:04] j...@php.net Does this happen with PHP_5_2 and/or HEAD? (if so, update the version properly) [2009-06-22 00:34:03] gwy...@php.net Description: The subject kind of says most of it. Under both GDB and Valgrind, PHP enters a massive recursion until it finally crashes by overrunning the stack, which is expected, according to a comment in a test that a fix needs to be backported from HEAD. So this bug is mostly about "please backport this fix", I suppose. Reproduce code: --- See tests/output/ob_11.phpt Expected result: A fatal error saying "you can't do that". Actual result: -- Endless recursion. -- Edit this bug report at http://bugs.php.net/?id=48634&edit=1
