#27780 [Bgs]: strtotime(+1 xxx) returns 1 more hours
ID: 27780
User updated by: Hua dot Qu at volvo dot com
Reported By: Hua dot Qu at volvo dot com
Status: Bogus
Bug Type: Date/time related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Thank you for quickly reply.
I still consider it as a bug. If I set
$to = 2004-03-28 00:00:00
$march0 = strftime("%Y-%m-%d %H:%M:%S", strtotime("$to"));
$march1 = strftime("%Y-%m-%d %H:%M:%S", strtotime("$to +1 second"));
$march2 = strftime("%Y-%m-%d %H:%M:%S", strtotime("$to +1 day "));
$march1 gives the correct result, while $march2 gives the wrong result.
Because during the midnight of 28th it changed from the wintertime to
the summertime for daylight saving.
As you pointed out, to add a timezone:
$to = "2004-03-28 00:00:00 WET";
$march0 = strftime("%Y-%m-%d %H:%M:%S", strtotime("$to"));
$march1 = strftime("%Y-%m-%d %H:%M:%S", strtotime("$to +1 seconds "));
$march2 = strftime("%Y-%m-%d %H:%M:%S", strtotime("$to +1 day "));
Relative to $march0, $march1 gives the correct output, but these two
outputs are not what I expected. $march2 is still totally wrong no
matter reference to which dates.
The point is, I think, PHP checks the output result with for daylight
saving, but not the original input date.
Regards,
Hua Qu
Previous Comments:
[2004-03-30 12:12:55] [EMAIL PROTECTED]
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
You need to add timezone information to the original date.
For example change your text time to "2004-06-01 00:00:00
EST".
The end result will be that strtotime($to) will be 1
smaller then strtotime("$to +1 seconds "), which is the
correct output.
[2004-03-30 10:52:02] Hua dot Qu at volvo dot com
Description:
strtotime($tm + 1 xxx) always adds one more hour to the result, if the
result-time is in the summertime, no matter $tm is in the summertime or
not.
It is the same in PHP CVS (5.0.x-dev) Built On: Mar 30, 2004 14:30 GMT
I think it is the daylight-savings-time problem. Perhaps, $tm is not
checked if it is already in the daylight-savings-time.
There are already some similar reports, but they did not get the point,
and the bug has not been corrected untill Mar 30, 2004 14:30 GMT.
Reproduce code:
---
echo "I have get one hour too much!";
$to = "2004-06-01 00:00:00";
echo strtotime($to)."\n";
echo strtotime("$to +1 seconds ")."\n";
$newtime1 = strftime("%Y-%m-%d %H:%M:%S", strtotime("$to +1 seconds
"));
$newtime2 = strftime("%Y-%m-%d %H:%M:%S", strtotime("$to +1 day "));
echo "$to \n";
echo "+1 s= $newtime1\n";
echo "+1day=$newtime2\n";
$correct = strftime("%Y-%m-%d %H:%M:%S", strtotime("$to +1 second -1
hour"));
echo "correct: +1 s=$correct";
Expected result:
If $tm is the summertime, strtotime($tm +1 day) should return 24 hours
more, not 25 hours more.
If $tm is the wintertime and result is in the summertime, it should
return one extra hour.
--
Edit this bug report at http://bugs.php.net/?id=27780&edit=1
#27696 [Opn->Fbk]: ORA-24327 error
ID: 27696
Updated by: [EMAIL PROTECTED]
Reported By: gioppo at csi dot it
-Status: Open
+Status: Feedback
Bug Type: OCI8 related
Operating System: System Linux 2.2.19-6.2.1
PHP Version: Irrelevant
Assigned To: tony2001
New Comment:
I can't reproduce it neither with PHP4, nor with PHP5.
Have you tried latest versions?
Previous Comments:
[2004-03-31 01:22:48] gioppo at csi dot it
Well I think that I've found a workaround.
To test it you can take the code from:
http://php.weblogs.com/adodb
and try a simple connection.
In any case you can try to see what happens if someone compile the
php+OCI using a symbolic link for oracle_home and than uses an absolute
oracle_home.
There could be a bug.
[2004-03-30 10:03:27] [EMAIL PROTECTED]
So, you've solved it, yes?
This piece of code didn't help me much, just because I can't test it.
[2004-03-30 09:05:14] gioppo at csi dot it
We probably solved the problem bypassing tnsnames.ora.
We made the connection using tnsnames defined alias and it got errors
sometime.
Here is a chunk of php code (we used method b which gave errors
sometime, when we used d mode we always manage to make connection) any
hint? A problem on finding tnsnames?
NOTE OCILogon is a php library function so no hint on how to modify it,
but the behaviour meke me think about an environment problem:
we have a
Compile-time ORACLE_HOME /oracle_home for compiling OCI for php
but
ORACLE_HOME /oracle817/app/oracle/product/8.1.7
_ENV["ORACLE_HOME"] /oracle817/app/oracle/product/8.1.7
on env for apache and php (/oracle_home is a symbolic link to the
/oracle817/app/oracle/product/8.1.7 folder) could be that the OCI8 so
compiled have trouble on traversing the link?
/*
Multiple modes of connection are supported:
a. Local Database
$conn->Connect(false,'scott','tiger');
b. From tnsnames.ora
$conn->Connect(false,'scott','tiger',$tnsname);
$conn->Connect($tnsname,'scott','tiger');
c. Server + service name
$conn->Connect($serveraddress,'scott,'tiger',$service_name);
d. Server + SID
$conn->connectSID = true;
$conn->Connect($serveraddress,'scott,'tiger',$SID);
Example TNSName:
---
NATSOFT.DOMAIN =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = kermit)(PORT = 1523))
)
(CONNECT_DATA =
(SERVICE_NAME = natsoft.domain)
)
)
There are 3 connection modes, 0 = non-persistent, 1 = persistent, 2 =
force new connection
*/
function _connect($argHostname, $argUsername, $argPassword,
$argDatabasename,$mode=0)
{
$this->_errorMsg = false;
$this->_errorCode = false;
if($argHostname) { // added by Jorma Tuomainen
<[EMAIL PROTECTED]>
if (empty($argDatabasename)) $argDatabasename = $argHostname;
else {
if(strpos($argHostname,":")) {
$argHostinfo=explode(":",$argHostname);
$argHostname=$argHostinfo[0];
$argHostport=$argHostinfo[1];
} else {
$argHostport="1521";
}
if ($this->connectSID) {
$argDatabasename="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=".$argHostname
.")(PORT=$argHostport))(CONNECT_DATA=(SID=$argDatabasename)))";
} else
$argDatabasename="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=".$argHostname
.")(PORT=$argHostport))(CONNECT_DATA=(SERVICE_NAME=$argDatabasename)))";
}
}
if ($mode==1) {
$this->_connectionID = OCIPLogon($argUsername,$argPassword,
$argDatabasename);
if ($this->_connectionID && $this->autoRollback)
OCIrollback($this->_connectionID);
} else if ($mode==2) {
$this->_connectionID = OCINLogon($argUsername,$argPassword,
$argDatabasename);
} else {
$this->_connectionID = OCILogon($argUsername,$argPassword,
$argDatabasename);
}
if ($this->_connectionID === false) return false;
[2004-03-26 05:00:13] [EMAIL PROTECTED]
Please, try latest stable PHP release.
And try latest PHP5 snapshot, there are
#21802 [Com]: unexpected T_WHITESPACE
ID: 21802 Comment by: monk at farpost dot com Reported By: gmourani at openna dot com Status: No Feedback Bug Type: Compile Failure Operating System: OpenNA Linux PHP Version: 4.3.0 New Comment: Some error with php-4.3.5 and bison-1.875 Fixed by installing bison-1.35 Previous Comments: [2003-07-10 04:26:05] [EMAIL PROTECTED] Re-classified to the proper category [2003-07-10 02:07:52] 5689103753 at ma-scha dot de I get the same bug with bison 1.875. I installed bison 1.28 and all works fine again. Try to look at the first lines of output from the configure script it shows you what version it needs, but it doesn't stop on a wrong version. [2003-04-03 01:02:34] thomas dot lamy at in-online dot net Seems like this bug is introduced when re-building Zend/zend_language_scanner.c with flex. Try to build again from fresh source, and with proper date/time on the build host. [2003-03-30 02:08:56] thomas dot lamy at in-online dot net Same problem here, with debian/sarge and php-4.3.1. I really don't have a clue, but suspect sablotron or expat to cause this. I use ablotron (0.9.7) and expat (1.95.6), and the debian-scripts from the deb package maintainer. configure: --enable-memory-limit \ --enable-calendar \ --enable-sysvsem \ --enable-sysvshm \ --enable-track-vars \ --enable-trans-sid \ --enable-bcmath \ --with-bz2 \ --enable-ctype \ --with-db2 \ --with-iconv \ --with-gdbm \ --enable-exif \ --enable-filepro \ --enable-ftp \ --with-gettext \ --enable-mbstring \ --with-pcre-regex=/usr \ --enable-shmop \ --enable-sockets \ --enable-wddx \ --with-xml=/usr --with-expat-dir=/usr \ --enable-yp \ --with-zlib \ --without-pgsql [2003-03-19 16:48:16] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. 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/21802 -- Edit this bug report at http://bugs.php.net/?id=21802&edit=1
#27697 [Opn->Csd]: errors compiling parsedate.y
ID: 27697 Updated by: [EMAIL PROTECTED] Reported By: wzaccone at optonline dot net -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.4 New Comment: Closing then. Previous Comments: [2004-03-30 20:39:57] wzaccone at optonline dot net I successfully compiled php with the latest snapshot.. thank you. [2004-03-25 14:37:31] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-03-25 10:55:23] wzaccone at optonline dot net Description: I successfully built php 4.3.3 on a Solaris 8 system with gcc (GCC) 3.2.2 bison 1.28 flex 2.5.4 However when we tried to build on another system with same configuration, and bison -y parsedate.y failed. Can anyone point me in the right direction as to why this error occurs. Thank You. Warren Reproduce code: --- /bin/sh /FREE_2.4/NMA_WEB/NMA.r140/03-25-2004/install_apache_php/php-4.3.3/libto ol --silent --preserve-dup-deps --mode=compile gcc -Iext/standard/ -I/FREE_2.4/ NMA_WEB/NMA.r140/03-25-2004/install_apache_php/php-4.3.3/ext/standard/ -DPHP_ATO M_INC -I/FREE_2.4/NMA_WEB/NMA.r140/03-25-2004/install_apache_php/php-4.3.3/inclu de -I/FREE_2.4/NMA_WEB/NMA.r140/03-25-2004/install_apache_php/php-4.3.3/main -I/ FREE_2.4/NMA_WEB/NMA.r140/03-25-2004/install_apache_php/php-4.3.3 -I/FREE_2.4/NM A_WEB/NMA.r140/03-25-2004/install_apache_php/php-4.3.3/Zend -I/FREE_2.4/NMA_WEB/ NMA.r140/03-25-2004/install_apache_php/php-4.3.3/ext/xml/expat -D_POSIX_PTHREAD _SEMANTICS -I/FREE_2.4/NMA_WEB/NMA.r140/03-25-2004/install_apache_php/php-4.3.3/ TSRM -g -O2 -prefer-pic -c /FREE_2.4/NMA_WEB/NMA.r140/03-25-2004/install_apach e_php/php-4.3.3/ext/standard/parsedate.c -o ext/standard/parsedate.lo /usr/local/share/bison.simple: In function `php_gd_parse': /usr/local/share/bison.simple:219: number of arguments doesn't match prototype /usr/local/share/bison.simple:153: prototype declaration -- Edit this bug report at http://bugs.php.net/?id=27697&edit=1
#27741 [Opn->Fbk]: IIS down while request .php file
ID: 27741 Updated by: [EMAIL PROTECTED] Reported By: yjt at 5kg dot net -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows 2000 Server PHP Version: 4.3.5 New Comment: Remove that extension and try again please. Previous Comments: [2004-03-30 19:07:19] yjt at 5kg dot net only Zend optimizer Optimization Pass 1 enabled Optimization Pass 2 enabled Optimization Pass 3 enabled Optimization Pass 4 enabled Optimization Pass 5 disabled Optimization Pass 9 disabled Optimization Pass 10 disabled Zend Loader enabled License Path no value [2004-03-30 10:35:18] [EMAIL PROTECTED] Do you have any Zend Extensions loaded in PHP.ini ? [2004-03-29 21:51:10] yjt at 5kg dot net problem shows on any script, such as below: [2004-03-29 15:51:14] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-03-29 03:32:26] franz dot winter at gbo dot com The same problem (frustrated sunday). W2K event-log shows "The service could not connect Instance 5...". CGI/Fast CGI mode is running (with the event-log message), ISAPI is not running at all. 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/27741 -- Edit this bug report at http://bugs.php.net/?id=27741&edit=1
#27786 [Opn->Bgs]: "last month" bypass feb.
ID: 27786
Updated by: [EMAIL PROTECTED]
Reported By: zhang_yinshu at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: linux
PHP Version: 5.0.0RC1
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:
[2004-03-30 17:55:17] zhang_yinshu at yahoo dot com
Description:
if call function strtotime("last month") or ("-1 month") at Mar. 30th
2004, it will return 3/1/04. ("-2 month") produce correct output.
Reproduce code:
---
--
Edit this bug report at http://bugs.php.net/?id=27786&edit=1
#27791 [NEW]: PHP5 + Apache2 + Mandrake 10/RC1 Fails
From: manish_dharwadker at yahoo dot com Operating system: Mandrake 10.0 RC1 PHP version: 5.0.0RC1 PHP Bug Type: Compile Failure Bug description: PHP5 + Apache2 + Mandrake 10/RC1 Fails Description: OS: Mandrake 10.0 RC1 Binutils: binutils-2.14.90.0.7-2mdk Make: GNU Make 3.80 AutoConf: 2.13 Apache: Latest 2.0 CVS Pull 3/31 AND 2.0.49 (Stable) PHP5: Latest 5.0 RC1 Build Pull 3/31 (AND php4-stable) OpenSSL: 0.9.7d MySQL: 4.0.48/4.1.1-alpha/5.0-dev (ALL) Error Occurence: With ALL PHP Builds 4 stable AND 5 dev I checked the bug list and could not find one. Basically, the sapi/.../mod_php5.lo fails with various parse errors, etc. in apr.h. Please advise. - Manish. Compiled With: ./configure --prefix=/web --with-apxs2=/web/bin/apxs --enable-shared --enable-debug --enable-safe-mode --enable-sigchild --with-zlib=/usr --enable-memory-limit --with-openssl=/web --with-mysql=/web Reproduce code: --- Standard code ... no modifications Expected result: Fully compiled libphp4/5.so and other binaries Actual result: -- Log: gcc -I/web/include -I/web/include -I/web/include -Isapi/apache2handler/ -I/software/php-5.0.0RC1/sapi/apache2handler/ -DPHP_ATOM_INC -I/software/php-5.0.0RC1/include -I/software/php-5.0.0RC1/main -I/software/php-5.0.0RC1 -I/software/php-5.0.0RC1/Zend -I/usr/local/include/libxml2 -I/web/include -I/web/include/mysql -I/software/php-5.0.0RC1/TSRM -g -Wall -c /software/php-5.0.0RC1/sapi/apache2handler/mod_php5.c -fPIC -DPIC -o sapi/apache2handler/mod_php5.lo In file included from /web/include/ap_config.h:19, from /web/include/httpd.h:29, from /software/php-5.0.0RC1/sapi/apache2handler/php_apache.h:24, from /software/php-5.0.0RC1/sapi/apache2handler/mod_php5.c:26: /web/include/apr.h:262: error: parse error before "apr_off_t" /web/include/apr.h:262: warning: type defaults to `int' in declaration of `apr_off_t' /web/include/apr.h:262: warning: data definition has no type or storage class In file included from /web/include/apr_file_io.h:28, from /web/include/apr_network_io.h:25, from /web/include/httpd.h:38, from /software/php-5.0.0RC1/sapi/apache2handler/php_apache.h:24, from /software/php-5.0.0RC1/sapi/apache2handler/mod_php5.c:26: /web/include/apr_file_info.h:184: error: parse error before "apr_off_t" /web/include/apr_file_info.h:184: warning: no semicolon at end of struct or union /web/include/apr_file_info.h:186: warning: type defaults to `int' in declaration of `csize' /web/include/apr_file_info.h:186: warning: data definition has no type or storage class /web/include/apr_file_info.h:192: error: `ctime' redeclared as different kind of symbol /usr/include/time.h:254: error: previous declaration of `ctime' /web/include/apr_file_info.h:199: error: parse error before '}' token In file included from /web/include/apr_network_io.h:25, from /web/include/httpd.h:38, from /software/php-5.0.0RC1/sapi/apache2handler/php_apache.h:24, from /software/php-5.0.0RC1/sapi/apache2handler/mod_php5.c:26: /web/include/apr_file_io.h:503: error: parse error before "apr_off_t" /web/include/apr_file_io.h:692: error: parse error before "apr_off_t" In file included from /web/include/httpd.h:38, from /software/php-5.0.0RC1/sapi/apache2handler/php_apache.h:24, from /software/php-5.0.0RC1/sapi/apache2handler/mod_php5.c:26: /web/include/apr_network_io.h:535: error: parse error before "apr_off_t" In file included from /web/include/apr_buckets.h:31, from /web/include/httpd.h:39, from /software/php-5.0.0RC1/sapi/apache2handler/php_apache.h:24, from /software/php-5.0.0RC1/sapi/apache2handler/mod_php5.c:26: /web/include/apr_mmap.h:133: error: parse error before "apr_off_t" /web/include/apr_mmap.h:160: error: parse error before "apr_off_t" In file included from /web/include/httpd.h:39, from /software/php-5.0.0RC1/sapi/apache2handler/php_apache.h:24, from /software/php-5.0.0RC1/sapi/apache2handler/mod_php5.c:26: /web/include/apr_buckets.h:241: error: parse error before "apr_off_t" /web/include/apr_buckets.h:241: warning: no semicolon at end of struct or union /web/include/apr_buckets.h:243: error: conflicting types for `data' /software/php-5.0.0RC1/main/php.h:261: error: previous declaration of `data' /web/include/apr_buckets.h:251: error: `free' redeclared as different kind of symbol /usr/include/stdlib.h:569: error: previous declaration of `free' /web/include/apr_buckets.h:254: error: parse error before '}' token /web/include/apr_buckets.h:633: error: field `b' has incomplete t
#27790 [Opn->Bgs]: PHP chmod's totaly wrong
ID: 27790 Updated by: [EMAIL PROTECTED] Reported By: postmaster at rrnet dot se -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: Slackware 9.1 PHP Version: 4.3.4 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php the mode is octel: eg. 0644 - not a string '644' Previous Comments: [2004-03-31 01:31:59] postmaster at rrnet dot se Sorry, forgot to say that it gets everything from an uploadscript, and then sets the right chmod to be able to delete the file later if needed. [2004-03-31 01:29:40] postmaster at rrnet dot se Description: PHP have some strange problem, to set file-permissions on my machine (Slackware 9.1). It sets them totaly wrong. Software is PHP 4.3.4 on Apache 1.3.29. Filesystem is ext3. PHP is NOT in safe_mode. Nothing more specific to report. Reproduce code: --- $file = "/home/dream/public_html/Upic/1/2.jpg"; chmod($file,'0644'); the same result happened with chmod($file,'644'); Expected result: -rw-r--r-- 1 nobody nobody 28739 Mar 31 08:30 2.jpg Actual result: -- --wr-T 1 nobody nobody 28739 Mar 31 08:30 2.jpg -- Edit this bug report at http://bugs.php.net/?id=27790&edit=1
#27790 [Opn]: PHP chmod's totaly wrong
ID: 27790 User updated by: postmaster at rrnet dot se Reported By: postmaster at rrnet dot se Status: Open Bug Type: Filesystem function related Operating System: Slackware 9.1 PHP Version: 4.3.4 New Comment: Sorry, forgot to say that it gets everything from an uploadscript, and then sets the right chmod to be able to delete the file later if needed. Previous Comments: [2004-03-31 01:29:40] postmaster at rrnet dot se Description: PHP have some strange problem, to set file-permissions on my machine (Slackware 9.1). It sets them totaly wrong. Software is PHP 4.3.4 on Apache 1.3.29. Filesystem is ext3. PHP is NOT in safe_mode. Nothing more specific to report. Reproduce code: --- $file = "/home/dream/public_html/Upic/1/2.jpg"; chmod($file,'0644'); the same result happened with chmod($file,'644'); Expected result: -rw-r--r-- 1 nobody nobody 28739 Mar 31 08:30 2.jpg Actual result: -- --wr-T 1 nobody nobody 28739 Mar 31 08:30 2.jpg -- Edit this bug report at http://bugs.php.net/?id=27790&edit=1
#27790 [NEW]: PHP chmod's totaly wrong
From: postmaster at rrnet dot se Operating system: Slackware 9.1 PHP version: 4.3.4 PHP Bug Type: Filesystem function related Bug description: PHP chmod's totaly wrong Description: PHP have some strange problem, to set file-permissions on my machine (Slackware 9.1). It sets them totaly wrong. Software is PHP 4.3.4 on Apache 1.3.29. Filesystem is ext3. PHP is NOT in safe_mode. Nothing more specific to report. Reproduce code: --- $file = "/home/dream/public_html/Upic/1/2.jpg"; chmod($file,'0644'); the same result happened with chmod($file,'644'); Expected result: -rw-r--r-- 1 nobody nobody 28739 Mar 31 08:30 2.jpg Actual result: -- --wr-T 1 nobody nobody 28739 Mar 31 08:30 2.jpg -- Edit bug report at http://bugs.php.net/?id=27790&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27790&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27790&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27790&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27790&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27790&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27790&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27790&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27790&r=support Expected behavior: http://bugs.php.net/fix.php?id=27790&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27790&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27790&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27790&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27790&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27790&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27790&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27790&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27790&r=float
#27696 [Fbk->Opn]: ORA-24327 error
ID: 27696
User updated by: gioppo at csi dot it
Reported By: gioppo at csi dot it
-Status: Feedback
+Status: Open
Bug Type: OCI8 related
Operating System: System Linux 2.2.19-6.2.1
PHP Version: Irrelevant
Assigned To: tony2001
New Comment:
Well I think that I've found a workaround.
To test it you can take the code from:
http://php.weblogs.com/adodb
and try a simple connection.
In any case you can try to see what happens if someone compile the
php+OCI using a symbolic link for oracle_home and than uses an absolute
oracle_home.
There could be a bug.
Previous Comments:
[2004-03-30 10:03:27] [EMAIL PROTECTED]
So, you've solved it, yes?
This piece of code didn't help me much, just because I can't test it.
[2004-03-30 09:05:14] gioppo at csi dot it
We probably solved the problem bypassing tnsnames.ora.
We made the connection using tnsnames defined alias and it got errors
sometime.
Here is a chunk of php code (we used method b which gave errors
sometime, when we used d mode we always manage to make connection) any
hint? A problem on finding tnsnames?
NOTE OCILogon is a php library function so no hint on how to modify it,
but the behaviour meke me think about an environment problem:
we have a
Compile-time ORACLE_HOME /oracle_home for compiling OCI for php
but
ORACLE_HOME /oracle817/app/oracle/product/8.1.7
_ENV["ORACLE_HOME"] /oracle817/app/oracle/product/8.1.7
on env for apache and php (/oracle_home is a symbolic link to the
/oracle817/app/oracle/product/8.1.7 folder) could be that the OCI8 so
compiled have trouble on traversing the link?
/*
Multiple modes of connection are supported:
a. Local Database
$conn->Connect(false,'scott','tiger');
b. From tnsnames.ora
$conn->Connect(false,'scott','tiger',$tnsname);
$conn->Connect($tnsname,'scott','tiger');
c. Server + service name
$conn->Connect($serveraddress,'scott,'tiger',$service_name);
d. Server + SID
$conn->connectSID = true;
$conn->Connect($serveraddress,'scott,'tiger',$SID);
Example TNSName:
---
NATSOFT.DOMAIN =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = kermit)(PORT = 1523))
)
(CONNECT_DATA =
(SERVICE_NAME = natsoft.domain)
)
)
There are 3 connection modes, 0 = non-persistent, 1 = persistent, 2 =
force new connection
*/
function _connect($argHostname, $argUsername, $argPassword,
$argDatabasename,$mode=0)
{
$this->_errorMsg = false;
$this->_errorCode = false;
if($argHostname) { // added by Jorma Tuomainen
<[EMAIL PROTECTED]>
if (empty($argDatabasename)) $argDatabasename = $argHostname;
else {
if(strpos($argHostname,":")) {
$argHostinfo=explode(":",$argHostname);
$argHostname=$argHostinfo[0];
$argHostport=$argHostinfo[1];
} else {
$argHostport="1521";
}
if ($this->connectSID) {
$argDatabasename="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=".$argHostname
.")(PORT=$argHostport))(CONNECT_DATA=(SID=$argDatabasename)))";
} else
$argDatabasename="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=".$argHostname
.")(PORT=$argHostport))(CONNECT_DATA=(SERVICE_NAME=$argDatabasename)))";
}
}
if ($mode==1) {
$this->_connectionID = OCIPLogon($argUsername,$argPassword,
$argDatabasename);
if ($this->_connectionID && $this->autoRollback)
OCIrollback($this->_connectionID);
} else if ($mode==2) {
$this->_connectionID = OCINLogon($argUsername,$argPassword,
$argDatabasename);
} else {
$this->_connectionID = OCILogon($argUsername,$argPassword,
$argDatabasename);
}
if ($this->_connectionID === false) return false;
[2004-03-26 05:00:13] [EMAIL PROTECTED]
Please, try latest stable PHP release.
And try latest PHP5 snapshot, there are a lot of changes since
November.
I have no idea what code ADO uses to connect to Oracle, so please
provide a short example with standard PHP functions, not wrapped with
ADO or other wrapper.
---
#27726 [Com]: iconv, iisfunc and printer extensions are missing
ID: 27726 Comment by: sdteffen at web dot de Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Dynamic loading Operating System: Windows PHP Version: 4.3.5 New Comment: I cannot find php_iconv.dll on the mentioned PECL site or on http://pecl.php.net at all. It also seems to be missing from the PHP 5 RC1 (incl. the PECL package). The ChangeLog should mention that iconv has moved to PECL (or wherever) - this part I consider as a bug. Previous Comments: [2004-03-28 19:36:58] [EMAIL PROTECTED] 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 Those extensions are now part of PECL and can be found inside http://snaps.php.net/win32/PECL_STABLE/ [2004-03-27 01:10:01] [EMAIL PROTECTED] Description: In ZIP package of Windows version 4.3.5 are missing these extensions: php_iconv.dll php_iisfunc.dll php_printer.dll They were in 4.3.4. I can't find anywhere they are deprecated or included in the main dll. -- Edit this bug report at http://bugs.php.net/?id=27726&edit=1
#27735 [Com]: restart of apache2 via kill -1 or apachectl causes crash
ID: 27735 Comment by: josestefan at hotmail dot com Reported By: as at netoholic dot de Status: Bogus Bug Type: Reproducible crash Operating System: Linux PHP Version: 4.3.5 New Comment: sorry, my report is wrong. I forgot that the error occurs after the first php request, when I did my testing. Previous Comments: [2004-03-30 22:59:59] josestefan at hotmail dot com I've noticed that disabling all CustomLog in apache's httpd conf file avoids the crash. So maybe that's a good place for the developers to start looking. I have log_errors = Off on my php.ini file, so it really doesn't make sense to me. But I have confirmed that with the CustomLogs disabled, I get no crashes. running Windows XP, Apache: 2.0.49, PHP: 4.3.5 [2004-03-30 08:50:43] noackjr at alumni dot rice dot edu I have this exact same problem (identical backtrace, etc.) with FreeBSD 5.2.1, Apache 2.0.49, and PHP 4.3.5. Reverting to the PCRE from 4.3.4 (replacing ext/pcre) also resolved the problem for me. Does PCRE 4.5 expose an Apache bug, or is this a problem with PCRE 4.5? If it's the former, leave it as Bogus. Otherwise, this is a PHP bug because it's bundled code. [2004-03-30 06:57:35] chb at muc dot de I don't think this bug is "Bogus". I'm experiencing the same problems using Apache 2.0.49 with RedHat Linux 8.0 (same backtrace, ...). So far I've been able to track it down to the PCRE extension. When I add "--without-pcre" everything is fine. I've now replaced "ext/pcre", using the version from PHP 4.3.4 (PCRE 4.3) and the problem is gone. My suspicion is that the new PCRE version has memory allocation problems. [2004-03-29 10:45:53] [EMAIL PROTECTED] read above comment. [2004-03-29 10:45:38] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. The backtrace shows the crash to reside deep inside AP2 code and not in PHP, hence this is not a PHP bug. 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/27735 -- Edit this bug report at http://bugs.php.net/?id=27735&edit=1
#27751 [Com]: Apache2 2.0.49 crash when restarting (PHP4.3.5 only, works fine in 4.3.4)
ID: 27751 Comment by: josestefan at hotmail dot com Reported By: packager at rabbito dot org Status: Bogus Bug Type: Apache2 related Operating System: Windows XP PHP Version: 4.3.5 New Comment: sorry, my report is wrong. I forgot that the error occurs after the first php request, when I did my testing. Previous Comments: [2004-03-30 22:45:49] josestefan at hotmail dot com I've noticed that disabling all CustomLog in apache's httpd conf file avoids the crash. So maybe that's a good place for the developers to start looking. I have log_errors = Off on my php.ini file, so it really doesn't make sense to me. But I have confirmed that with the CustomLogs disabled, I get no crashes. [2004-03-29 10:46:29] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Dupe of bug #27735 [2004-03-29 08:23:35] packager at rabbito dot org The crash only occur after the first PHP script is executed, ie) someone requested a url that is generated by PHP. Uses standard php.ini file and a slightly modified httpd.conf file with the following lines added: LoadModule php4_module C:\www\php\sapi\php4apache2.dll AddType application/x-httpd-php .php [2004-03-29 08:20:09] packager at rabbito dot org Description: Apache2 2.0.49 crash when restarting Apache2 from Apache Service Monitor under PHP4.3.5 Works fine (no crash) with PHP-4.3.4, Apache2.0.49. Expected result: Apache2 should exit without application error Actual result: -- The following Apache Application Error occurs - The instruction at "0x77f83aed" referenced memory at "0x37412d32". The memory could not be "written". Click on OK to terminate the program Click on CANCEL to debug the program -- Edit this bug report at http://bugs.php.net/?id=27751&edit=1
#27772 [Fbk->Opn]: It crashes at the last of cgi_main.
ID: 27772
User updated by: khagiya1 at yahoo dot co dot jp
Reported By: khagiya1 at yahoo dot co dot jp
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Windows Xp Professional Ver2002
PHP Version: 4.3.5
New Comment:
I am sorry since the range of zend and the range of php are not known
well.
Is it the same as this bug(Bug #27141)?
In my place, even if this problem is not a command line, it occurs.
> Does it work when you disable the ioncube_loader?
Yes, it operates satisfactory.
It will crash, if there is some zend_extension_ts.
For example, It crashes, even if it writes this.
[php.ini]
zend_extension_ts = C:\ZendOptimizer.dll
An extended module calls ZEND_INIT_MODULE_GLOBALS in PHP_MINIT_FUNCTION
mostly.
In ZTS mode, this calls ts_allocate_id.
dtor and ctor(for module) are registered by this.
So, in zend_extension_ts which is not calling this function, it doesn't
crash.
Previous Comments:
[2004-03-30 09:53:37] [EMAIL PROTECTED]
Does it work when you disable the ioncube_loader?
[2004-03-30 08:52:58] egarcia at egm dot as
You can get mor information from:
Bug #27141 PHP.exe crash on console.
[2004-03-30 08:47:06] egarcia at egm dot as
Well, I report a similar error when this version was in beta testing.
The product can be used with Zend Optimizer, this carsh constantly.
If I disable the Zend Optimizer 2.1b or 2.5 the product works OK, even
with the Zend Extensions enabled the product works OK.
The answer that I get about this incident not existent in the 4.3.4 was
that this problem is related to Zend and not to the PHP itself.
But reading the report with the Ioncube extensions must be related to
the Zend Engine or the PHP.
Regards,
[2004-03-30 05:22:00] khagiya1 at yahoo dot co dot jp
Description:
Please let me know.
I downloaded "PHP 4.3.5 (tar.gz) [4,706Kb]-26 March 2004." from
"http://www.php.net/downloads.php";
It is used building it personally.
It crash, although only built.
Reproduce code:
---
The example of a code to generate
[c:/hello.csp]
[php.ini]
zend_extension_ts = c:/ioncube_loader.dll
EThe following is performed on a console.
c:/php.exe -f c:/hello.csp
It is displayed on a screen as "hello!!".
Crash occurs together with it.
This is generated only when module(zend_extension_ts) is loaded.
It does not generate in module(extension).
When the code was seen, it had generated in the following places.
The following change went into TSRM/TSRM.c by php-4.3.4 to php-4.3.5.
*** TSRM/TSRM.c Tue Nov 11 14:17:17 2003 <-- 4.3.4
--- TSRM/TSRM.c Wed Dec 17 04:59:58 2003 <-- 4.3.5
***
*** 157,163
int j;
next_p = p->next;
! for (j=0; jstorage[j]);
}
free(p->storage);
--- 157,166
int j;
next_p = p->next;
! for (j=0; jcount; j++) {
! if (resource_types_table &&
resource_types_table[j].dtor) {
!
resource_types_table[j].dtor(p->storage[j], &p->storage); <--
cause the problem!!
! }
free(p->storage[j]);
}
free(p->storage);
sapi/cgi/cgi_main.c: line 1787 - 1792
--
php_module_shutdown(TSRMLS_C);
HLOG_LOG( HLOG_NOTICE, "php_module_shutdown" );
#ifdef ZTS
tsrm_shutdown();
#endif
--
show callstack.
1. php_module_shutdown
2. zend_shutdown
3. zend_shutdown_extensions
4. zend_llist_destroy
5. zend_extension_dtor
6. DL_UNLOAD <-- module(by zend_extension_ts) is unload here.
7. tsrm_shutdown <-- dtor can't be called.
--
Edit this bug report at http://bugs.php.net/?id=27772&edit=1
#27735 [Com]: restart of apache2 via kill -1 or apachectl causes crash
ID: 27735 Comment by: josestefan at hotmail dot com Reported By: as at netoholic dot de Status: Bogus Bug Type: Reproducible crash Operating System: Linux PHP Version: 4.3.5 New Comment: I've noticed that disabling all CustomLog in apache's httpd conf file avoids the crash. So maybe that's a good place for the developers to start looking. I have log_errors = Off on my php.ini file, so it really doesn't make sense to me. But I have confirmed that with the CustomLogs disabled, I get no crashes. running Windows XP, Apache: 2.0.49, PHP: 4.3.5 Previous Comments: [2004-03-30 08:50:43] noackjr at alumni dot rice dot edu I have this exact same problem (identical backtrace, etc.) with FreeBSD 5.2.1, Apache 2.0.49, and PHP 4.3.5. Reverting to the PCRE from 4.3.4 (replacing ext/pcre) also resolved the problem for me. Does PCRE 4.5 expose an Apache bug, or is this a problem with PCRE 4.5? If it's the former, leave it as Bogus. Otherwise, this is a PHP bug because it's bundled code. [2004-03-30 06:57:35] chb at muc dot de I don't think this bug is "Bogus". I'm experiencing the same problems using Apache 2.0.49 with RedHat Linux 8.0 (same backtrace, ...). So far I've been able to track it down to the PCRE extension. When I add "--without-pcre" everything is fine. I've now replaced "ext/pcre", using the version from PHP 4.3.4 (PCRE 4.3) and the problem is gone. My suspicion is that the new PCRE version has memory allocation problems. [2004-03-29 10:45:53] [EMAIL PROTECTED] read above comment. [2004-03-29 10:45:38] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. The backtrace shows the crash to reside deep inside AP2 code and not in PHP, hence this is not a PHP bug. [2004-03-29 05:25:01] as at netoholic dot de my backtrace: (gdb) bt #0 0x4b8f2630 in ?? () #1 0x080728a1 in regex_cleanup (preg=0x0) at util.c:258 #2 0x4b56c39d in run_cleanups (cref=0x80ac838) at apr_pools.c:1951 #3 0x4b56bbe9 in apr_pool_clear (pool=0x80ac828) at apr_pools.c:693 #4 0x0806e4d2 in main (argc=4, argv=0xb1d38f34) at main.c:574 #5 0x4b6558ae in __libc_start_main () from /lib/libc.so.6 apache built with prefork mpm... 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/27735 -- Edit this bug report at http://bugs.php.net/?id=27735&edit=1
#27277 [Com]: Apache crash on shutdown
ID: 27277 Comment by: josestefan at hotmail dot com Reported By: andreas dot goetz dot external at fujitsu-siemens dot c Status: Bogus Bug Type: Reproducible crash Operating System: WinXP PHP Version: 5.0.0b4 (beta4) New Comment: I have added something related to this on bug number 27751 Previous Comments: [2004-02-16 21:30:03] [EMAIL PROTECTED] Can not reproduce with properly configured Apache2 and using latest CVS snapshot. [2004-02-16 08:03:40] andreas dot goetz dot external at fujitsu-siemens dot c Further tests seem to indicate that the crash behaviour is only experienced when the php_curl extension is loaded. Can you confirm this? Thanks, Andi [2004-02-16 08:00:43] andreas dot goetz dot external at fujitsu-siemens dot c Description: I've just tried the PHP5.0.0b4. The apache2 service reproducibly crashes (instruction ar "0x10002726" referenced memory at "0x4", the memory could not be read) when the apache2 service is stopped. No further details in the apache log files/ system event viewer. PHP is loaded as module. Cheers, Andi -- Edit this bug report at http://bugs.php.net/?id=27277&edit=1
#27751 [Com]: Apache2 2.0.49 crash when restarting (PHP4.3.5 only, works fine in 4.3.4)
ID: 27751 Comment by: josestefan at hotmail dot com Reported By: packager at rabbito dot org Status: Bogus Bug Type: Apache2 related Operating System: Windows XP PHP Version: 4.3.5 New Comment: I've noticed that disabling all CustomLog in apache's httpd conf file avoids the crash. So maybe that's a good place for the developers to start looking. I have log_errors = Off on my php.ini file, so it really doesn't make sense to me. But I have confirmed that with the CustomLogs disabled, I get no crashes. Previous Comments: [2004-03-29 10:46:29] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Dupe of bug #27735 [2004-03-29 08:23:35] packager at rabbito dot org The crash only occur after the first PHP script is executed, ie) someone requested a url that is generated by PHP. Uses standard php.ini file and a slightly modified httpd.conf file with the following lines added: LoadModule php4_module C:\www\php\sapi\php4apache2.dll AddType application/x-httpd-php .php [2004-03-29 08:20:09] packager at rabbito dot org Description: Apache2 2.0.49 crash when restarting Apache2 from Apache Service Monitor under PHP4.3.5 Works fine (no crash) with PHP-4.3.4, Apache2.0.49. Expected result: Apache2 should exit without application error Actual result: -- The following Apache Application Error occurs - The instruction at "0x77f83aed" referenced memory at "0x37412d32". The memory could not be "written". Click on OK to terminate the program Click on CANCEL to debug the program -- Edit this bug report at http://bugs.php.net/?id=27751&edit=1
#27789 [Opn->Bgs]: march returned instead of february with mktime and date
ID: 27789
Updated by: [EMAIL PROTECTED]
Reported By: summercom at comcast dot net
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Windows XP SP1
PHP Version: 4.3.5
New Comment:
Today is the 30th. When using mktime with only four parameters as you
are you'll get the hour, minute, second, and month specified for the
current day and year.
February 30th, because it doesn't actually exist, translates out to
March 2nd.
Please search the bug database next time. This has been reported and
explained several times already.
Previous Comments:
[2004-03-30 21:19:06] summercom at comcast dot net
Description:
When using mktime and the date functions it seems that instead of
properly returning "February" the two functions used together will
return "March"
Reproduce code:
---
".date("F", mktime(0, 0,
0, $i))."\n";
$i++;
} while ($i < 13);
?>
Expected result:
date("F", mktime(0, 0, 0, 1)); --> January
date("F", mktime(0, 0, 0, 2)); --> February
date("F", mktime(0, 0, 0, 3)); --> March
date("F", mktime(0, 0, 0, 4)); --> April
date("F", mktime(0, 0, 0, 5)); --> May
date("F", mktime(0, 0, 0, 6)); --> June
date("F", mktime(0, 0, 0, 7)); --> July
date("F", mktime(0, 0, 0, 8)); --> August
date("F", mktime(0, 0, 0, 9)); --> September
date("F", mktime(0, 0, 0, 10)); --> October
date("F", mktime(0, 0, 0, 11)); --> November
date("F", mktime(0, 0, 0, 12)); --> December
Actual result:
--
date("F", mktime(0, 0, 0, 1)); --> January
date("F", mktime(0, 0, 0, 2)); --> March
date("F", mktime(0, 0, 0, 3)); --> March
date("F", mktime(0, 0, 0, 4)); --> April
date("F", mktime(0, 0, 0, 5)); --> May
date("F", mktime(0, 0, 0, 6)); --> June
date("F", mktime(0, 0, 0, 7)); --> July
date("F", mktime(0, 0, 0, 8)); --> August
date("F", mktime(0, 0, 0, 9)); --> September
date("F", mktime(0, 0, 0, 10)); --> October
date("F", mktime(0, 0, 0, 11)); --> November
date("F", mktime(0, 0, 0, 12)); --> December
--
Edit this bug report at http://bugs.php.net/?id=27789&edit=1
#27744 [Bgs]: 141.23 - 141.00 = 0.22999999999999 ?
ID: 27744
Updated by: [EMAIL PROTECTED]
Reported By: t dot steve at ariadne-quatra dot com
Status: Bogus
Bug Type: Math related
Operating System: *
PHP Version: *
New Comment:
Floating point values in computers are never exact.
It's a fact of life, and an issue that is not only
encountered with PHP but other languages as well.
Previous Comments:
[2004-03-30 21:35:54] t dot steve at ariadne-quatra dot com
Hi!
I am sure I am something, apologies for that. :(
"Guys, how in the world is PHP supposed to magically guess what
precision you want results displayed in."
141.23 - 141 _is_ precisely 0.23. If I was asking for 1/3, then I would
understand the decimal places. But how come 141.23-141 turns out to
have so many decimal places in the end instead of just being 0.23 - the
mathematically correct and precise result?
[2004-03-30 19:59:05] [EMAIL PROTECTED]
Guys, how in the world is PHP supposed to magically guess what
precision you want results displayed in. If you know you always want
lower precision, set that in your php.ini file. Or if you just want it
temporarily simply do:
$old = ini_set('precision',2);
echo (string)(750 - 749.99);
ini_set('precision',$old);
[2004-03-30 19:47:47] [EMAIL PROTECTED]
create table a ( b float,c float );
Query OK, 0 rows affected (0.11 sec)
mysql> insert into a (b,c) values (141.23,141);
Query OK, 1 row affected (0.07 sec)
mysql> select b-c from a;
+--+
| b-c |
+--+
| 0.22999572753906 |
+--+
1 row in set (0.00 sec)
[2004-03-30 13:45:03] [EMAIL PROTECTED]
That is the whole point of the answer. Floating point values are not
accurate and are not nice. And we do not do a bunch of work just to
make them look better in certain circumstances.
[2004-03-30 12:07:45] garbo_doe at hotmail dot com
IMHO I think this is a bug. Of course there are problems with
floatingpoint values in binary form, especially when rounded many
times. But in an operation like it
shouldn't return "0.00" but "0.01".
I did a quick test in Delphi: showmessage(floattostr(750 - 749.99));
returns "0.01, not "0.00".
I had to solve it in PHP but multiplying with 100, then subtract and
then divide the result by 100 again.
It's not pretty :-D
(0.00999[infinite 9's] IS exactly the same as 0.01, but it should
remember the "infinite" with a bit or something, so (1/3)*3 = 1 and not
0.9)
(this is similar as bug #8164)
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/27744
--
Edit this bug report at http://bugs.php.net/?id=27744&edit=1
#27744 [Bgs]: 141.23 - 141.00 = 0.22999999999999 ?
ID: 27744
User updated by: t dot steve at ariadne-quatra dot com
Reported By: t dot steve at ariadne-quatra dot com
Status: Bogus
Bug Type: Math related
Operating System: *
PHP Version: *
New Comment:
Hi!
I am sure I am something, apologies for that. :(
"Guys, how in the world is PHP supposed to magically guess what
precision you want results displayed in."
141.23 - 141 _is_ precisely 0.23. If I was asking for 1/3, then I would
understand the decimal places. But how come 141.23-141 turns out to
have so many decimal places in the end instead of just being 0.23 - the
mathematically correct and precise result?
Previous Comments:
[2004-03-30 19:59:05] [EMAIL PROTECTED]
Guys, how in the world is PHP supposed to magically guess what
precision you want results displayed in. If you know you always want
lower precision, set that in your php.ini file. Or if you just want it
temporarily simply do:
$old = ini_set('precision',2);
echo (string)(750 - 749.99);
ini_set('precision',$old);
[2004-03-30 19:47:47] [EMAIL PROTECTED]
create table a ( b float,c float );
Query OK, 0 rows affected (0.11 sec)
mysql> insert into a (b,c) values (141.23,141);
Query OK, 1 row affected (0.07 sec)
mysql> select b-c from a;
+--+
| b-c |
+--+
| 0.22999572753906 |
+--+
1 row in set (0.00 sec)
[2004-03-30 13:45:03] [EMAIL PROTECTED]
That is the whole point of the answer. Floating point values are not
accurate and are not nice. And we do not do a bunch of work just to
make them look better in certain circumstances.
[2004-03-30 12:07:45] garbo_doe at hotmail dot com
IMHO I think this is a bug. Of course there are problems with
floatingpoint values in binary form, especially when rounded many
times. But in an operation like it
shouldn't return "0.00" but "0.01".
I did a quick test in Delphi: showmessage(floattostr(750 - 749.99));
returns "0.01, not "0.00".
I had to solve it in PHP but multiplying with 100, then subtract and
then divide the result by 100 again.
It's not pretty :-D
(0.00999[infinite 9's] IS exactly the same as 0.01, but it should
remember the "infinite" with a bit or something, so (1/3)*3 = 1 and not
0.9)
(this is similar as bug #8164)
[2004-03-29 01:06:46] [EMAIL PROTECTED]
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
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/27744
--
Edit this bug report at http://bugs.php.net/?id=27744&edit=1
#27789 [NEW]: march returned instead of february with mktime and date
From: summercom at comcast dot net
Operating system: Windows XP SP1
PHP version: 4.3.5
PHP Bug Type: Date/time related
Bug description: march returned instead of february with mktime and date
Description:
When using mktime and the date functions it seems that instead of properly
returning "February" the two functions used together will return "March"
Reproduce code:
---
".date("F", mktime(0, 0, 0,
$i))."\n";
$i++;
} while ($i < 13);
?>
Expected result:
date("F", mktime(0, 0, 0, 1)); --> January
date("F", mktime(0, 0, 0, 2)); --> February
date("F", mktime(0, 0, 0, 3)); --> March
date("F", mktime(0, 0, 0, 4)); --> April
date("F", mktime(0, 0, 0, 5)); --> May
date("F", mktime(0, 0, 0, 6)); --> June
date("F", mktime(0, 0, 0, 7)); --> July
date("F", mktime(0, 0, 0, 8)); --> August
date("F", mktime(0, 0, 0, 9)); --> September
date("F", mktime(0, 0, 0, 10)); --> October
date("F", mktime(0, 0, 0, 11)); --> November
date("F", mktime(0, 0, 0, 12)); --> December
Actual result:
--
date("F", mktime(0, 0, 0, 1)); --> January
date("F", mktime(0, 0, 0, 2)); --> March
date("F", mktime(0, 0, 0, 3)); --> March
date("F", mktime(0, 0, 0, 4)); --> April
date("F", mktime(0, 0, 0, 5)); --> May
date("F", mktime(0, 0, 0, 6)); --> June
date("F", mktime(0, 0, 0, 7)); --> July
date("F", mktime(0, 0, 0, 8)); --> August
date("F", mktime(0, 0, 0, 9)); --> September
date("F", mktime(0, 0, 0, 10)); --> October
date("F", mktime(0, 0, 0, 11)); --> November
date("F", mktime(0, 0, 0, 12)); --> December
--
Edit bug report at http://bugs.php.net/?id=27789&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27789&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27789&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27789&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27789&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27789&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27789&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27789&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27789&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27789&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27789&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27789&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27789&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27789&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27789&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27789&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27789&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27789&r=float
#27266 [Com]: modifying php.ini crashes apache 1.3.29
ID: 27266 Comment by: ammarali at yahoo dot com Reported By: jimmybrock at yahoo dot com Status: Assigned Bug Type: Reproducible crash Operating System: windows 2000 PHP Version: 5.0.0b4 (beta4) Assigned To: helly New Comment: Howdy, I got this several times with version php-5.0.0RC1-Win32. I didn't compile my own as it's a testing environment. Anyway, the apache I'm running is 1.3.27. I noticed a crash that sounds a lot like Jimmy describes. However, I saw it with other variables too. For example, when I appended a new path at the end of PEAR's path, it crashed every time. Works: ;* Added by go-pear include_path=".;C:\PHP\pear" ;* Crashes: ;* Added by go-pear include_path=".;C:\PHP\pear;C:\www" ;* Hope it helps, and is actually relevant. Previous Comments: [2004-02-15 16:03:06] [EMAIL PROTECTED] This most likely happens with PHP 4 too. (didn't test) [2004-02-15 16:02:31] [EMAIL PROTECTED] Assigned to Marcus per his request. [2004-02-15 15:51:05] jimmybrock at yahoo dot com Description: by default 'docref_root' and docref_ext are commented out. I uncommented these variables and change 'docref_root' to the appropriate uri for the php manual and set the extension for 'docref_ext' to: .php After saving php.ini I attempted to restart Apache 1.3.29 and it crahses. There is nothing written to Apache's error log. After rebooting the machine Apache starts up on boot and runs fine. If there is an error in my code, I can click on the hyperlink and it will take me to the section of PHP.net manual for the error function that was called. But if you restart the Apache service it will crash again - the only way to get Apache running is by rebooting the machine. Note: I am running Apache as an ISAPI module, not CGI. Reproduce code: --- // uncommented and edited the following two lines of code in the php.ini file: docref_root = "http://us2.php.net/manual/en/"; docref_ext = .php Expected result: I didn't expect Apache to crash just because I changed the location of the PHP manual. If I comment out the two lines of offending code...Apache will restart without any problem. -- Edit this bug report at http://bugs.php.net/?id=27266&edit=1
#27697 [Fbk->Opn]: errors compiling parsedate.y
ID: 27697 User updated by: wzaccone at optonline dot net Reported By: wzaccone at optonline dot net -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.4 New Comment: I successfully compiled php with the latest snapshot.. thank you. Previous Comments: [2004-03-25 14:37:31] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-03-25 10:55:23] wzaccone at optonline dot net Description: I successfully built php 4.3.3 on a Solaris 8 system with gcc (GCC) 3.2.2 bison 1.28 flex 2.5.4 However when we tried to build on another system with same configuration, and bison -y parsedate.y failed. Can anyone point me in the right direction as to why this error occurs. Thank You. Warren Reproduce code: --- /bin/sh /FREE_2.4/NMA_WEB/NMA.r140/03-25-2004/install_apache_php/php-4.3.3/libto ol --silent --preserve-dup-deps --mode=compile gcc -Iext/standard/ -I/FREE_2.4/ NMA_WEB/NMA.r140/03-25-2004/install_apache_php/php-4.3.3/ext/standard/ -DPHP_ATO M_INC -I/FREE_2.4/NMA_WEB/NMA.r140/03-25-2004/install_apache_php/php-4.3.3/inclu de -I/FREE_2.4/NMA_WEB/NMA.r140/03-25-2004/install_apache_php/php-4.3.3/main -I/ FREE_2.4/NMA_WEB/NMA.r140/03-25-2004/install_apache_php/php-4.3.3 -I/FREE_2.4/NM A_WEB/NMA.r140/03-25-2004/install_apache_php/php-4.3.3/Zend -I/FREE_2.4/NMA_WEB/ NMA.r140/03-25-2004/install_apache_php/php-4.3.3/ext/xml/expat -D_POSIX_PTHREAD _SEMANTICS -I/FREE_2.4/NMA_WEB/NMA.r140/03-25-2004/install_apache_php/php-4.3.3/ TSRM -g -O2 -prefer-pic -c /FREE_2.4/NMA_WEB/NMA.r140/03-25-2004/install_apach e_php/php-4.3.3/ext/standard/parsedate.c -o ext/standard/parsedate.lo /usr/local/share/bison.simple: In function `php_gd_parse': /usr/local/share/bison.simple:219: number of arguments doesn't match prototype /usr/local/share/bison.simple:153: prototype declaration -- Edit this bug report at http://bugs.php.net/?id=27697&edit=1
#27744 [Bgs]: 141.23 - 141.00 = 0.22999999999999 ?
ID: 27744
Updated by: [EMAIL PROTECTED]
Reported By: t dot steve at ariadne-quatra dot com
Status: Bogus
Bug Type: Math related
Operating System: *
PHP Version: *
New Comment:
Guys, how in the world is PHP supposed to magically guess what
precision you want results displayed in. If you know you always want
lower precision, set that in your php.ini file. Or if you just want it
temporarily simply do:
$old = ini_set('precision',2);
echo (string)(750 - 749.99);
ini_set('precision',$old);
Previous Comments:
[2004-03-30 19:47:47] [EMAIL PROTECTED]
create table a ( b float,c float );
Query OK, 0 rows affected (0.11 sec)
mysql> insert into a (b,c) values (141.23,141);
Query OK, 1 row affected (0.07 sec)
mysql> select b-c from a;
+--+
| b-c |
+--+
| 0.22999572753906 |
+--+
1 row in set (0.00 sec)
[2004-03-30 13:45:03] [EMAIL PROTECTED]
That is the whole point of the answer. Floating point values are not
accurate and are not nice. And we do not do a bunch of work just to
make them look better in certain circumstances.
[2004-03-30 12:07:45] garbo_doe at hotmail dot com
IMHO I think this is a bug. Of course there are problems with
floatingpoint values in binary form, especially when rounded many
times. But in an operation like it
shouldn't return "0.00" but "0.01".
I did a quick test in Delphi: showmessage(floattostr(750 - 749.99));
returns "0.01, not "0.00".
I had to solve it in PHP but multiplying with 100, then subtract and
then divide the result by 100 again.
It's not pretty :-D
(0.00999[infinite 9's] IS exactly the same as 0.01, but it should
remember the "infinite" with a bit or something, so (1/3)*3 = 1 and not
0.9)
(this is similar as bug #8164)
[2004-03-29 01:06:46] [EMAIL PROTECTED]
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
Thank you for your interest in PHP.
.
[2004-03-29 01:05:32] t dot steve at ariadne-quatra dot com
Description:
Subtraction does not work as expected.
Windows 2000 Server
SP4
IIS5
PHP5RC1
Reproduce code:
---
$result=141.23-141.00;
echo $result;
(or
$result=141.23-141;
echo $result;
- same result)
Expected result:
0.23
Actual result:
--
0.22
--
Edit this bug report at http://bugs.php.net/?id=27744&edit=1
#27744 [Bgs]: 141.23 - 141.00 = 0.22999999999999 ?
ID: 27744 Updated by: [EMAIL PROTECTED] Reported By: t dot steve at ariadne-quatra dot com Status: Bogus Bug Type: Math related Operating System: * PHP Version: * New Comment: create table a ( b float,c float ); Query OK, 0 rows affected (0.11 sec) mysql> insert into a (b,c) values (141.23,141); Query OK, 1 row affected (0.07 sec) mysql> select b-c from a; +--+ | b-c | +--+ | 0.22999572753906 | +--+ 1 row in set (0.00 sec) Previous Comments: [2004-03-30 13:45:03] [EMAIL PROTECTED] That is the whole point of the answer. Floating point values are not accurate and are not nice. And we do not do a bunch of work just to make them look better in certain circumstances. [2004-03-30 12:07:45] garbo_doe at hotmail dot com IMHO I think this is a bug. Of course there are problems with floatingpoint values in binary form, especially when rounded many times. But in an operation like it shouldn't return "0.00" but "0.01". I did a quick test in Delphi: showmessage(floattostr(750 - 749.99)); returns "0.01, not "0.00". I had to solve it in PHP but multiplying with 100, then subtract and then divide the result by 100 again. It's not pretty :-D (0.00999[infinite 9's] IS exactly the same as 0.01, but it should remember the "infinite" with a bit or something, so (1/3)*3 = 1 and not 0.9) (this is similar as bug #8164) [2004-03-29 01:06:46] [EMAIL PROTECTED] Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. Thank you for your interest in PHP. . [2004-03-29 01:05:32] t dot steve at ariadne-quatra dot com Description: Subtraction does not work as expected. Windows 2000 Server SP4 IIS5 PHP5RC1 Reproduce code: --- $result=141.23-141.00; echo $result; (or $result=141.23-141; echo $result; - same result) Expected result: 0.23 Actual result: -- 0.22 -- Edit this bug report at http://bugs.php.net/?id=27744&edit=1
#27788 [NEW]: array_multisort doesn't mantain index associations with numeric arrays
From: mail at spybreak dot de Operating system: Win2K PHP version: 4.3.4 PHP Bug Type: Feature/Change Request Bug description: array_multisort doesn't mantain index associations with numeric arrays Description: The manual says that array_multisort mantains key associations. This is only true if the keys are strings. If the keys are integers on the other hand, key association is not mantained. I don't think that this is a bug since it's so obvious. But I wish feedback on this to clear this issue up. Thanks alot! Reproduce code: --- Expected result: I expect this: // _should_ return // // array // 5 => 'Peter' // 34 => 'Robert' // 7 => 'Jim' // 33 => 'John' // 11 => 'Martin' Actual result: -- // returns the following for me // // array // 0 => 'Peter' // 1 => 'Robert' // 2 => 'Jim' // 3 => 'John' // 4 => 'Martin' -- Edit bug report at http://bugs.php.net/?id=27788&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27788&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27788&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27788&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27788&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27788&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27788&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27788&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27788&r=support Expected behavior: http://bugs.php.net/fix.php?id=27788&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27788&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27788&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27788&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27788&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27788&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27788&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27788&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27788&r=float
#27741 [Fbk->Opn]: IIS down while request .php file
ID: 27741 User updated by: yjt at 5kg dot net Reported By: yjt at 5kg dot net -Status: Feedback +Status: Open Bug Type: IIS related Operating System: Windows 2000 Server PHP Version: 4.3.5 New Comment: only Zend optimizer Optimization Pass 1 enabled Optimization Pass 2 enabled Optimization Pass 3 enabled Optimization Pass 4 enabled Optimization Pass 5 disabled Optimization Pass 9 disabled Optimization Pass 10 disabled Zend Loader enabled License Path no value Previous Comments: [2004-03-30 10:35:18] [EMAIL PROTECTED] Do you have any Zend Extensions loaded in PHP.ini ? [2004-03-29 21:51:10] yjt at 5kg dot net problem shows on any script, such as below: [2004-03-29 15:51:14] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-03-29 03:32:26] franz dot winter at gbo dot com The same problem (frustrated sunday). W2K event-log shows "The service could not connect Instance 5...". CGI/Fast CGI mode is running (with the event-log message), ISAPI is not running at all. [2004-03-28 19:46:37] yjt at 5kg dot net Description: php 4.3.5 installed in win2k server & iis 5, when request a page,show errors below: Unknown list entry type in request shutdown (2) in Unknown on line 0. open php error log and found errors in event viewer: c-client[1264], PHP Warning: Unknown list entry type in request shutdown (2) in Unknown on line 0. I tried isapi and cgi mode : in isapi mode, w3svc halt and cannot restart, only way is restart the server; in cgi mode, application popup show "inetinfo.exe" error for several times. end of report. -- Edit this bug report at http://bugs.php.net/?id=27741&edit=1
#27787 [NEW]: browser hangs with exec()
From: vardemor at hotmail dot com Operating system: windows 2000 professional/server PHP version: 4.3.5 PHP Bug Type: Program Execution Bug description: browser hangs with exec() Description: I've been trying to call a Win NT executable from a PHP4 script and the result is very strange. The browser hangs, and not finish to show results. If I stop the navigation, nothing appens. The script execute an win app like that: The code after the execution is not show in the browser. The app executes normally, but after the execution the script maybe hangs the browser. PHP was installed like a ISAPI module, not CGI. All help appreciated. Reproduce code: --- http://bugs.php.net/?id=27787&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27787&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27787&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27787&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27787&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27787&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27787&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27787&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27787&r=support Expected behavior: http://bugs.php.net/fix.php?id=27787&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27787&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27787&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27787&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27787&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27787&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27787&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27787&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27787&r=float
#27786 [NEW]: "last month" bypass feb.
From: zhang_yinshu at yahoo dot com
Operating system: linux
PHP version: 5.0.0RC1
PHP Bug Type: Date/time related
Bug description: "last month" bypass feb.
Description:
if call function strtotime("last month") or ("-1 month") at Mar. 30th
2004, it will return 3/1/04. ("-2 month") produce correct output.
Reproduce code:
---
--
Edit bug report at http://bugs.php.net/?id=27786&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27786&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27786&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27786&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27786&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27786&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27786&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27786&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27786&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27786&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27786&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27786&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27786&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27786&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27786&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27786&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27786&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27786&r=float
#27785 [NEW]: Change __sleep to always work on copy of object instead of reference
From: brad at info-link dot net
Operating system: Linux
PHP version: 5.0.0RC1
PHP Bug Type: Feature/Change Request
Bug description: Change __sleep to always work on copy of object instead of reference
Description:
When serializing an object with a __sleep method defined, the original
object may be modified by __sleep. I'd like to see the __sleep method
always being called on a copy of the object being serialized and not on
the actual object. In PHP4, this is _mostly_ the case as long as you're
not working with references, but in PHP5, the original object is always
modified directly.
The example below is a little contrived, but does demonstrate the idea.
Under PHP4, the result is _almost_ as expected, except that the instance
of B referenced by $a->b is modified. If the reference is changed to a
plain copy (change the line reading "$a->b = &$b;" to "$a->b = $b;"), then
the instance is not modified.
PHP5 gives the output given under actual result, which is probably wrong
in either case.
Reproduce code:
---
b = 'serialized';
return Array('b');
}
}
class A {
var $a = "default";
var $b = null;
function __sleep() {
$this->a = "serialized";
return array_keys(get_object_vars($this));
}
}
$a = new A();
$b = new B();
$a->b = &$b;
print_r($a);
$s = serialize($a);
print_r($s);
print_r($a);
$na = unserialize($s);
print_r($na);
?>
Expected result:
a Object
(
[a] => default
[b] => b Object
(
[b] => default
)
)
O:1:"a":2:{s:1:"a";s:10:"serialized";s:1:"b";O:1:"b":1:{s:1:"b";s:10:"serialized";}}a
Object
(
[a] => default
[b] => b Object
(
[b] => default
)
)
a Object
(
[a] => serialized
[b] => b Object
(
[b] => serialized
)
)
Actual result:
--
A Object
(
[a] => default
[b] => B Object
(
[b] => default
)
)
O:1:"A":2:{s:1:"a";s:10:"serialized";s:1:"b";O:1:"B":1:{s:1:"b";s:10:"serialized";}}A
Object
(
[a] => serialized
[b] => B Object
(
[b] => serialized
)
)
A Object
(
[a] => serialized
[b] => B Object
(
[b] => serialized
)
)
--
Edit bug report at http://bugs.php.net/?id=27785&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27785&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27785&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27785&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27785&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27785&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27785&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27785&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27785&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27785&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27785&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27785&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27785&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27785&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27785&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27785&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27785&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27785&r=float
#27779 [Bgs]: fopen problem
ID: 27779 User updated by: baloor at clara dot co dot uk Reported By: baloor at clara dot co dot uk Status: Bogus Bug Type: IIS related Operating System: Windows 2000 s-pack 4 PHP Version: 4.3.4 New Comment: OK thank's! I tink is IIS the problem. I look on link you give it to me. Previous Comments: [2004-03-30 10:58:30] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. As the error messages implies this is a simple file system permissions errors, the INI settings you've mentioned have no relevance in this case. [2004-03-30 10:41:50] baloor at clara dot co dot uk Description: Hi I have problem with fopen $FX_fso = fopen($FX_fpath,"r+"); I look in php.ini and I think everytign is OK like register_globals = Off allow_url_fopen = On This scrip is for counter and it's fonctionnaly on other server. Expected result: Warning: fopen(my_datacounter/counter01.txt): failed to open stream: Permission denied in c:\inetpub\wwwroot\compteur_v1.1\compteur.php on line 21 and other... -- Edit this bug report at http://bugs.php.net/?id=27779&edit=1
#27784 [NEW]: "unkown software exception" (0x00000fd) and php5 crash
From: bestmischmaker at web dot de Operating system: w2k_sp4 PHP version: 5CVS-2004-03-30 (dev) PHP Bug Type: Reproducible crash Bug description: "unkown software exception" (0x0fd) and php5 crash Description: Hy if i try to run this script php crash with Die Ausnahme "unkown software exception" (0x0fd) ist in der Anwendung an der Stelle 0x78007497 aufgetreten and i can say when i will happend for that i have upload 2 little txt files for you !!! Reproduce code: --- http://mitglied.lycos.de/bestmischmaker/php5/example.txt http://mitglied.lycos.de/bestmischmaker/php5/email.class.txt have a look at line 109 http://mitglied.lycos.de/bestmischmaker/php/debug1.jpg Expected result: run Actual result: -- crash -- Edit bug report at http://bugs.php.net/?id=27784&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27784&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27784&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27784&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27784&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27784&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27784&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27784&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27784&r=support Expected behavior: http://bugs.php.net/fix.php?id=27784&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27784&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27784&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27784&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27784&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27784&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27784&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27784&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27784&r=float
#27738 [Com]: php crashes when calling odbc_pconnect(...)
ID: 27738
Comment by: sengelmann at gmx dot de
Reported By: info at bitart dot at
Status: Feedback
Bug Type: ODBC related
Operating System: win xp
PHP Version: 4.3.5
New Comment:
I use no zend extensions.
Testet with the original php.ini-recommended and the small testfile
Previous Comments:
[2004-03-30 11:04:59] [EMAIL PROTECTED]
Do you have any zend extensions loaded via php.ini?
[2004-03-29 07:35:05] sengelmann at gmx dot de
Same PRoblem with Windows 2000 Prof.
Error: (zend_hash_index_find)
[2004-03-27 15:00:20] info at bitart dot at
Description:
Very simple:
when calling
odbc_pconnect("myDatabase","","");
--> php.exe crashes.
odbc_connect("myDatabase","","");
--> works fine.
It works also fine on several other versions of PHP.
The Database is Access2000.
Binary WIN32 version of PHP.
Webserver: Apache.
Reproduce code:
---
Expected result:
no crash...
Actual result:
--
php.exe crashes.
--
Edit this bug report at http://bugs.php.net/?id=27738&edit=1
#27783 [NEW]: DomDocument::formatOutput = true doesn' work with loaded files.
From: manuel dot hesse at xplib dot de
Operating system: linux fedora core 1
PHP version: 5.0.0RC1
PHP Bug Type: DOM XML related
Bug description: DomDocument::formatOutput = true doesn' work with loaded files.
Description:
The formatOutput feature doesn' t work with documents, that use
DomDocument::load() for creation. But it works with in memory DOM
Documents.
Reproduce code:
---
$dom = new DomDocument();
$file = "/path/to/file/dom.xml";
if (file_exists($file)) {
$dom->load($file);
} else {
$dom->appendChild(dom->createElement('foobar'));
}
printf("%s", htmlentities($dom->saveXML()));
--
Edit bug report at http://bugs.php.net/?id=27783&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27783&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27783&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27783&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27783&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27783&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27783&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27783&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27783&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27783&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27783&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27783&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27783&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27783&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27783&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27783&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27783&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27783&r=float
#27782 [Csd]: Wrong behaviour of next() and prev()
ID: 27782 User updated by: giovanni at giacobbi dot net Reported By: giovanni at giacobbi dot net Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.3.4 New Comment: the following revision: +++ ext/standard/array.c30 Mar 2004 19:09:10 - 1.199.2.31 has been tested and perfectly works. Thank you. Previous Comments: [2004-03-30 14:00:23] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2004-03-30 12:09:37] giovanni at giacobbi dot net Description: As stated in documentation, next() returns the NEXT element in the array and THEN increases internal pointer. Thus, when this function returns FALSE, I expect the internal pointer to be in the last position, thus prev() should return end()-1 element. Reproduce code: --- http://bugs.php.net/?id=27782&edit=1
#27771 [Opn->Fbk]: Seg fault with php-apache-sybase-ct compil
ID: 27771 Updated by: [EMAIL PROTECTED] Reported By: nsl at free dot fr -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: rh 7.2 -apa1.3.26-php435 PHP Version: 4.3.5 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2004-03-30 04:41:09] nsl at free dot fr Description: Hi, i 'l like to compile apache with php and sybase-ct support . I've got this error on the php compil : make test make: [test] Erreur 139 (ignorée) and at the make install : [EMAIL PROTECTED] php]# make install Installing PHP SAPI module: cgi Installing PHP CGI into: /usr/local/bin/ Installing PEAR environment: /usr/local/lib/php/ make[1]: *** [install-pear-installer] Erreur de segmentation make: *** [install-pear] Erreur 2 i've got this error with : apache 1.3.26 , 1.3.29 with php 4.3.1 and 4.3.5 on : rh 7.3 , rh 8 and rh 9 ... and i've try it on two computers ... always same error here is the php compil command : ./configure --with-apache-apxs=/home/manu/data/final/bin/apxs --enable-track-vars --enable-sockets --enable-wddx --with-sybase-ct=/opt/sybase-11.9.2 --without-mysql and the apache compil command : ./configure --prefix=/home/manu/data/final/ --enable-module=so what's wrong with php :( ? regards Manu -- Edit this bug report at http://bugs.php.net/?id=27771&edit=1
#27775 [Opn->Fbk]: Using session_start() simultaneous causes script to crash
ID: 27775 Updated by: [EMAIL PROTECTED] Reported By: mattias at pfeiffer dot dk -Status: Open +Status: Feedback Bug Type: Session related Operating System: Debian GNU/Linux PHP Version: 4.3.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2004-03-30 08:23:00] mattias at pfeiffer dot dk Description: I'm experiencing a problem using session_start() simultaneous - ie. in 2 iframes. An example: I have a page with to iframes embedded. Frame 1 runs a script with a while(true), and at line 1 a session_start(). A page is loaded into Frame 2, with session_start() as the only content. (Except for of course) The page in Frame 2 will not be parsed unless the session_start() is removed from the top. It seems as when 2 pages are loaded/loading and executing session_start() simultaneous, PHP will fail to interpret one of them. I've tested and determined this issue at two self-contained systems. === System information: PHP: 2.4.3 Apache: 1.3.29 Configured with: '../configure' '--prefix=/usr' '--with-apxs=/usr/bin/apxs' '--with-regex=php' '--with-config-file-path=/etc/php4/apache' '--disable-rpath' '--enable-memory-limit' '--disable-debug' '--with-layout=GNU' '--with-pear=/usr/share/php' '--enable-calendar' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid' '--enable-bcmath' '--with-bz2' '--enable-ctype' '--with-db4' '--with-iconv' '--enable-exif' '--enable-filepro' '--enable-ftp' '--with-gettext' '--enable-mbstring' '--with-pcre-regex=/usr' '--enable-shmop' '--enable-sockets' '--enable-wddx' '--disable-xml' '--with-expat-dir=/usr' '--enable-yp' '--with-zlib' '--without-pgsql' '--with-kerberos=/usr' '--with-openssl=/usr' '--with-exec-dir=/usr/lib/php4/libexec' '--disable-static' '--with-curl=shared,/usr' '--with-dom=shared,/usr' '--with-dom-xslt=shared,/usr' '--with-dom-exslt=shared,/usr' '--with-zlib-dir=/usr' '--with-gd=shared,/usr' '--enable-gd-native-ttf' '--with-jpeg-dir=shared,/usr' '--with-xpm-dir=shared,/usr/X11R6' '--with-png-dir=shared,/usr' '--with-freetype-dir=shared,/usr' '--with-imap=shared,/usr' '--with-imap-ssl' '--with-ldap=shared,/usr' '--with-mcal=shared,/usr' '--with-mhash=shared,/usr' '--with-mm' '--with-mysql=shared,/usr' '--with-unixODBC=shared,/usr' '--with-recode=shared,/usr' '--enable-xslt=shared' '--with-xslt-sablot=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-sybase-ct=shared,/usr' '--with-ttf=shared,/usr' '--with-t1lib=shared,/usr' Reproduce code: --- I've put up an example: http://home.madd.dk/phptest/ Expected result: I've expected frameA to produce desired output "HEST", but it seems like frameA.php fails to be parsed. Actual result: -- See "Expected result" -- Edit this bug report at http://bugs.php.net/?id=27775&edit=1
#27658 [Fbk->NoF]: PHP5 looks for php4ts.dll
ID: 27658 Updated by: [EMAIL PROTECTED] Reported By: memoimyself at yahoo dot com dot br -Status: Feedback +Status: No Feedback Bug Type: Apache2 related Operating System: Windows 2000 SP 4 PHP Version: 5.0.0RC1 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2004-03-24 17:28:26] [EMAIL PROTECTED] And just in case try the latest snapshot available at: http://snaps.php.net/win32/php5-win32-latest.zip [2004-03-24 17:20:52] [EMAIL PROTECTED] Its quite possible that the documentation is outdated :) I have just installed php and apache2 from scratch: 0. Get rid of old apache and php files (and really all of it) 1. Unpack php zip file to a folder, say c:\php5 2. Add c:\php5; to your system path (right click on My Computer->Properties->Advanced->Environmental Variables->System Variables->Path) 3. Reboot 4. Install apache to say c:\apache2 5. Edit c:\apache2\conf\httpd.conf 6. Add these two lines LoadModule php5_module "c:/php5/php5apache2.dll" AddType application/x-httpd-php .php 7. Stop and start apache2 service. Just repeated these steps myself and I'm looking at phpinfo() page right now! [2004-03-24 14:24:11] memoimyself at yahoo dot com dot br The line I have in my httpd.conf file is *exactly* LoadModule php5_module "c:/php/php5apache2.dll" I've tried everything, including shutting down my firewall (which sometimes interferes with Apache in weird ways) before even starting the installation process. The problem persists. Perhaps I posted this possible bug under the wrong heading. I'm not at all sure that this problem has anything to do with Apache or, more specifically, Apache2. What I do know for certain is that I get an error message every time Apache is started unless, as I said, I rename php5ts.dll to php4ts.dll. So, basically, it seems to me that whatever PHP5 DLL is called first by Apache is trying to call php4ts.dll instead of php5ts.dll, hence the error message. Mind you, I'm totally clueless as to how the PHP module is called and how each DLL is called in turn. The only thing I know for certain is that I've followed all instructions to the letter, checked and re-checked every possible configuration, and am still getting the same error.) [2004-03-24 00:39:16] [EMAIL PROTECTED] Please double check that the line LoadModule php5_module "c:/php/php5apache2.dll" is actually used in your configuration. I have the same install and apache works fine. [2004-03-23 13:06:57] memoimyself at yahoo dot com dot br Description: Having successfully installed PHP dozens of times before under Windows, Linux and FreeBSD, I downloaded the PHP5 RC1 package and installed it according to the instructions in the install.txt file. (Note: I tried the installation for the first time with Apache 2.0.47, but have since upgrated to the latest stable version, to no avail.) Upon installation, when I started Apache again, I got an error message to the effect that php4ts.dll could not be found in the system32 directory or any of the system paths. This is curious because if anything were to be missing, it should be php5ts.dll, not php4ts.dll. I renamed php5ts.dll to php4ts.dll and stopped getting the error message, so there's clearly something in the entrails of PHP5 that expects to find php4ts.dll. Renaming the file is not exactly a pretty solution, though. I have of course edited httpd.conf so that it now contains the line LoadModule php5_module "c:/php/php5apache2.dll" instead of LoadModule php4_module "c:/php/sapi/php4apache2.dll" My system path variable contains "C:\PHP", and I have also checked the new php.ini file to make sure that it contains valid paths (e.g. extension_dir "C:\PHP\ext\"). Everything looks fine. I have checked both my system32 and system32\dllcache directories to make sure that no old versions of any of the PHP DLLs are still there. (In fact, none of the PHP DLLs, old or new, are there any more; they're all in C:\PHP and, as I mentioned above, I have C:\PHP in my system path variable.) Expected result: Apache should work with PHP5RC1 as a module without issuing any error messages. Actual result: -- An error message is issued to the effect that php4ts.dll cannot be found in any of the specifi
#27610 [Fbk->NoF]: Segmentation fault using large object functions with php-odbc & php-pgsql
ID: 27610 Updated by: [EMAIL PROTECTED] Reported By: mark at lapcrew dot com -Status: Feedback +Status: No Feedback Bug Type: Reproducible crash Operating System: Linux PHP Version: 4.3.4 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2004-03-24 07:48:10] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. We have a nice "quick fix" for this, but Ilia didn't use it... so here it is :-) [2004-03-24 07:31:33] mark at lapcrew dot com Can you point me in the right direction on how to generate the a backtrace, an example or a howto site. Thanks [2004-03-15 16:46:07] [EMAIL PROTECTED] Please generate a backtrace of the crash. [2004-03-15 16:06:57] mark at lapcrew dot com Description: When both php-odbc & php-pgsql are installed an attempt to read data thru the pg_lo_read_all() function causes a segmentation fault. Removing the php-odbc module eliminated the problem. The following setup is being used Linux 2.6.1 Apache 2.0.48 PHP 4.3.4 PostgreSQL 7.4.1 Reproduce code: --- Load both the php-odbc & php-pgsql module and attempt to read large object data from a PostgreSQL database using pg_lo_read_all(). Run from the command line to see the segmentation fault error, or look in the apache error log -- Edit this bug report at http://bugs.php.net/?id=27610&edit=1
#27782 [Opn->Csd]: Wrong behaviour of next() and prev()
ID: 27782 Updated by: [EMAIL PROTECTED] Reported By: giovanni at giacobbi dot net -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.3.4 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2004-03-30 12:09:37] giovanni at giacobbi dot net Description: As stated in documentation, next() returns the NEXT element in the array and THEN increases internal pointer. Thus, when this function returns FALSE, I expect the internal pointer to be in the last position, thus prev() should return end()-1 element. Reproduce code: --- http://bugs.php.net/?id=27782&edit=1
#27744 [Bgs]: 141.23 - 141.00 = 0.22999999999999 ?
ID: 27744 Updated by: [EMAIL PROTECTED] Reported By: t dot steve at ariadne-quatra dot com Status: Bogus Bug Type: Math related -Operating System: Windows 2000 Server SP4 +Operating System: * -PHP Version: 5.0.0RC1 +PHP Version: * New Comment: That is the whole point of the answer. Floating point values are not accurate and are not nice. And we do not do a bunch of work just to make them look better in certain circumstances. Previous Comments: [2004-03-30 12:07:45] garbo_doe at hotmail dot com IMHO I think this is a bug. Of course there are problems with floatingpoint values in binary form, especially when rounded many times. But in an operation like it shouldn't return "0.00" but "0.01". I did a quick test in Delphi: showmessage(floattostr(750 - 749.99)); returns "0.01, not "0.00". I had to solve it in PHP but multiplying with 100, then subtract and then divide the result by 100 again. It's not pretty :-D (0.00999[infinite 9's] IS exactly the same as 0.01, but it should remember the "infinite" with a bit or something, so (1/3)*3 = 1 and not 0.9) (this is similar as bug #8164) [2004-03-29 01:06:46] [EMAIL PROTECTED] Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. Thank you for your interest in PHP. . [2004-03-29 01:05:32] t dot steve at ariadne-quatra dot com Description: Subtraction does not work as expected. Windows 2000 Server SP4 IIS5 PHP5RC1 Reproduce code: --- $result=141.23-141.00; echo $result; (or $result=141.23-141; echo $result; - same result) Expected result: 0.23 Actual result: -- 0.22 -- Edit this bug report at http://bugs.php.net/?id=27744&edit=1
#27764 [Asn->Csd]: Stored Procedure with no result sets doesn't set output params
ID: 27764 Updated by: [EMAIL PROTECTED] Reported By: Jeff dot Leigh at Premconf dot com -Status: Assigned +Status: Closed Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.3.5 Assigned To: fmk New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. The second parameter to mssql_execute() can be used to skip any result sets returned by the stored procedure. I've tested thsi with both php4 and php5 and the parameter works fine, and can even be used as a workarround for this bug. Previous Comments: [2004-03-29 17:30:11] Jeff dot Leigh at Premconf dot com Description: Create an MSSQL stored procedure that does not return any result sets. It only takes input parameters, and returns parameters. Create php code to called stored procedure, bind, etc, etc. Execute the procedure. You will not get any bug reported, and the output param variables will not be changed. mssql_execute will not return anything, since there are no result sets. Thus, 'mssql_next_result' cannot be called. If I force the stored procedure to return at least one result set, the output parameter is set properly. (There is nothing wrong with my MSSQL configuration from what I can tell. I can connect and do standard queries just fine.) Oh, and the current documentation says there is an optional second parameter for mssql_execute()... a boolean. If I try to use it, I get an error regarding an incorrect number of arguments to mssql_execute(). I'm assuming this was depreciated, but not documented. -- Edit this bug report at http://bugs.php.net/?id=27764&edit=1
#27717 [Opn]: Test Failures when compiled on 64-bit mode + Segmentation Fault
ID: 27717 User updated by: joelee at joeworks dot com -Summary: Test Failures when compiled on 64-bit mode Reported By: joelee at joeworks dot com Status: Open -Bug Type: Math related +Bug Type: Reproducible crash Operating System: Linux (Suse Linux 9.0 for AMD64) -PHP Version: 5.0 +PHP Version: 5.0.0RC1 New Comment: PHP5 ApacheHandler & CLI crashes with Segmentation Fault whenever E_ERROR occured. Previous Comments: [2004-03-26 13:41:57] [EMAIL PROTECTED] The PHP4 tests failures you've indicated are not 'real' failures, the results simply do not match since integers on your system can go much further then on 32 bit systems. [2004-03-26 12:35:26] joelee at joeworks dot com As requested, link to make test results: PHP 4.3.5 http://joeworks.com/pickup/php4.3.5_test_results_20040326.txt PHP 5.0.0RC1 http://joeworks.com/pickup/php5.0.0RC1_test_results_20040324_1124.txt [2004-03-26 11:11:53] [EMAIL PROTECTED] Please add a link to the information that "make test" saved to disk. [2004-03-26 10:56:14] joelee at joeworks dot com Tested on both 5.0.0RC1 and 4.3.5 Result from 5.0.0RC1 = FAILED TEST SUMMARY - ZE2 __toString() [tests/classes/tostring.phpt] ZE2: set_exception_handler() [tests/lang/035.phpt] Bug #22367 (weird zval allocation problem) [tests/lang/bug22367.phpt] Bug #23279 (exception handler stops after first function call) [tests/lang/bug23279.phpt] Bug #23384 (use of class constants in statics) [tests/lang/bug23384.phpt] Bug #26866 (segfault when exception raised in __get) [tests/lang/bug26866.phpt] ZE2 errors caught as exceptions [tests/lang/error_2_exception_001.phpt] invoke with non object or null value [tests/reflection/invoke.phpt] Bug #22836 (returning references to NULL) [Zend/tests/bug22836.phpt] Bug #26166 (__toString() crash when no values returned) [Zend/tests/bug26166.phpt] Bug #26698 (Thrown exceptions while evaluting argument to pass as parameter crash PHP) [Zend/tests/bug26698.phpt] Test 3: Exception Test [ext/dom/tests/dom003.phpt] sqlite-oo: factory and exception [ext/sqlite/tests/sqlite_oo_020.phpt] sqlite-oo: and spl [ext/sqlite/tests/sqlite_oo_031.phpt] Bug #25038 (call_user_func issues warning if function throws exception) [ext/standard/tests/general_functions/bug25038.phpt] date_sunrise() and date_sunset() functions [ext/standard/tests/general_functions/sunfuncts.phpt] Bug #26614 (CDATA sections skipped on line count) [ext/xml/tests/bug26614.phpt] = [2004-03-26 10:48:55] joelee at joeworks dot com Description: make test failure on abs(), pow() and round() when compile in 64-bit mode Tested on both 5.0.0RC1 and 4.3.5 Reproduce code: --- # Compile in 64-bit mode $ ./configure $ make $ make test # Actual Result # Compiled in 32-bit mode $ CFLAGS=-m32 ./configure $ make $ make test # Expected result Expected result: = FAILED TEST SUMMARY - Bug #25547 (error_handler and array index with function call) [tests/lang/bug25547.phpt] = Actual result: -- = FAILED TEST SUMMARY - Bug #24054 (Assignment operator *= broken) [tests/lang/bug24054.phpt] Bug #25547 (error_handler and array index with function call) [tests/lang/bug25547.phpt] serializing references test case using globals [ext/session/tests/019.phpt] Simple math tests [ext/standard/tests/math/abs.phpt] Various pow() tests [ext/standard/tests/math/pow.phpt] Simple math tests [ext/standard/tests/math/round.phpt] = -- Edit this bug report at http://bugs.php.net/?id=27717&edit=1
#27780 [Opn->Bgs]: strtotime(+1 xxx) returns 1 more hours
ID: 27780
Updated by: [EMAIL PROTECTED]
Reported By: Hua dot Qu at volvo dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Windows 2000
PHP Version: 4.3.4
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
You need to add timezone information to the original date.
For example change your text time to "2004-06-01 00:00:00
EST".
The end result will be that strtotime($to) will be 1
smaller then strtotime("$to +1 seconds "), which is the
correct output.
Previous Comments:
[2004-03-30 10:52:02] Hua dot Qu at volvo dot com
Description:
strtotime($tm + 1 xxx) always adds one more hour to the result, if the
result-time is in the summertime, no matter $tm is in the summertime or
not.
It is the same in PHP CVS (5.0.x-dev) Built On: Mar 30, 2004 14:30 GMT
I think it is the daylight-savings-time problem. Perhaps, $tm is not
checked if it is already in the daylight-savings-time.
There are already some similar reports, but they did not get the point,
and the bug has not been corrected untill Mar 30, 2004 14:30 GMT.
Reproduce code:
---
echo "I have get one hour too much!";
$to = "2004-06-01 00:00:00";
echo strtotime($to)."\n";
echo strtotime("$to +1 seconds ")."\n";
$newtime1 = strftime("%Y-%m-%d %H:%M:%S", strtotime("$to +1 seconds
"));
$newtime2 = strftime("%Y-%m-%d %H:%M:%S", strtotime("$to +1 day "));
echo "$to \n";
echo "+1 s= $newtime1\n";
echo "+1day=$newtime2\n";
$correct = strftime("%Y-%m-%d %H:%M:%S", strtotime("$to +1 second -1
hour"));
echo "correct: +1 s=$correct";
Expected result:
If $tm is the summertime, strtotime($tm +1 day) should return 24 hours
more, not 25 hours more.
If $tm is the wintertime and result is in the summertime, it should
return one extra hour.
--
Edit this bug report at http://bugs.php.net/?id=27780&edit=1
#25252 [Com]: CGI Application Timeout
ID: 25252 Comment by: bryan at bleu-tango dot com Reported By: brothererryn at atomicmonks dot com Status: Closed Bug Type: CGI related Operating System: Windows 2000 Professional PHP Version: 4.3.3 Assigned To: phildriscoll New Comment: I have been having a similar problem, but it happens in every version from 4.3.2 through the 3-30 stable win32 release. See Bug #27781 Previous Comments: [2004-03-30 01:26:55] [EMAIL PROTECTED] This bug (number 25252) is related to the fact that I accidentally put the cli rather than the cgi version of php.exe into the 4.3.3 installer. This was corrected after a few hours, and I'm certain that I didn't repeat the mistake in 4.3.4 or 4.3.5. Hence, I can state with confidence that the problems reported after I fixed the original error in August 2003, are not related to this bug. [2004-03-29 19:26:39] bryan at bleu-tango dot com I am having a similar problem with a similar setup. IIS 5, Win2k, PHP4.3.4 and 4.3.5 (tried with both). Any scripts that require database WRITES and executed with Internet Explorer (6.0) timeout. If you use Netscape, the script executes fine. If the script only does reads, you can use Netscape or IE. I have had this problem with PHPBB, in particular. This was not an issue in PHP 4.3.2 [2004-01-30 01:40:25] evan dot swendsen at shaw dot ca I have IIS 5.0 win Win 2K server with php 4.3.4 (from the installer and I'm getting the same thing) i tried pasting the 4.3.4 zip over top and im still getting it. HELP!! [2003-08-28 08:48:46] notepad at codewalkers dot com i'm not sure the problem is fixed, cause i had the same problem having downloaded the installer after this conversation took place. got it working with dan's suggestion, using the stable release. you may want to double check [2003-08-27 07:38:23] [EMAIL PROTECTED] Installer package has been updated with the correct php.exe. 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/25252 -- Edit this bug report at http://bugs.php.net/?id=25252&edit=1
#27782 [NEW]: Wrong behaviour of next() and prev()
From: giovanni at giacobbi dot net Operating system: Linux PHP version: 4.3.4 PHP Bug Type: Scripting Engine problem Bug description: Wrong behaviour of next() and prev() Description: As stated in documentation, next() returns the NEXT element in the array and THEN increases internal pointer. Thus, when this function returns FALSE, I expect the internal pointer to be in the last position, thus prev() should return end()-1 element. Reproduce code: --- http://bugs.php.net/?id=27782&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27782&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27782&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27782&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27782&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27782&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27782&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27782&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27782&r=support Expected behavior: http://bugs.php.net/fix.php?id=27782&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27782&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27782&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27782&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27782&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27782&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27782&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27782&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27782&r=float
#27756 [Opn->Bgs]: ImageSetThickness + ImageArc = strange results
ID: 27756 Updated by: [EMAIL PROTECTED] Reported By: info at silisoftware dot com -Status: Open +Status: Bogus Bug Type: GD related Operating System: Windows XP Pro PHP Version: 4.3.5 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 That is the nature of the arc drawing algorithm inside the GD library. Previous Comments: [2004-03-29 10:44:20] info at silisoftware dot com Description: Drawing an arc with an image thickness of other than 1 produces very strange results. The thicker the line specified, the "hairier" it gets. At 5px it's uneven, 25px quite ragged, at 50px and above it gets very non-round. The best way I can show the problem is with some sample images: http://www.silisoftware.com/temp/imagearc/ Not sure if it's a related issue, but I notice if I use the same code to draw an arc from 1-360 degrees, it looks like a big hairy "+" instead of a "o", but if I draw from 0-360 degrees it becomes a 1px circle, no matter what I specify for ImageSetThickness. Reproduce code: --- $imagethickness = 100; $gdimg_output = ImageCreateTrueColor(400, 400); $color_bg = ImageColorAllocate($gdimg_output, 0, 0, 255); $color_fg = ImageColorAllocate($gdimg_output, 255, 0, 0); ImageSetThickness($gdimg_output, $imagethickness); ImageFilledRectangle($gdimg_output, 0, 0, 400, 400, $color_bg); ImageArc($gdimg_output, 200, 200, 200, 200, 90, 360, $color_fg); ImagePNG($gdimg_output); Expected result: 100px thick, 270-degree red arc on blue background Actual result: -- This: http://www.silisoftware.com/temp/imagearc/100.png 270-degree red arc on blue background, but thickness varies from 1px to 100px, it looks "hairy", with a tendency to elongate into a "+" rather than a "o" (more pronounced the thicker the line is set to). -- Edit this bug report at http://bugs.php.net/?id=27756&edit=1
#27744 [Com]: 141.23 - 141.00 = 0.22999999999999 ?
ID: 27744 Comment by: garbo_doe at hotmail dot com Reported By: t dot steve at ariadne-quatra dot com Status: Bogus Bug Type: Math related Operating System: Windows 2000 Server SP4 PHP Version: 5.0.0RC1 New Comment: IMHO I think this is a bug. Of course there are problems with floatingpoint values in binary form, especially when rounded many times. But in an operation like it shouldn't return "0.00" but "0.01". I did a quick test in Delphi: showmessage(floattostr(750 - 749.99)); returns "0.01, not "0.00". I had to solve it in PHP but multiplying with 100, then subtract and then divide the result by 100 again. It's not pretty :-D (0.00999[infinite 9's] IS exactly the same as 0.01, but it should remember the "infinite" with a bit or something, so (1/3)*3 = 1 and not 0.9) (this is similar as bug #8164) Previous Comments: [2004-03-29 01:06:46] [EMAIL PROTECTED] Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. Thank you for your interest in PHP. . [2004-03-29 01:05:32] t dot steve at ariadne-quatra dot com Description: Subtraction does not work as expected. Windows 2000 Server SP4 IIS5 PHP5RC1 Reproduce code: --- $result=141.23-141.00; echo $result; (or $result=141.23-141; echo $result; - same result) Expected result: 0.23 Actual result: -- 0.22 -- Edit this bug report at http://bugs.php.net/?id=27744&edit=1
#27781 [NEW]: Scripts timeout when called by IE
From: bryan at bleu-tango dot com Operating system: Windows 2000 Server PHP version: 4CVS-2004-03-30 (stable) PHP Bug Type: IIS related Bug description: Scripts timeout when called by IE Description: I have had this problem with all versions of PHP from 4.3.2 up to the 3-30 stable release. When a PHP script is called from Internet Explorer that requires database writes, the script will hang, with the following written to the System event log: "The script started from the URL '/phpbb2/profile.php' with parameters '' has not responded within the configured timeout period. The HTTP server is terminating the script." This occurrs in phpbb, as well as phpMyAdmin. It occurrs if the database is mySQL OR MSSQL. The commonality seems to be database writes and IE. I have also attempted to run everything under the Administrator account, to rule out any permissions issues. Same result. -- Edit bug report at http://bugs.php.net/?id=27781&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27781&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27781&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27781&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27781&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27781&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27781&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27781&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27781&r=support Expected behavior: http://bugs.php.net/fix.php?id=27781&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27781&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27781&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27781&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27781&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27781&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27781&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27781&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27781&r=float
#27747 [Fbk->Opn]: ISAPI modul is not working
ID: 27747 User updated by: T dot Hauck at janaserver dot de Reported By: T dot Hauck at janaserver dot de -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: W2k PHP Version: 4.3.5 New Comment: No, i do not have the Zend extensions loaded, i don't have any extension loaded right now. Previous Comments: [2004-03-30 10:35:44] [EMAIL PROTECTED] Do you have any Zend extensions being loaded in php.ini? [2004-03-30 10:08:03] T dot Hauck at janaserver dot de With the isapi dll from version 4.3.4 is now diffrent, php crashes. Useing the "php4isapi.dll" from version 4.3.5 and the "php4ts.dll" from version 4.3.4 does NOT crash, and everything works fine. So the error must be in the "php4ts.dll" So i think the "php4ts.dll" raises some kind of exeption, what is catched in the "php4isapi.dll", how is than terminating the thread (on the server) how called the "HttpExtensionProc" function. Thomas [2004-03-30 09:09:31] [EMAIL PROTECTED] Could you please try replacing php4isapi.dll with the one in 4.3.4? [2004-03-30 04:05:43] T dot Hauck at janaserver dot de Hallo, i'am again. I just downloaded the sourcecode from php 3.4.5 and find the followring: Calling "_endthread();" in the "HttpExtensionProc" will always kill the thread on the server how called the "HttpExtensionProc" ! That looks to my as a huge bug. I mean the php modul can not just kill a thread on the server, or do i see this wrong ? (than i quit my job as software developer) [2004-03-30 02:03:43] T dot Hauck at janaserver dot de I disabled all extensions, same crash. As soon the thread exist how called the ISAPI extension the server crashes. This may be diffrent on each server implementation, and some server my only exit the isapi thread when thy a shut down. And the IIS may report not a error when shutting down at all. Bugreport 27741 and 27751 report simular or even the same crashes. All when they updatet from version 4.3.4 to 4.3.5. Thomas 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/27747 -- Edit this bug report at http://bugs.php.net/?id=27747&edit=1
#27738 [Opn->Fbk]: php crashes when calling odbc_pconnect(...)
ID: 27738
Updated by: [EMAIL PROTECTED]
Reported By: info at bitart dot at
-Status: Open
+Status: Feedback
Bug Type: ODBC related
Operating System: win xp
PHP Version: 4.3.5
New Comment:
Do you have any zend extensions loaded via php.ini?
Previous Comments:
[2004-03-29 07:35:05] sengelmann at gmx dot de
Same PRoblem with Windows 2000 Prof.
Error: (zend_hash_index_find)
[2004-03-27 15:00:20] info at bitart dot at
Description:
Very simple:
when calling
odbc_pconnect("myDatabase","","");
--> php.exe crashes.
odbc_connect("myDatabase","","");
--> works fine.
It works also fine on several other versions of PHP.
The Database is Access2000.
Binary WIN32 version of PHP.
Webserver: Apache.
Reproduce code:
---
Expected result:
no crash...
Actual result:
--
php.exe crashes.
--
Edit this bug report at http://bugs.php.net/?id=27738&edit=1
#27779 [Opn->Bgs]: fopen problem
ID: 27779 Updated by: [EMAIL PROTECTED] Reported By: baloor at clara dot co dot uk -Status: Open +Status: Bogus Bug Type: IIS related Operating System: Windows 2000 s-pack 4 PHP Version: 4.3.4 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. Thank you for your interest in PHP. As the error messages implies this is a simple file system permissions errors, the INI settings you've mentioned have no relevance in this case. Previous Comments: [2004-03-30 10:41:50] baloor at clara dot co dot uk Description: Hi I have problem with fopen $FX_fso = fopen($FX_fpath,"r+"); I look in php.ini and I think everytign is OK like register_globals = Off allow_url_fopen = On This scrip is for counter and it's fonctionnaly on other server. Expected result: Warning: fopen(my_datacounter/counter01.txt): failed to open stream: Permission denied in c:\inetpub\wwwroot\compteur_v1.1\compteur.php on line 21 and other... -- Edit this bug report at http://bugs.php.net/?id=27779&edit=1
#27780 [NEW]: strtotime(+1 xxx) returns 1 more hours
From: Hua dot Qu at volvo dot com
Operating system: Windows 2000
PHP version: 4.3.4
PHP Bug Type: Date/time related
Bug description: strtotime(+1 xxx) returns 1 more hours
Description:
strtotime($tm + 1 xxx) always adds one more hour to the result, if the
result-time is in the summertime, no matter $tm is in the summertime or
not.
It is the same in PHP CVS (5.0.x-dev) Built On: Mar 30, 2004 14:30 GMT
I think it is the daylight-savings-time problem. Perhaps, $tm is not
checked if it is already in the daylight-savings-time.
There are already some similar reports, but they did not get the point,
and the bug has not been corrected untill Mar 30, 2004 14:30 GMT.
Reproduce code:
---
echo "I have get one hour too much!";
$to = "2004-06-01 00:00:00";
echo strtotime($to)."\n";
echo strtotime("$to +1 seconds ")."\n";
$newtime1 = strftime("%Y-%m-%d %H:%M:%S", strtotime("$to +1 seconds "));
$newtime2 = strftime("%Y-%m-%d %H:%M:%S", strtotime("$to +1 day "));
echo "$to \n";
echo "+1 s= $newtime1\n";
echo "+1day=$newtime2\n";
$correct = strftime("%Y-%m-%d %H:%M:%S", strtotime("$to +1 second -1
hour"));
echo "correct: +1 s=$correct";
Expected result:
If $tm is the summertime, strtotime($tm +1 day) should return 24 hours
more, not 25 hours more.
If $tm is the wintertime and result is in the summertime, it should return
one extra hour.
--
Edit bug report at http://bugs.php.net/?id=27780&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27780&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27780&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27780&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27780&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27780&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27780&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27780&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27780&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27780&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27780&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27780&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27780&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27780&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27780&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27780&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27780&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27780&r=float
#27779 [NEW]: fopen problem
From: baloor at clara dot co dot uk Operating system: Windows 2000 s-pack 4 PHP version: 4.3.4 PHP Bug Type: IIS related Bug description: fopen problem Description: Hi I have problem with fopen $FX_fso = fopen($FX_fpath,"r+"); I look in php.ini and I think everytign is OK like register_globals = Off allow_url_fopen = On This scrip is for counter and it's fonctionnaly on other server. Expected result: Warning: fopen(my_datacounter/counter01.txt): failed to open stream: Permission denied in c:\inetpub\wwwroot\compteur_v1.1\compteur.php on line 21 and other... -- Edit bug report at http://bugs.php.net/?id=27779&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27779&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27779&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27779&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27779&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27779&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27779&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27779&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27779&r=support Expected behavior: http://bugs.php.net/fix.php?id=27779&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27779&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27779&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27779&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27779&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27779&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27779&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27779&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27779&r=float
#27747 [Opn->Fbk]: ISAPI modul is not working
ID: 27747 Updated by: [EMAIL PROTECTED] Reported By: T dot Hauck at janaserver dot de -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: W2k PHP Version: 4.3.5 New Comment: Do you have any Zend extensions being loaded in php.ini? Previous Comments: [2004-03-30 10:08:03] T dot Hauck at janaserver dot de With the isapi dll from version 4.3.4 is now diffrent, php crashes. Useing the "php4isapi.dll" from version 4.3.5 and the "php4ts.dll" from version 4.3.4 does NOT crash, and everything works fine. So the error must be in the "php4ts.dll" So i think the "php4ts.dll" raises some kind of exeption, what is catched in the "php4isapi.dll", how is than terminating the thread (on the server) how called the "HttpExtensionProc" function. Thomas [2004-03-30 09:09:31] [EMAIL PROTECTED] Could you please try replacing php4isapi.dll with the one in 4.3.4? [2004-03-30 04:05:43] T dot Hauck at janaserver dot de Hallo, i'am again. I just downloaded the sourcecode from php 3.4.5 and find the followring: Calling "_endthread();" in the "HttpExtensionProc" will always kill the thread on the server how called the "HttpExtensionProc" ! That looks to my as a huge bug. I mean the php modul can not just kill a thread on the server, or do i see this wrong ? (than i quit my job as software developer) [2004-03-30 02:03:43] T dot Hauck at janaserver dot de I disabled all extensions, same crash. As soon the thread exist how called the ISAPI extension the server crashes. This may be diffrent on each server implementation, and some server my only exit the isapi thread when thy a shut down. And the IIS may report not a error when shutting down at all. Bugreport 27741 and 27751 report simular or even the same crashes. All when they updatet from version 4.3.4 to 4.3.5. Thomas [2004-03-29 15:46:46] com at sambarserver dot info Same in the Sambar Server, the ISAPI is broken. Btw. 4.3.5RC4-dev is working without issues. Steffen 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/27747 -- Edit this bug report at http://bugs.php.net/?id=27747&edit=1
#27741 [Opn->Fbk]: IIS down while request .php file
ID: 27741 Updated by: [EMAIL PROTECTED] Reported By: yjt at 5kg dot net -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows 2000 Server PHP Version: 4.3.5 New Comment: Do you have any Zend Extensions loaded in PHP.ini ? Previous Comments: [2004-03-29 21:51:10] yjt at 5kg dot net problem shows on any script, such as below: [2004-03-29 15:51:14] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-03-29 03:32:26] franz dot winter at gbo dot com The same problem (frustrated sunday). W2K event-log shows "The service could not connect Instance 5...". CGI/Fast CGI mode is running (with the event-log message), ISAPI is not running at all. [2004-03-28 19:46:37] yjt at 5kg dot net Description: php 4.3.5 installed in win2k server & iis 5, when request a page,show errors below: Unknown list entry type in request shutdown (2) in Unknown on line 0. open php error log and found errors in event viewer: c-client[1264], PHP Warning: Unknown list entry type in request shutdown (2) in Unknown on line 0. I tried isapi and cgi mode : in isapi mode, w3svc halt and cannot restart, only way is restart the server; in cgi mode, application popup show "inetinfo.exe" error for several times. end of report. -- Edit this bug report at http://bugs.php.net/?id=27741&edit=1
#27773 [Opn->Csd]: Segmentation fault (core dumped) if -DZTS
ID: 27773 User updated by: krasnov at euroweb dot ru Reported By: krasnov at euroweb dot ru -Status: Open +Status: Closed Bug Type: Reproducible crash Operating System: FreeBSD 4.8 RELEASE PHP Version: 4.3.5 New Comment: Zend Support was notified. Previous Comments: [2004-03-30 10:11:04] krasnov at euroweb dot ru Thank you for your attention, so I think this bug may be closed as Bogus. Regard, Oleg [2004-03-30 10:02:08] [EMAIL PROTECTED] So? It might mean that it's just no longer compatible with PHP 4.3.5; those things happen. Anyway, the problem does seem related to something else though: persistent resources in zend extensions. [2004-03-30 09:59:37] krasnov at euroweb dot ru But you have changed PHP code while version of Zend Optimizer ramains the same! [2004-03-30 09:51:48] [EMAIL PROTECTED] Report this bug to the zend guys then, as it is not a problem with PHP but with their optimizer. regards, Derick [2004-03-30 09:06:25] krasnov at euroweb dot ru The same effect with the latest ZendOptimizer-2.5.1 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/27773 -- Edit this bug report at http://bugs.php.net/?id=27773&edit=1
#27750 [Com]: CLI script generates a "Please tell Microsoft about this problem".
ID: 27750 Comment by: mike at microspread dot com Reported By: richard dot quadling at carval dot co dot uk Status: Bogus Bug Type: Reproducible crash Operating System: Windows XP Pro SP1 PHP Version: 4.3.5 New Comment: Yep, you got me on the optimizer. Sorry Previous Comments: [2004-03-30 10:08:42] [EMAIL PROTECTED] The Zend Optimizer is NOT part of the default install. [2004-03-30 10:01:23] mike at microspread dot com What kind of support is this? The printer dll and Zend optimizer are part of the default install. Therefore there should be better support than to tell us to go somewhere else and clasifing the status as BOGUS. Telling me to go to the support page actually doesn't tell me where to where to look for support. I don't know the internals of PHP. I don't understand what PECL means. How do you expect us to know that. We've helped by narrowing the problem, but it is still a problem with PHP. I did a quick search on the PECL site and can't find a reference to a print package. Richard, I now see that my PHP bug is different than yours, and I'm sorry that I muddied up your bug submission. I thought I was doing pretty good when I searched the bug database for 4.3.5 and found the same message as I was getting being "Please tell Microsoft about this problem". P.S. There is no way to enter a ZEND support ticket for the ZEND optimizer, so that suggestion also isn't very good. [2004-03-30 04:13:52] [EMAIL PROTECTED] OK. So this is not a bug in php itself. Please see http://www.zend.com/support/ for zend support options. [2004-03-30 04:09:44] richard dot quadling at carval dot co dot uk By removing the ZEND Optimizer entries in the PHP.INI file, I have removed the problem. I have copied my PHP.INI file from C:\WINDOWS to C:\PHP\CLI and removed the ZEND optimizer section from the new INI file. Then, I've changed the "Open" command from ... C:\PHP\CLI\PHP.EXE "%1" to C:\PHP\CLI\PHP.EXE -c C:\PHP\CLI\PHP.INI "%1" I am no longer receiving any errors. Regards, Richard Quadling. [2004-03-30 03:28:42] richard dot quadling at carval dot co dot uk My CLI issue has nothing to do with the printer extension. My PHP.INI has no extensions enabled. ;Windows Extensions ;Note that MySQL and ODBC support is now built in, so no dll is needed for it. ; ;extension=php_bz2.dll ;extension=php_cpdf.dll ;extension=php_crack.dll ;extension=php_curl.dll ;extension=php_db.dll ;extension=php_dba.dll ;extension=php_dbase.dll ;extension=php_dbx.dll ;extension=php_domxml.dll ;extension=php_exif.dll ;extension=php_fdf.dll ;extension=php_filepro.dll ;extension=php_gd2.dll ;extension=php_gettext.dll ;extension=php_hyperwave.dll ;extension=php_iconv.dll ;extension=php_ifx.dll ;extension=php_iisfunc.dll ;extension=php_imap.dll ;extension=php_interbase.dll ;extension=php_java.dll ;extension=php_ldap.dll ;extension=php_mbstring.dll ;extension=php_mcrypt.dll ;extension=php_mhash.dll ;extension=php_mime_magic.dll ;extension=php_ming.dll ;extension=php_mssql.dll ;extension=php_msql.dll ;extension=php_oci8.dll ;extension=php_openssl.dll ;extension=php_oracle.dll ;extension=php_pdf.dll ;extension=php_pgsql.dll ;extension=php_printer.dll ;extension=php_shmop.dll ;extension=php_snmp.dll ;extension=php_sockets.dll ;extension=php_sybase_ct.dll ;extension=php_w32api.dll ;extension=php_xmlrpc.dll ;extension=php_xslt.dll ;extension=php_yaz.dll ;extension=php_zip.dll All files in the c:\PHP directory are from the zip version of 4.3.5. (25/03/2004 3:33pm) The following extensions were NOT updated as part of this release: C:\PHP\extensions\php_iisfunc.dll C:\PHP\extensions\php_printer.dll C:\PHP\extensions\php_iconv.dll These extensions are NOT enabled in PHP.INI and I have removed them from the extensions directory. I am STILL getting this problem even with the following script. As this script is NOT using ANY extensions and I am NOT loading ANY extensions in my PHP.INI file, I can only conclude that this IS an issue with PHP and NOT any PECL extension. The above script does generate a different offset. AppName: php.exe AppVer: 4.3.5.5 ModName: unknown ModVer: 0.0.0.0 Offset: 00ac41f0 Even ... generates the same error. I am executing the PHP files via the command line. I have added PHP to PATHEXT (which allows PHP files to be executed like a BAT/COM/EXE file. I have removed all the windows scripting extensions (VBS/VBE/JS/JSE/WSF/WSH). Using Windows Explorer|Tools|Folder Options
#27773 [Opn]: Segmentation fault (core dumped) if -DZTS
ID: 27773 User updated by: krasnov at euroweb dot ru Reported By: krasnov at euroweb dot ru Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 4.8 RELEASE PHP Version: 4.3.5 New Comment: Thank you for your attention, so I think this bug may be closed as Bogus. Regard, Oleg Previous Comments: [2004-03-30 10:02:08] [EMAIL PROTECTED] So? It might mean that it's just no longer compatible with PHP 4.3.5; those things happen. Anyway, the problem does seem related to something else though: persistent resources in zend extensions. [2004-03-30 09:59:37] krasnov at euroweb dot ru But you have changed PHP code while version of Zend Optimizer ramains the same! [2004-03-30 09:51:48] [EMAIL PROTECTED] Report this bug to the zend guys then, as it is not a problem with PHP but with their optimizer. regards, Derick [2004-03-30 09:06:25] krasnov at euroweb dot ru The same effect with the latest ZendOptimizer-2.5.1 [2004-03-30 08:55:26] krasnov at euroweb dot ru Complete list of directives in pnp.ini -- [Zend] zend_optimizer.optimization_level=15 zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-2.1.0 zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-2.1.0 zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so -- Without php.ini all works and do not carshes. The same config with php 4.3.4 works fine. 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/27773 -- Edit this bug report at http://bugs.php.net/?id=27773&edit=1
#27750 [Bgs]: CLI script generates a "Please tell Microsoft about this problem".
ID: 27750 Updated by: [EMAIL PROTECTED] Reported By: richard dot quadling at carval dot co dot uk Status: Bogus Bug Type: Reproducible crash Operating System: Windows XP Pro SP1 PHP Version: 4.3.5 New Comment: The Zend Optimizer is NOT part of the default install. Previous Comments: [2004-03-30 10:01:23] mike at microspread dot com What kind of support is this? The printer dll and Zend optimizer are part of the default install. Therefore there should be better support than to tell us to go somewhere else and clasifing the status as BOGUS. Telling me to go to the support page actually doesn't tell me where to where to look for support. I don't know the internals of PHP. I don't understand what PECL means. How do you expect us to know that. We've helped by narrowing the problem, but it is still a problem with PHP. I did a quick search on the PECL site and can't find a reference to a print package. Richard, I now see that my PHP bug is different than yours, and I'm sorry that I muddied up your bug submission. I thought I was doing pretty good when I searched the bug database for 4.3.5 and found the same message as I was getting being "Please tell Microsoft about this problem". P.S. There is no way to enter a ZEND support ticket for the ZEND optimizer, so that suggestion also isn't very good. [2004-03-30 04:13:52] [EMAIL PROTECTED] OK. So this is not a bug in php itself. Please see http://www.zend.com/support/ for zend support options. [2004-03-30 04:09:44] richard dot quadling at carval dot co dot uk By removing the ZEND Optimizer entries in the PHP.INI file, I have removed the problem. I have copied my PHP.INI file from C:\WINDOWS to C:\PHP\CLI and removed the ZEND optimizer section from the new INI file. Then, I've changed the "Open" command from ... C:\PHP\CLI\PHP.EXE "%1" to C:\PHP\CLI\PHP.EXE -c C:\PHP\CLI\PHP.INI "%1" I am no longer receiving any errors. Regards, Richard Quadling. [2004-03-30 03:28:42] richard dot quadling at carval dot co dot uk My CLI issue has nothing to do with the printer extension. My PHP.INI has no extensions enabled. ;Windows Extensions ;Note that MySQL and ODBC support is now built in, so no dll is needed for it. ; ;extension=php_bz2.dll ;extension=php_cpdf.dll ;extension=php_crack.dll ;extension=php_curl.dll ;extension=php_db.dll ;extension=php_dba.dll ;extension=php_dbase.dll ;extension=php_dbx.dll ;extension=php_domxml.dll ;extension=php_exif.dll ;extension=php_fdf.dll ;extension=php_filepro.dll ;extension=php_gd2.dll ;extension=php_gettext.dll ;extension=php_hyperwave.dll ;extension=php_iconv.dll ;extension=php_ifx.dll ;extension=php_iisfunc.dll ;extension=php_imap.dll ;extension=php_interbase.dll ;extension=php_java.dll ;extension=php_ldap.dll ;extension=php_mbstring.dll ;extension=php_mcrypt.dll ;extension=php_mhash.dll ;extension=php_mime_magic.dll ;extension=php_ming.dll ;extension=php_mssql.dll ;extension=php_msql.dll ;extension=php_oci8.dll ;extension=php_openssl.dll ;extension=php_oracle.dll ;extension=php_pdf.dll ;extension=php_pgsql.dll ;extension=php_printer.dll ;extension=php_shmop.dll ;extension=php_snmp.dll ;extension=php_sockets.dll ;extension=php_sybase_ct.dll ;extension=php_w32api.dll ;extension=php_xmlrpc.dll ;extension=php_xslt.dll ;extension=php_yaz.dll ;extension=php_zip.dll All files in the c:\PHP directory are from the zip version of 4.3.5. (25/03/2004 3:33pm) The following extensions were NOT updated as part of this release: C:\PHP\extensions\php_iisfunc.dll C:\PHP\extensions\php_printer.dll C:\PHP\extensions\php_iconv.dll These extensions are NOT enabled in PHP.INI and I have removed them from the extensions directory. I am STILL getting this problem even with the following script. As this script is NOT using ANY extensions and I am NOT loading ANY extensions in my PHP.INI file, I can only conclude that this IS an issue with PHP and NOT any PECL extension. The above script does generate a different offset. AppName: php.exe AppVer: 4.3.5.5 ModName: unknown ModVer: 0.0.0.0 Offset: 00ac41f0 Even ... generates the same error. I am executing the PHP files via the command line. I have added PHP to PATHEXT (which allows PHP files to be executed like a BAT/COM/EXE file. I have removed all the windows scripting extensions (VBS/VBE/JS/JSE/WSF/WSH). Using Windows Explorer|Tools|Folder Options|File Types|PHP, the default method of Run is set to run C:\PHP\CLI\PHP.EXE "%1" This allows me to simply type the name of script at the command line and have the o
#27747 [Fbk->Opn]: ISAPI modul is not working
ID: 27747 User updated by: T dot Hauck at janaserver dot de Reported By: T dot Hauck at janaserver dot de -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: W2k PHP Version: 4.3.5 New Comment: With the isapi dll from version 4.3.4 is now diffrent, php crashes. Useing the "php4isapi.dll" from version 4.3.5 and the "php4ts.dll" from version 4.3.4 does NOT crash, and everything works fine. So the error must be in the "php4ts.dll" So i think the "php4ts.dll" raises some kind of exeption, what is catched in the "php4isapi.dll", how is than terminating the thread (on the server) how called the "HttpExtensionProc" function. Thomas Previous Comments: [2004-03-30 09:09:31] [EMAIL PROTECTED] Could you please try replacing php4isapi.dll with the one in 4.3.4? [2004-03-30 04:05:43] T dot Hauck at janaserver dot de Hallo, i'am again. I just downloaded the sourcecode from php 3.4.5 and find the followring: Calling "_endthread();" in the "HttpExtensionProc" will always kill the thread on the server how called the "HttpExtensionProc" ! That looks to my as a huge bug. I mean the php modul can not just kill a thread on the server, or do i see this wrong ? (than i quit my job as software developer) [2004-03-30 02:03:43] T dot Hauck at janaserver dot de I disabled all extensions, same crash. As soon the thread exist how called the ISAPI extension the server crashes. This may be diffrent on each server implementation, and some server my only exit the isapi thread when thy a shut down. And the IIS may report not a error when shutting down at all. Bugreport 27741 and 27751 report simular or even the same crashes. All when they updatet from version 4.3.4 to 4.3.5. Thomas [2004-03-29 15:46:46] com at sambarserver dot info Same in the Sambar Server, the ISAPI is broken. Btw. 4.3.5RC4-dev is working without issues. Steffen [2004-03-29 15:39:24] [EMAIL PROTECTED] Cannot reproduce this with IIS 5.0 on W2k. Do you have any extensions enabled in your php.ini? Are you sure you don't have any leftover dlls from previois php versions? 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/27747 -- Edit this bug report at http://bugs.php.net/?id=27747&edit=1
#27696 [Opn->Fbk]: ORA-24327 error
ID: 27696
Updated by: [EMAIL PROTECTED]
Reported By: gioppo at csi dot it
-Status: Open
+Status: Feedback
Bug Type: OCI8 related
Operating System: System Linux 2.2.19-6.2.1
PHP Version: Irrelevant
Assigned To: tony2001
New Comment:
So, you've solved it, yes?
This piece of code didn't help me much, just because I can't test it.
Previous Comments:
[2004-03-30 09:05:14] gioppo at csi dot it
We probably solved the problem bypassing tnsnames.ora.
We made the connection using tnsnames defined alias and it got errors
sometime.
Here is a chunk of php code (we used method b which gave errors
sometime, when we used d mode we always manage to make connection) any
hint? A problem on finding tnsnames?
NOTE OCILogon is a php library function so no hint on how to modify it,
but the behaviour meke me think about an environment problem:
we have a
Compile-time ORACLE_HOME /oracle_home for compiling OCI for php
but
ORACLE_HOME /oracle817/app/oracle/product/8.1.7
_ENV["ORACLE_HOME"] /oracle817/app/oracle/product/8.1.7
on env for apache and php (/oracle_home is a symbolic link to the
/oracle817/app/oracle/product/8.1.7 folder) could be that the OCI8 so
compiled have trouble on traversing the link?
/*
Multiple modes of connection are supported:
a. Local Database
$conn->Connect(false,'scott','tiger');
b. From tnsnames.ora
$conn->Connect(false,'scott','tiger',$tnsname);
$conn->Connect($tnsname,'scott','tiger');
c. Server + service name
$conn->Connect($serveraddress,'scott,'tiger',$service_name);
d. Server + SID
$conn->connectSID = true;
$conn->Connect($serveraddress,'scott,'tiger',$SID);
Example TNSName:
---
NATSOFT.DOMAIN =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = kermit)(PORT = 1523))
)
(CONNECT_DATA =
(SERVICE_NAME = natsoft.domain)
)
)
There are 3 connection modes, 0 = non-persistent, 1 = persistent, 2 =
force new connection
*/
function _connect($argHostname, $argUsername, $argPassword,
$argDatabasename,$mode=0)
{
$this->_errorMsg = false;
$this->_errorCode = false;
if($argHostname) { // added by Jorma Tuomainen
<[EMAIL PROTECTED]>
if (empty($argDatabasename)) $argDatabasename = $argHostname;
else {
if(strpos($argHostname,":")) {
$argHostinfo=explode(":",$argHostname);
$argHostname=$argHostinfo[0];
$argHostport=$argHostinfo[1];
} else {
$argHostport="1521";
}
if ($this->connectSID) {
$argDatabasename="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=".$argHostname
.")(PORT=$argHostport))(CONNECT_DATA=(SID=$argDatabasename)))";
} else
$argDatabasename="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=".$argHostname
.")(PORT=$argHostport))(CONNECT_DATA=(SERVICE_NAME=$argDatabasename)))";
}
}
if ($mode==1) {
$this->_connectionID = OCIPLogon($argUsername,$argPassword,
$argDatabasename);
if ($this->_connectionID && $this->autoRollback)
OCIrollback($this->_connectionID);
} else if ($mode==2) {
$this->_connectionID = OCINLogon($argUsername,$argPassword,
$argDatabasename);
} else {
$this->_connectionID = OCILogon($argUsername,$argPassword,
$argDatabasename);
}
if ($this->_connectionID === false) return false;
[2004-03-26 05:00:13] [EMAIL PROTECTED]
Please, try latest stable PHP release.
And try latest PHP5 snapshot, there are a lot of changes since
November.
I have no idea what code ADO uses to connect to Oracle, so please
provide a short example with standard PHP functions, not wrapped with
ADO or other wrapper.
[2004-03-25 17:16:32] gioppo at csi dot it
Here is a note from oracle metalink
The errors ( ORA-24327, OCI-21560) may indicate OCI usage error
if you are using OCI, can you verify if it's possible to physically
connect to a server process or dispatcher ( for MTS-configured DB) via
OCIServerAttach ... then try to authenticate one of more users via that
connection to
#27773 [Opn]: Segmentation fault (core dumped) if -DZTS
ID: 27773 Updated by: [EMAIL PROTECTED] Reported By: krasnov at euroweb dot ru Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 4.8 RELEASE PHP Version: 4.3.5 New Comment: So? It might mean that it's just no longer compatible with PHP 4.3.5; those things happen. Anyway, the problem does seem related to something else though: persistent resources in zend extensions. Previous Comments: [2004-03-30 09:59:37] krasnov at euroweb dot ru But you have changed PHP code while version of Zend Optimizer ramains the same! [2004-03-30 09:51:48] [EMAIL PROTECTED] Report this bug to the zend guys then, as it is not a problem with PHP but with their optimizer. regards, Derick [2004-03-30 09:06:25] krasnov at euroweb dot ru The same effect with the latest ZendOptimizer-2.5.1 [2004-03-30 08:55:26] krasnov at euroweb dot ru Complete list of directives in pnp.ini -- [Zend] zend_optimizer.optimization_level=15 zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-2.1.0 zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-2.1.0 zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so -- Without php.ini all works and do not carshes. The same config with php 4.3.4 works fine. [2004-03-30 08:46:19] [EMAIL PROTECTED] Do you have any PHP or Zend extensions loaded via php.ini? 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/27773 -- Edit this bug report at http://bugs.php.net/?id=27773&edit=1
#27750 [Com]: CLI script generates a "Please tell Microsoft about this problem".
ID: 27750 Comment by: mike at microspread dot com Reported By: richard dot quadling at carval dot co dot uk Status: Bogus Bug Type: Reproducible crash Operating System: Windows XP Pro SP1 PHP Version: 4.3.5 New Comment: What kind of support is this? The printer dll and Zend optimizer are part of the default install. Therefore there should be better support than to tell us to go somewhere else and clasifing the status as BOGUS. Telling me to go to the support page actually doesn't tell me where to where to look for support. I don't know the internals of PHP. I don't understand what PECL means. How do you expect us to know that. We've helped by narrowing the problem, but it is still a problem with PHP. I did a quick search on the PECL site and can't find a reference to a print package. Richard, I now see that my PHP bug is different than yours, and I'm sorry that I muddied up your bug submission. I thought I was doing pretty good when I searched the bug database for 4.3.5 and found the same message as I was getting being "Please tell Microsoft about this problem". P.S. There is no way to enter a ZEND support ticket for the ZEND optimizer, so that suggestion also isn't very good. Previous Comments: [2004-03-30 04:13:52] [EMAIL PROTECTED] OK. So this is not a bug in php itself. Please see http://www.zend.com/support/ for zend support options. [2004-03-30 04:09:44] richard dot quadling at carval dot co dot uk By removing the ZEND Optimizer entries in the PHP.INI file, I have removed the problem. I have copied my PHP.INI file from C:\WINDOWS to C:\PHP\CLI and removed the ZEND optimizer section from the new INI file. Then, I've changed the "Open" command from ... C:\PHP\CLI\PHP.EXE "%1" to C:\PHP\CLI\PHP.EXE -c C:\PHP\CLI\PHP.INI "%1" I am no longer receiving any errors. Regards, Richard Quadling. [2004-03-30 03:28:42] richard dot quadling at carval dot co dot uk My CLI issue has nothing to do with the printer extension. My PHP.INI has no extensions enabled. ;Windows Extensions ;Note that MySQL and ODBC support is now built in, so no dll is needed for it. ; ;extension=php_bz2.dll ;extension=php_cpdf.dll ;extension=php_crack.dll ;extension=php_curl.dll ;extension=php_db.dll ;extension=php_dba.dll ;extension=php_dbase.dll ;extension=php_dbx.dll ;extension=php_domxml.dll ;extension=php_exif.dll ;extension=php_fdf.dll ;extension=php_filepro.dll ;extension=php_gd2.dll ;extension=php_gettext.dll ;extension=php_hyperwave.dll ;extension=php_iconv.dll ;extension=php_ifx.dll ;extension=php_iisfunc.dll ;extension=php_imap.dll ;extension=php_interbase.dll ;extension=php_java.dll ;extension=php_ldap.dll ;extension=php_mbstring.dll ;extension=php_mcrypt.dll ;extension=php_mhash.dll ;extension=php_mime_magic.dll ;extension=php_ming.dll ;extension=php_mssql.dll ;extension=php_msql.dll ;extension=php_oci8.dll ;extension=php_openssl.dll ;extension=php_oracle.dll ;extension=php_pdf.dll ;extension=php_pgsql.dll ;extension=php_printer.dll ;extension=php_shmop.dll ;extension=php_snmp.dll ;extension=php_sockets.dll ;extension=php_sybase_ct.dll ;extension=php_w32api.dll ;extension=php_xmlrpc.dll ;extension=php_xslt.dll ;extension=php_yaz.dll ;extension=php_zip.dll All files in the c:\PHP directory are from the zip version of 4.3.5. (25/03/2004 3:33pm) The following extensions were NOT updated as part of this release: C:\PHP\extensions\php_iisfunc.dll C:\PHP\extensions\php_printer.dll C:\PHP\extensions\php_iconv.dll These extensions are NOT enabled in PHP.INI and I have removed them from the extensions directory. I am STILL getting this problem even with the following script. As this script is NOT using ANY extensions and I am NOT loading ANY extensions in my PHP.INI file, I can only conclude that this IS an issue with PHP and NOT any PECL extension. The above script does generate a different offset. AppName: php.exe AppVer: 4.3.5.5 ModName: unknown ModVer: 0.0.0.0 Offset: 00ac41f0 Even ... generates the same error. I am executing the PHP files via the command line. I have added PHP to PATHEXT (which allows PHP files to be executed like a BAT/COM/EXE file. I have removed all the windows scripting extensions (VBS/VBE/JS/JSE/WSF/WSH). Using Windows Explorer|Tools|Folder Options|File Types|PHP, the default method of Run is set to run C:\PHP\CLI\PHP.EXE "%1" This allows me to simply type the name of script at the command line and have the output (if any) appear on the console. The scripts I run in this way tend NOT to be used within a webserver and are normally scheduled using windows Tasks. This worked p
#25996 [Com]: Assignment by reference suppress index error
ID: 25996 Comment by: unknown at simplemachines dot org Reported By: hongnk at hotmail dot com Status: Verified Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS, 4CVS (2004-03-15) New Comment: I would like to say that this is a feature of PHP, and that it is working as intended. Why? This simple snippet explains it all: array( 'another' => array() ) ); $element = &$array['inner']['another'][]; $element['test'] = 1; $element['test2'] = 4; ?> This functionality makes sense, at least in this context. You're creating a new element, and getting it with the element reference. This can make things easier and possibly faster to work with - instead of this: array( 'another' => array() ) ); $element['test'] = 1; $element['test2'] = 4; $array['inner']['another'][] = $element; ?> Which is basically the same thing - just in a different order. I don't think this is a bug, and if it were to be fixed it would cause a lot of scripts - including ones I've written - to start generating notices when they shouldn't be. (as I always try to write notice-less code.) -[Unknown] Previous Comments: [2003-10-29 14:13:04] [EMAIL PROTECTED] Related to bug #26030 [2003-10-26 21:33:23] hongnk at hotmail dot com Description: Accessing array with uninitialized index will normally trigger error: $a=array(); $b=$a['unknown']; => undefined index error but if I assign by reference: $b=&$a['unknown']; then PHP no longer throw error. (The same goes for assigning undefined property to an object.) This makes it difficult to debug scripts. -- Edit this bug report at http://bugs.php.net/?id=25996&edit=1
#27773 [Bgs->Opn]: Segmentation fault (core dumped) if -DZTS
ID: 27773 User updated by: krasnov at euroweb dot ru Reported By: krasnov at euroweb dot ru -Status: Bogus +Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 4.8 RELEASE PHP Version: 4.3.5 New Comment: But you have changed PHP code while version of Zend Optimizer ramains the same! Previous Comments: [2004-03-30 09:51:48] [EMAIL PROTECTED] Report this bug to the zend guys then, as it is not a problem with PHP but with their optimizer. regards, Derick [2004-03-30 09:06:25] krasnov at euroweb dot ru The same effect with the latest ZendOptimizer-2.5.1 [2004-03-30 08:55:26] krasnov at euroweb dot ru Complete list of directives in pnp.ini -- [Zend] zend_optimizer.optimization_level=15 zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-2.1.0 zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-2.1.0 zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so -- Without php.ini all works and do not carshes. The same config with php 4.3.4 works fine. [2004-03-30 08:46:19] [EMAIL PROTECTED] Do you have any PHP or Zend extensions loaded via php.ini? [2004-03-30 07:17:40] krasnov at euroweb dot ru After removal of this code Apache 2.0.49 and Apache 2.0.48 stop to throw exceptions (means Segmentation Faults) in main thread upon -HUP (-1) or graceful restart. (Bug #27735) 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/27773 -- Edit this bug report at http://bugs.php.net/?id=27773&edit=1
#27772 [Opn->Fbk]: It crashes at the last of cgi_main.
ID: 27772
Updated by: [EMAIL PROTECTED]
Reported By: khagiya1 at yahoo dot co dot jp
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Windows Xp Professional Ver2002
PHP Version: 4.3.5
New Comment:
Does it work when you disable the ioncube_loader?
Previous Comments:
[2004-03-30 08:52:58] egarcia at egm dot as
You can get mor information from:
Bug #27141 PHP.exe crash on console.
[2004-03-30 08:47:06] egarcia at egm dot as
Well, I report a similar error when this version was in beta testing.
The product can be used with Zend Optimizer, this carsh constantly.
If I disable the Zend Optimizer 2.1b or 2.5 the product works OK, even
with the Zend Extensions enabled the product works OK.
The answer that I get about this incident not existent in the 4.3.4 was
that this problem is related to Zend and not to the PHP itself.
But reading the report with the Ioncube extensions must be related to
the Zend Engine or the PHP.
Regards,
[2004-03-30 05:22:00] khagiya1 at yahoo dot co dot jp
Description:
Please let me know.
I downloaded "PHP 4.3.5 (tar.gz) [4,706Kb]-26 March 2004." from
"http://www.php.net/downloads.php";
It is used building it personally.
It crash, although only built.
Reproduce code:
---
The example of a code to generate
[c:/hello.csp]
[php.ini]
zend_extension_ts = c:/ioncube_loader.dll
EThe following is performed on a console.
c:/php.exe -f c:/hello.csp
It is displayed on a screen as "hello!!".
Crash occurs together with it.
This is generated only when module(zend_extension_ts) is loaded.
It does not generate in module(extension).
When the code was seen, it had generated in the following places.
The following change went into TSRM/TSRM.c by php-4.3.4 to php-4.3.5.
*** TSRM/TSRM.c Tue Nov 11 14:17:17 2003 <-- 4.3.4
--- TSRM/TSRM.c Wed Dec 17 04:59:58 2003 <-- 4.3.5
***
*** 157,163
int j;
next_p = p->next;
! for (j=0; jstorage[j]);
}
free(p->storage);
--- 157,166
int j;
next_p = p->next;
! for (j=0; jcount; j++) {
! if (resource_types_table &&
resource_types_table[j].dtor) {
!
resource_types_table[j].dtor(p->storage[j], &p->storage); <--
cause the problem!!
! }
free(p->storage[j]);
}
free(p->storage);
sapi/cgi/cgi_main.c: line 1787 - 1792
--
php_module_shutdown(TSRMLS_C);
HLOG_LOG( HLOG_NOTICE, "php_module_shutdown" );
#ifdef ZTS
tsrm_shutdown();
#endif
--
show callstack.
1. php_module_shutdown
2. zend_shutdown
3. zend_shutdown_extensions
4. zend_llist_destroy
5. zend_extension_dtor
6. DL_UNLOAD <-- module(by zend_extension_ts) is unload here.
7. tsrm_shutdown <-- dtor can't be called.
--
Edit this bug report at http://bugs.php.net/?id=27772&edit=1
#27773 [Opn->Bgs]: Segmentation fault (core dumped) if -DZTS
ID: 27773
Updated by: [EMAIL PROTECTED]
Reported By: krasnov at euroweb dot ru
-Status: Open
+Status: Bogus
Bug Type: Reproducible crash
Operating System: FreeBSD 4.8 RELEASE
PHP Version: 4.3.5
New Comment:
Report this bug to the zend guys then, as it is not a problem with PHP
but with their optimizer.
regards,
Derick
Previous Comments:
[2004-03-30 09:06:25] krasnov at euroweb dot ru
The same effect with the latest ZendOptimizer-2.5.1
[2004-03-30 08:55:26] krasnov at euroweb dot ru
Complete list of directives in pnp.ini
--
[Zend]
zend_optimizer.optimization_level=15
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-2.1.0
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-2.1.0
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so
--
Without php.ini all works and do not carshes.
The same config with php 4.3.4 works fine.
[2004-03-30 08:46:19] [EMAIL PROTECTED]
Do you have any PHP or Zend extensions loaded via php.ini?
[2004-03-30 07:17:40] krasnov at euroweb dot ru
After removal of this code Apache 2.0.49 and Apache 2.0.48 stop to
throw exceptions (means Segmentation Faults) in main thread upon -HUP
(-1) or graceful restart. (Bug #27735)
[2004-03-30 06:44:01] krasnov at euroweb dot ru
I have found that php NOT crash if i remove the following code from
TSRM_API void tsrm_shutdown(void) (file TSRM.c)
---
if (resource_types_table && resource_types_table[j].dtor) {
resource_types_table[j].dtor(p->storage[j], &p->storage);
}
---
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/27773
--
Edit this bug report at http://bugs.php.net/?id=27773&edit=1
#27747 [Opn->Fbk]: ISAPI modul is not working
ID: 27747 Updated by: [EMAIL PROTECTED] Reported By: T dot Hauck at janaserver dot de -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: W2k PHP Version: 4.3.5 New Comment: Could you please try replacing php4isapi.dll with the one in 4.3.4? Previous Comments: [2004-03-30 04:05:43] T dot Hauck at janaserver dot de Hallo, i'am again. I just downloaded the sourcecode from php 3.4.5 and find the followring: Calling "_endthread();" in the "HttpExtensionProc" will always kill the thread on the server how called the "HttpExtensionProc" ! That looks to my as a huge bug. I mean the php modul can not just kill a thread on the server, or do i see this wrong ? (than i quit my job as software developer) [2004-03-30 02:03:43] T dot Hauck at janaserver dot de I disabled all extensions, same crash. As soon the thread exist how called the ISAPI extension the server crashes. This may be diffrent on each server implementation, and some server my only exit the isapi thread when thy a shut down. And the IIS may report not a error when shutting down at all. Bugreport 27741 and 27751 report simular or even the same crashes. All when they updatet from version 4.3.4 to 4.3.5. Thomas [2004-03-29 15:46:46] com at sambarserver dot info Same in the Sambar Server, the ISAPI is broken. Btw. 4.3.5RC4-dev is working without issues. Steffen [2004-03-29 15:39:24] [EMAIL PROTECTED] Cannot reproduce this with IIS 5.0 on W2k. Do you have any extensions enabled in your php.ini? Are you sure you don't have any leftover dlls from previois php versions? [2004-03-29 04:24:00] T dot Hauck at janaserver dot de Description: In version 4.3.5 the isapi modul is not working any more. Calling the isapi function to run the php script from within its own thread in the Server software will bring a access violation when this thread is ending. It looks to me as if php is corupting soem kind of data in the thread handling of windows. This allways happend calling "phpinfo();" in a script. Some other script work Ok for a while. Trying it on a apache server on w2k will bring up a errormessage that apache has a "access violation", by shutting down the apache. "phpinfo();" was called during the session. PHP has encountered an Access Violation at 01395DF7 This showed up running "phpgroupware" with ISAPI modul on the "Jana-Server" webserver, with php 4.3.5 All this startet when php 4.3.5 was installed, Non of this happend with php 4.3.4 -- Edit this bug report at http://bugs.php.net/?id=27747&edit=1
#27773 [Opn]: Segmentation fault (core dumped) if -DZTS
ID: 27773
User updated by: krasnov at euroweb dot ru
Reported By: krasnov at euroweb dot ru
Status: Open
Bug Type: Reproducible crash
Operating System: FreeBSD 4.8 RELEASE
PHP Version: 4.3.5
New Comment:
The same effect with the latest ZendOptimizer-2.5.1
Previous Comments:
[2004-03-30 08:55:26] krasnov at euroweb dot ru
Complete list of directives in pnp.ini
--
[Zend]
zend_optimizer.optimization_level=15
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-2.1.0
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-2.1.0
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so
--
Without php.ini all works and do not carshes.
The same config with php 4.3.4 works fine.
[2004-03-30 08:46:19] [EMAIL PROTECTED]
Do you have any PHP or Zend extensions loaded via php.ini?
[2004-03-30 07:17:40] krasnov at euroweb dot ru
After removal of this code Apache 2.0.49 and Apache 2.0.48 stop to
throw exceptions (means Segmentation Faults) in main thread upon -HUP
(-1) or graceful restart. (Bug #27735)
[2004-03-30 06:44:01] krasnov at euroweb dot ru
I have found that php NOT crash if i remove the following code from
TSRM_API void tsrm_shutdown(void) (file TSRM.c)
---
if (resource_types_table && resource_types_table[j].dtor) {
resource_types_table[j].dtor(p->storage[j], &p->storage);
}
---
[2004-03-30 05:30:20] krasnov at euroweb dot ru
And i have forgot about this option in php_config.h
/* #undef HAVE_REALPATH */
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/27773
--
Edit this bug report at http://bugs.php.net/?id=27773&edit=1
#27696 [Fbk->Opn]: ORA-24327 error
ID: 27696
User updated by: gioppo at csi dot it
Reported By: gioppo at csi dot it
-Status: Feedback
+Status: Open
Bug Type: OCI8 related
Operating System: System Linux 2.2.19-6.2.1
PHP Version: Irrelevant
Assigned To: tony2001
New Comment:
We probably solved the problem bypassing tnsnames.ora.
We made the connection using tnsnames defined alias and it got errors
sometime.
Here is a chunk of php code (we used method b which gave errors
sometime, when we used d mode we always manage to make connection) any
hint? A problem on finding tnsnames?
NOTE OCILogon is a php library function so no hint on how to modify it,
but the behaviour meke me think about an environment problem:
we have a
Compile-time ORACLE_HOME /oracle_home for compiling OCI for php
but
ORACLE_HOME /oracle817/app/oracle/product/8.1.7
_ENV["ORACLE_HOME"] /oracle817/app/oracle/product/8.1.7
on env for apache and php (/oracle_home is a symbolic link to the
/oracle817/app/oracle/product/8.1.7 folder) could be that the OCI8 so
compiled have trouble on traversing the link?
/*
Multiple modes of connection are supported:
a. Local Database
$conn->Connect(false,'scott','tiger');
b. From tnsnames.ora
$conn->Connect(false,'scott','tiger',$tnsname);
$conn->Connect($tnsname,'scott','tiger');
c. Server + service name
$conn->Connect($serveraddress,'scott,'tiger',$service_name);
d. Server + SID
$conn->connectSID = true;
$conn->Connect($serveraddress,'scott,'tiger',$SID);
Example TNSName:
---
NATSOFT.DOMAIN =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = kermit)(PORT = 1523))
)
(CONNECT_DATA =
(SERVICE_NAME = natsoft.domain)
)
)
There are 3 connection modes, 0 = non-persistent, 1 = persistent, 2 =
force new connection
*/
function _connect($argHostname, $argUsername, $argPassword,
$argDatabasename,$mode=0)
{
$this->_errorMsg = false;
$this->_errorCode = false;
if($argHostname) { // added by Jorma Tuomainen
<[EMAIL PROTECTED]>
if (empty($argDatabasename)) $argDatabasename = $argHostname;
else {
if(strpos($argHostname,":")) {
$argHostinfo=explode(":",$argHostname);
$argHostname=$argHostinfo[0];
$argHostport=$argHostinfo[1];
} else {
$argHostport="1521";
}
if ($this->connectSID) {
$argDatabasename="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=".$argHostname
.")(PORT=$argHostport))(CONNECT_DATA=(SID=$argDatabasename)))";
} else
$argDatabasename="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=".$argHostname
.")(PORT=$argHostport))(CONNECT_DATA=(SERVICE_NAME=$argDatabasename)))";
}
}
if ($mode==1) {
$this->_connectionID = OCIPLogon($argUsername,$argPassword,
$argDatabasename);
if ($this->_connectionID && $this->autoRollback)
OCIrollback($this->_connectionID);
} else if ($mode==2) {
$this->_connectionID = OCINLogon($argUsername,$argPassword,
$argDatabasename);
} else {
$this->_connectionID = OCILogon($argUsername,$argPassword,
$argDatabasename);
}
if ($this->_connectionID === false) return false;
Previous Comments:
[2004-03-26 05:00:13] [EMAIL PROTECTED]
Please, try latest stable PHP release.
And try latest PHP5 snapshot, there are a lot of changes since
November.
I have no idea what code ADO uses to connect to Oracle, so please
provide a short example with standard PHP functions, not wrapped with
ADO or other wrapper.
[2004-03-25 17:16:32] gioppo at csi dot it
Here is a note from oracle metalink
The errors ( ORA-24327, OCI-21560) may indicate OCI usage error
if you are using OCI, can you verify if it's possible to physically
connect to a server process or dispatcher ( for MTS-configured DB) via
OCIServerAttach ... then try to authenticate one of more users via that
connection to start one or more database sessions (via
OCISessionBegin).
IF OCIServerAttach fails and OCISessionBegin is invoked, you may get
errors.
According to OCI Programmer's guide (OCISessionBegin)
For rel
#27773 [Fbk->Opn]: Segmentation fault (core dumped) if -DZTS
ID: 27773
User updated by: krasnov at euroweb dot ru
Reported By: krasnov at euroweb dot ru
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: FreeBSD 4.8 RELEASE
PHP Version: 4.3.5
New Comment:
Complete list of directives in pnp.ini
--
[Zend]
zend_optimizer.optimization_level=15
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-2.1.0
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-2.1.0
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so
--
Without php.ini all works and do not carshes.
The same config with php 4.3.4 works fine.
Previous Comments:
[2004-03-30 08:46:19] [EMAIL PROTECTED]
Do you have any PHP or Zend extensions loaded via php.ini?
[2004-03-30 07:17:40] krasnov at euroweb dot ru
After removal of this code Apache 2.0.49 and Apache 2.0.48 stop to
throw exceptions (means Segmentation Faults) in main thread upon -HUP
(-1) or graceful restart. (Bug #27735)
[2004-03-30 06:44:01] krasnov at euroweb dot ru
I have found that php NOT crash if i remove the following code from
TSRM_API void tsrm_shutdown(void) (file TSRM.c)
---
if (resource_types_table && resource_types_table[j].dtor) {
resource_types_table[j].dtor(p->storage[j], &p->storage);
}
---
[2004-03-30 05:30:20] krasnov at euroweb dot ru
And i have forgot about this option in php_config.h
/* #undef HAVE_REALPATH */
[2004-03-30 05:29:09] krasnov at euroweb dot ru
I ma really sorry it was misprint, I meant bug #27735
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/27773
--
Edit this bug report at http://bugs.php.net/?id=27773&edit=1
#27772 [Com]: It crashes at the last of cgi_main.
ID: 27772
Comment by: egarcia at egm dot as
Reported By: khagiya1 at yahoo dot co dot jp
Status: Open
Bug Type: Reproducible crash
Operating System: Windows Xp Professional Ver2002
PHP Version: 4.3.5
New Comment:
You can get mor information from:
Bug #27141 PHP.exe crash on console.
Previous Comments:
[2004-03-30 08:47:06] egarcia at egm dot as
Well, I report a similar error when this version was in beta testing.
The product can be used with Zend Optimizer, this carsh constantly.
If I disable the Zend Optimizer 2.1b or 2.5 the product works OK, even
with the Zend Extensions enabled the product works OK.
The answer that I get about this incident not existent in the 4.3.4 was
that this problem is related to Zend and not to the PHP itself.
But reading the report with the Ioncube extensions must be related to
the Zend Engine or the PHP.
Regards,
[2004-03-30 05:22:00] khagiya1 at yahoo dot co dot jp
Description:
Please let me know.
I downloaded "PHP 4.3.5 (tar.gz) [4,706Kb]-26 March 2004." from
"http://www.php.net/downloads.php";
It is used building it personally.
It crash, although only built.
Reproduce code:
---
The example of a code to generate
[c:/hello.csp]
[php.ini]
zend_extension_ts = c:/ioncube_loader.dll
EThe following is performed on a console.
c:/php.exe -f c:/hello.csp
It is displayed on a screen as "hello!!".
Crash occurs together with it.
This is generated only when module(zend_extension_ts) is loaded.
It does not generate in module(extension).
When the code was seen, it had generated in the following places.
The following change went into TSRM/TSRM.c by php-4.3.4 to php-4.3.5.
*** TSRM/TSRM.c Tue Nov 11 14:17:17 2003 <-- 4.3.4
--- TSRM/TSRM.c Wed Dec 17 04:59:58 2003 <-- 4.3.5
***
*** 157,163
int j;
next_p = p->next;
! for (j=0; jstorage[j]);
}
free(p->storage);
--- 157,166
int j;
next_p = p->next;
! for (j=0; jcount; j++) {
! if (resource_types_table &&
resource_types_table[j].dtor) {
!
resource_types_table[j].dtor(p->storage[j], &p->storage); <--
cause the problem!!
! }
free(p->storage[j]);
}
free(p->storage);
sapi/cgi/cgi_main.c: line 1787 - 1792
--
php_module_shutdown(TSRMLS_C);
HLOG_LOG( HLOG_NOTICE, "php_module_shutdown" );
#ifdef ZTS
tsrm_shutdown();
#endif
--
show callstack.
1. php_module_shutdown
2. zend_shutdown
3. zend_shutdown_extensions
4. zend_llist_destroy
5. zend_extension_dtor
6. DL_UNLOAD <-- module(by zend_extension_ts) is unload here.
7. tsrm_shutdown <-- dtor can't be called.
--
Edit this bug report at http://bugs.php.net/?id=27772&edit=1
#27735 [Com]: restart of apache2 via kill -1 or apachectl causes crash
ID: 27735 Comment by: noackjr at alumni dot rice dot edu Reported By: as at netoholic dot de Status: Bogus Bug Type: Reproducible crash Operating System: Linux PHP Version: 4.3.5 New Comment: I have this exact same problem (identical backtrace, etc.) with FreeBSD 5.2.1, Apache 2.0.49, and PHP 4.3.5. Reverting to the PCRE from 4.3.4 (replacing ext/pcre) also resolved the problem for me. Does PCRE 4.5 expose an Apache bug, or is this a problem with PCRE 4.5? If it's the former, leave it as Bogus. Otherwise, this is a PHP bug because it's bundled code. Previous Comments: [2004-03-30 06:57:35] chb at muc dot de I don't think this bug is "Bogus". I'm experiencing the same problems using Apache 2.0.49 with RedHat Linux 8.0 (same backtrace, ...). So far I've been able to track it down to the PCRE extension. When I add "--without-pcre" everything is fine. I've now replaced "ext/pcre", using the version from PHP 4.3.4 (PCRE 4.3) and the problem is gone. My suspicion is that the new PCRE version has memory allocation problems. [2004-03-29 10:45:53] [EMAIL PROTECTED] read above comment. [2004-03-29 10:45:38] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. The backtrace shows the crash to reside deep inside AP2 code and not in PHP, hence this is not a PHP bug. [2004-03-29 05:25:01] as at netoholic dot de my backtrace: (gdb) bt #0 0x4b8f2630 in ?? () #1 0x080728a1 in regex_cleanup (preg=0x0) at util.c:258 #2 0x4b56c39d in run_cleanups (cref=0x80ac838) at apr_pools.c:1951 #3 0x4b56bbe9 in apr_pool_clear (pool=0x80ac828) at apr_pools.c:693 #4 0x0806e4d2 in main (argc=4, argv=0xb1d38f34) at main.c:574 #5 0x4b6558ae in __libc_start_main () from /lib/libc.so.6 apache built with prefork mpm... [2004-03-29 05:03:36] krasnov at euroweb dot ru It is awful but all my attempts to core PHP 4.3.5 with --enable-debug were failed. But in release mode CGI part cores even when it reads php.ini file during "make test". And mod_php behaves as written before... Here is the part of core file after "make test" (sorry but without debug). #0 0x808644f in ?? () #1 0x808605e in ?? () #2 0x808856f in ?? () #3 0x80886c3 in ?? () #4 0x8088649 in ?? () #5 0x80886c3 in ?? () #6 0x8088649 in ?? () #7 0x80886c3 in ?? () #8 0x8088649 in ?? () #9 0x80886c3 in ?? () #10 0x8088649 in ?? () #11 0x80886c3 in ?? () #12 0x8088649 in ?? () #13 0x80886c3 in ?? () #14 0x8088649 in ?? () #15 0x80886c3 in ?? () #16 0x8088649 in ?? () #17 0x80886c3 in ?? () #18 0x8088649 in ?? () #19 0x80886c3 in ?? () #20 0x8088649 in ?? () #21 0x80886c3 in ?? () #22 0x8088649 in ?? () #23 0x80886c3 in ?? () #24 0x8088649 in ?? () #25 0x80886c3 in ?? () #26 0x8088649 in ?? () #27 0x80886c3 in ?? () #28 0x8088649 in ?? () #29 0x80886c3 in ?? () #30 0x8088649 in ?? () #31 0x80886c3 in ?? () #32 0x8088649 in ?? () #33 0x80886c3 in ?? () #34 0x8088649 in ?? () #35 0x80886c3 in ?? () #36 0x8088649 in ?? () #37 0x80886c3 in ?? () #38 0x8088649 in ?? () #39 0x80886c3 in ?? () #40 0x8088649 in ?? () #41 0x80886c3 in ?? () #42 0x8088649 in ?? () #43 0x80886c3 in ?? () #44 0x8088649 in ?? () #45 0x80886c3 in ?? () 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/27735 -- Edit this bug report at http://bugs.php.net/?id=27735&edit=1
#27772 [Com]: It crashes at the last of cgi_main.
ID: 27772
Comment by: egarcia at egm dot as
Reported By: khagiya1 at yahoo dot co dot jp
Status: Open
Bug Type: Reproducible crash
Operating System: Windows Xp Professional Ver2002
PHP Version: 4.3.5
New Comment:
Well, I report a similar error when this version was in beta testing.
The product can be used with Zend Optimizer, this carsh constantly.
If I disable the Zend Optimizer 2.1b or 2.5 the product works OK, even
with the Zend Extensions enabled the product works OK.
The answer that I get about this incident not existent in the 4.3.4 was
that this problem is related to Zend and not to the PHP itself.
But reading the report with the Ioncube extensions must be related to
the Zend Engine or the PHP.
Regards,
Previous Comments:
[2004-03-30 05:22:00] khagiya1 at yahoo dot co dot jp
Description:
Please let me know.
I downloaded "PHP 4.3.5 (tar.gz) [4,706Kb]-26 March 2004." from
"http://www.php.net/downloads.php";
It is used building it personally.
It crash, although only built.
Reproduce code:
---
The example of a code to generate
[c:/hello.csp]
[php.ini]
zend_extension_ts = c:/ioncube_loader.dll
EThe following is performed on a console.
c:/php.exe -f c:/hello.csp
It is displayed on a screen as "hello!!".
Crash occurs together with it.
This is generated only when module(zend_extension_ts) is loaded.
It does not generate in module(extension).
When the code was seen, it had generated in the following places.
The following change went into TSRM/TSRM.c by php-4.3.4 to php-4.3.5.
*** TSRM/TSRM.c Tue Nov 11 14:17:17 2003 <-- 4.3.4
--- TSRM/TSRM.c Wed Dec 17 04:59:58 2003 <-- 4.3.5
***
*** 157,163
int j;
next_p = p->next;
! for (j=0; jstorage[j]);
}
free(p->storage);
--- 157,166
int j;
next_p = p->next;
! for (j=0; jcount; j++) {
! if (resource_types_table &&
resource_types_table[j].dtor) {
!
resource_types_table[j].dtor(p->storage[j], &p->storage); <--
cause the problem!!
! }
free(p->storage[j]);
}
free(p->storage);
sapi/cgi/cgi_main.c: line 1787 - 1792
--
php_module_shutdown(TSRMLS_C);
HLOG_LOG( HLOG_NOTICE, "php_module_shutdown" );
#ifdef ZTS
tsrm_shutdown();
#endif
--
show callstack.
1. php_module_shutdown
2. zend_shutdown
3. zend_shutdown_extensions
4. zend_llist_destroy
5. zend_extension_dtor
6. DL_UNLOAD <-- module(by zend_extension_ts) is unload here.
7. tsrm_shutdown <-- dtor can't be called.
--
Edit this bug report at http://bugs.php.net/?id=27772&edit=1
#27773 [Opn->Fbk]: Segmentation fault (core dumped) if -DZTS
ID: 27773
Updated by: [EMAIL PROTECTED]
Reported By: krasnov at euroweb dot ru
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: FreeBSD 4.8 RELEASE
PHP Version: 4.3.5
New Comment:
Do you have any PHP or Zend extensions loaded via php.ini?
Previous Comments:
[2004-03-30 07:17:40] krasnov at euroweb dot ru
After removal of this code Apache 2.0.49 and Apache 2.0.48 stop to
throw exceptions (means Segmentation Faults) in main thread upon -HUP
(-1) or graceful restart. (Bug #27735)
[2004-03-30 06:44:01] krasnov at euroweb dot ru
I have found that php NOT crash if i remove the following code from
TSRM_API void tsrm_shutdown(void) (file TSRM.c)
---
if (resource_types_table && resource_types_table[j].dtor) {
resource_types_table[j].dtor(p->storage[j], &p->storage);
}
---
[2004-03-30 05:30:20] krasnov at euroweb dot ru
And i have forgot about this option in php_config.h
/* #undef HAVE_REALPATH */
[2004-03-30 05:29:09] krasnov at euroweb dot ru
I ma really sorry it was misprint, I meant bug #27735
[2004-03-30 05:27:00] krasnov at euroweb dot ru
Description:
If I compile PHP 4.3.5 with --enable-experimental-zts or with
--with-apxs2=/usr/local/apache2/bin/apxs (which affection are the
same), I see "Segmentation fault (core dumped)" as a result of any php
script in CLI mode.
And if I uses --with-apxs2, I get result like bug #17735, which you
have closed as Bogus, but it is not right, cause it does not depend on
Apache.
Here is compilation options:
CFLAGS='-O -pipe -march=pentiumpro -D__USE_UNIX98 -D_REENTRANT
-D_THREAD_SAFE -DHAVE_BROKEN_REALPATH -I/usr/local/include/pthread
/linuxthreads -L/usr/local/lib -llthread -llgcc_r' \
LIBS='-L/usr/local/lib -llthread -llgcc_r' \
./configure \
--prefix=/usr/local/php \
--with-tsrm-pthreads \
--enable-experimental-zts
Actual result:
--
=
CWD : /usr/local/src/php.new.test/php-4.3.5
PHP : /usr/local/src/php.new.test/php-4.3.5/sapi/cli/php
PHP_SAPI: cli
PHP_VERSION : 4.3.5
ZEND_VERSION: 1.3.0
PHP_OS : FreeBSD - FreeBSD xx.xxx.ru 4.8-RELEASE FreeBSD
4.8-RELEASE #0: Thu Aug i386
INI actual : /usr/local/php/lib/php.ini
More .INIs : Segmentation fault (core dumped)
Extra dirs :
=
TIME START 2004-03-30 14:25:44
=
FAIL EXPECT [tests/run-test/test001.phpt]
FAIL EXPECTF [tests/run-test/test002.phpt]
FAIL EXPECTREGEX [tests/run-test/test003.phpt]
FAIL INI section allows '=' [tests/run-test/test004.phpt]
SKIP Error message handling (without ZendOptimizer)
[tests/run-test/test005.phpt] (reason: Zend Optimizer is
loadedSegmentation fault (core dumped))
PASS Error messages are shown [tests/run-test/test006.phpt]
FAIL dirname test [tests/run-test/test007.phpt]
FAIL Error message handling (with ZendOptimizer)
[tests/run-test/test008.phpt]
FAIL Trivial "Hello World" test [tests/basic/001.phpt]
FAIL Simple POST Method test [tests/basic/002.phpt]
FAIL GET and POST Method combined [tests/basic/003.phpt]
FAIL Two variables in POST data [tests/basic/004.phpt]
FAIL Three variables in POST data [tests/basic/005.phpt]
FAIL Add 3 variables together and print result [tests/basic/006.phpt]
FAIL Multiply 3 variables and print result [tests/basic/007.phpt]
FAIL Divide 3 variables and print result [tests/basic/008.phpt]
FAIL Subtract 3 variables and print result [tests/basic/009.phpt]
FAIL Testing | and & operators [tests/basic/010.phpt]
FAIL Testing $argc and $argv handling (GET) [tests/basic/011.phpt]
FAIL Testing $argc and $argv handling (cli) [tests/basic/012.phpt]
FAIL Bug #20539 (PHP CLI Segmentation Fault)
[tests/basic/bug20539.phpt]
FAIL Methods via variable name, bug #20120
[tests/classes/bug20120.phpt]
--
Edit this bug report at http://bugs.php.net/?id=27773&edit=1
#27776 [Bgs]: arrays in class behave differently than expected
ID: 27776 Updated by: [EMAIL PROTECTED] Reported By: pedja at uzice dot net Status: Bogus Bug Type: Arrays related Operating System: Windows XP PHP Version: 4.3.4 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. Thank you for your interest in PHP. Previous Comments: [2004-03-30 08:42:40] [EMAIL PROTECTED] 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 not a bug. [2004-03-30 08:39:09] pedja at uzice dot net Hmm... i found out what was the problem. Instead of $this->$testarray[$counter] i should use $this->testarray[$counter] [2004-03-30 08:32:14] pedja at uzice dot net Description: I created array as class property. It does not work as expected. Here is an example: $testarray[$counter] = chr ($counter); } } } $testvar = new testclass(); print_r ($testvar->$testarray); ?> The result of this code is array containing one record. It should contain several records. If I cahnge this code to use global variable instead of class property ... ... it works: I get what I expected - array containing several records. -- Edit this bug report at http://bugs.php.net/?id=27776&edit=1
#27764 [Opn->Asn]: Stored Procedure with no result sets doesn't set output params
ID: 27764 Updated by: [EMAIL PROTECTED] Reported By: Jeff dot Leigh at Premconf dot com -Status: Open +Status: Assigned Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.3.5 -Assigned To: +Assigned To: fmk Previous Comments: [2004-03-29 17:30:11] Jeff dot Leigh at Premconf dot com Description: Create an MSSQL stored procedure that does not return any result sets. It only takes input parameters, and returns parameters. Create php code to called stored procedure, bind, etc, etc. Execute the procedure. You will not get any bug reported, and the output param variables will not be changed. mssql_execute will not return anything, since there are no result sets. Thus, 'mssql_next_result' cannot be called. If I force the stored procedure to return at least one result set, the output parameter is set properly. (There is nothing wrong with my MSSQL configuration from what I can tell. I can connect and do standard queries just fine.) Oh, and the current documentation says there is an optional second parameter for mssql_execute()... a boolean. If I try to use it, I get an error regarding an incorrect number of arguments to mssql_execute(). I'm assuming this was depreciated, but not documented. -- Edit this bug report at http://bugs.php.net/?id=27764&edit=1
#27776 [Opn->Bgs]: arrays in class behave differently than expected
ID: 27776 Updated by: [EMAIL PROTECTED] Reported By: pedja at uzice dot net -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Windows XP PHP Version: 4.3.4 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 not a bug. Previous Comments: [2004-03-30 08:39:09] pedja at uzice dot net Hmm... i found out what was the problem. Instead of $this->$testarray[$counter] i should use $this->testarray[$counter] [2004-03-30 08:32:14] pedja at uzice dot net Description: I created array as class property. It does not work as expected. Here is an example: $testarray[$counter] = chr ($counter); } } } $testvar = new testclass(); print_r ($testvar->$testarray); ?> The result of this code is array containing one record. It should contain several records. If I cahnge this code to use global variable instead of class property ... ... it works: I get what I expected - array containing several records. -- Edit this bug report at http://bugs.php.net/?id=27776&edit=1
#27765 [Opn->Bgs]: is_dir on large file make an error
ID: 27765 Updated by: [EMAIL PROTECTED] Reported By: chris at root dot pl -Status: Open +Status: Bogus Bug Type: Directory function related Operating System: Linux 2.4.25 SMP PHP Version: 4.3.4 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 Your libc cannot handle files that big and throws the error you are seeing. This is not a PHP bug. Previous Comments: [2004-03-29 17:59:56] chris at root dot pl Description: when I make is_dir function of file which has about 4gb (DVD ISO), then PHP makes an error: Warning: is_dir(): Stat failed for /var/ftp/public/filest_dvd.iso (errno=75 - Value too large for defined data type) in /var/htdocs/html/akacjenet/include/addons/ftpfiles.inc on line 17 Reproduce code: --- it doesn't matter Expected result: i want to know is that file is a file or a directory... I have a small script for catalogue ftp content into mysql database Actual result: -- Warning: is_dir(): Stat failed for /var/ftp/public/filest_dvd.iso (errno=75 - Value too large for defined data type) in /var/htdocs/html/akacjenet/include/addons/ftpfiles.inc on line 17 -- Edit this bug report at http://bugs.php.net/?id=27765&edit=1
#27776 [Opn]: arrays in class behave differently than expected
ID: 27776 User updated by: pedja at uzice dot net Reported By: pedja at uzice dot net Status: Open Bug Type: Arrays related Operating System: Windows XP PHP Version: 4.3.4 New Comment: Hmm... i found out what was the problem. Instead of $this->$testarray[$counter] i should use $this->testarray[$counter] Previous Comments: [2004-03-30 08:32:14] pedja at uzice dot net Description: I created array as class property. It does not work as expected. Here is an example: $testarray[$counter] = chr ($counter); } } } $testvar = new testclass(); print_r ($testvar->$testarray); ?> The result of this code is array containing one record. It should contain several records. If I cahnge this code to use global variable instead of class property ... ... it works: I get what I expected - array containing several records. -- Edit this bug report at http://bugs.php.net/?id=27776&edit=1
#27777 [NEW]: basic authentication broken
From: mikx at mikx dot de
Operating system: Windows XP Pro
PHP version: 5.0.0RC1
PHP Bug Type: SOAP related
Bug description: basic authentication broken
Description:
When using basic authentication the soap client does not authenticate
itself automaticly using the options array. You need to add the login and
password in the uri.
Reproduce code:
---
_NOT working_
$client = new SoapClient("http://foo.com/bar.wsdl";, array(
"login" => "yourLogin",
"password" => "yourPassword"));
_working_
$client = new
SoapClient("http://yourLogin:[EMAIL PROTECTED]/bar.wsdl");
Expected result:
The SOAP client should take the login and password from the options array
and automaticly authenticate itself.
--
Edit bug report at http://bugs.php.net/?id=2&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=2&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=2&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=2&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=2&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=2&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=2&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=2&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=2&r=support
Expected behavior: http://bugs.php.net/fix.php?id=2&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=2&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=2&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=2&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=2&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=2&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=2&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=2&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=2&r=float
#27776 [NEW]: arrays in class behave differently than expected
From: pedja at uzice dot net Operating system: Windows XP PHP version: 4.3.4 PHP Bug Type: Arrays related Bug description: arrays in class behave differently than expected Description: I created array as class property. It does not work as expected. Here is an example: $testarray[$counter] = chr ($counter); } } } $testvar = new testclass(); print_r ($testvar->$testarray); ?> The result of this code is array containing one record. It should contain several records. If I cahnge this code to use global variable instead of class property ... ... it works: I get what I expected - array containing several records. -- Edit bug report at http://bugs.php.net/?id=27776&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27776&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27776&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27776&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27776&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27776&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27776&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27776&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27776&r=support Expected behavior: http://bugs.php.net/fix.php?id=27776&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27776&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27776&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27776&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27776&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27776&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27776&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27776&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27776&r=float
#27775 [NEW]: Using session_start() simultaneous causes script to crash
From: mattias at pfeiffer dot dk Operating system: Debian GNU/Linux PHP version: 4.3.4 PHP Bug Type: Session related Bug description: Using session_start() simultaneous causes script to crash Description: I'm experiencing a problem using session_start() simultaneous - ie. in 2 iframes. An example: I have a page with to iframes embedded. Frame 1 runs a script with a while(true), and at line 1 a session_start(). A page is loaded into Frame 2, with session_start() as the only content. (Except for of course) The page in Frame 2 will not be parsed unless the session_start() is removed from the top. It seems as when 2 pages are loaded/loading and executing session_start() simultaneous, PHP will fail to interpret one of them. I've tested and determined this issue at two self-contained systems. === System information: PHP: 2.4.3 Apache: 1.3.29 Configured with: '../configure' '--prefix=/usr' '--with-apxs=/usr/bin/apxs' '--with-regex=php' '--with-config-file-path=/etc/php4/apache' '--disable-rpath' '--enable-memory-limit' '--disable-debug' '--with-layout=GNU' '--with-pear=/usr/share/php' '--enable-calendar' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid' '--enable-bcmath' '--with-bz2' '--enable-ctype' '--with-db4' '--with-iconv' '--enable-exif' '--enable-filepro' '--enable-ftp' '--with-gettext' '--enable-mbstring' '--with-pcre-regex=/usr' '--enable-shmop' '--enable-sockets' '--enable-wddx' '--disable-xml' '--with-expat-dir=/usr' '--enable-yp' '--with-zlib' '--without-pgsql' '--with-kerberos=/usr' '--with-openssl=/usr' '--with-exec-dir=/usr/lib/php4/libexec' '--disable-static' '--with-curl=shared,/usr' '--with-dom=shared,/usr' '--with-dom-xslt=shared,/usr' '--with-dom-exslt=shared,/usr' '--with-zlib-dir=/usr' '--with-gd=shared,/usr' '--enable-gd-native-ttf' '--with-jpeg-dir=shared,/usr' '--with-xpm-dir=shared,/usr/X11R6' '--with-png-dir=shared,/usr' '--with-freetype-dir=shared,/usr' '--with-imap=shared,/usr' '--with-imap-ssl' '--with-ldap=shared,/usr' '--with-mcal=shared,/usr' '--with-mhash=shared,/usr' '--with-mm' '--with-mysql=shared,/usr' '--with-unixODBC=shared,/usr' '--with-recode=shared,/usr' '--enable-xslt=shared' '--with-xslt-sablot=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-sybase-ct=shared,/usr' '--with-ttf=shared,/usr' '--with-t1lib=shared,/usr' Reproduce code: --- I've put up an example: http://home.madd.dk/phptest/ Expected result: I've expected frameA to produce desired output "HEST", but it seems like frameA.php fails to be parsed. Actual result: -- See "Expected result" -- Edit bug report at http://bugs.php.net/?id=27775&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27775&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27775&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27775&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27775&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27775&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27775&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27775&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27775&r=support Expected behavior: http://bugs.php.net/fix.php?id=27775&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27775&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27775&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27775&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27775&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27775&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27775&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27775&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27775&r=float
#27719 [Opn->Csd]: mktime returns incorrect timestamp for dst days
ID: 27719 Updated by: [EMAIL PROTECTED] Reported By: schmidt dot a at rogers dot com -Status: Open +Status: Closed Bug Type: Date/time related Operating System: FreeBSD 4.4 PHP Version: 5.0.0RC1 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2004-03-26 14:50:12] schmidt dot a at rogers dot com problem fixed. thanks. [2004-03-26 14:25:25] [EMAIL PROTECTED] I have committed a fix which uses the 4am offset instead of 2 there around line 192 in datetime.c. Any chance you could test that and let me know if it fixes your problem? [2004-03-26 14:00:40] [EMAIL PROTECTED] I made the changed referenced above to address this bug: http://bugs.php.net/27533 Perhaps the solution here is to offset it to +3 or +4 instead to get the baseline timestamp. [2004-03-26 13:39:51] schmidt dot a at rogers dot com Ok I've done some more testing, FreeBSD mktime will return -1 when passed in 2 am for the day when clocks are being moved ahead, since 2am should never exist. I'm not sure how linux handles this (maybe returns a 3am timestamp). This coupled with the change to ext/standard/datetime.c line 192+ which always changes the hour 2am if its 12 or 1 am. Unfortunatly this has a bad effect of messing up 12am and 1am for daylight savings days which are valid hours. http://cvs.php.net/diff.php/php-src/ext/standard/datetime.c?r1=1.116&r2=1.117&ty=h I'm not sure what the best solution is, but I hope this helps. [2004-03-26 12:13:44] schmidt dot a at rogers dot com I tested it out on FreeBSD 5.2.1 and still had the same problem using the latest snapshot: [GD:andrew] ~ (1) > uname -a FreeBSD my.domain 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23 20:45:55 GMT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 [GD:andrew] ~ (2) > php -v PHP 5.0.0RC2-dev (cgi) (built: Mar 26 2004 12:19:53) Copyright (c) 1997-2004 The PHP Group Zend Engine v2.0.0RC2-dev, Copyright (c) 1998-2004 Zend Technologies [GD:andrew] ~ (3) > php test_mktime.php Content-type: text/html X-Powered-By: PHP/5.0.0RC2-dev -7262 -7262 -7262 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/27719 -- Edit this bug report at http://bugs.php.net/?id=27719&edit=1
#27774 [Opn->Bgs]: Bug in strtotime calculation (bissextile year ?)
ID: 27774
Updated by: [EMAIL PROTECTED]
Reported By: eparis at plurimedia dot fr
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Linux Debian / Solaris ... any
PHP Version: Irrelevant
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
march 30 - 1 month = feb 30; that doesn't exist and is the same as
march 1.
Previous Comments:
[2004-03-30 07:14:55] eparis at plurimedia dot fr
Description:
Since today (2004-03-30), we experience a calculation error when using
strtotime("-1 month") to get previous month date. Maybe this error is
due to the fact that 2004 is a bissextile year. The last bissextile
year was 1996.
Reproduce code:
---
The actual computer date must be 2004-03-30.
Expected result:
2004-02-29
Actual result:
--
2004-03-01
--
Edit this bug report at http://bugs.php.net/?id=27774&edit=1
#27773 [Opn]: Segmentation fault (core dumped) if -DZTS
ID: 27773
User updated by: krasnov at euroweb dot ru
Reported By: krasnov at euroweb dot ru
Status: Open
Bug Type: Reproducible crash
Operating System: FreeBSD 4.8 RELEASE
PHP Version: 4.3.5
New Comment:
After removal of this code Apache 2.0.49 and Apache 2.0.48 stop to
throw exceptions (means Segmentation Faults) in main thread upon -HUP
(-1) or graceful restart. (Bug #27735)
Previous Comments:
[2004-03-30 06:44:01] krasnov at euroweb dot ru
I have found that php NOT crash if i remove the following code from
TSRM_API void tsrm_shutdown(void) (file TSRM.c)
---
if (resource_types_table && resource_types_table[j].dtor) {
resource_types_table[j].dtor(p->storage[j], &p->storage);
}
---
[2004-03-30 05:30:20] krasnov at euroweb dot ru
And i have forgot about this option in php_config.h
/* #undef HAVE_REALPATH */
[2004-03-30 05:29:09] krasnov at euroweb dot ru
I ma really sorry it was misprint, I meant bug #27735
[2004-03-30 05:27:00] krasnov at euroweb dot ru
Description:
If I compile PHP 4.3.5 with --enable-experimental-zts or with
--with-apxs2=/usr/local/apache2/bin/apxs (which affection are the
same), I see "Segmentation fault (core dumped)" as a result of any php
script in CLI mode.
And if I uses --with-apxs2, I get result like bug #17735, which you
have closed as Bogus, but it is not right, cause it does not depend on
Apache.
Here is compilation options:
CFLAGS='-O -pipe -march=pentiumpro -D__USE_UNIX98 -D_REENTRANT
-D_THREAD_SAFE -DHAVE_BROKEN_REALPATH -I/usr/local/include/pthread
/linuxthreads -L/usr/local/lib -llthread -llgcc_r' \
LIBS='-L/usr/local/lib -llthread -llgcc_r' \
./configure \
--prefix=/usr/local/php \
--with-tsrm-pthreads \
--enable-experimental-zts
Actual result:
--
=
CWD : /usr/local/src/php.new.test/php-4.3.5
PHP : /usr/local/src/php.new.test/php-4.3.5/sapi/cli/php
PHP_SAPI: cli
PHP_VERSION : 4.3.5
ZEND_VERSION: 1.3.0
PHP_OS : FreeBSD - FreeBSD xx.xxx.ru 4.8-RELEASE FreeBSD
4.8-RELEASE #0: Thu Aug i386
INI actual : /usr/local/php/lib/php.ini
More .INIs : Segmentation fault (core dumped)
Extra dirs :
=
TIME START 2004-03-30 14:25:44
=
FAIL EXPECT [tests/run-test/test001.phpt]
FAIL EXPECTF [tests/run-test/test002.phpt]
FAIL EXPECTREGEX [tests/run-test/test003.phpt]
FAIL INI section allows '=' [tests/run-test/test004.phpt]
SKIP Error message handling (without ZendOptimizer)
[tests/run-test/test005.phpt] (reason: Zend Optimizer is
loadedSegmentation fault (core dumped))
PASS Error messages are shown [tests/run-test/test006.phpt]
FAIL dirname test [tests/run-test/test007.phpt]
FAIL Error message handling (with ZendOptimizer)
[tests/run-test/test008.phpt]
FAIL Trivial "Hello World" test [tests/basic/001.phpt]
FAIL Simple POST Method test [tests/basic/002.phpt]
FAIL GET and POST Method combined [tests/basic/003.phpt]
FAIL Two variables in POST data [tests/basic/004.phpt]
FAIL Three variables in POST data [tests/basic/005.phpt]
FAIL Add 3 variables together and print result [tests/basic/006.phpt]
FAIL Multiply 3 variables and print result [tests/basic/007.phpt]
FAIL Divide 3 variables and print result [tests/basic/008.phpt]
FAIL Subtract 3 variables and print result [tests/basic/009.phpt]
FAIL Testing | and & operators [tests/basic/010.phpt]
FAIL Testing $argc and $argv handling (GET) [tests/basic/011.phpt]
FAIL Testing $argc and $argv handling (cli) [tests/basic/012.phpt]
FAIL Bug #20539 (PHP CLI Segmentation Fault)
[tests/basic/bug20539.phpt]
FAIL Methods via variable name, bug #20120
[tests/classes/bug20120.phpt]
--
Edit this bug report at http://bugs.php.net/?id=27773&edit=1
#27774 [NEW]: Bug in strtotime calculation (bissextile year ?)
From: eparis at plurimedia dot fr
Operating system: Linux Debian / Solaris ... any
PHP version: Irrelevant
PHP Bug Type: Date/time related
Bug description: Bug in strtotime calculation (bissextile year ?)
Description:
Since today (2004-03-30), we experience a calculation error when using
strtotime("-1 month") to get previous month date. Maybe this error is due
to the fact that 2004 is a bissextile year. The last bissextile year was
1996.
Reproduce code:
---
The actual computer date must be 2004-03-30.
Expected result:
2004-02-29
Actual result:
--
2004-03-01
--
Edit bug report at http://bugs.php.net/?id=27774&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27774&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27774&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27774&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27774&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27774&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27774&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27774&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27774&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27774&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27774&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27774&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27774&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27774&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27774&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27774&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27774&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27774&r=float
#27735 [Com]: restart of apache2 via kill -1 or apachectl causes crash
ID: 27735 Comment by: chb at muc dot de Reported By: as at netoholic dot de Status: Bogus Bug Type: Reproducible crash Operating System: Linux PHP Version: 4.3.5 New Comment: I don't think this bug is "Bogus". I'm experiencing the same problems using Apache 2.0.49 with RedHat Linux 8.0 (same backtrace, ...). So far I've been able to track it down to the PCRE extension. When I add "--without-pcre" everything is fine. I've now replaced "ext/pcre", using the version from PHP 4.3.4 (PCRE 4.3) and the problem is gone. My suspicion is that the new PCRE version has memory allocation problems. Previous Comments: [2004-03-29 10:45:53] [EMAIL PROTECTED] read above comment. [2004-03-29 10:45:38] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. The backtrace shows the crash to reside deep inside AP2 code and not in PHP, hence this is not a PHP bug. [2004-03-29 05:25:01] as at netoholic dot de my backtrace: (gdb) bt #0 0x4b8f2630 in ?? () #1 0x080728a1 in regex_cleanup (preg=0x0) at util.c:258 #2 0x4b56c39d in run_cleanups (cref=0x80ac838) at apr_pools.c:1951 #3 0x4b56bbe9 in apr_pool_clear (pool=0x80ac828) at apr_pools.c:693 #4 0x0806e4d2 in main (argc=4, argv=0xb1d38f34) at main.c:574 #5 0x4b6558ae in __libc_start_main () from /lib/libc.so.6 apache built with prefork mpm... [2004-03-29 05:03:36] krasnov at euroweb dot ru It is awful but all my attempts to core PHP 4.3.5 with --enable-debug were failed. But in release mode CGI part cores even when it reads php.ini file during "make test". And mod_php behaves as written before... Here is the part of core file after "make test" (sorry but without debug). #0 0x808644f in ?? () #1 0x808605e in ?? () #2 0x808856f in ?? () #3 0x80886c3 in ?? () #4 0x8088649 in ?? () #5 0x80886c3 in ?? () #6 0x8088649 in ?? () #7 0x80886c3 in ?? () #8 0x8088649 in ?? () #9 0x80886c3 in ?? () #10 0x8088649 in ?? () #11 0x80886c3 in ?? () #12 0x8088649 in ?? () #13 0x80886c3 in ?? () #14 0x8088649 in ?? () #15 0x80886c3 in ?? () #16 0x8088649 in ?? () #17 0x80886c3 in ?? () #18 0x8088649 in ?? () #19 0x80886c3 in ?? () #20 0x8088649 in ?? () #21 0x80886c3 in ?? () #22 0x8088649 in ?? () #23 0x80886c3 in ?? () #24 0x8088649 in ?? () #25 0x80886c3 in ?? () #26 0x8088649 in ?? () #27 0x80886c3 in ?? () #28 0x8088649 in ?? () #29 0x80886c3 in ?? () #30 0x8088649 in ?? () #31 0x80886c3 in ?? () #32 0x8088649 in ?? () #33 0x80886c3 in ?? () #34 0x8088649 in ?? () #35 0x80886c3 in ?? () #36 0x8088649 in ?? () #37 0x80886c3 in ?? () #38 0x8088649 in ?? () #39 0x80886c3 in ?? () #40 0x8088649 in ?? () #41 0x80886c3 in ?? () #42 0x8088649 in ?? () #43 0x80886c3 in ?? () #44 0x8088649 in ?? () #45 0x80886c3 in ?? () [2004-03-28 19:43:40] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. 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/27735 -- Edit this bug report at http://bugs.php.net/?id=27735&edit=1
#27755 [Bgs]: PHP chrashes with ZendOptimizer 2.5.1
ID: 27755 User updated by: cryp at ctco dot lv Reported By: cryp at ctco dot lv Status: Bogus Bug Type: Reproducible crash Operating System: Windows 2000 PHP Version: 4.3.5 New Comment: Actually, i've tryed different versions of optimizer, they all works fine for the php 4.3.4 and previos versions. This happens only with the php 4.3.5. I've tryed php 4.3.5RCx for testing, and the result was the same, apache crashes on startup. Windows XP users got the same problem. Previous Comments: [2004-03-29 10:42:28] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. This is likely to be the problem with ZendOptimizer not PHP. [2004-03-29 10:39:13] cryp at ctco dot lv Description: Platform: Windows 2000. Web-server: Apache 1.3.29 PHP version: 4.3.5 If php installed as apache module, apache will crashes when service is starting. If php installed as CGI, apache starts normally, but all php files cause crashing of php.exe. It doesn't matter if the php file is encoded or not with ZendEncoder. I've tryed an old version of ZendOptimizer (2.1.0), the result was the same. There is no problems with PHP version 4.3.4. -- Edit this bug report at http://bugs.php.net/?id=27755&edit=1
#26647 [Fbk->Opn]: Intermittent upload crash in FastCGI mode
ID: 26647 User updated by: faraco dot phpbugs at mailnull dot com Reported By: faraco dot phpbugs at mailnull dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows NT4 SP6 -PHP Version: 4CVS-2004-02-11 +PHP Version: 4.3.6-dev New Comment: The problem persists. Previous Comments: [2004-03-28 19:53:22] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-02-10 05:45:37] faraco dot phpbugs at mailnull dot com The problem persists. This time I was able to identify that the error occurs more often when the file size is over 50KB. [2004-02-09 20:38:11] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-12-17 06:55:55] faraco dot phpbugs at mailnull dot com Description: When running PHP 4.3.4 (also 4.3.2) in FastCGI mode, the http upload of files occasionally results on "Page Cannot Be Displayed". Some comments: 1. The SAME file sometimes is uploaded successfully and sometimes is not. So, no problems with MAX_FILE_SIZE (HTML script) or UPLOAD_MAX_FILESIZE, POST_MAX_SIZE (PHP.INI) settings. 2. No problems with plain/text files uploads. These intermittent problems seem to occur only with binary files. 3. On a manual test, in 60 seconds, the same requisition failed 8 times and succeeded other 4. Reproduce code: --- up.html --- upload.php -- "; print_r($_FILES); } ?> -- Edit this bug report at http://bugs.php.net/?id=26647&edit=1
#27773 [Opn]: Segmentation fault (core dumped) if -DZTS
ID: 27773
User updated by: krasnov at euroweb dot ru
Reported By: krasnov at euroweb dot ru
Status: Open
Bug Type: Reproducible crash
Operating System: FreeBSD 4.8 RELEASE
PHP Version: 4.3.5
New Comment:
I have found that php NOT crash if i remove the following code from
TSRM_API void tsrm_shutdown(void) (file TSRM.c)
---
if (resource_types_table && resource_types_table[j].dtor) {
resource_types_table[j].dtor(p->storage[j], &p->storage);
}
---
Previous Comments:
[2004-03-30 05:30:20] krasnov at euroweb dot ru
And i have forgot about this option in php_config.h
/* #undef HAVE_REALPATH */
[2004-03-30 05:29:09] krasnov at euroweb dot ru
I ma really sorry it was misprint, I meant bug #27735
[2004-03-30 05:27:00] krasnov at euroweb dot ru
Description:
If I compile PHP 4.3.5 with --enable-experimental-zts or with
--with-apxs2=/usr/local/apache2/bin/apxs (which affection are the
same), I see "Segmentation fault (core dumped)" as a result of any php
script in CLI mode.
And if I uses --with-apxs2, I get result like bug #17735, which you
have closed as Bogus, but it is not right, cause it does not depend on
Apache.
Here is compilation options:
CFLAGS='-O -pipe -march=pentiumpro -D__USE_UNIX98 -D_REENTRANT
-D_THREAD_SAFE -DHAVE_BROKEN_REALPATH -I/usr/local/include/pthread
/linuxthreads -L/usr/local/lib -llthread -llgcc_r' \
LIBS='-L/usr/local/lib -llthread -llgcc_r' \
./configure \
--prefix=/usr/local/php \
--with-tsrm-pthreads \
--enable-experimental-zts
Actual result:
--
=
CWD : /usr/local/src/php.new.test/php-4.3.5
PHP : /usr/local/src/php.new.test/php-4.3.5/sapi/cli/php
PHP_SAPI: cli
PHP_VERSION : 4.3.5
ZEND_VERSION: 1.3.0
PHP_OS : FreeBSD - FreeBSD xx.xxx.ru 4.8-RELEASE FreeBSD
4.8-RELEASE #0: Thu Aug i386
INI actual : /usr/local/php/lib/php.ini
More .INIs : Segmentation fault (core dumped)
Extra dirs :
=
TIME START 2004-03-30 14:25:44
=
FAIL EXPECT [tests/run-test/test001.phpt]
FAIL EXPECTF [tests/run-test/test002.phpt]
FAIL EXPECTREGEX [tests/run-test/test003.phpt]
FAIL INI section allows '=' [tests/run-test/test004.phpt]
SKIP Error message handling (without ZendOptimizer)
[tests/run-test/test005.phpt] (reason: Zend Optimizer is
loadedSegmentation fault (core dumped))
PASS Error messages are shown [tests/run-test/test006.phpt]
FAIL dirname test [tests/run-test/test007.phpt]
FAIL Error message handling (with ZendOptimizer)
[tests/run-test/test008.phpt]
FAIL Trivial "Hello World" test [tests/basic/001.phpt]
FAIL Simple POST Method test [tests/basic/002.phpt]
FAIL GET and POST Method combined [tests/basic/003.phpt]
FAIL Two variables in POST data [tests/basic/004.phpt]
FAIL Three variables in POST data [tests/basic/005.phpt]
FAIL Add 3 variables together and print result [tests/basic/006.phpt]
FAIL Multiply 3 variables and print result [tests/basic/007.phpt]
FAIL Divide 3 variables and print result [tests/basic/008.phpt]
FAIL Subtract 3 variables and print result [tests/basic/009.phpt]
FAIL Testing | and & operators [tests/basic/010.phpt]
FAIL Testing $argc and $argv handling (GET) [tests/basic/011.phpt]
FAIL Testing $argc and $argv handling (cli) [tests/basic/012.phpt]
FAIL Bug #20539 (PHP CLI Segmentation Fault)
[tests/basic/bug20539.phpt]
FAIL Methods via variable name, bug #20120
[tests/classes/bug20120.phpt]
--
Edit this bug report at http://bugs.php.net/?id=27773&edit=1
#25777 [Com]: char and varchar fields are being rtrimmed (and also ltrimmed?) using freetds
ID: 25777 Comment by: arion_ at msn dot com Reported By: duh at dowebwedo dot com Status: Closed Bug Type: MSSQL related Operating System: Debian GNU/Linux 3.0 PHP Version: 4.3.4RC1 New Comment: Description: If a field is empty it returns one blank space character. Reproduce code: --- Expected result: AB Actual result: -- A B I reported this here http://bugs.php.net/bug.php?id=26996 and I have wait for the new release to solve this problem. I've just test with 4.3.5 and doesn't works yet. Previous Comments: [2003-11-17 18:14:15] [EMAIL PROTECTED] The sybase and mssql extensions do not handle returned data the exact same way, and it might be that we need to readd the rtrim code to the sybase extensions. It seams like the dbconvert() finctions are implemented differently. You could also try the native mssql extension. That will work with FreeTDS as well, and give you more functions. [2003-11-17 17:29:18] cquincy at whitewave dot com I think I have run into a problem related to this bug fix. I am using sybase/freetds to interact with mssql on my company intranet like the orginator of this bug. Now with version 4.3.4 numbers, whether integer of floating points are coming back with spaces on the right side. i.e. you put "123" in the database, then when you mssql_fetch* you get back "123 ". Note that the originator of the bug was only concerned with char and varchar fields. 4.3.3 did not have this problem with numbers. So, it seems the "fix" has created an unforseen problem with numbers which is worse in my opinion than "hi " coming back as "hi". Obviously I expect to get exactly the same data that is stored in the database instead of right padded data. Expected result: Put 123 in the database get back 123, not '123 '. Put 123.456 in the database get back 123.45, not '123.456 ' Thanks for your efforts. [2003-10-14 23:32:13] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-10-10 06:12:57] duh at dowebwedo dot com the configure line is: './configure' '--with-mysql' '--with-apxs=/www/bin/apxs' '--with-gd=/usr/local' '--with-png-dir' '--with-freetype-dir' '--with-pear' '--with-zlib-dir' '--enable-track-vars' '--enable-trans-sid' '--disable-posix-threads' '--enable-shared' '--with-pgsql=/usr' '--with-unixODBC=/usr/local/easysoft/unixODBC' '--with-mssql=/usr/local' [2003-10-07 19:09:27] [EMAIL PROTECTED] What was the configure line used to configure 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/25777 -- Edit this bug report at http://bugs.php.net/?id=25777&edit=1
#27762 [Opn->Csd]: S_ISSOCK undefined
ID: 27762 Updated by: [EMAIL PROTECTED] Reported By: ppporch at theporch dot com -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: SCO Openserver 5.0.6A PHP Version: 4.3.5 New Comment: The next snapshot should contain the fix. (try http://snaps.php.net in a couple of hours; look for the stable snapshot) Note that the lack of S_ISSOCK on your platform means that you might not have much success using CLI version of PHP run from inetd (just in case you were thinking about it). Previous Comments: [2004-03-29 17:04:39] ppporch at theporch dot com Description: When trying to compile the php-4.3.5 code with Openserver 5.0.6A using gcc, I receive a symbol undefined error in the link phase for S_ISSOCK referenced in mail/streams.lo In looking at the code, #if defined (S_ISFIFO) || defined(S_ISSOCK) on line 2019 is where the problem is. SCO Openserver has S_ISFIFO defined but not S_ISSOCK and so the if statement is true (from the S_ISFIFO) but the code the gets ececuted below it assumes that S_ISSOCK is defined which it is not on this system. A grep -rl S_ISSOCK * and grep -rl S_IFSOCK * in the /usr/include directory produces nothing. *grep -rl (recurse and list files that match). Expected result: The compile to complete. Actual result: -- /bin/sh /software/apache/php-4.3.5/libtool --silent --preserve-dup-deps --mode=link gcc -export-dynamic -g -O2 ext/ctype/ctype.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/libmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo ext/mysql/libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_alloc.lo ext/mysql/libmysql/mf_format.lo ext/mysql/libmysql/mf_path.lo ext/mysql/libmysql/mf_unixpath.lo ext/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpath.lo ext/mysql/libmysql/my_pthread.lo ext/mysql/libmysql/my_thr_init.lo ext/mysql/libmysql/thr_mutex.lo ext/mysql/libmysql/mulalloc.lo ext/mysql/libmysql/string.lo ext/mysql/libmysql/default.lo ext/mysql/libmysql/my_compress.lo ext/mysql/libmysql/array.lo ext/mysql/libmysql/my_once.lo ext/mysql/libmysql/list.lo ext/mysql/libmysql/my_net.lo ext/mysql/libmysql/dbug.lo ext/mysql/libmysql/strmov.lo ext/mysql/libmysql/strxmov.lo ext/mysql/libmysql/strnmov.lo ext/mysql/libmysql/strmake.lo ext/mysql/libmysql/strend.lo ext/mysql/libmysql/strfill.lo ext/mysql/libmysql/is_prefix.lo ext/mysql/libmysql/int2str.lo ext/mysql/libmysql/str2int.lo ext/mysql/libmysql/strinstr.lo ext/mysql/libmysql/strcont.lo ext/mysql/libmysql/strcend.lo ext/mysql/libmysql/bchange.lo ext/mysql/libmysql/bmove.lo ext/mysql/libmysql/bmove_upp.lo ext/mysql/libmysql/longlong2str.lo ext/mysql/libmysql/strtoull.lo ext/mysql/libmysql/strtoll.lo ext/mysql/libmysql/charset.lo ext/mysql/libmysql/ctype.lo ext/overload/overload.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo ext/standard/url.lo ext/standard/url_scanner.lo e
#27539 [Opn]: PHP output: No input file specified
ID: 27539
User updated by: barry at teleserver dot es
Reported By: barry at teleserver dot es
Status: Open
Bug Type: CGI related
Operating System: Sun Solaris 2.6
PHP Version: 4.3.4
New Comment:
After looking for posible solutions in internet I tried some posible
solutions for example compiling de PHP software without the options
--enable-discard-path and --enable-force-cgi-redirect. The new
situation seems to be more suitable, I can´t reproduce de coredump on
the browser and the behavier seems to be the same executing the PHP
script through IPlanet and Apache, in both cases with the same result
on the browser "No input file specified.".
Previous Comments:
[2004-03-24 04:08:50] barry at teleserver dot es
I made the changes in php.ini for the backtrace generation as commented
in "bugs-generating-backtrace.php", however there is nothing changed
refering the behaviour of the apache/php execution as commented
initially in bug: 27540.
This erroneous result doesn't create a core on my solaris file system
so it is impossible for me to generate the backtrace file you asked
for. In sted of generating the core file on the file system, the PHP
shell execution from the CGI, sends the coredump information directly
to the browser. Is there someting else I can do in order to give you
the necesary information?
[2004-03-15 07:32:28] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
[2004-03-15 06:22:54] barry at teleserver dot es
The problem I have with bug: 27540 is PHP versión independend and only
with apache. If you prefer hendling thes both bugs under this
reference, I will close the other one.
Refering your request, please tell me exaclty with backtrace you mean,
I don´t know PHP to much and need some help. If you refer to the
coredump I see on the browser, its a lot of informatión and seems to
refer to a lot of memory data not only PHP.
[2004-03-10 13:27:06] [EMAIL PROTECTED]
Please close the other report, the issue is same.
And provide the backtrace of the crash here.
[2004-03-10 03:56:35] barry at teleserver dot es
First of all thanks for your request.
The PHP script seems to work fine from de unix command line:
About the C coded CGI: The webserver starts up a normal CGI programmed
in C. This CGY starts up the PHP script as it was from the command
line, by using the C system() function as followed:
system("/disco1/php/test.php");
About apache: For this tests I used the netscape webserver because of
some other problems I have using apache with this same configuration
and reported as bug: 27540
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/27539
--
Edit this bug report at http://bugs.php.net/?id=27539&edit=1
#27773 [Opn]: Segmentation fault (core dumped) if -DZTS
ID: 27773 User updated by: krasnov at euroweb dot ru Reported By: krasnov at euroweb dot ru Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 4.8 RELEASE PHP Version: 4.3.5 New Comment: And i have forgot about this option in php_config.h /* #undef HAVE_REALPATH */ Previous Comments: [2004-03-30 05:29:09] krasnov at euroweb dot ru I ma really sorry it was misprint, I meant bug #27735 [2004-03-30 05:27:00] krasnov at euroweb dot ru Description: If I compile PHP 4.3.5 with --enable-experimental-zts or with --with-apxs2=/usr/local/apache2/bin/apxs (which affection are the same), I see "Segmentation fault (core dumped)" as a result of any php script in CLI mode. And if I uses --with-apxs2, I get result like bug #17735, which you have closed as Bogus, but it is not right, cause it does not depend on Apache. Here is compilation options: CFLAGS='-O -pipe -march=pentiumpro -D__USE_UNIX98 -D_REENTRANT -D_THREAD_SAFE -DHAVE_BROKEN_REALPATH -I/usr/local/include/pthread /linuxthreads -L/usr/local/lib -llthread -llgcc_r' \ LIBS='-L/usr/local/lib -llthread -llgcc_r' \ ./configure \ --prefix=/usr/local/php \ --with-tsrm-pthreads \ --enable-experimental-zts Actual result: -- = CWD : /usr/local/src/php.new.test/php-4.3.5 PHP : /usr/local/src/php.new.test/php-4.3.5/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.3.5 ZEND_VERSION: 1.3.0 PHP_OS : FreeBSD - FreeBSD xx.xxx.ru 4.8-RELEASE FreeBSD 4.8-RELEASE #0: Thu Aug i386 INI actual : /usr/local/php/lib/php.ini More .INIs : Segmentation fault (core dumped) Extra dirs : = TIME START 2004-03-30 14:25:44 = FAIL EXPECT [tests/run-test/test001.phpt] FAIL EXPECTF [tests/run-test/test002.phpt] FAIL EXPECTREGEX [tests/run-test/test003.phpt] FAIL INI section allows '=' [tests/run-test/test004.phpt] SKIP Error message handling (without ZendOptimizer) [tests/run-test/test005.phpt] (reason: Zend Optimizer is loadedSegmentation fault (core dumped)) PASS Error messages are shown [tests/run-test/test006.phpt] FAIL dirname test [tests/run-test/test007.phpt] FAIL Error message handling (with ZendOptimizer) [tests/run-test/test008.phpt] FAIL Trivial "Hello World" test [tests/basic/001.phpt] FAIL Simple POST Method test [tests/basic/002.phpt] FAIL GET and POST Method combined [tests/basic/003.phpt] FAIL Two variables in POST data [tests/basic/004.phpt] FAIL Three variables in POST data [tests/basic/005.phpt] FAIL Add 3 variables together and print result [tests/basic/006.phpt] FAIL Multiply 3 variables and print result [tests/basic/007.phpt] FAIL Divide 3 variables and print result [tests/basic/008.phpt] FAIL Subtract 3 variables and print result [tests/basic/009.phpt] FAIL Testing | and & operators [tests/basic/010.phpt] FAIL Testing $argc and $argv handling (GET) [tests/basic/011.phpt] FAIL Testing $argc and $argv handling (cli) [tests/basic/012.phpt] FAIL Bug #20539 (PHP CLI Segmentation Fault) [tests/basic/bug20539.phpt] FAIL Methods via variable name, bug #20120 [tests/classes/bug20120.phpt] -- Edit this bug report at http://bugs.php.net/?id=27773&edit=1
#27773 [Opn]: Segmentation fault (core dumped) if -DZTS
ID: 27773 User updated by: krasnov at euroweb dot ru Reported By: krasnov at euroweb dot ru Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 4.8 RELEASE PHP Version: 4.3.5 New Comment: I ma really sorry it was misprint, I meant bug #27735 Previous Comments: [2004-03-30 05:27:00] krasnov at euroweb dot ru Description: If I compile PHP 4.3.5 with --enable-experimental-zts or with --with-apxs2=/usr/local/apache2/bin/apxs (which affection are the same), I see "Segmentation fault (core dumped)" as a result of any php script in CLI mode. And if I uses --with-apxs2, I get result like bug #17735, which you have closed as Bogus, but it is not right, cause it does not depend on Apache. Here is compilation options: CFLAGS='-O -pipe -march=pentiumpro -D__USE_UNIX98 -D_REENTRANT -D_THREAD_SAFE -DHAVE_BROKEN_REALPATH -I/usr/local/include/pthread /linuxthreads -L/usr/local/lib -llthread -llgcc_r' \ LIBS='-L/usr/local/lib -llthread -llgcc_r' \ ./configure \ --prefix=/usr/local/php \ --with-tsrm-pthreads \ --enable-experimental-zts Actual result: -- = CWD : /usr/local/src/php.new.test/php-4.3.5 PHP : /usr/local/src/php.new.test/php-4.3.5/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.3.5 ZEND_VERSION: 1.3.0 PHP_OS : FreeBSD - FreeBSD xx.xxx.ru 4.8-RELEASE FreeBSD 4.8-RELEASE #0: Thu Aug i386 INI actual : /usr/local/php/lib/php.ini More .INIs : Segmentation fault (core dumped) Extra dirs : = TIME START 2004-03-30 14:25:44 = FAIL EXPECT [tests/run-test/test001.phpt] FAIL EXPECTF [tests/run-test/test002.phpt] FAIL EXPECTREGEX [tests/run-test/test003.phpt] FAIL INI section allows '=' [tests/run-test/test004.phpt] SKIP Error message handling (without ZendOptimizer) [tests/run-test/test005.phpt] (reason: Zend Optimizer is loadedSegmentation fault (core dumped)) PASS Error messages are shown [tests/run-test/test006.phpt] FAIL dirname test [tests/run-test/test007.phpt] FAIL Error message handling (with ZendOptimizer) [tests/run-test/test008.phpt] FAIL Trivial "Hello World" test [tests/basic/001.phpt] FAIL Simple POST Method test [tests/basic/002.phpt] FAIL GET and POST Method combined [tests/basic/003.phpt] FAIL Two variables in POST data [tests/basic/004.phpt] FAIL Three variables in POST data [tests/basic/005.phpt] FAIL Add 3 variables together and print result [tests/basic/006.phpt] FAIL Multiply 3 variables and print result [tests/basic/007.phpt] FAIL Divide 3 variables and print result [tests/basic/008.phpt] FAIL Subtract 3 variables and print result [tests/basic/009.phpt] FAIL Testing | and & operators [tests/basic/010.phpt] FAIL Testing $argc and $argv handling (GET) [tests/basic/011.phpt] FAIL Testing $argc and $argv handling (cli) [tests/basic/012.phpt] FAIL Bug #20539 (PHP CLI Segmentation Fault) [tests/basic/bug20539.phpt] FAIL Methods via variable name, bug #20120 [tests/classes/bug20120.phpt] -- Edit this bug report at http://bugs.php.net/?id=27773&edit=1
#27773 [NEW]: Segmentation fault (core dumped) if -DZTS
From: krasnov at euroweb dot ru Operating system: FreeBSD 4.8 RELEASE PHP version: 4.3.5 PHP Bug Type: Reproducible crash Bug description: Segmentation fault (core dumped) if -DZTS Description: If I compile PHP 4.3.5 with --enable-experimental-zts or with --with-apxs2=/usr/local/apache2/bin/apxs (which affection are the same), I see "Segmentation fault (core dumped)" as a result of any php script in CLI mode. And if I uses --with-apxs2, I get result like bug #17735, which you have closed as Bogus, but it is not right, cause it does not depend on Apache. Here is compilation options: CFLAGS='-O -pipe -march=pentiumpro -D__USE_UNIX98 -D_REENTRANT -D_THREAD_SAFE -DHAVE_BROKEN_REALPATH -I/usr/local/include/pthread /linuxthreads -L/usr/local/lib -llthread -llgcc_r' \ LIBS='-L/usr/local/lib -llthread -llgcc_r' \ ./configure \ --prefix=/usr/local/php \ --with-tsrm-pthreads \ --enable-experimental-zts Actual result: -- = CWD : /usr/local/src/php.new.test/php-4.3.5 PHP : /usr/local/src/php.new.test/php-4.3.5/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.3.5 ZEND_VERSION: 1.3.0 PHP_OS : FreeBSD - FreeBSD xx.xxx.ru 4.8-RELEASE FreeBSD 4.8-RELEASE #0: Thu Aug i386 INI actual : /usr/local/php/lib/php.ini More .INIs : Segmentation fault (core dumped) Extra dirs : = TIME START 2004-03-30 14:25:44 = FAIL EXPECT [tests/run-test/test001.phpt] FAIL EXPECTF [tests/run-test/test002.phpt] FAIL EXPECTREGEX [tests/run-test/test003.phpt] FAIL INI section allows '=' [tests/run-test/test004.phpt] SKIP Error message handling (without ZendOptimizer) [tests/run-test/test005.phpt] (reason: Zend Optimizer is loadedSegmentation fault (core dumped)) PASS Error messages are shown [tests/run-test/test006.phpt] FAIL dirname test [tests/run-test/test007.phpt] FAIL Error message handling (with ZendOptimizer) [tests/run-test/test008.phpt] FAIL Trivial "Hello World" test [tests/basic/001.phpt] FAIL Simple POST Method test [tests/basic/002.phpt] FAIL GET and POST Method combined [tests/basic/003.phpt] FAIL Two variables in POST data [tests/basic/004.phpt] FAIL Three variables in POST data [tests/basic/005.phpt] FAIL Add 3 variables together and print result [tests/basic/006.phpt] FAIL Multiply 3 variables and print result [tests/basic/007.phpt] FAIL Divide 3 variables and print result [tests/basic/008.phpt] FAIL Subtract 3 variables and print result [tests/basic/009.phpt] FAIL Testing | and & operators [tests/basic/010.phpt] FAIL Testing $argc and $argv handling (GET) [tests/basic/011.phpt] FAIL Testing $argc and $argv handling (cli) [tests/basic/012.phpt] FAIL Bug #20539 (PHP CLI Segmentation Fault) [tests/basic/bug20539.phpt] FAIL Methods via variable name, bug #20120 [tests/classes/bug20120.phpt] -- Edit bug report at http://bugs.php.net/?id=27773&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27773&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27773&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27773&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27773&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27773&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27773&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27773&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27773&r=support Expected behavior: http://bugs.php.net/fix.php?id=27773&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27773&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27773&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27773&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27773&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27773&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27773&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27773&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27773&r=float
#27772 [NEW]: It crashes at the last of cgi_main.
From: khagiya1 at yahoo dot co dot jp
Operating system: Windows Xp Professional Ver2002
PHP version: 4.3.5
PHP Bug Type: Reproducible crash
Bug description: It crashes at the last of cgi_main.
Description:
Please let me know.
I downloaded "PHP 4.3.5 (tar.gz) [4,706Kb]-26 March 2004." from
"http://www.php.net/downloads.php";
It is used building it personally.
It crash, although only built.
Reproduce code:
---
The example of a code to generate
[c:/hello.csp]
[php.ini]
zend_extension_ts = c:/ioncube_loader.dll
EThe following is performed on a console.
c:/php.exe -f c:/hello.csp
It is displayed on a screen as "hello!!".
Crash occurs together with it.
This is generated only when module(zend_extension_ts) is loaded.
It does not generate in module(extension).
When the code was seen, it had generated in the following places.
The following change went into TSRM/TSRM.c by php-4.3.4 to php-4.3.5.
*** TSRM/TSRM.c Tue Nov 11 14:17:17 2003 <-- 4.3.4
--- TSRM/TSRM.c Wed Dec 17 04:59:58 2003 <-- 4.3.5
***
*** 157,163
int j;
next_p = p->next;
! for (j=0; jstorage[j]);
}
free(p->storage);
--- 157,166
int j;
next_p = p->next;
! for (j=0; jcount; j++) {
! if (resource_types_table &&
resource_types_table[j].dtor) {
!
resource_types_table[j].dtor(p->storage[j], &p->storage); <--
cause the problem!!
! }
free(p->storage[j]);
}
free(p->storage);
sapi/cgi/cgi_main.c: line 1787 - 1792
--
php_module_shutdown(TSRMLS_C);
HLOG_LOG( HLOG_NOTICE, "php_module_shutdown" );
#ifdef ZTS
tsrm_shutdown();
#endif
--
show callstack.
1. php_module_shutdown
2. zend_shutdown
3. zend_shutdown_extensions
4. zend_llist_destroy
5. zend_extension_dtor
6. DL_UNLOAD <-- module(by zend_extension_ts) is unload here.
7. tsrm_shutdown <-- dtor can't be called.
--
Edit bug report at http://bugs.php.net/?id=27772&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27772&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27772&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27772&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27772&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27772&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27772&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27772&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27772&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27772&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27772&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27772&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27772&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27772&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27772&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27772&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27772&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27772&r=float
