#44137 [NEW]: Compile will fail with MySQL-5.1.23-rc
From: jari dot tuomoja at gmail dot com Operating system: Fedora Core 6, x86_64 PHP version: 5.2.5 PHP Bug Type: MySQLi related Bug description: Compile will fail with MySQL-5.1.23-rc Description: When compiling MySQL 5.1.23-rc, option --with-mysqli=/youd/dir/to/mysql_config will always fail. MySQL and PDO are working ok but mysqli is failing. With MySQL 5.1.22-rc everything works well. MySQL answered that this is a bug in PHP, not in MySQL. MySQL server is working okay. Reproduce code: --- Compile php-5.2.5 with mysqli -option. Expected result: Compile ok Actual result: -- Error messages and compile will exit -- Edit bug report at http://bugs.php.net/?id=44137&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=44137&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44137&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44137&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44137&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44137&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44137&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44137&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44137&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44137&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44137&r=support Expected behavior:http://bugs.php.net/fix.php?id=44137&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44137&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44137&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44137&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44137&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=44137&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44137&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44137&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44137&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44137&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44137&r=mysqlcfg
#44136 [NEW]: Using strtotime with a @ sign date doesn't work
From: idonthaveemail at example dot com Operating system: winxp PHP version: 4.4.8 PHP Bug Type: Date/time related Bug description: Using strtotime with a @ sign date doesn't work Description: Using strtotime with a @ sign date doesn't work. (At least I can work around) Expected result: the correct answer Actual result: -- -1 -- Edit bug report at http://bugs.php.net/?id=44136&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=44136&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44136&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44136&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44136&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44136&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44136&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44136&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44136&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44136&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44136&r=support Expected behavior:http://bugs.php.net/fix.php?id=44136&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44136&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44136&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44136&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44136&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=44136&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44136&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44136&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44136&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44136&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44136&r=mysqlcfg
#44135 [Com]: PDO MySQL does not support CLIENT_FOUND_ROWS
ID: 44135 Comment by: larry at garfieldtech dot com Reported By: chx1975 at gmail dot com Status: Open Bug Type: PDO related Operating System: Linux PHP Version: 5.2.5 New Comment: I can duplicate this problem. The issue appears to be that by default, MySQL will return the number of affected rows from a previous UPDATE statement, not the number of matched rows. That values will differ if the update statement would set a row to its existing value. With ext/mysql and ext/mysqli, it can be set to return matched rows instead. PDO does not appear to have a way to allow that. Previous Comments: [2008-02-16 03:26:34] chx1975 at gmail dot com Description: mysql_real_connect supports client flags http://dev.mysql.com/doc/refman/4.1/en/mysql-real-connect.html most importantly CLIENT_FOUND_ROWS but PDO provides no way to pass it in. -- Edit this bug report at http://bugs.php.net/?id=44135&edit=1
#44135 [NEW]: PDO MySQL does not support CLIENT_FOUND_ROWS
From: chx1975 at gmail dot com Operating system: Linux PHP version: 5.2.5 PHP Bug Type: PDO related Bug description: PDO MySQL does not support CLIENT_FOUND_ROWS Description: mysql_real_connect supports client flags http://dev.mysql.com/doc/refman/4.1/en/mysql-real-connect.html most importantly CLIENT_FOUND_ROWS but PDO provides no way to pass it in. -- Edit bug report at http://bugs.php.net/?id=44135&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=44135&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44135&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44135&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44135&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44135&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44135&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44135&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44135&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44135&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44135&r=support Expected behavior:http://bugs.php.net/fix.php?id=44135&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44135&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44135&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44135&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44135&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=44135&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44135&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44135&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44135&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44135&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44135&r=mysqlcfg
#44133 [Opn->Bgs]: Encrypting then decrypting a string results in unidentical strings.
ID: 44133 Updated by: [EMAIL PROTECTED] Reported By: squinky86 at gmail dot com -Status: Open +Status: Bogus Bug Type: mcrypt related Operating System: Linux and Windows PHP Version: 5.2.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's because the IV needs to be the same for encrypting as well as decrypting. Previous Comments: [2008-02-15 22:20:56] squinky86 at gmail dot com Description: When I mcrypt_encrypt() a string, then immediately mcrypt_decrypt() the string, the result is two strings that appear identical but are not. Reproduce code: --- Due to having multiple test cases for this bug, I have posted the code to: http://www.phpfreaks.com/forums/index.php/topic,182537.msg815864.html Note also that since the posting of this issue, I have noted the following: strlen($toEncrypt) == strlen($decrypted) == 13 ord($toEncrypt[$i]) == ord($decrypted[$i]) for all $i = 0..12 For all intensive purposes, the strings are identical, but PHP does not define them as such. Expected result: The strings should be identical after encryption and decryption Actual result: -- The strcmp() function returns "-3". The == operator returns "false". -- Edit this bug report at http://bugs.php.net/?id=44133&edit=1
#44113 [Opn->Csd]: New collection creation can fail with OCI-22303
ID: 44113
Updated by: [EMAIL PROTECTED]
Reported By: christopher dot jones at oracle dot com
-Status: Open
+Status: Closed
Bug Type: OCI8 related
Operating System: n/a
PHP Version: 5.2.5
Assigned To: sixd
New Comment:
The above patch (+ variable initialization) from Haneef has been
merged.
Previous Comments:
[2008-02-14 23:03:18] [EMAIL PROTECTED]
Try this patch for 5.2.5:
--- php-5.2.5/php-5.2.5/ext/oci8/oci8_collection.c 2007-07-31
12:21:08.0 -0700
+++ oci8_collection.c 2008-02-14 01:56:15.0 -0800
@@ -219,11 +219,17 @@
goto CLEANUP;
}
+ /* free the describe handle */
+ PHP_OCI_CALL(OCIHandleFree, ((dvoid *) dschp1, OCI_HTYPE_DESCRIBE));
PHP_OCI_REGISTER_RESOURCE(collection, le_collection);
return collection;
CLEANUP:
+ if (dschp1) {
+ PHP_OCI_CALL(OCIHandleFree, ((dvoid *) dschp1,
OCI_HTYPE_DESCRIBE));
+ }
php_oci_error(connection->err, connection->errcode TSRMLS_CC);
php_oci_collection_close(collection TSRMLS_CC);
return NULL;
[2008-02-13 21:30:23] christopher dot jones at oracle dot com
Description:
In some circumstances oci_new_collection() can fail. The problem
was reported to me as occurring from at least PHP 5.1.2 onwards.
The cause appears to be lack of a describe-handle free in the
OCI8 extension; this is under investigation.
Reproduce code:
---
create or replace type ut_num_list_t as table of number;
create or replace procedure test_load(
p_list_1ut_num_list_t)
as
begin
for i in 1..p_list_1.count()
loop
null;
end loop;
end;
/
show errors
:list_1);
end;";
$sth = oci_parse($dbh, $sql);
$type = 'UT_NUM_LIST_T';
$placeholder = ':list_1';
if (!($var = oci_new_collection($dbh, $type)))
{
print "Failed new collection creation on $x\n";
}
foreach ($list as $list_item)
{
$var->append($list_item);
}
oci_bind_by_name($sth, $placeholder, $var, -1, OCI_B_NTY);
try
{
oci_execute($sth);
$var->free();
oci_free_statement($sth);
}
catch (Exception $e)
{
print "Failed on $x\n";
throw $e;
}
}
print "Completed $x\n";
oci_close($dbh);
?>
Expected result:
Completed 10
Actual result:
--
Warning: oci_new_collection(): OCI-22303: type ""."UT_NUM_LIST_T" not
found in /home/cjones/public_html/t1.php on line 26
Failed new collection creation on 65464
--
Edit this bug report at http://bugs.php.net/?id=44113&edit=1
#44134 [NEW]: sessions calling causes timeout and failed response in simplexml and curl
From: doc+phpbugs at skynet dot ie Operating system: ubuntu linux PHP version: 5.2.5 PHP Bug Type: Session related Bug description: sessions calling causes timeout and failed response in simplexml and curl Description: When I pass a parameter of session_name()=session_id() in a url or as a header and use curl or simplexml the connection times out. I get the following response from simplexml_load_file($url). failed to open stream: HTTP request failed! However, when I connect to the same url with curl on the commandline I get the expected response immediately. Reproduce code: --- echo $data_source_url = DATAURL.'?bget=1&'.session_name().'='.session_id().'&basket_id='.clean_from_db($basket_id); $basket_details = simplexml_load_file($data_source_url); I also get the same when I use: $ch=curl_init(); echo $this->URL.$this->XMLRequest.'?'.$urlstring; curl_setopt($ch, CURLOPT_URL,$this->URL.$this->XMLRequest.'?'.$urlstring); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $data = curl_exec($ch); curl_close($ch); or pass it as a more standard CURLOPT_HTTPHEADER to curl_setopt. Expected result: To retrieve xml from the server. Actual result: -- The page is called which then attempts to connect to the data url, that stalls for some time then calls the server correctly then the script eventually times out. I've used wireshark on the machine and it's calling the url correctly and getting the expected response, as I can see the xml being passed back, but somewhere between then and actually returning, it stalls and times out. -- Edit bug report at http://bugs.php.net/?id=44134&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=44134&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44134&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44134&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44134&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44134&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44134&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44134&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44134&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44134&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44134&r=support Expected behavior:http://bugs.php.net/fix.php?id=44134&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44134&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44134&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44134&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44134&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=44134&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44134&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44134&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44134&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44134&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44134&r=mysqlcfg
#36250 [Csd]: PHP Causes ORA-07445 Core dump in Oracle server 9.2.x
ID: 36250 Updated by: [EMAIL PROTECTED] Reported By: fred dot cohen at iridium dot com Status: Closed Bug Type: OCI8 related Operating System: Solaris 9 PHP Version: 5.1.2 New Comment: Also see http://pecl.php.net/bugs/bug.php?id=12431 Previous Comments: [2006-03-07 08:52:52] [EMAIL PROTECTED] Ok, I've commented out OCIPing() call, OCI8 from now will use OCIServerVersion() with all client versions. [2006-03-07 00:18:41] cjbj at hotmail dot com OCIPing requires 10.1 or 10.2 OCI client libraries. It will (or should) return a nice error when the database server is 8.1 or 9.2. This won't help PHP validate the connection as intended when connected to these older databases. The oci8 extension should just use OCIServerVersion. The OCI Developers are against the concept of pinging for each connection because it is an unneccessary round-trip between OCI client and database server. [2006-03-06 22:19:53] fred dot cohen at iridium dot com That's what Oracle is telling us. This is directly from our ticket with them: I think there are 2 things you can do to fix your problem. 1. Install the 10.2 listener in the box where your 10.1.x or your 9.x database are running and use that listener to listen for your databases. 2. Fix the OCI8 driver for PHP so it does not use OCIPING at all We're awaiting further response from Oracle because their response conflicts with all the documentation I've been able to find on OCI and the OCIPing function. [2006-03-05 08:43:35] [EMAIL PROTECTED] So you're effectively saying that OCIPing() which exists in OIC is not supported by Oracle servers 8 and 9 and causes them to crash? This sounds really.. hmm.. weird, because I was recommended to use OCIPing() namely by Oracle developers. [2006-03-04 07:41:10] fred dot cohen at iridium dot com It might be a good idea get the Server Version with a call to OCIServerVersion rather than relying on the OCI_xx_VERSION defines. Any of the developers care to comment? #if OCI_MAJOR_VERSION >= 10 && OCI_MINOR_VERSION >= 2 /* OCIPing() is usable only in 10.2 */ OCI_G(errcode) = PHP_OCI_CALL(OCIPing, (connection->svc, OCI_G(err), OCI_DEFAULT)); #else char version[256]; /* use good old OCIServerVersion() by default */ OCI_G(errcode) = PHP_OCI_CALL(OCIServerVersion, (connection->server, OCI_G(err), (text*)version, sizeof(version), OCI_HTYPE_SERVER)); #endif 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/36250 -- Edit this bug report at http://bugs.php.net/?id=36250&edit=1
#44133 [NEW]: Encrypting then decrypting a string results in unidentical strings.
From: squinky86 at gmail dot com Operating system: Linux and Windows PHP version: 5.2.5 PHP Bug Type: mcrypt related Bug description: Encrypting then decrypting a string results in unidentical strings. Description: When I mcrypt_encrypt() a string, then immediately mcrypt_decrypt() the string, the result is two strings that appear identical but are not. Reproduce code: --- Due to having multiple test cases for this bug, I have posted the code to: http://www.phpfreaks.com/forums/index.php/topic,182537.msg815864.html Note also that since the posting of this issue, I have noted the following: strlen($toEncrypt) == strlen($decrypted) == 13 ord($toEncrypt[$i]) == ord($decrypted[$i]) for all $i = 0..12 For all intensive purposes, the strings are identical, but PHP does not define them as such. Expected result: The strings should be identical after encryption and decryption Actual result: -- The strcmp() function returns "-3". The == operator returns "false". -- Edit bug report at http://bugs.php.net/?id=44133&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=44133&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44133&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44133&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44133&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44133&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44133&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44133&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44133&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44133&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44133&r=support Expected behavior:http://bugs.php.net/fix.php?id=44133&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44133&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44133&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44133&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44133&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=44133&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44133&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44133&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44133&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44133&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44133&r=mysqlcfg
#41593 [Com]: FastCGI does not handle graceful reload/shutdown
ID: 41593 Comment by: dan at sypher7 dot com Reported By: jonepet at dcvhost dot no Status: No Feedback Bug Type: CGI related Operating System: Linux PHP Version: 5.2.3 Assigned To: dmitry New Comment: I was able to reproduce this in the 4.4.8 version of PHP using the latest mod_fastcgi and Apache 1.3. >From what I understand, a graceful reload sends a SIGUSR1 to Apache. The FastCGI processor manager then sends SIGTERMs to all of the running processes. Instead of exiting cleanly, the PHP script ends abruptly and doesn't even finish sending headers. Here is what Apache's log had to say about it: FastCGI: incomplete headers (0 bytes) received from server "/path/to/php-fcgi-wrapper" I've tried messing with the FastCgiConfig settings a lot, but nothing in there appears to be changing the result. I do not know either codebase well, so I can't say with certainty if this is a mod_fastcgi or PHP bug. It would appear that either PHP isn't closing out cleanly on a SIGTERM or mod_fastcgi isn't waiting around for the process to end. Previous Comments: [2007-12-18 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2007-12-10 16:15:16] [EMAIL PROTECTED] I'm not able to reproduce the HTTP 500 response on graceful restart with PHP_5_3, mod_fastcgi and Apache. [2007-11-19 18:56:25] [EMAIL PROTECTED] This is still buggy. [2007-10-16 20:48:22] andrei dot nigmatulin at gmail dot com Graceful reload/shutdown implemented in unofficial patch http://php-fpm.anight.org/. For now docs are in Russian, though. [2007-06-13 19:25:56] severn-php at xephris dot net Re: mod_fcgid: I see... I guess I'll modify mod_fcgid myself for that setup. That doesn't explain the mod_fastcgi problems though. I thought it might be something with my setup so I rebuilt it from scratch... might have had some old crap left behind. I don't get 500 errors with PHP 5.2.3 + mod_fastcgi 2.4.2 + Apache 1.3.37 anymore, so it does look fixed in 5.2.3... but I get another strange problem: doing a graceful restart shortens the sleep time to zero. i.e. Going to this page then doing a graceful after 5 seconds would give "5" instead of the expected "30". php5.fcgi== #!/bin/sh export PHP_FCGI_CHILDREN=4 exec /opt/php5/bin/php-cgi $* For the record, PHP 4.4.7 dies with a 500 error, but that's not a big problem for us... Could the OP perhaps provide us some info on what versions of Apache and mod_fastcgi/mod_fcgid so we can try replicating it? 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/41593 -- Edit this bug report at http://bugs.php.net/?id=41593&edit=1
#43518 [Fbk->Bgs]: file upload disappears on bigger files than upload_max_filesize
ID: 43518
Updated by: [EMAIL PROTECTED]
Reported By: info at inprosof dot de
-Status: Feedback
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Windows, Linux
PHP Version: 5.2.5
New Comment:
That is because your client (browser) keeps uploading the file.
There is nothing PHP can do about it except ignoring it.
Previous Comments:
[2008-02-14 21:01:04] henning dot lenz at quaerosys dot com
The following code (consisting mostly of the example from the php docs)
should only allow 300kB files to be uploaded resulting in an
UPLOAD_ERR_FORM_SIZE. If you dismiss the hidden field, it should produce
an UPLOAD_ERR_INI_SIZE. Emergency stop should be after max_input_time.
My Values are:
upload_max_size: 8M
post_max_size: 8M
max_input_time: 60
Reality shows, that a possibly created tmp File stops growing after
reaching upload_max_size and is deleted, but upload continues even after
60s (watch with iptraf or something like this).
\n";
print "post_max_size: ".ini_get("post_max_size")."\n";
print "max_input_time: ".ini_get("max_input_time")."\n";
print '
Send this file:
';
if (isset($_FILES["userfile"]))
{
var_dump($_FILES);
}
?>
[2008-02-14 20:38:35] [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 the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2008-02-14 20:27:42] henning dot lenz at quaerosys dot com
I experience the same/more problems in this way.
File uploads below post_max_size and file_max_size work without any
problems.
If the filesize is bigger than one of them, PHP does not accept the
file, but file uploading continues until the "real" end of the file
regardless of the limit settings (even of input_max_time)
[2007-12-06 13:51:56] info at inprosof dot de
Description:
-upload_max_filesize and post_max_size in php.ini set to 100M
-file to upload is 140M
- All Array ($_POST, $_GET, $_FILES) are empty after uploading file.
- File does not exist on server.
- No PHP-error or message or notice is requested
Problem: without any file size analysing the script can not generate an
error for the user.
Tested on
- windows OS 32bit, PHP 5.1.6 and Apache 2.0
- linux OS, PHP 5.2.5, Apache 2.0
Reproduce code:
---
please contact me, to send to talk about code.
Expected result:
We except the file size of the file.
Actual result:
--
nothing
--
Edit this bug report at http://bugs.php.net/?id=43518&edit=1
#44009 [Fbk->Csd]: fopen hangs with recent upgrade
ID: 44009 User updated by: brandonkahre at charter dot net Reported By: brandonkahre at charter dot net -Status: Feedback +Status: Closed Bug Type: HTTP related Operating System: Windows PHP Version: 5.2.5 New Comment: You are, of course, correct. It looks like this has been a long outstanding bug. After digging through a very long (and seemingly unresolved) bug ticket, I was able to use the mysql and mysqli extensions from PHP 5.1.2 with the 5.2.X branch and have no problems. I will mark this ticket resolved since it overlaps bug #41350. http://bugs.php.net/bug.php?id=41350 Previous Comments: [2008-02-14 22:54:12] [EMAIL PROTECTED] Let me guess: there's an error in some log with this in it 'my_thread_global_end' ?? (Try search for that in the bug db too..) [2008-02-14 18:26:58] brandonkahre at charter dot net A correction to the post above: It is not the "extension_dir" directive causing problems, but actually the extensions themselves. If I change the directive to what was listed initially, but disable all of the extensions, the scripts execute quickly. However, once a single extension is loaded (eg. php_mysql.dll or php_mysqli.dll), the script hangs as stated previously. [2008-02-14 18:09:59] brandonkahre at charter dot net Thank you for the response. I have upgraded my server using the latest PHP build and I have found that the test script above runs quickly, but only when using the recommended-ini configuration. I have compared my existing configuration to the recommended configuration and I have found that the problem lies with the "extension_dir" directive. My existing configuration (experiencing the bug) uses: extension_dir = "C:\Program Files\PHP\ext" The recommended configuration uses: extension_dir = "./" Prior to PHP 5.2.X (tested with 5.1.2), I did not experience this bug, but making this simple change to PHP 5.2.X fixes the bug. [2008-02-13 18:30:16] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2008-02-01 00:34:53] brandonkahre at charter dot net Description: When opening a file using fopen and a network wrapper (HTTP), the page will lag before finishing. The response from fopen is fast (determined by echo'ing the return, and any code that is to be processed after the fopen function is processed without delay. It is only when the page is ready to finish loading that the lag becomes noticeable. The lag takes 3-6 seconds and does not seem to be affected by any timeout settings in the php.ini file. This problem does not exist in PHP 5.1.2, and started immediately after upgrading to PHP 5.2.4 and 5.2.5. This problem also seems to only exist on my Windows server. Reproduce code: --- http://www.google.com";)); ?> -- Edit this bug report at http://bugs.php.net/?id=44009&edit=1
#44132 [Opn->Bgs]: mysql_connect hangs
ID: 44132 Updated by: [EMAIL PROTECTED] Reported By: martin-israel at gmx dot de -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: Linux 2.6.23 PHP Version: 5.2CVS-2008-02-15 (CVS) New Comment: This already was reported and fixed: See Bug#44094 Thanks. Previous Comments: [2008-02-15 15:49:40] martin-israel at gmx dot de Description: Php hangs when the new_link parameter of the function mysql_connect is set to FALSE. Used for example by phpMyAdmin. Sorry I've just tested it with PHP Version 5.2.5_p20080206 (The current latest Gentoo-Version) Reproduce code: --- Expected result: Connected! Actual result: -- nothing, because the Server hangs. -- Edit this bug report at http://bugs.php.net/?id=44132&edit=1
#44130 [Opn->Bgs]: func_get_args should return references
ID: 44130
Updated by: [EMAIL PROTECTED]
Reported By: thomas at koch dot ro
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Debian
PHP Version: 4.4.8
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
Says the documentation:
Note: This function returns a copy of the passed arguments only, and
does not account for default (non-passed) arguments.
http://docs.php.net/func-get-args
Previous Comments:
[2008-02-15 13:41:44] thomas at koch dot ro
Description:
THIS IS MY FIRST REPORT! PLEASE DON'T BANG ME!
I'd like to use func_get_args to manipulate variables sent by
reference. I encountered this problem(?) by evaluating ezcSignalSlot[1].
There you find:
$parameters = array_slice( func_get_args(), 1 );
call_user_func_array( $callback, $parameters );
It would be fine, if I could use the combination of this methods to
pipe references to normal variables.
[1] http://ezcomponents.org/docs/tutorials/SignalSlot
Reproduce code:
---
function test( )
{
$args =& func_get_args();
$args[0]++;
}
$i=1;
test( &$i );
echo $i;
Expected result:
2
Actual result:
--
1
--
Edit this bug report at http://bugs.php.net/?id=44130&edit=1
#44132 [NEW]: mysql_connect hangs
From: martin-israel at gmx dot de Operating system: Linux 2.6.23 PHP version: 5.2CVS-2008-02-15 (CVS) PHP Bug Type: MySQL related Bug description: mysql_connect hangs Description: Php hangs when the new_link parameter of the function mysql_connect is set to FALSE. Used for example by phpMyAdmin. Sorry I've just tested it with PHP Version 5.2.5_p20080206 (The current latest Gentoo-Version) Reproduce code: --- Expected result: Connected! Actual result: -- nothing, because the Server hangs. -- Edit bug report at http://bugs.php.net/?id=44132&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=44132&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44132&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44132&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44132&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44132&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44132&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44132&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44132&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44132&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44132&r=support Expected behavior:http://bugs.php.net/fix.php?id=44132&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44132&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44132&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44132&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44132&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=44132&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44132&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44132&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44132&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44132&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44132&r=mysqlcfg
#44072 [Fbk->Opn]: substr don't work correctly with binary string
ID: 44072 User updated by: sergey89 at gmail dot com Reported By: sergey89 at gmail dot com -Status: Feedback +Status: Open Bug Type: Strings related Operating System: FreeBSD 6.3 PHP Version: 5.2.5 New Comment: The version and build are the same. Previous Comments: [2008-02-15 14:27:22] [EMAIL PROTECTED] If it works in CLI but not in webserver, then there's propably something different between those two, maybe PHP version..?* [2008-02-14 09:38:55] sergey89 at gmail dot com I generate data with simple PHP script: Expected result: 45e26dc33aad8e93f3f45c8d5100feb0 | 03d900cc2ba7276fb3bb3f1939303e3b Actual result: -- 45e26dc33aad8e93f3f45c8d5100feb0 | d1cea9d93cb48b2d897595f5e96ba352 -- Edit this bug report at http://bugs.php.net/?id=44072&edit=1
#44129 [Opn->Bgs]: Halt-hour timezones returning UTC
ID: 44129
Updated by: [EMAIL PROTECTED]
Reported By: protomank at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: Windows XP
PHP Version: 5.2.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
Right, that's not a bug then. Please use date.timezone ini setting to
set your timezone - that's what it's for.
Previous Comments:
[2008-02-15 14:57:42] protomank at gmail dot com
Hum, forgot to mention I was running it under Apache 2.2, sorry :(
But it doesn't affect the bug anyway.
The bug doesn't happen when you pass the timezone to PHP, but when you
change the timezone in Windows and then execute simply:
php echo date("T");
This returns UTC instead of IST.
Seems like PHP is not able to correctly reading the Timezone from
Windows environment, so it does not know what is the system timezone.
[2008-02-15 13:29:05] [EMAIL PROTECTED]
# php -n -d date.timezone=Asia/Calcutta -r 'echo date("T");'
IST
So you're just using wrong timezone name..?
[2008-02-15 13:12:09] protomank at gmail dot com
Description:
If I set the windows timzeone to a zone with half-hour, like 5:30
(clacuttah) date('T') returns UTC.
This way I can't convert timestamps to the correct time of the machine.
Reproduce code:
---
date('T')
Expected result:
Asia/Calcuttah
Actual result:
--
UTC
--
Edit this bug report at http://bugs.php.net/?id=44129&edit=1
#44129 [Fbk->Opn]: Halt-hour timezones returning UTC
ID: 44129
User updated by: protomank at gmail dot com
Reported By: protomank at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: *General Issues
Operating System: Windows XP
PHP Version: 5.2.5
New Comment:
Hum, forgot to mention I was running it under Apache 2.2, sorry :(
But it doesn't affect the bug anyway.
The bug doesn't happen when you pass the timezone to PHP, but when you
change the timezone in Windows and then execute simply:
php echo date("T");
This returns UTC instead of IST.
Seems like PHP is not able to correctly reading the Timezone from
Windows environment, so it does not know what is the system timezone.
Previous Comments:
[2008-02-15 13:29:05] [EMAIL PROTECTED]
# php -n -d date.timezone=Asia/Calcutta -r 'echo date("T");'
IST
So you're just using wrong timezone name..?
[2008-02-15 13:12:09] protomank at gmail dot com
Description:
If I set the windows timzeone to a zone with half-hour, like 5:30
(clacuttah) date('T') returns UTC.
This way I can't convert timestamps to the correct time of the machine.
Reproduce code:
---
date('T')
Expected result:
Asia/Calcuttah
Actual result:
--
UTC
--
Edit this bug report at http://bugs.php.net/?id=44129&edit=1
#44080 [Fbk->Opn]: Session misbehaviour with Mozilla browsers
ID: 44080 User updated by: k dot mcmanus at gre dot ac dot uk Reported By: k dot mcmanus at gre dot ac dot uk -Status: Feedback +Status: Open Bug Type: Session related Operating System: Solaris and Windows PHP Version: 5.2.5 New Comment: Yes, in an ideal world pages should not have empty elements. But in my less than ideal world I have students using XHML templates with empty placeholders. Not surprisingly I have some pretty confused students who I am having difficulty keeping away from IE. I can understand how an empty href attribute may cause a user agent to make an HTTP request for the file path with no file name and the server returning whatever is the default file, usually index.php or index.html. But Moz interprets the empty href attribute value as being the filename, which isn't really all that sensible. And... surely the browser should be sensible enough to realise that the HTTP response isn't text/css. Before I pass this over to the good people at Moz there remains an unresolved PHP problem... If this effect is caused by Moz sending a GET request for register.php we should see warnings. This is a simple enough experiment. Instead of refreshing register.php (in which case the browser will want to resend the POST data), click in the browser address bar and hit Enter to force it to GET register.php - hey presto - warnings. Previous Comments: [2008-02-15 14:25:38] [EMAIL PROTECTED] See also bug #10599 and bug #33705 [2008-02-15 13:41:42] [EMAIL PROTECTED] Ah yes..that empty link definately will cause problems. I guess Mozilla based browsers are more strict in this, IE is known to allow pretty much any crap. :) I tested your page using FF and having Firebug installed, and it does 2 requests for index.php. For example this bug page only shows 1 request. This is not really any PHP bug just how decent browsers behave. You shouldn't have empty links like that around anyway. [2008-02-15 04:28:13] k dot mcmanus at gre dot ac dot uk Since posting my ever helpful sysops have moved http://cms-stu-iis.gre.ac.uk/mk05/session/index.php to PHP 5.2.5 and I have recently installed 5.2.5 onto Apache 2.2.8 The bug still manifests. I am not sure why jani asks for session settings as the sessions work correctly in all browsers other than Moz and work but incorrectly in all Moz browsers, but if it helps these can be found at http://staffweb.cms.gre.ac.uk/~mk05/info.php http://stuweb.cms.gre.ac.uk/~mk05/info.php http://cms-stu-iis.gre.ac.uk/mk05/info.php I am slightly puzzled as to how this bug has lived so long as it is causing dreadful problems for my poor students. As to the underlying mechanism... I think, but don't know, and I am not terribly confident but... Perhaps Moz clients send an HTTP GET request for register.php when they encounter the empty href attribute in the element. This would overwrite the SESSION entries causing them to lose their value, which is what we see. Although if this is happening then why do we not see Undefined index warnings raised by the POST variables not existing (which is what you see if you GET register.php). [2008-02-13 18:02:53] [EMAIL PROTECTED] You're not using PHP 5.2.5 in any place? I'd suggest upgrading first. And then check what your session.* settings are in your php.ini file. (or rather from the phpinfo(); output) [2008-02-13 17:51:47] svenne at krap dot dk for me the bug creeps up in old, stable code that suddently doesn't work any more. as original poster said, IE works fine, FF does not. The bug is also not present in konqueror (kde browser) nor epiphany (gnome browser) As OP said, strings entered to the session object (in my case indirectly via some custom classes) are kept, values from database seems kept, values from queries (GET/POST) are dropped. My server runs Linux (Gentoo, mostly stable) 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/44080 -- Edit this bug report at http://bugs.php.net/?id=44080&edit=1
#37351 [Com]: func_get_args() does not return variables by reference
ID: 37351 Comment by: thomas at koch dot ro Reported By: chris at starglade dot org Status: Open Bug Type: Feature/Change Request Operating System: Any PHP Version: 5.1.4 New Comment: is the same as http://bugs.php.net/bug.php?id=6427 Previous Comments: [2006-05-07 18:49:53] chris at starglade dot org Description: func_get_args() and func_get_arg() should return variables by reference. Reproduce code: --- http://bugs.php.net/?id=37351&edit=1
#44072 [Opn->Fbk]: substr don't work correctly with binary string
ID: 44072 Updated by: [EMAIL PROTECTED] Reported By: sergey89 at gmail dot com -Status: Open +Status: Feedback Bug Type: Strings related Operating System: FreeBSD 6.3 PHP Version: 5.2.5 New Comment: If it works in CLI but not in webserver, then there's propably something different between those two, maybe PHP version..?* Previous Comments: [2008-02-14 09:38:55] sergey89 at gmail dot com I generate data with simple PHP script: Expected result: 45e26dc33aad8e93f3f45c8d5100feb0 | 03d900cc2ba7276fb3bb3f1939303e3b Actual result: -- 45e26dc33aad8e93f3f45c8d5100feb0 | d1cea9d93cb48b2d897595f5e96ba352 -- Edit this bug report at http://bugs.php.net/?id=44072&edit=1
#44080 [Fbk]: Session misbehaviour with Mozilla browsers
ID: 44080 Updated by: [EMAIL PROTECTED] Reported By: k dot mcmanus at gre dot ac dot uk Status: Feedback Bug Type: Session related Operating System: Solaris and Windows PHP Version: 5.2.5 New Comment: See also bug #10599 and bug #33705 Previous Comments: [2008-02-15 13:41:42] [EMAIL PROTECTED] Ah yes..that empty link definately will cause problems. I guess Mozilla based browsers are more strict in this, IE is known to allow pretty much any crap. :) I tested your page using FF and having Firebug installed, and it does 2 requests for index.php. For example this bug page only shows 1 request. This is not really any PHP bug just how decent browsers behave. You shouldn't have empty links like that around anyway. [2008-02-15 04:28:13] k dot mcmanus at gre dot ac dot uk Since posting my ever helpful sysops have moved http://cms-stu-iis.gre.ac.uk/mk05/session/index.php to PHP 5.2.5 and I have recently installed 5.2.5 onto Apache 2.2.8 The bug still manifests. I am not sure why jani asks for session settings as the sessions work correctly in all browsers other than Moz and work but incorrectly in all Moz browsers, but if it helps these can be found at http://staffweb.cms.gre.ac.uk/~mk05/info.php http://stuweb.cms.gre.ac.uk/~mk05/info.php http://cms-stu-iis.gre.ac.uk/mk05/info.php I am slightly puzzled as to how this bug has lived so long as it is causing dreadful problems for my poor students. As to the underlying mechanism... I think, but don't know, and I am not terribly confident but... Perhaps Moz clients send an HTTP GET request for register.php when they encounter the empty href attribute in the element. This would overwrite the SESSION entries causing them to lose their value, which is what we see. Although if this is happening then why do we not see Undefined index warnings raised by the POST variables not existing (which is what you see if you GET register.php). [2008-02-13 18:02:53] [EMAIL PROTECTED] You're not using PHP 5.2.5 in any place? I'd suggest upgrading first. And then check what your session.* settings are in your php.ini file. (or rather from the phpinfo(); output) [2008-02-13 17:51:47] svenne at krap dot dk for me the bug creeps up in old, stable code that suddently doesn't work any more. as original poster said, IE works fine, FF does not. The bug is also not present in konqueror (kde browser) nor epiphany (gnome browser) As OP said, strings entered to the session object (in my case indirectly via some custom classes) are kept, values from database seems kept, values from queries (GET/POST) are dropped. My server runs Linux (Gentoo, mostly stable) [2008-02-09 02:43:02] k dot mcmanus at gre dot ac dot uk Description: I have EXACTLY the same files on 2 different Apache (Solaris) servers and an IIS server. The example works correctly with IE5.5, 6 and 7 and Opera 9 clients but with Firefox (2.0.0.12 or 2.0.0.11) or Mozilla (1.7.10) clients. Yes, cookies are on in the clients and I have tried restarting the clients and tried several client machines. Please feel free to try the examples... PHP 4.3.10 on Apache http://staffweb.cms.gre.ac.uk/~mk05/session/index.php PHP5.0.5 on Apache http://stuweb.cms.gre.ac.uk/~mk05/session/index.php PHP5.2.3 on IIS http://cms-stu-iis.gre.ac.uk/mk05/session/index.php When you reach activate.php $_SESSION has remembered literals but has forgotten variable values. I am at a loss to explain why it refuses to work in Moz clients. I am am even more confused at to why commenting out the line in register.php fixes the problem. I am not at all clear as to whether the problem lies with Mozilla or PHP. The fact that it affects such a range of versions of both PHP and Mozilla is also mystifying. I cannot imaging what possible mechanism could cause this effect. Reproduce code: --- http://staffweb.cms.gre.ac.uk/~mk05/session/index.php.txt http://staffweb.cms.gre.ac.uk/~mk05/session/register.php.txt http://staffweb.cms.gre.ac.uk/~mk05/session/activate.php.txt These are links not copies so you see exactly the same source. Expected result: 3 stage process index.php -> register.php -> activate.php (you don't need to fill in the forms, just press the buttons) form input from index.php is posted to register.php in register.php the POST data is copied into $_SESSION together with a string literal in activate.php the session values are printed Actual result: -- in activate.php the session has lost the values of the variables but not the value of the literal - only with Mo
#44080 [Opn->Fbk]: Session misbehaviour with Mozilla browsers
ID: 44080 Updated by: [EMAIL PROTECTED] Reported By: k dot mcmanus at gre dot ac dot uk -Status: Open +Status: Feedback Bug Type: Session related Operating System: Solaris and Windows PHP Version: 5.2.5 New Comment: Ah yes..that empty link definately will cause problems. I guess Mozilla based browsers are more strict in this, IE is known to allow pretty much any crap. :) I tested your page using FF and having Firebug installed, and it does 2 requests for index.php. For example this bug page only shows 1 request. This is not really any PHP bug just how decent browsers behave. You shouldn't have empty links like that around anyway. Previous Comments: [2008-02-15 04:28:13] k dot mcmanus at gre dot ac dot uk Since posting my ever helpful sysops have moved http://cms-stu-iis.gre.ac.uk/mk05/session/index.php to PHP 5.2.5 and I have recently installed 5.2.5 onto Apache 2.2.8 The bug still manifests. I am not sure why jani asks for session settings as the sessions work correctly in all browsers other than Moz and work but incorrectly in all Moz browsers, but if it helps these can be found at http://staffweb.cms.gre.ac.uk/~mk05/info.php http://stuweb.cms.gre.ac.uk/~mk05/info.php http://cms-stu-iis.gre.ac.uk/mk05/info.php I am slightly puzzled as to how this bug has lived so long as it is causing dreadful problems for my poor students. As to the underlying mechanism... I think, but don't know, and I am not terribly confident but... Perhaps Moz clients send an HTTP GET request for register.php when they encounter the empty href attribute in the element. This would overwrite the SESSION entries causing them to lose their value, which is what we see. Although if this is happening then why do we not see Undefined index warnings raised by the POST variables not existing (which is what you see if you GET register.php). [2008-02-13 18:02:53] [EMAIL PROTECTED] You're not using PHP 5.2.5 in any place? I'd suggest upgrading first. And then check what your session.* settings are in your php.ini file. (or rather from the phpinfo(); output) [2008-02-13 17:51:47] svenne at krap dot dk for me the bug creeps up in old, stable code that suddently doesn't work any more. as original poster said, IE works fine, FF does not. The bug is also not present in konqueror (kde browser) nor epiphany (gnome browser) As OP said, strings entered to the session object (in my case indirectly via some custom classes) are kept, values from database seems kept, values from queries (GET/POST) are dropped. My server runs Linux (Gentoo, mostly stable) [2008-02-09 02:43:02] k dot mcmanus at gre dot ac dot uk Description: I have EXACTLY the same files on 2 different Apache (Solaris) servers and an IIS server. The example works correctly with IE5.5, 6 and 7 and Opera 9 clients but with Firefox (2.0.0.12 or 2.0.0.11) or Mozilla (1.7.10) clients. Yes, cookies are on in the clients and I have tried restarting the clients and tried several client machines. Please feel free to try the examples... PHP 4.3.10 on Apache http://staffweb.cms.gre.ac.uk/~mk05/session/index.php PHP5.0.5 on Apache http://stuweb.cms.gre.ac.uk/~mk05/session/index.php PHP5.2.3 on IIS http://cms-stu-iis.gre.ac.uk/mk05/session/index.php When you reach activate.php $_SESSION has remembered literals but has forgotten variable values. I am at a loss to explain why it refuses to work in Moz clients. I am am even more confused at to why commenting out the line in register.php fixes the problem. I am not at all clear as to whether the problem lies with Mozilla or PHP. The fact that it affects such a range of versions of both PHP and Mozilla is also mystifying. I cannot imaging what possible mechanism could cause this effect. Reproduce code: --- http://staffweb.cms.gre.ac.uk/~mk05/session/index.php.txt http://staffweb.cms.gre.ac.uk/~mk05/session/register.php.txt http://staffweb.cms.gre.ac.uk/~mk05/session/activate.php.txt These are links not copies so you see exactly the same source. Expected result: 3 stage process index.php -> register.php -> activate.php (you don't need to fill in the forms, just press the buttons) form input from index.php is posted to register.php in register.php the POST data is copied into $_SESSION together with a string literal in activate.php the session values are printed Actual result: -- in activate.php the session has lost the values of the variables but not the value of the literal - only with Mozilla/Firefox browsers -- Edit this bug report a
#44130 [NEW]: func_get_args should return references
From: thomas at koch dot ro
Operating system: Debian
PHP version: 4.4.8
PHP Bug Type: Unknown/Other Function
Bug description: func_get_args should return references
Description:
THIS IS MY FIRST REPORT! PLEASE DON'T BANG ME!
I'd like to use func_get_args to manipulate variables sent by reference. I
encountered this problem(?) by evaluating ezcSignalSlot[1]. There you
find:
$parameters = array_slice( func_get_args(), 1 );
call_user_func_array( $callback, $parameters );
It would be fine, if I could use the combination of this methods to pipe
references to normal variables.
[1] http://ezcomponents.org/docs/tutorials/SignalSlot
Reproduce code:
---
function test( )
{
$args =& func_get_args();
$args[0]++;
}
$i=1;
test( &$i );
echo $i;
Expected result:
2
Actual result:
--
1
--
Edit bug report at http://bugs.php.net/?id=44130&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=44130&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44130&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44130&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44130&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44130&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44130&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44130&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44130&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44130&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44130&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44130&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44130&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44130&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44130&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44130&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=44130&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44130&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44130&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44130&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44130&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44130&r=mysqlcfg
#44129 [Opn->Fbk]: Halt-hour timezones returning UTC
ID: 44129
Updated by: [EMAIL PROTECTED]
Reported By: protomank at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: *General Issues
Operating System: Windows XP
PHP Version: 5.2.5
New Comment:
# php -n -d date.timezone=Asia/Calcutta -r 'echo date("T");'
IST
So you're just using wrong timezone name..?
Previous Comments:
[2008-02-15 13:12:09] protomank at gmail dot com
Description:
If I set the windows timzeone to a zone with half-hour, like 5:30
(clacuttah) date('T') returns UTC.
This way I can't convert timestamps to the correct time of the machine.
Reproduce code:
---
date('T')
Expected result:
Asia/Calcuttah
Actual result:
--
UTC
--
Edit this bug report at http://bugs.php.net/?id=44129&edit=1
#44129 [NEW]: Halt-hour timezones returning UTC
From: protomank at gmail dot com
Operating system: Windows XP
PHP version: 5.2.5
PHP Bug Type: *General Issues
Bug description: Halt-hour timezones returning UTC
Description:
If I set the windows timzeone to a zone with half-hour, like 5:30
(clacuttah) date('T') returns UTC.
This way I can't convert timestamps to the correct time of the machine.
Reproduce code:
---
date('T')
Expected result:
Asia/Calcuttah
Actual result:
--
UTC
--
Edit bug report at http://bugs.php.net/?id=44129&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=44129&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44129&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44129&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44129&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44129&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44129&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44129&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44129&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44129&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44129&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44129&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44129&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44129&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44129&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44129&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=44129&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44129&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44129&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44129&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44129&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44129&r=mysqlcfg
#44128 [NEW]: Incorrect recursion detection for undefined variable
From: felipensp at gmail dot com
Operating system:
PHP version: 5.3CVS-2008-02-15 (CVS)
PHP Bug Type: Scripting Engine problem
Bug description: Incorrect recursion detection for undefined variable
Description:
Undefined variables non-reference/reference as item of an array has
different behavior.
Reproduce code:
---
1:
[EMAIL PROTECTED]:~/php5$ sapi/cli/php -r 'var_dump($a =array($a));'
2:
[EMAIL PROTECTED]:~/php5$ sapi/cli/php -r 'var_dump(array(&$a));'
3:
[EMAIL PROTECTED]:~/php5$ sapi/cli/php -r 'var_dump($a =array(&$a));'
Expected result:
2 and 3 as same result.
Actual result:
--
1:
array(1) {
[0]=>
NULL
}
2:
array(1) {
[0]=>
&NULL
}
3:
array(1) {
[0]=>
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
--
Edit bug report at http://bugs.php.net/?id=44128&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=44128&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44128&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44128&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44128&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44128&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44128&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44128&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44128&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44128&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44128&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44128&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44128&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44128&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44128&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44128&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=44128&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44128&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44128&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44128&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44128&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44128&r=mysqlcfg
#43616 [Com]: mssql_execute() stored procedure has no return value.
ID: 43616 Comment by: sven dot vandorpe at telenet dot be Reported By: ville dot tuomola at mehilainen dot fi Status: Open Bug Type: MSSQL related Operating System: Fedora 8 PHP Version: 5.2.5 New Comment: Hi, Some additional information. This issue is resolved when using FreeTDS v0.82RC1 With kind regards, Van Dorpe Sven Previous Comments: [2008-02-14 15:12:46] sven dot vandorpe at telenet dot be Some additional information about this problem. It seems that this is probably not PHP related. I tested the procedure on PHP 5.1.6 that was compiled with FreeTDS 0.63: The result was that the PHP script returned "2" Afterwards I compiled FreeTDS 0.64 and recompiled PHP 5.1.6 so that it used the FreeTDS 0.64 libraries: The result of the PHP script is now "0" The error in the Apache error log: "[Thu Feb 14 14:17:10 2008] [error] PHP Warning: mssql_execute() [function.mssql-execute]: stored procedure has no return value. Nothing was returned into RETVAL in /usr/share/nagios/share/test.php on line 18" With kind regards, Van Dorpe Sven [2008-01-28 20:13:27] ethan dot nelson at ltd dot org Connecting to MSSQL 2000, I cannot get the return values from a user-defined function. The number of rows comes through. The column names comes through when I do fetch_array. However, the values do not. Same query returns values in query analyzer. Further, testing showed that when a SQL view was created that selected * from the user defined function and added a derived column, such as 'test' = 1, the derived column's value comes through, but still the other values associated with the user-defined function do not. [2007-12-17 13:24:43] ville dot tuomola at mehilainen dot fi Description: When executing a stored procedure with mssql_execute, it does not return the return value of the procedure. It does not matter whether the "skip_results" parameters is used in mssql_execute or not. Reproduce code: --- CREATE PROC sp_Test AS RETURN 2 sp_Test returned: $ret"; ?> Expected result: sp_Test returned: 2 Actual result: -- Warning: mssql_execute() [function.mssql-execute]: stored procedure has no return value. Nothing was returned into RETVAL in /var/www/vkajanvaraus/htdocs/test.php on line 20 sp_Test returned: 0 -- Edit this bug report at http://bugs.php.net/?id=43616&edit=1
#43164 [Fbk]: Array property with recursion
ID: 43164
Updated by: [EMAIL PROTECTED]
Reported By: felipensp at gmail dot com
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.3CVS-2007-10-31 (snap)
Assigned To: dmitry
New Comment:
Actual result (5_3):
object(foo)#1 (1) {
["a"]=>
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
object(foo)#1 (1) {
["a"]=>
array(1) {
[0]=>
array(0) {
}
}
}
array(1) {
[0]=>
array(0) {
}
}
array(1) {
[0]=>
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
It looks fixed! :)
Previous Comments:
[2008-02-15 07:00:13] [EMAIL PROTECTED]
I don't see where the problem is. It looks like both PHP_5_2 and
PHP_5_3 work proper (except of memory leaks in PHP_5_2). Expectations
for the second and third cases in original post are wrong.
[2008-02-15 00:07:12] [EMAIL PROTECTED]
Oh..I forgot the original problem, that still exists, just the leaks
are gone now in PHP_5_3.
[2008-02-15 00:05:50] [EMAIL PROTECTED]
This seems to be fixed for PHP 5.3, but it still happens with PHP 5.2
(latest CVS), can you check whether it's fixable? Maybe some patch
wasn't MFH'd?
[2007-11-01 09:23:39] [EMAIL PROTECTED]
Same result with all branches: HEAD/PHP_5_3/PHP_5_2
[2007-11-01 09:22:15] [EMAIL PROTECTED]
A bit different result:
object(foo)#1 (1) {
["a"]=>
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
object(foo)#1 (1) {
["a"]=>
array(1) {
[0]=>
array(0) {
}
}
}
array(1) {
[0]=>
array(1) {
[0]=>
*RECURSION*
}
}
array(1) {
[0]=>
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
And it leaks too:
[Thu Nov 1 11:21:24 2007] Script: 't.php'
/home/jani/src/php-5.3/Zend/zend_vm_execute.h(18896) : Freeing
0x0A62D848 (44 bytes), script=t.php
/home/jani/src/php-5.3/Zend/zend_API.c(911) : Actual location (location
was relayed)
Last leak repeated 3 times
[Thu Nov 1 11:21:24 2007] Script: 't.php'
/home/jani/src/php-5.3/Zend/zend_execute.c(852) : Freeing 0x0A62DBD0
(16 bytes), script=t.php
Last leak repeated 1 time
[Thu Nov 1 11:21:24 2007] Script: 't.php'
/home/jani/src/php-5.3/Zend/zend_execute.c(1093) : Freeing 0x0A62DC60
(35 bytes), script=t.php
/home/jani/src/php-5.3/Zend/zend_hash.c(388) : Actual location
(location was relayed)
Last leak repeated 1 time
=== Total 8 memory leaks detected ===
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/43164
--
Edit this bug report at http://bugs.php.net/?id=43164&edit=1
#43487 [Asn]: Wrong conversion of float to string
ID: 43487 Updated by: [EMAIL PROTECTED] Reported By: jm at wo dot cz Status: Assigned Bug Type: Strings related Operating System: Linux PHP Version: 5.2.5 Assigned To: dmitry New Comment: Not reproducible with GCC 4.3.0 & 4.3.2 with -O3 on Linux 64bit. Previous Comments: [2008-02-14 23:31:30] [EMAIL PROTECTED] Dmitry, can you check this out? There's a patch too. :) [2008-02-11 17:49:44] oeriksson at mandriva dot com Here's a shorter URL that hopefully won't wrap: http://n1.nux.se/php-5.2.5-use-volatile-to-force-float-store.patch [2008-02-01 12:07:10] oeriksson at mandriva dot com Pascal Rigaux at Mandriva has a patch for this, please review it. http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/php/current/SOURCES/php-5.2.5-use-volatile-to-force-float-store.patch?revision=161099&view=markup [2008-01-31 15:42:55] oeriksson at mandriva dot com Update; taken from our bugzilla: "as peroyvind found, the miscompilation is inside Zend/zend_strtod.c, and -no-ftree-vrp workaround the bug." [2008-01-30 19:41:18] oeriksson at mandriva dot com I think I found the problem. On Mandriva Linux Cooker we are using: gcc (GCC) 4.2.2 20071128 (prerelease) (4.2.2-2mdv2008.1) glibc-2.7-1mdv2008.1 If I change the optimization from -O2 to -O0 (-O+zero) the bug goes away on x86_32. 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/43487 -- Edit this bug report at http://bugs.php.net/?id=43487&edit=1
#44127 [NEW]: UNIX abstract namespace socket connects only work sometimes
From: pz4u at vplace dot de Operating system: Linux PHP version: 5.2.5 PHP Bug Type: Sockets related Bug description: UNIX abstract namespace socket connects only work sometimes Description: I'm currently developing a binding for D-BUS based on native PHP. For that reason I need to talk to abstract namespace sockets. It seems like PHP is handling these socket type differently than D-BUS. I can't connect to the abstract socket. I asked for help on the php-general mailing list and got some helpful responses for further investigation: http://marc.info/?t=12029132085&r=1&w=2 After that I asked on the D-BUS mailing list for clarification how D-BUS implements abstract namespace support: http://lists.freedesktop.org/archives/dbus/2008-February/009303.html As pointed out by Havoc on the dbus mailing list I think the problem is here: http://cvs.php.net/viewvc.cgi/php-src/ext/sockets/sockets.c?revision=1.197&view=markup or in the stream version of this API (not sure if it uses the same functions). - I'm wondering why 108 is hardcoded here (in the connect function). A constant might be better? - "If the connect() or listen() just does sizeof(struct sockaddr_un) then it will always get a bunch of trailing garbage bytes in the abstract name." (quoted Havoc here) - Even if their is no NUL byte to mark the end of the string PHP should only use non-nul byte characters for the path (or better: the string that has been given by the programmer.) If a programmer want's to fill up sun_path with NUL bytes, it should be added to the PHP code and not "assumed". I'm not a C programmer - so the code in sockets.c might just do what I wrote - I'm sorry for any inconveniences in this case. This seems to be a regression of bug #16121 Reproduce code: --- Expected result: A connect with \x00/tmp/dbus-whatever (without added NUL bytes until the maximum sun path length is reached). Actual result: -- fsockopen: fsockopen(): unable to connect to unix://:0 (Connection refused) for unix://\x00/tmp/dbus-whatever which is a bit strange because I expected at least the error message "fsockopen() [function.fsockopen]: unable to connect to unix://[NUL byte]/tmp/dbus-whatever:0 (Connection refused)" stream_socket_client: stream_socket_client: unable to connect to unix://\0/tmp/hald-local/dbus-ZniNmvr5O0 (Connection refused) in ... socket_connect: Warning: socket_connect(): unable to connect [22]: Invalid argument in ... I can garantuee that the arguments are right - removing the NUL byte from socket_connect allows me to connect to a non-abstract socket. -- Edit bug report at http://bugs.php.net/?id=44127&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=44127&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44127&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44127&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44127&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44127&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44127&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44127&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44127&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44127&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44127&r=support Expected behavior:http://bugs.php.net/fix.php?id=44127&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44127&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44127&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44127&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44127&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=44127&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44127&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44127&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44127&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44127&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44127&r=mysqlcfg
