#43649 [NEW]: Strange error message when performing a query
From: andrei dot vig at ecommerce dot com Operating system: Debian GNU PHP version: 5.2CVS-2007-12-21 (snap) PHP Bug Type: PDO related Bug description: Strange error message when performing a query Description: i am trying to run a few lines of code and i am getting the following error. Can you please give me a hint here : Error message : Invalid datetime format: 7 ERROR: invalid input syntax for type timestamp: "2007-12-21 07$1$2"' and error code 22007 Reproduce code: --- Code : $s_sql = "SELECT hd.hd_ticketid, hdc.title AS category_title, hds.title AS status_title, hd.subject, hd.datetimecreated, extract(epoch from hd.datetimecreated) as datetimecreated_timestamp, CASE WHEN hd.domain IS NOT NULL THEN hd.domain WHEN hd.dom_domain IS NOT NULL THEN hd.dom_domain ELSE 'General Inquiry' END as target, CASE WHEN loginid_last_repl <> 56455 AND (hd.hd_statusid = 3 OR hd.hd_statusid = 1) THEN 'Processing Ticket' WHEN hd.hd_statusid = 2 THEN 'http://andrei-ixhead.ecommerce.com/index.php/cpanelhelpdesk.getFrmTicketModify/hd_ticketid/' || hd.hd_ticketid ||'''>Please Respond' WHEN hd.hd_statusid = 4 THEN 'http://andrei-ixhead.ecommerce.com/index.php/cpanelhelpdesk.getFrmTicketModify/hd_ticketid/' || hd.hd_ticketid ||'''>Review Solution' WHEN hd.hd_statusid = 5 THEN 'Ticket Closed' WHEN loginid_last_repl = 56455 THEN (extract(epoch from '2007-12-21 07:42:53'::timestamp) - extract(epoch from coalesce(hd.datetimemodified_customer, hd.datetimecreated)))::varchar END as time_passed, CASE WHEN loginid_last_repl <> 56455 AND (hd.hd_statusid = 3 OR hd.hd_statusid = 1) THEN -4 WHEN hd.hd_statusid = 2 THEN -3 WHEN hd.hd_statusid = 4 THEN -2 WHEN hd.hd_statusid = 5 THEN -1 WHEN loginid_last_repl = 56455 THEN extract(epoch from '2007-12-21 07:42:53'::timestamp) - extract(epoch from coalesce(hd.datetimemodified_customer, hd.datetimecreated)) END as time_passed_timestamp, customer_read, CASE WHEN datetimeconfirmed IS NULL THEN 'http://andrei-ixhead.ecommerce.com/index.php/cpanelhelpdesk.qryTicketVerify/hd_ticketid/' || hd.hd_ticketid ||'''>Verify' ELSE 'Verified' END as verify_link, CASE WHEN hd.hd_statusid = 5 THEN 'Closed' ELSE 'Close' END AS close_link, CASE WHEN 4=hd.hd_statusid THEN hd.hd_ticketid ELSE NULL END AS close_ticketid FROMhd_ticket hd INNER JOIN hd_ticket_category hdc USING(hd_ticket_categoryid) INNER JOIN hd_ticket_status hds USING(hd_statusid) WHERE hd.customerid = 56204 AND hd.b_visible AND hd.hd_statusid IN (1,2,3,4)GROUP BYhd.hd_ticketid, hdc.title, hds.title, hd.subject, hd.datetimecreated, hd.domain, hd.dom_domain, hd.customer_read, hd.hd_statusid, hd.datetimemodified_emp, hd.datetimemodified_customer, hd.loginid_last_repl, hd.datetimeconfirmed ORDER BY hd.hd_statusid = 2, hd.hd_statusid = 4, hd.hd_ticketid DESC LIMIT 1 OFFSET 0"; $o_pdo->query($s_sql); Expected result: query works when i run it directly in psql -- Edit bug report at http://bugs.php.net/?id=43649&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43649&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43649&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43649&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43649&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43649&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43649&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43649&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43649&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43649&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43649&r=support Expected behavior:http://bugs.php.net/fix.php?id=43649&r=notwrong Not e
#41350 [Com]: Error in my_thread_global_end()
ID: 41350 Comment by: ekarudito at gmail dot com Reported By: graham at directhostinguk dot com Status: No Feedback Bug Type: MySQL related Operating System: Windows 2003 PHP Version: 5.2.3 New Comment: i have error too... using apache 2.2.4 php 5.2.1 (windows XP) mysql 5.0.37 i have this error when using stored procedure.. in php script and show this error in error log in apache.. and i think's maybe.. caused by bind_result function.. (using mysqli) because when i comment this function, mozzila can work normally although it show few of warning Previous Comments: [2007-12-17 10:44:22] scratch65535 at att dot net I'm in the throes of converting from PHP 4 and MySQL 4 to PHP 5.2.5 and MySQL 5.0.45 on my W2K dev machine. So I'm moving to latest-and-greatest code on both sides, and was quite surprised, also dismayed, to see this my_thread bug. [2007-12-10 16:21:53] m dot bariola at prodigiweb dot it Hi, I experienced this problem too and still am. however I might give some info that might move the focus to a different point. Reading the comments, I see that some people are experiencing it with or without mySQL, or on imap, solving with older lib version, etc. I have two winXP systems both running the same XAMPP version (1.6.4). I have no problems on my home PC, so I repeated the configuration on the work PC. easy as repeating the XAMPP installation with same paths as home, then copying the apache conf folder from home, and modifying the Path variable so that it will look for executables in c:\xampp\php also. basically, exactly the same as home, but the work PC does not work, while the home installation has no such problems. hope this helps in finding the real cause of the problem. [2007-12-07 13:47:32] jean-yves dot deleze at crealp dot vs dot ch I recently installed PHP 5.2.5 on Windows and the error was still there (MySQL version 5.0.45). The only way to remove the error was to use old versions of php_mysql(i).dll or libmysql.dll (<= 5.0.27). Today I downloaded MySQL 5.0.51 Win32 sources, I compiled the libmysql.dll library and replaced the one shiped with PHP 5.2.5. This solved the problem. [2007-12-05 12:53:41] ulmer at energieagentur dot nrw dot de The version of the mysql extension at http://dev.mysql.com/downloads/connector/php/ is 5.0.27 right now which seems to be quite old. The Changelog date is 2006-11-17, so it is more than a year old! Installing this version is NOT a solution for me. [2007-12-04 12:40:24] webmaster at cosmicperl dot com !!SOLUTION!! !!SOLUTION!! If you download the latest PHP - MySQL connector files direct from MySQL this problem goes away:- http://dev.mysql.com/downloads/connector/php/ Why hasn't PHP updated to these latest files?!?!? !!SOLUTION!! !!SOLUTION!! 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/41350 -- Edit this bug report at http://bugs.php.net/?id=41350&edit=1
#43644 [Opn->Csd]: is_callable(':') crashes in CLI.
ID: 43644
Updated by: [EMAIL PROTECTED]
Reported By: kubo at iteman dot jp
-Status: Open
+Status: Closed
Bug Type: Reproducible crash
Operating System: Windows XP SP2
PHP Version: 5.3CVS-2007-12-20 (snap)
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:
[2007-12-20 17:43:35] [EMAIL PROTECTED]
In Linux works fine.
[2007-12-20 16:46:23] kubo at iteman dot jp
Description:
is_callable(':') crashes in CLI.
Reproduce code:
---
var_dump(is_callable(':'));
Expected result:
bool(false)
Actual result:
--
No display. A Windows Error Reporting dialog box appears.
--
Edit this bug report at http://bugs.php.net/?id=43644&edit=1
#43645 [Com]: PHP 5.2.5 + php_mssql OR FreeTDS does not work
ID: 43645
Comment by: pcorbe81 at maine dot edu
Reported By: earnest dot berry at gmail dot com
Status: Open
Bug Type: MSSQL related
Operating System: Windows/Linux
PHP Version: 5.2.5
New Comment:
I have the same setup and once I upgraded to 5.2.5, I received the same
error. When I downgraded back to 5.2.3, it worked fine. I also used the
same php.ini as I had in 5.2.3 and also tried modifying the new
php-dist.ini with no avail. I am using the php_mssql.dll driver in
conjuction with ntwlib.dll (same as the one described by above). I would
agree that there seems to be something different in 5.2.5 that is
causing this, although I can't tell what either.
Previous Comments:
[2007-12-20 18:18:38] earnest dot berry at gmail dot com
I also forgot to add that this issue has been verified by another
independent developer. He had the same issue when trying to move to
5.2.5.
[2007-12-20 18:16:43] earnest dot berry at gmail dot com
Description:
I've tried using FreeTDS on Windows. With build 5.2.5, the php_mssql
driver does not work. I haven't had a chance to investigate what changed
in 5.2.5 to make this happen.
I had an application running perfectly using PHP+MSSQL but upon
upgrading to 5.2.5 all failed. When I down-graded, the application
worked again.
Also, if anyone is wondering, yes, I am using the updated ntwlib, no
the default one that comes with PHP. Also, if I use the microsoft SQL
Driver ( http://www.microsoft.com/sql/technologies/php/default.mspx )
using 5.2.5, I can connect to SQL Server just fine, so this leads me to
believe it's a problem with 5.2.5 in particular.
Also, I am not using the default port of 1433, but I have tried this
connection using bot hthe default port of 1433 and the port I set to no
avail. But the SQL Driver from MSFT will connect on either port, and
when I downgrade it connects on either port fine.
Reproduce code:
---
$server = "localhost";
$port = "5356";
$username = 'webapp';
$password = '**';
$db = 'drupal5';
$con = mssql_connect("$server,$port", $username, $password);
if($con) {
print "We have a connection!";
}
else {
print "NO CONNECTION TO |$server,$port| $username, $password!
ERROR!";
}
Expected result:
A screen that says: "We have a connection!"
Actual result:
--
A screen that says: "NO CONNECTION" with connection information.
--
Edit this bug report at http://bugs.php.net/?id=43645&edit=1
#43647 [NEW]: RFC: FindFile should use PATH_SEPARATOR instead of ";" to split $path
From: fangel at sevengoslings dot net Operating system: All PHP version: 5.2.5 PHP Bug Type: SPL related Bug description: RFC: FindFile should use PATH_SEPARATOR instead of ";" to split $path Description: If you look at the documentation for SPL's FindFile [1] the input $path, which can be separator by ";". Wouldn't it make more sense if this was set to PATH_SEPARATOR? (PS) If it was set to PS, one could search for files in the include-path just by supplying get_include_path() as a parameter.. And that makes sense to me.. Well - just want to know if it's deliberate, or if it's possible to even get a change like this considered.. [1] http://www.php.net/~helly/php/ext/spl/classFindFile.html Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit bug report at http://bugs.php.net/?id=43647&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43647&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43647&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43647&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43647&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43647&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43647&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43647&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43647&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43647&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43647&r=support Expected behavior:http://bugs.php.net/fix.php?id=43647&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43647&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43647&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43647&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43647&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43647&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43647&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43647&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43647&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43647&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43647&r=mysqlcfg
#43646 [NEW]: incorrect error message on recursive interface implementation error
From: weyrick at roadsend dot com Operating system: all PHP version: 5.2.5 PHP Bug Type: Unknown/Other Function Bug description: incorrect error message on recursive interface implementation error Description: A simple typo in the error message. This is originally from bug #30922, and the regression test will have to be changed as well. Reproduce code: --- Expected result: Fatal error: Interface RecurisiveFooFar cannot implement itself in ... Actual result: -- Fatal error: Interface RecurisiveFooFar cannot not implement itself in ... -- Edit bug report at http://bugs.php.net/?id=43646&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43646&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43646&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43646&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43646&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43646&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43646&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43646&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43646&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43646&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43646&r=support Expected behavior:http://bugs.php.net/fix.php?id=43646&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43646&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43646&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43646&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43646&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43646&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43646&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43646&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43646&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43646&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43646&r=mysqlcfg
#43645 [Opn]: PHP 5.2.5 + php_mssql OR FreeTDS does not work
ID: 43645
User updated by: earnest dot berry at gmail dot com
Reported By: earnest dot berry at gmail dot com
Status: Open
Bug Type: MSSQL related
Operating System: Windows/Linux
PHP Version: 5.2.5
New Comment:
I also forgot to add that this issue has been verified by another
independent developer. He had the same issue when trying to move to
5.2.5.
Previous Comments:
[2007-12-20 18:16:43] earnest dot berry at gmail dot com
Description:
I've tried using FreeTDS on Windows. With build 5.2.5, the php_mssql
driver does not work. I haven't had a chance to investigate what changed
in 5.2.5 to make this happen.
I had an application running perfectly using PHP+MSSQL but upon
upgrading to 5.2.5 all failed. When I down-graded, the application
worked again.
Also, if anyone is wondering, yes, I am using the updated ntwlib, no
the default one that comes with PHP. Also, if I use the microsoft SQL
Driver ( http://www.microsoft.com/sql/technologies/php/default.mspx )
using 5.2.5, I can connect to SQL Server just fine, so this leads me to
believe it's a problem with 5.2.5 in particular.
Also, I am not using the default port of 1433, but I have tried this
connection using bot hthe default port of 1433 and the port I set to no
avail. But the SQL Driver from MSFT will connect on either port, and
when I downgrade it connects on either port fine.
Reproduce code:
---
$server = "localhost";
$port = "5356";
$username = 'webapp';
$password = '**';
$db = 'drupal5';
$con = mssql_connect("$server,$port", $username, $password);
if($con) {
print "We have a connection!";
}
else {
print "NO CONNECTION TO |$server,$port| $username, $password!
ERROR!";
}
Expected result:
A screen that says: "We have a connection!"
Actual result:
--
A screen that says: "NO CONNECTION" with connection information.
--
Edit this bug report at http://bugs.php.net/?id=43645&edit=1
#43645 [NEW]: PHP 5.2.5 + php_mssql OR FreeTDS does not work
From: earnest dot berry at gmail dot com
Operating system: Windows/Linux
PHP version: 5.2.5
PHP Bug Type: MSSQL related
Bug description: PHP 5.2.5 + php_mssql OR FreeTDS does not work
Description:
I've tried using FreeTDS on Windows. With build 5.2.5, the php_mssql
driver does not work. I haven't had a chance to investigate what changed in
5.2.5 to make this happen.
I had an application running perfectly using PHP+MSSQL but upon upgrading
to 5.2.5 all failed. When I down-graded, the application worked again.
Also, if anyone is wondering, yes, I am using the updated ntwlib, no the
default one that comes with PHP. Also, if I use the microsoft SQL Driver (
http://www.microsoft.com/sql/technologies/php/default.mspx ) using 5.2.5, I
can connect to SQL Server just fine, so this leads me to believe it's a
problem with 5.2.5 in particular.
Also, I am not using the default port of 1433, but I have tried this
connection using bot hthe default port of 1433 and the port I set to no
avail. But the SQL Driver from MSFT will connect on either port, and when I
downgrade it connects on either port fine.
Reproduce code:
---
$server = "localhost";
$port = "5356";
$username = 'webapp';
$password = '**';
$db = 'drupal5';
$con = mssql_connect("$server,$port", $username, $password);
if($con) {
print "We have a connection!";
}
else {
print "NO CONNECTION TO |$server,$port| $username, $password!
ERROR!";
}
Expected result:
A screen that says: "We have a connection!"
Actual result:
--
A screen that says: "NO CONNECTION" with connection information.
--
Edit bug report at http://bugs.php.net/?id=43645&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43645&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43645&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43645&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43645&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43645&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43645&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43645&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43645&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43645&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43645&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43645&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43645&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43645&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43645&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43645&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43645&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43645&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43645&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43645&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43645&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43645&r=mysqlcfg
#43497 [Opn]: OCI8 XML/getClobVal leaks UGA memory
ID: 43497 User updated by: ghosh at q-one dot com Reported By: ghosh at q-one dot com Status: Open Bug Type: OCI8 related Operating System: Linux 2.6.22-14-server PHP Version: 5.2.5 New Comment: Would pay someone who resolves this bug. Feel free to contact me if you are interested. Previous Comments: [2007-12-05 23:18:05] [EMAIL PROTECTED] Confirmed. [2007-12-04 13:09:49] ghosh at q-one dot com Description: There is a memory leaking when using the OCI8 interface and querying XML columns. Demo code available via the url below. This creates a table with an XML column and queries this column. UGA memory is leaking. This does not happen when doing the same directly via SQLPlus. Reproduce code: --- http://oberon.q-one-hosting.com/6648051.txt Expected result: No UGA memory leaking Actual result: -- UGA memory going up. Table with temporary lobs filling up. -- Edit this bug report at http://bugs.php.net/?id=43497&edit=1
#43644 [Opn]: is_callable(':') crashes in CLI.
ID: 43644
Updated by: [EMAIL PROTECTED]
Reported By: kubo at iteman dot jp
Status: Open
Bug Type: Reproducible crash
Operating System: Windows XP SP2
PHP Version: 5.3CVS-2007-12-20 (snap)
New Comment:
In Linux works fine.
Previous Comments:
[2007-12-20 16:46:23] kubo at iteman dot jp
Description:
is_callable(':') crashes in CLI.
Reproduce code:
---
var_dump(is_callable(':'));
Expected result:
bool(false)
Actual result:
--
No display. A Windows Error Reporting dialog box appears.
--
Edit this bug report at http://bugs.php.net/?id=43644&edit=1
#41577 [Com]: DOTNET is successful once per server run
ID: 41577 Comment by: heathfrankel at internode dot on dot net Reported By: boen dot robot at gmail dot com Status: Assigned Bug Type: COM related Operating System: Windows XP Professional SP2 PHP Version: 5CVS-2007-06-03 (snap) Assigned To: wez New Comment: Is this related http://support.microsoft.com/kb/837318? Previous Comments: [2007-12-20 15:58:45] heathfrankel at internode dot on dot net I have also exerienced this issue and it is likely to be a show stopper for a very important project for our company. I have tried this on Win XP and Win 2003, I have used PHP5.2 from PHP.NET and from WAMPSERVER, I have used IIS and Apache. It oocurs for my own .NET objects and for the standard PHP documentation example. It is all the same. Finally after much searching I have found this Bug Report, now I don't feel so alone but still in the learch. A quick fix would be appreciated. [2007-08-15 08:32:34] [EMAIL PROTECTED] Assigned to the maintainer. [2007-06-03 15:31:09] boen dot robot at gmail dot com Description: When I run any PHP file using the DOTNET class, The class is first run as it should (the sample from the documentation does ineed produce "Hello .Net"), but after a page refresh, or if a navigate away from the page and go back, the server crashes. I have PHP installed locally as an Apache 2.2.4 module. I tryed turning off my antivirus (NOD32 in case it's relevant), but that didn't helped either. I have all .NET 1.1, .NET 2.0 and .NET 3.0 with all updates from Microsoft Update. Reproduce code: --- Expected result: The file should output "created" every time it's executed, unless perhaps I had an error in the constructor, in which case it should output "not created". Actual result: -- "created" is only outputted the first time. After that... A server crash with this in the error details: szAppName : httpd.exe szAppVer : 2.2.4.0 szModName : php5ts.dll szModVer : 5.2.4.4 offset : 000e622d -- Edit this bug report at http://bugs.php.net/?id=41577&edit=1
#43643 [Opn->Csd]: XMLReader::isValid returns false always
ID: 43643
User updated by: arkadiusz dot tulodziecki at firma dot o2 dot pl
Reported By: arkadiusz dot tulodziecki at firma dot o2 dot pl
-Status: Open
+Status: Closed
Bug Type: XML Reader
Operating System: Linux
PHP Version: 5.2.5
New Comment:
Thanks,
There is only basic documentation for XMLReader.
There was possible other bug but because in this moment I can't
reproduce it I'll wait with reporting.
Previous Comments:
[2007-12-20 16:04:39] [EMAIL PROTECTED]
Use:
$reader->setParserProperty(XMLReader::VALIDATE, true);
[2007-12-20 15:34:47] arkadiusz dot tulodziecki at firma dot o2 dot pl
Description:
XMLReader::isValid gives false for all valid XML I had. All files
parses correctly but sometimes XMLReader::read generates PHP Worning.
Reproduce code:
---
open('test.xml');
var_dump($reader->isValid());
?>
http://www.example.com/xmlns/1.0/";>
AAA
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=43643&edit=1
#43644 [NEW]: is_callable(':') crashes in CLI.
From: kubo at iteman dot jp
Operating system: Windows XP SP2
PHP version: 5.3CVS-2007-12-20 (snap)
PHP Bug Type: Reproducible crash
Bug description: is_callable(':') crashes in CLI.
Description:
is_callable(':') crashes in CLI.
Reproduce code:
---
var_dump(is_callable(':'));
Expected result:
bool(false)
Actual result:
--
No display. A Windows Error Reporting dialog box appears.
--
Edit bug report at http://bugs.php.net/?id=43644&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43644&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43644&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43644&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43644&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43644&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43644&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43644&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43644&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43644&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43644&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43644&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43644&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43644&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43644&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43644&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43644&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43644&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43644&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43644&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43644&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43644&r=mysqlcfg
#43643 [Opn]: XMLReader::isValid returns false always
ID: 43643
Updated by: [EMAIL PROTECTED]
Reported By: arkadiusz dot tulodziecki at firma dot o2 dot pl
Status: Open
Bug Type: XML Reader
Operating System: Linux
PHP Version: 5.2.5
New Comment:
Use:
$reader->setParserProperty(XMLReader::VALIDATE, true);
Previous Comments:
[2007-12-20 15:34:47] arkadiusz dot tulodziecki at firma dot o2 dot pl
Description:
XMLReader::isValid gives false for all valid XML I had. All files
parses correctly but sometimes XMLReader::read generates PHP Worning.
Reproduce code:
---
open('test.xml');
var_dump($reader->isValid());
?>
http://www.example.com/xmlns/1.0/";>
AAA
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=43643&edit=1
#41577 [Com]: DOTNET is successful once per server run
ID: 41577 Comment by: heathfrankel at internode dot on dot net Reported By: boen dot robot at gmail dot com Status: Assigned Bug Type: COM related Operating System: Windows XP Professional SP2 PHP Version: 5CVS-2007-06-03 (snap) Assigned To: wez New Comment: I have also exerienced this issue and it is likely to be a show stopper for a very important project for our company. I have tried this on Win XP and Win 2003, I have used PHP5.2 from PHP.NET and from WAMPSERVER, I have used IIS and Apache. It oocurs for my own .NET objects and for the standard PHP documentation example. It is all the same. Finally after much searching I have found this Bug Report, now I don't feel so alone but still in the learch. A quick fix would be appreciated. Previous Comments: [2007-08-15 08:32:34] [EMAIL PROTECTED] Assigned to the maintainer. [2007-06-03 15:31:09] boen dot robot at gmail dot com Description: When I run any PHP file using the DOTNET class, The class is first run as it should (the sample from the documentation does ineed produce "Hello .Net"), but after a page refresh, or if a navigate away from the page and go back, the server crashes. I have PHP installed locally as an Apache 2.2.4 module. I tryed turning off my antivirus (NOD32 in case it's relevant), but that didn't helped either. I have all .NET 1.1, .NET 2.0 and .NET 3.0 with all updates from Microsoft Update. Reproduce code: --- Expected result: The file should output "created" every time it's executed, unless perhaps I had an error in the constructor, in which case it should output "not created". Actual result: -- "created" is only outputted the first time. After that... A server crash with this in the error details: szAppName : httpd.exe szAppVer : 2.2.4.0 szModName : php5ts.dll szModVer : 5.2.4.4 offset : 000e622d -- Edit this bug report at http://bugs.php.net/?id=41577&edit=1
#43643 [NEW]: XMLReader::isValid returns false always
From: arkadiusz dot tulodziecki at firma dot o2 dot pl
Operating system: Linux
PHP version: 5.2.5
PHP Bug Type: XML Reader
Bug description: XMLReader::isValid returns false always
Description:
XMLReader::isValid gives false for all valid XML I had. All files parses
correctly but sometimes XMLReader::read generates PHP Worning.
Reproduce code:
---
open('test.xml');
var_dump($reader->isValid());
?>
http://www.example.com/xmlns/1.0/";>
AAA
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit bug report at http://bugs.php.net/?id=43643&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43643&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43643&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43643&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43643&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43643&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43643&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43643&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43643&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43643&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43643&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43643&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43643&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43643&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43643&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43643&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43643&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43643&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43643&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43643&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43643&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43643&r=mysqlcfg
#43630 [Opn->Bgs]: exif_read_data crashes on certain images
ID: 43630 Updated by: [EMAIL PROTECTED] Reported By: erin at thedalzells dot org -Status: Open +Status: Bogus Bug Type: EXIF related Operating System: ALL PHP Version: 6CVS-2007-12-18 (CVS) 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 This simply tells you that your EXIF information is broken. Previous Comments: [2007-12-18 21:08:17] erin at thedalzells dot org Description: I have PHP version 5.2.3 and am getting an error on this image: http://thedalzells.org/photos/test/IMG_2982.JPG when I try to read the EXIF data with exif_read_data. I have looked at the other bug reports and they all say fixed in head for version 5.2.1. Reproduce code: --- $file = '/home/.jeannie/edalzell/thedalzells.org/photos/test/IMG_2982.JPG'; $data = exif_read_data($file, "EXIF"); Expected result: No errors Actual result: -- Warning: exif_read_data(IMG_2982.JPG) [exif_read_data]: Process tag(x=UndefinedTa): Illegal format code 0x, suppose BYTE in /home/.jeannie/edalzell/thedalzells.org/secret/core/core.functions.php(637) : eval()'d code on line 22 Warning: exif_read_data(IMG_2982.JPG) [exif_read_data]: Process tag(x=UndefinedTa): Illegal pointer offset(x6E004361 + x43616E6F = xB161B1D0 > x0207) in /home/.jeannie/edalzell/thedalzells.org/secret/core/core.functions.php(637) : eval()'d code on line 22 Warning: exif_read_data(IMG_2982.JPG) [exif_read_data]: Illegal IFD offset in /home/.jeannie/edalzell/thedalzells.org/secret/core/core.functions.php(637) : eval()'d code on line 22 -- Edit this bug report at http://bugs.php.net/?id=43630&edit=1
#43542 [Opn]: simpleXML thinks that comment is node
ID: 43542
Updated by: [EMAIL PROTECTED]
Reported By: 007not at gmail dot com
Status: Open
Bug Type: SimpleXML related
-Operating System: win xp sp2
+Operating System: *
PHP Version: 5.2.5
New Comment:
The comment is a node. What we actually need is a way to figure out the
xml type of a SimpleXMLElement instance (Element, Comment,...). This
will also have to return the internal SXE state (iterator for something
or direct value).
Previous Comments:
[2007-12-10 20:29:17] 007not at gmail dot com
hubert, you rigth about first test, i made mistake while i made posting
of this bug.
the right firts test looks such:
//first test
echo "node:";
var_dump($xml->node);
echo "notExitsNode:";
var_dump($xml->notExitsNode);
echo "otherNode:";
var_dump($xml->otherNode);
Expected result:
node:
object(SimpleXMLElement)[2]
public 'comment' =>
object(SimpleXMLElement)[4]
notExitsNode:
null
otherNode:
object(SimpleXMLElement)[2]
Actual result:
--
node:
object(SimpleXMLElement)[2]
public 'comment' =>
object(SimpleXMLElement)[4]
notExitsNode:
object(SimpleXMLElement)[2]
otherNode:
object(SimpleXMLElement)[2]
>Actually, that "comment" property might have been intentionally
created
as a way to indicate whether the node has a comment.
But it is illogical, and we will have "comments hell" like:
array(/*'comment' => 'value'*/) === array('comment' => 'value')
>As for your second test, I'm afraid it is incorrect
may be (because i tryed to count nodes, and it must be 1 1), but when
we use arrays we have problems with fake comments
$i = 0;
foreach ((array) $xml->node as $node)
{
$i++;
}
echo $i . "\n";
$i = 0;
foreach ((array) $xml->otherNode as $node)
{
$i++;
}
echo $i . "\n";
Expected result:
0
0
Actual result:
--
1
0
#
updated test:
value
XML;
$xml = simplexml_load_string($string);
//first test
echo "node:";
var_dump($xml->node);
echo "notExitsNode:";
var_dump($xml->notExitsNode);
echo "otherNode:";
var_dump($xml->otherNode);
/*
Expected result:
node:
object(SimpleXMLElement)[2]
public 'comment' =>
object(SimpleXMLElement)[4]
notExitsNode:
null
otherNode:
object(SimpleXMLElement)[2]
Actual result:
--
node:
object(SimpleXMLElement)[2]
public 'comment' =>
object(SimpleXMLElement)[4]
notExitsNode:
object(SimpleXMLElement)[2]
otherNode:
object(SimpleXMLElement)[2]
*/
//second test
$i = 0;
foreach ($xml->node as $node)
{
$i++;
}
echo $i . "\n";
$i = 0;
foreach ($xml->otherNode as $node)
{
$i++;
}
echo $i . "\n";
$i = 0;
foreach ((array) $xml->node as $node)
{
$i++;
}
echo $i . "\n";
$i = 0;
foreach ((array) $xml->otherNode as $node)
{
$i++;
}
echo $i . "\n";
/*
Expected result:
1
1
0
0
Actual result:
--
1
1
1
0
*/
//third test
var_dump($xml->node->comment);
var_dump($xml->otherNode->comment);
//check magic
echo "node:\n";
if (is_object($xml->node->comment))
{
echo "is_object === TRUE \n";
}
if (isset($xml->node->comment))
{
echo "isset === TRUE \n";
}
//but
if (strlen($xml->node->comment) > 0)
{
echo "strlen > 0\n";
}
if (strlen($xml->node->comment) == 0)
{
echo "strlen == 0\n";
}
echo "otherNode:\n";
if (is_object($xml->otherNode->comment))
{
echo "is_object === TRUE \n";
}
if (isset($xml->otherNode->comment))
{
echo "isset === TRUE \n";
}
/*
Expected result:
node:
is_object === TRUE
isset === TRUE
strlen == 0
otherNode:
is_object === TRUE
Actual result:
--
node:
is_object === TRUE
strlen == 0
otherNode:
is_object === TRUE
*/
[2007-12-09 14:39:46] hubert dot roksor at gmail dot com
Regarding your first test, I wouldn't consider that a bug. var_dump()
is a debugging tool, it may expose some of the behind-the-scene magic.
Actually, that "comment" property might have been intentionally created
as a way to indicate whether the node has a comment. That would explain
isset()'s behaviour in your third test, but in this case I would
recommand replacing that magical property with a method such as
$node->hasComment(). I guess Rob Richards will be able to shed some
light here.
As for your second test, I'm afraid it is incorrect: both $xml->node
and $xml->otherNode should return 1 element and I don't see why having a
comment as a child would change that.
[2007-12-09 11:02:10] 007not at gmail dot com
Description:
also see http://bugs.php.net/43392
>[EMAIL PROTECTED] comment:
>Th
#43642 [Opn->Bgs]: str_replace('foo', some_func(), $text) ALWAYS call some_func()
ID: 43642
Updated by: [EMAIL PROTECTED]
Reported By: kampde at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Performance problem
Operating System: debian etch
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
Previous Comments:
[2007-12-20 12:05:33] kampde at gmail dot com
Description:
In str_replace(), if you put as a replace string a call to a function
(that returns a string), this call is executed always, even if the text
to be replaced is not found in the text.
Reproduce code:
---
function some_func()
{
echo "some_func() was called!\n";
return 'bar';
}
echo str_replace('foo', some_func(), "a");
Expected result:
Actual result:
--
some_func() was called!
--
Edit this bug report at http://bugs.php.net/?id=43642&edit=1
#43641 [Ana]: ZipArchive::open() fails to open some archives
ID: 43641
Updated by: [EMAIL PROTECTED]
Reported By: max630 at gmail dot com
Status: Analyzed
Bug Type: Zip Related
Operating System: linux/amd64
PHP Version: 5.2.5
Assigned To: pajoye
New Comment:
To make it slighty clearer, 0.8.1 (and cvs versions) has large support
but in a complete unportable way. There is already unportable issues in
the libzip code (patches have been sent) about binary streams and
tempfiles. For some reasons, they did not have been applied upstream.
I have sent some mails recently but did not get yet an answer. I also
tried to motivate them to use an issue tracker to ease the developments.
Previous Comments:
[2007-12-20 13:27:29] [EMAIL PROTECTED]
It is as the offset_t supports a larger range. The whole offset system
uses a larger range.
[2007-12-20 13:24:41] max630 at gmail dot com
Files in question are not huge at all - the dir900.zip is just about
100K. So, strictly speaking, it is not a huge file support.
[2007-12-20 12:50:08] [EMAIL PROTECTED]
I'm working to fix the 64bit huge file support in libzip.
They added it recently but in a relatively bad way and works only on
some systems. What I'm doing is to add custom streams support. This way
I can use the native IO functions on each platform (especially important
on windows) or use the PHP stream functions (as soon as the large file
support works or is available).
It is not a small task, so don't hold your breath :)
[2007-12-20 10:43:28] max630 at gmail dot com
Description:
ZipArchive fails on opening some zip archives
file which php fails on is here:
http://max630.info/dir900.zip
it is just 900 empty files in one directory. Produced by zip utility
from a recent Linux distribution (Debian).
This IS NOT an OS issue, as no failed syscall appears in strace. Most
probable reason is that in-source zip library is not completely ready
for 64-bit wide offsets, but I'm not sure. I'm not even sure that it is
the reason of the failure is size of the archive.
I can not reopen Bug #40873 - I am not the original reporter - so here
is a new bug
BTW, libzip from
http://ftp.de.debian.org/debian/pool/main/libz/libzip/libzip_0.8-1.dsc
- which is where the builtin implementation came from - opens all files
I have tested without errors
Reproduce code:
---
open("dir900.zip");
if ($status !== TRUE) {
print_r($status);
die("open failed");
}
?>
Expected result:
$./sapi/cli/php test-zip.php
$
Actual result:
--
$./sapi/cli/php test-zip.php
5open failed
$
noteable piece from strace:
open("/home/max/dir900.zip", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2aaff7b39000
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 122880, SEEK_SET) = 122880
read(3, "\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0\0\0\0\0\0\0\0\0\244\201"...,
1246) = 1246
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 57344, SEEK_SET) = 57344
read(3, "K\3\4\n\0\0\0\0\0\374x\2247\0\0\0\0\0\0\0\0\0\0\0\0\16"...,
4096) = 4096
read(3, "\n\0\0\0\0\0\373x\2247\0\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0"...,
61440) = 61440
read(3, "\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0\0\0\0\0\0\0\0\0\244\201"...,
4096) = 1246
brk(0xdce000) = 0xdce000
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 4295024640, SEEK_SET) = 4295024640
read(3, "", 4096) = 0
lseek(3, 1104, SEEK_CUR)= 4295025744
read(3, "", 4096) = 0
Note the huge offset. I fixed this specific place
("ext/zip/lib/zip_open.c" line 316), but it still fails on some other
zip files. I could not reproduce that failure with test zip yet
--
Edit this bug report at http://bugs.php.net/?id=43641&edit=1
#43641 [Ana]: ZipArchive::open() fails to open some archives
ID: 43641
Updated by: [EMAIL PROTECTED]
Reported By: max630 at gmail dot com
Status: Analyzed
Bug Type: Zip Related
Operating System: linux/amd64
PHP Version: 5.2.5
Assigned To: pajoye
New Comment:
It is as the offset_t supports a larger range. The whole offset system
uses a larger range.
Previous Comments:
[2007-12-20 13:24:41] max630 at gmail dot com
Files in question are not huge at all - the dir900.zip is just about
100K. So, strictly speaking, it is not a huge file support.
[2007-12-20 12:50:08] [EMAIL PROTECTED]
I'm working to fix the 64bit huge file support in libzip.
They added it recently but in a relatively bad way and works only on
some systems. What I'm doing is to add custom streams support. This way
I can use the native IO functions on each platform (especially important
on windows) or use the PHP stream functions (as soon as the large file
support works or is available).
It is not a small task, so don't hold your breath :)
[2007-12-20 10:43:28] max630 at gmail dot com
Description:
ZipArchive fails on opening some zip archives
file which php fails on is here:
http://max630.info/dir900.zip
it is just 900 empty files in one directory. Produced by zip utility
from a recent Linux distribution (Debian).
This IS NOT an OS issue, as no failed syscall appears in strace. Most
probable reason is that in-source zip library is not completely ready
for 64-bit wide offsets, but I'm not sure. I'm not even sure that it is
the reason of the failure is size of the archive.
I can not reopen Bug #40873 - I am not the original reporter - so here
is a new bug
BTW, libzip from
http://ftp.de.debian.org/debian/pool/main/libz/libzip/libzip_0.8-1.dsc
- which is where the builtin implementation came from - opens all files
I have tested without errors
Reproduce code:
---
open("dir900.zip");
if ($status !== TRUE) {
print_r($status);
die("open failed");
}
?>
Expected result:
$./sapi/cli/php test-zip.php
$
Actual result:
--
$./sapi/cli/php test-zip.php
5open failed
$
noteable piece from strace:
open("/home/max/dir900.zip", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2aaff7b39000
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 122880, SEEK_SET) = 122880
read(3, "\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0\0\0\0\0\0\0\0\0\244\201"...,
1246) = 1246
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 57344, SEEK_SET) = 57344
read(3, "K\3\4\n\0\0\0\0\0\374x\2247\0\0\0\0\0\0\0\0\0\0\0\0\16"...,
4096) = 4096
read(3, "\n\0\0\0\0\0\373x\2247\0\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0"...,
61440) = 61440
read(3, "\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0\0\0\0\0\0\0\0\0\244\201"...,
4096) = 1246
brk(0xdce000) = 0xdce000
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 4295024640, SEEK_SET) = 4295024640
read(3, "", 4096) = 0
lseek(3, 1104, SEEK_CUR)= 4295025744
read(3, "", 4096) = 0
Note the huge offset. I fixed this specific place
("ext/zip/lib/zip_open.c" line 316), but it still fails on some other
zip files. I could not reproduce that failure with test zip yet
--
Edit this bug report at http://bugs.php.net/?id=43641&edit=1
#43641 [Ana]: ZipArchive::open() fails to open some archives
ID: 43641
User updated by: max630 at gmail dot com
Reported By: max630 at gmail dot com
Status: Analyzed
Bug Type: Zip Related
Operating System: linux/amd64
PHP Version: 5.2.5
Assigned To: pajoye
New Comment:
Files in question are not huge at all - the dir900.zip is just about
100K. So, strictly speaking, it is not a huge file support.
Previous Comments:
[2007-12-20 12:50:08] [EMAIL PROTECTED]
I'm working to fix the 64bit huge file support in libzip.
They added it recently but in a relatively bad way and works only on
some systems. What I'm doing is to add custom streams support. This way
I can use the native IO functions on each platform (especially important
on windows) or use the PHP stream functions (as soon as the large file
support works or is available).
It is not a small task, so don't hold your breath :)
[2007-12-20 10:43:28] max630 at gmail dot com
Description:
ZipArchive fails on opening some zip archives
file which php fails on is here:
http://max630.info/dir900.zip
it is just 900 empty files in one directory. Produced by zip utility
from a recent Linux distribution (Debian).
This IS NOT an OS issue, as no failed syscall appears in strace. Most
probable reason is that in-source zip library is not completely ready
for 64-bit wide offsets, but I'm not sure. I'm not even sure that it is
the reason of the failure is size of the archive.
I can not reopen Bug #40873 - I am not the original reporter - so here
is a new bug
BTW, libzip from
http://ftp.de.debian.org/debian/pool/main/libz/libzip/libzip_0.8-1.dsc
- which is where the builtin implementation came from - opens all files
I have tested without errors
Reproduce code:
---
open("dir900.zip");
if ($status !== TRUE) {
print_r($status);
die("open failed");
}
?>
Expected result:
$./sapi/cli/php test-zip.php
$
Actual result:
--
$./sapi/cli/php test-zip.php
5open failed
$
noteable piece from strace:
open("/home/max/dir900.zip", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2aaff7b39000
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 122880, SEEK_SET) = 122880
read(3, "\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0\0\0\0\0\0\0\0\0\244\201"...,
1246) = 1246
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 57344, SEEK_SET) = 57344
read(3, "K\3\4\n\0\0\0\0\0\374x\2247\0\0\0\0\0\0\0\0\0\0\0\0\16"...,
4096) = 4096
read(3, "\n\0\0\0\0\0\373x\2247\0\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0"...,
61440) = 61440
read(3, "\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0\0\0\0\0\0\0\0\0\244\201"...,
4096) = 1246
brk(0xdce000) = 0xdce000
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 4295024640, SEEK_SET) = 4295024640
read(3, "", 4096) = 0
lseek(3, 1104, SEEK_CUR)= 4295025744
read(3, "", 4096) = 0
Note the huge offset. I fixed this specific place
("ext/zip/lib/zip_open.c" line 316), but it still fails on some other
zip files. I could not reproduce that failure with test zip yet
--
Edit this bug report at http://bugs.php.net/?id=43641&edit=1
#43641 [Opn->Ana]: ZipArchive::open() fails to open some archives
ID: 43641
Updated by: [EMAIL PROTECTED]
Reported By: max630 at gmail dot com
-Status: Open
+Status: Analyzed
Bug Type: Zip Related
Operating System: linux/amd64
PHP Version: 5.2.5
-Assigned To:
+Assigned To: pajoye
New Comment:
I'm working to fix the 64bit huge file support in libzip.
They added it recently but in a relatively bad way and works only on
some systems. What I'm doing is to add custom streams support. This way
I can use the native IO functions on each platform (especially important
on windows) or use the PHP stream functions (as soon as the large file
support works or is available).
It is not a small task, so don't hold your breath :)
Previous Comments:
[2007-12-20 10:43:28] max630 at gmail dot com
Description:
ZipArchive fails on opening some zip archives
file which php fails on is here:
http://max630.info/dir900.zip
it is just 900 empty files in one directory. Produced by zip utility
from a recent Linux distribution (Debian).
This IS NOT an OS issue, as no failed syscall appears in strace. Most
probable reason is that in-source zip library is not completely ready
for 64-bit wide offsets, but I'm not sure. I'm not even sure that it is
the reason of the failure is size of the archive.
I can not reopen Bug #40873 - I am not the original reporter - so here
is a new bug
BTW, libzip from
http://ftp.de.debian.org/debian/pool/main/libz/libzip/libzip_0.8-1.dsc
- which is where the builtin implementation came from - opens all files
I have tested without errors
Reproduce code:
---
open("dir900.zip");
if ($status !== TRUE) {
print_r($status);
die("open failed");
}
?>
Expected result:
$./sapi/cli/php test-zip.php
$
Actual result:
--
$./sapi/cli/php test-zip.php
5open failed
$
noteable piece from strace:
open("/home/max/dir900.zip", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2aaff7b39000
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 122880, SEEK_SET) = 122880
read(3, "\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0\0\0\0\0\0\0\0\0\244\201"...,
1246) = 1246
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 57344, SEEK_SET) = 57344
read(3, "K\3\4\n\0\0\0\0\0\374x\2247\0\0\0\0\0\0\0\0\0\0\0\0\16"...,
4096) = 4096
read(3, "\n\0\0\0\0\0\373x\2247\0\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0"...,
61440) = 61440
read(3, "\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0\0\0\0\0\0\0\0\0\244\201"...,
4096) = 1246
brk(0xdce000) = 0xdce000
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 4295024640, SEEK_SET) = 4295024640
read(3, "", 4096) = 0
lseek(3, 1104, SEEK_CUR)= 4295025744
read(3, "", 4096) = 0
Note the huge offset. I fixed this specific place
("ext/zip/lib/zip_open.c" line 316), but it still fails on some other
zip files. I could not reproduce that failure with test zip yet
--
Edit this bug report at http://bugs.php.net/?id=43641&edit=1
#43642 [NEW]: str_replace('foo', some_func(), $text) ALWAYS call some_func()
From: kampde at gmail dot com
Operating system: debian etch
PHP version: 5.2.5
PHP Bug Type: Performance problem
Bug description: str_replace('foo', some_func(), $text) ALWAYS call some_func()
Description:
In str_replace(), if you put as a replace string a call to a function
(that returns a string), this call is executed always, even if the text to
be replaced is not found in the text.
Reproduce code:
---
function some_func()
{
echo "some_func() was called!\n";
return 'bar';
}
echo str_replace('foo', some_func(), "a");
Expected result:
Actual result:
--
some_func() was called!
--
Edit bug report at http://bugs.php.net/?id=43642&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43642&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43642&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43642&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43642&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43642&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43642&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43642&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43642&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43642&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43642&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43642&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43642&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43642&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43642&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43642&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43642&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43642&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43642&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43642&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43642&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43642&r=mysqlcfg
#39581 [Com]: Apache crash on php5ts.dll
ID: 39581 Comment by: azatyar at gmail dot com Reported By: durumdara at gmail dot com Status: No Feedback Bug Type: Apache2 related Operating System: win2k3 sp1 PHP Version: 5.2.0 New Comment: You should disable the following module (php.ini): ;extension=php_threads.dll After that the Apache won't. p.s. php 5.2.5, apache 2.2.6. Previous Comments: [2007-02-07 14:42:27] abel dot online at xs4all dot nl This bug appeared next to impossible to workaround. However, after several hours, I found that the following sequence of actions removed the error. I assume W2K3, PHP52 and MySql50. 1) Install using the wizard, set option for integrating in Apache 2.2, do NOT set any extensions. 2) Restart Apache and test its stability 3) Run the wizard again. Now install ONE/TWO extension(s), only "MySql" and/or "MySqli". 4) Manually edit php.ini (in c:\program files\php). Change the line with the ext-dir to (including quotes): extension_dir="C:\Program Files\PHP\ext" 5) Uncomment the line with php_mysql.dll 6) Restart Apache and test (careful, gently, php may crash again!) It worked for me. Any other sequence of actions, including installing some other extensions, crashed it. Selecting all extensions always crashed Apache in php5ts.dll (I consider it a severe bug, because it php actually crashes its host Apache, which is evil). [2006-12-22 10:15:16] johnr at silver-bullet dot co dot nz I had EXACTLY the same issue. Same error when installing PHP, etc. When I went to uninstall I noticed thaat I had TWO versions of PHP installed... 4.3 and 5.2. I uninstalled both and then reinstalled PHP 5.2 and everything worked sweet. BUT I also ONLY installed the MySQL extension the second time around so was the answer having two versions installed or was it one of the extensions? [2006-12-06 20:44:41] jason dot egan at gmail dot com swummer, would you mind clarifying that a little? My current install uses php5apache2_2.dll as the default file name. I've gone ahead and changed it to php5apache2.dll, updated my httpd.conf, and restarted the server. I still have the same issues no matter how it is named. [2006-12-06 18:32:45] swummer at gmail dot com Hi... Maybe i have the answer for our problems. I change the ../../PHP/php5apache2.dll to ../../PHP/php5apache2_2.dll and the error doesn´t appear again. I´m still testing, and everything it´s seems ok. Hug. [2006-12-06 15:00:11] jason dot egan at gmail dot com I'm getting the exact same error with the exact same setup (Apache 2.2.3 and PHP 5.2.0) While I'm unable to do a backtrace, I was able to find this in the error.log generated by Apache: [Wed Dec 06 08:43:01 2006] [notice] Apache/2.2.3 (Win32) PHP/5.2.0 configured -- resuming normal operations [Wed Dec 06 08:43:01 2006] [notice] Server built: Jul 27 2006 16:49:49 [Wed Dec 06 08:43:01 2006] [notice] Parent: Created child process 168 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\PHP\\ext\\php_exif.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\PHP\\ext\\php_ifx.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\PHP\\ext\\php_oci8.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\PHP\\ext\\php_pdo_oci.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\PHP\\ext\\php_pdo_oci8.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\PHP\\ext\\php_pspell.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\PHP\\ext\\php_sybase_ct.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\PHP\\ext\\php_ibm_db2.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\PHP\\ext\\php_imagick.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\PHP\\ext\\php_ingres.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\PHP\\ext\\php_netools.dll' - The specified module could not be
#43450 [Opn]: Memory leak on some functions with implicit object __toString() call
ID: 43450
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: Any
PHP Version: 5.2.5
New Comment:
It appears that zend_std_cast_object_tostring() does not check whether
it has to dref readobj prior writing to writeobj in case they are the
same zval.
That said the code needs to be refactored to:
- if (readobj==writeobj) { zval_dtor(readobj); } // not zval_ptr_dtor
- call INIT_PZVAL(writeobj) always
- set Z_TYPE_P(writeobj) = IS_NULL; for the default case
Previous Comments:
[2007-11-30 01:34:56] [EMAIL PROTECTED]
I'm still not sure if this has anything to do with the new Zend parsing
API, but I've tested the md5 function with the zend_get_parameters_ex
(the old API) and the leak didn't occur. See the two version for a
comparison.
currently
PHP_NAMED_FUNCTION(php_if_md5)
{
char *arg;
int arg_len;
zend_bool raw_output = 0;
char md5str[33];
PHP_MD5_CTX context;
unsigned char digest[16];
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
"s|b", &arg, &arg_len, &raw_output) == FAILURE) {
return;
}
md5str[0] = '\0';
PHP_MD5Init(&context);
PHP_MD5Update(&context, arg, arg_len);
PHP_MD5Final(digest, &context);
if (raw_output) {
RETURN_STRINGL(digest, 16, 1);
} else {
make_digest_ex(md5str, digest, 16);
RETVAL_STRING(md5str, 1);
}
}
--- hacked rewrite
PHP_NAMED_FUNCTION(php_if_md5)
{
zval **zarg;
zend_bool raw_output = 0;
char md5str[33];
PHP_MD5_CTX context;
unsigned char digest[16];
if (ZEND_NUM_ARGS() != 1 ||
zend_get_parameters_ex(1, &zarg) == FAILURE) {
WRONG_PARAM_COUNT;
}
convert_to_string_ex(zarg);
md5str[0] = '\0';
PHP_MD5Init(&context);
PHP_MD5Update(&context, Z_STRVAL_PP(zarg), Z_STRLEN_PP(zarg));
PHP_MD5Final(digest, &context);
if (raw_output) {
RETURN_STRINGL(digest, 16, 1);
} else {
make_digest_ex(md5str, digest, 16);
RETVAL_STRING(md5str, 1);
}
}
[2007-11-29 14:59:48] [EMAIL PROTECTED]
Description:
Under certain circumenstances, the implicit call to __toString() on an
object may lead to memory leaks.
In the reproducable example, the following line leaks ($o is a simply
object):
md5($o);
But this line doesn't:
md5($o->__toString());
This only applies to certain functions, I've identifier md5, sha1 and
crc32.
If I try other examples like strstr or strlen, there's no leak at all.
A wild guess is that this maybe has to do whether the function
internally uses zend_parse_parameters() or zend_get_parameters_ex().
The function which leak use zend_parse_parameters(), the others don't.
But this may completely accidental.
It seems very related to bug#38591. However I don't see how bug#38604
is related to this issue (mentioned in bug#38591).
This leak was most notable found in an application which is supposed to
run for a long time, even hours. So usually within web application this
is not an issue.
Reproduce code:
---
__toString());
# does not leak either way
# strstr($o, 'f');
#strstr($o->__toString(), 'f');
if ($i % 1e3 == 0) {
printf("%u: %1.2f KB\n",
$i, memory_get_usage(true) / 1024);
}
}
Expected result:
Constant memory usage.
Actual result:
--
Memory grows and grows.
--
Edit this bug report at http://bugs.php.net/?id=43450&edit=1
#43641 [NEW]: ZipArchive::open() fails to open some archives
From: max630 at gmail dot com
Operating system: linux/amd64
PHP version: 5.2.5
PHP Bug Type: Zip Related
Bug description: ZipArchive::open() fails to open some archives
Description:
ZipArchive fails on opening some zip archives
file which php fails on is here:
http://max630.info/dir900.zip
it is just 900 empty files in one directory. Produced by zip utility from
a recent Linux distribution (Debian).
This IS NOT an OS issue, as no failed syscall appears in strace. Most
probable reason is that in-source zip library is not completely ready for
64-bit wide offsets, but I'm not sure. I'm not even sure that it is the
reason of the failure is size of the archive.
I can not reopen Bug #40873 - I am not the original reporter - so here is
a new bug
BTW, libzip from
http://ftp.de.debian.org/debian/pool/main/libz/libzip/libzip_0.8-1.dsc
- which is where the builtin implementation came from - opens all files I
have tested without errors
Reproduce code:
---
open("dir900.zip");
if ($status !== TRUE) {
print_r($status);
die("open failed");
}
?>
Expected result:
$./sapi/cli/php test-zip.php
$
Actual result:
--
$./sapi/cli/php test-zip.php
5open failed
$
noteable piece from strace:
open("/home/max/dir900.zip", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2aaff7b39000
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 122880, SEEK_SET) = 122880
read(3, "\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0\0\0\0\0\0\0\0\0\244\201"...,
1246) = 1246
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 57344, SEEK_SET) = 57344
read(3, "K\3\4\n\0\0\0\0\0\374x\2247\0\0\0\0\0\0\0\0\0\0\0\0\16"..., 4096)
= 4096
read(3, "\n\0\0\0\0\0\373x\2247\0\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0"...,
61440) = 61440
read(3, "\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0\0\0\0\0\0\0\0\0\244\201"...,
4096) = 1246
brk(0xdce000) = 0xdce000
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 4295024640, SEEK_SET) = 4295024640
read(3, "", 4096) = 0
lseek(3, 1104, SEEK_CUR)= 4295025744
read(3, "", 4096) = 0
Note the huge offset. I fixed this specific place
("ext/zip/lib/zip_open.c" line 316), but it still fails on some other zip
files. I could not reproduce that failure with test zip yet
--
Edit bug report at http://bugs.php.net/?id=43641&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43641&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43641&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43641&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43641&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43641&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43641&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43641&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43641&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43641&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43641&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43641&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43641&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43641&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43641&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43641&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43641&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43641&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43641&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43641&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43641&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43641&r=mysqlcfg
