#45437 [Com]: Calls to imagettftext crash
ID: 45437 Comment by: akorthaus at web dot de Reported By: ms at mac-specialist dot com Status: Feedback Bug Type: GD related Operating System: OS X 10.5.3 PHP Version: 5.2.6 Assigned To: pajoye New Comment: I have exactly the same problem using Mac OS X 10.4.6, Apache 2 with mod_php (5.2.5), 32-bit. Here is a short script to reproduce the error: -- -- You can find the 'default.ttf' I used here: http://www.jtr.de/scripting/php/classes/captcha/index.html (klick "Jax Captcha Class downloaden", you will find the .ttf file in the archive) PHP/the Apache process crashes and I get a 200 Response from the server without any headers or content. Here is what the error log writes: -- [notice] Accept mutex: flock (Default: flock) dyld: lazy symbol binding failed: Symbol not found: _FSPathMakeRef Referenced from: /usr/local/lib/freetype-2.2.1/lib/libfreetype.6.dylib Expected in: flat namespace dyld: Symbol not found: _FSPathMakeRef Referenced from: /usr/local/lib/freetype-2.2.1/lib/libfreetype.6.dylib Expected in: flat namespace [Sat Jul 12 17:49:00 2008] [notice] child pid 3369 exit signal Trace/BPT trap (5) dyld: lazy symbol binding failed: Symbol not found: _FSPathMakeRef Referenced from: /usr/local/lib/freetype-2.2.1/lib/libfreetype.6.dylib Expected in: flat namespace dyld: Symbol not found: _FSPathMakeRef Referenced from: /usr/local/lib/freetype-2.2.1/lib/libfreetype.6.dylib Expected in: flat namespace [Sat Jul 12 17:56:41 2008] [notice] child pid 3368 exit signal Trace/BPT trap (5) -- Previous Comments: [2008-07-08 06:00:39] [EMAIL PROTECTED] Sorry, we don't support 3rd party tools like ZendDebugger, ZendCore, XCache or other tools affecting the runtime. Please try without any of these tools using our source releases. [2008-07-08 01:52:48] ms at mac-specialist dot com SUCCESS, SOMEWHAT... When I installed Zend Debugger 5.5.1 about a year and a half ago, it came with its own php.ini, and originally had a great deal of trouble getting it running. It had been compiled in 32 bit mode as best I understand it, so once I got everything working I posted a message on 4/29/2008 "Getting 32 bit ZendStudio Debugger to work with 64 bit Apache2 - PHP using MacPorts on Leopard" that provided explicit instructions on how to get it working. The message I posted on 4/29/2008 "Getting 32 bit ZendStudio Debugger to work with 64 bit Apache2 - PHP using MacPorts on Leopard" that provided explicit instructions on how to get it working, is no longer valid. In the later versions of OS X ZEND DEBUGGER DOES NOT require that you call : -- - RESTART THE 64 bit APACHE2 using the 32 bit mode ( 'arch -i386' ) : -- - shell> ~ $ sudo arch -i386 /opt/local/apache2/bin/apachectl start shell> ~ $ ps aux | grep httpd -- - ZEND DEBUGGER works fine using 64 bit mode : -- - shell> ~ $ sudo /opt/local/apache2/bin/apachectl start shell> ~ $ ps aux | grep httpd As a carry over from an old version of Zend Debugger 4.x (about 3-4 years old) my php.ini contained : ; [Zend] extension_dir=/Applications/Zend/ZendStudio-5.5.1/bin/php5 extension=pgsql.so $ which php ---> /opt/local/bin/php $ php --version ---> PHP Warning: PHP Startup: Unable to load dynamic library '/Applications/Zend/ZendStudio-5.5.1/bin/php5/pgsql.so' - (null) in Unknown on line 0 ---> Warning: PHP Startup: Unable to load dynamic library '/Applications/Zend/ZendStudio-5.5.1/bin/php5/pgsql.so' - (null) in Unknown on line 0 ---> PHP 5.2.6 (cli) (built: Jul 7 2008 15:05:26) ---> Copyright (c) 1997-2008 The PHP Group ---> Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies ---> with Zend Debugger v5.2.12, Copyright (c) 1999-2007, by Zend Technologies Originally when I tried I got the errors again : $ php inc_random_image_two.php > zippy.png ---> PHP Warning: PHP Startup: Unable to load dynamic library '/Applications/Zend/ZendStudio-5.5.1/bin/php5/pgsql.so' - (null) in Unknown on line 0 ---> Warning: PHP Startup: Unable to load dynamic library '/Applications/Zend/ZendStudio-5.5.1/bin/php5/pgsql.so' - (null) in Unknown on line 0 $ open zippy.png But when I opened zippy.png above the image
#38314 [Fbk->Opn]: setlocale() - LC_NUMERIC does not work
ID: 38314 User updated by: akorthaus at web dot de Reported By: akorthaus at web dot de -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Mac OS X (10.4.7) PHP Version: 5.2.0RC1 New Comment: $ locale LC_NUMERIC "." "" Previous Comments: [2006-08-03 14:36:16] [EMAIL PROTECTED] What do you get with `locale LC_NUMERIC` in shell? [2006-08-03 14:14:37] akorthaus at web dot de Description: LC_NUMERIC does not work, it only makes localeconv() return the correct decimal_point, nothing else. If I use LC_ALL, localeconv() works better (more data, e.g. mon_*) but thousands_sep is still wrong (empty). I installed PHP 5.2.0 RC1 on a MacBook and run "make test", you can find the results here: http://news.php.net/php.qa/26855 The same happens with PHP 4.4.1, shiped with OS X! Reproduce code: --- Actual result: -- string(5) "de_DE" Array ( [decimal_point] => , [thousands_sep] => [int_curr_symbol] => [currency_symbol] => [mon_decimal_point] => [mon_thousands_sep] => [positive_sign] => [negative_sign] => [int_frac_digits] => 127 [frac_digits] => 127 [p_cs_precedes] => 127 [p_sep_by_space] => 127 [n_cs_precedes] => 127 [n_sep_by_space] => 127 [p_sign_posn] => 127 [n_sign_posn] => 127 [grouping] => Array ( [0] => 127 ) [mon_grouping] => Array ( [0] => 127 ) ) string(5) "de_DE" Array ( [decimal_point] => , [thousands_sep] => [int_curr_symbol] => EUR [currency_symbol] => Eu [mon_decimal_point] => , [mon_thousands_sep] => . [positive_sign] => [negative_sign] => - [int_frac_digits] => 2 [frac_digits] => 2 [p_cs_precedes] => 1 [p_sep_by_space] => 0 [n_cs_precedes] => 1 [n_sep_by_space] => 0 [p_sign_posn] => 1 [n_sign_posn] => 1 [grouping] => Array ( [0] => 127 ) [mon_grouping] => Array ( [0] => 3 [1] => 3 ) ) -- Edit this bug report at http://bugs.php.net/?id=38314&edit=1
#38314 [NEW]: setlocale() - LC_NUMERIC does not work
From: akorthaus at web dot de Operating system: Mac OS X (10.4.7) PHP version: 5.2.0RC1 PHP Bug Type: Unknown/Other Function Bug description: setlocale() - LC_NUMERIC does not work Description: LC_NUMERIC does not work, it only makes localeconv() return the correct decimal_point, nothing else. If I use LC_ALL, localeconv() works better (more data, e.g. mon_*) but thousands_sep is still wrong (empty). I installed PHP 5.2.0 RC1 on a MacBook and run "make test", you can find the results here: http://news.php.net/php.qa/26855 The same happens with PHP 4.4.1, shiped with OS X! Reproduce code: --- Actual result: -- string(5) "de_DE" Array ( [decimal_point] => , [thousands_sep] => [int_curr_symbol] => [currency_symbol] => [mon_decimal_point] => [mon_thousands_sep] => [positive_sign] => [negative_sign] => [int_frac_digits] => 127 [frac_digits] => 127 [p_cs_precedes] => 127 [p_sep_by_space] => 127 [n_cs_precedes] => 127 [n_sep_by_space] => 127 [p_sign_posn] => 127 [n_sign_posn] => 127 [grouping] => Array ( [0] => 127 ) [mon_grouping] => Array ( [0] => 127 ) ) string(5) "de_DE" Array ( [decimal_point] => , [thousands_sep] => [int_curr_symbol] => EUR [currency_symbol] => Eu [mon_decimal_point] => , [mon_thousands_sep] => . [positive_sign] => [negative_sign] => - [int_frac_digits] => 2 [frac_digits] => 2 [p_cs_precedes] => 1 [p_sep_by_space] => 0 [n_cs_precedes] => 1 [n_sep_by_space] => 0 [p_sign_posn] => 1 [n_sign_posn] => 1 [grouping] => Array ( [0] => 127 ) [mon_grouping] => Array ( [0] => 3 [1] => 3 ) ) -- Edit bug report at http://bugs.php.net/?id=38314&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38314&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38314&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38314&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38314&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38314&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38314&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38314&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38314&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38314&r=support Expected behavior:http://bugs.php.net/fix.php?id=38314&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38314&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38314&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38314&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38314&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38314&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38314&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38314&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38314&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38314&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38314&r=mysqlcfg
#36890 [Fbk->Opn]: PDO does not throw Exception
ID: 36890
User updated by: akorthaus at web dot de
Reported By: akorthaus at web dot de
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Linux 2.4.32 (gentoo)
PHP Version: 5.1.2
New Comment:
Now the pdo_mysql works with libmysql 5.0 and 3.23! No error or
exception anymore. The code returns data form database now!
Thanks a lot Wez for fixing this!
PS: but I still don't understand why there has not been thrown an
exception before...
Previous Comments:
[2006-04-09 08:28:52] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-03-28 13:59:20] akorthaus at web dot de
Description:
The following code leads to a "Unknown Command" Error (because I tried
to use PDO with a 5.0 libmysql to connect to a 3.23 mysqld), but for
any reason this does not throw an Ecxeption, though I used:
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
Why doesn't PDO throw an Exception here?
Reproduce code:
---
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$result = $dbh->query('SELECT * FROM test');
var_dump($dbh->errorInfo());
}
catch(PDOException $e){
die($e->getMessage());
}
?>
Expected result:
should throw a PDOEception ("Unknown Command"), which is caused by
PDO::query().
Actual result:
--
Does not throw any exception, only $dbh->errorInfo() gives some info
here.
$dbh->query() return FALSE
$dbh->errorInfo() returns error "Unknown Command"
$dbh->getAttribute(PDO::ATTR_ERRMODE) returns "2"
which is == PDO::ERRMODE_EXCEPTION
shouldn't PDO throw an Exception here? Seems to ignore the errormode
set by $dbh->setAttribute(). Before calling $dbh->query() and after
calling $dbh->setAttribute() $dbh->errorInfo() returns no error.
I started a thread on php.pecl.dev last week about a problem with using
PDO_MYSQL linked against a 5.0 libmysql with a 3.23 mysqld. The reason
for the error seems to be, that PDO_MYSQL uses "prepare" internally,
which is not supported by mysqld <4.1:
http://marc.theaimsgroup.com/?t=1143141&r=1&w=2
--
Edit this bug report at http://bugs.php.net/?id=36890&edit=1
#36896 [NEW]: ErrorException does not work with include/require errors
From: akorthaus at web dot de Operating system: Linux 2.4.32 (gentoo) PHP version: 5.1.2 PHP Bug Type: Scripting Engine problem Bug description: ErrorException does not work with include/require errors Description: The ErrorException class bundled with PHP 5.1 does not work with Warnings/Fatal Errors produced by include() and require(). Reproduce code: --- getMessage(); } ?> Expected result: should throw an ErrorException and display $e->getMessage(), and should NOT display a PHP Warning. Actual result: -- Warning: main(): Failed opening './DOES_NOT_EXIST' for inclusion (include_path='.:') in /home/akorthaus/test/exc4.php on line 16 ErrorException catched! include(./DOES_NOT_EXIST): failed to open stream: No such file or directory if I replace "include" with "require", I get: Fatal error: main(): Failed opening required './DOES_NOT_EXIST' (include_path='.:') in /home/akorthaus/test/exc4.php on line 14 if I replace "require" with "file_get_contents", I get: ErrorException catched! file_get_contents(./DOES_NOT_EXIST): failed to open stream: No such file or directory That's what I'd expect to see from include() and require() too (ErrorException also works with other Fatal Errors!). So include() seems to throw an ErrorException, but additionaly displays the PHP Warning, require only displays the PHP Fatal Error, and does not throw an Exception at all. Is this intended? Is it somewhere documented how ErrorException works or should be used? -- Edit bug report at http://bugs.php.net/?id=36896&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36896&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36896&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36896&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36896&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36896&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36896&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36896&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36896&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36896&r=support Expected behavior:http://bugs.php.net/fix.php?id=36896&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36896&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36896&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36896&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36896&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36896&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36896&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36896&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36896&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36896&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36896&r=mysqlcfg
#36890 [NEW]: PDO does not throw Exception
From: akorthaus at web dot de
Operating system: Linux 2.4.32 (gentoo)
PHP version: 5.1.2
PHP Bug Type: PDO related
Bug description: PDO does not throw Exception
Description:
The following code leads to a "Unknown Command" Error (because I tried to
use PDO with a 5.0 libmysql to connect to a 3.23 mysqld), but for any
reason this does not throw an Ecxeption, though I used:
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
Why doesn't PDO throw an Exception here?
Reproduce code:
---
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$result = $dbh->query('SELECT * FROM test');
var_dump($dbh->errorInfo());
}
catch(PDOException $e){
die($e->getMessage());
}
?>
Expected result:
should throw a PDOEception ("Unknown Command"), which is caused by
PDO::query().
Actual result:
--
Does not throw any exception, only $dbh->errorInfo() gives some info here.
$dbh->query() return FALSE
$dbh->errorInfo() returns error "Unknown Command"
$dbh->getAttribute(PDO::ATTR_ERRMODE) returns "2"
which is == PDO::ERRMODE_EXCEPTION
shouldn't PDO throw an Exception here? Seems to ignore the errormode set
by $dbh->setAttribute(). Before calling $dbh->query() and after calling
$dbh->setAttribute() $dbh->errorInfo() returns no error.
I started a thread on php.pecl.dev last week about a problem with using
PDO_MYSQL linked against a 5.0 libmysql with a 3.23 mysqld. The reason for
the error seems to be, that PDO_MYSQL uses "prepare" internally, which is
not supported by mysqld <4.1:
http://marc.theaimsgroup.com/?t=1143141&r=1&w=2
--
Edit bug report at http://bugs.php.net/?id=36890&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36890&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36890&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36890&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36890&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36890&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36890&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36890&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36890&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36890&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36890&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36890&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36890&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36890&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36890&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36890&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36890&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36890&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36890&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36890&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36890&r=mysqlcfg
#34964 [Bgs]: using PDO::query() more than once with MySQL-driver
ID: 34964
User updated by: akorthaus at web dot de
-Summary: using PDO::query() more than once
Reported By: akorthaus at web dot de
Status: Bogus
Bug Type: PDO related
Operating System: *
PHP Version: 5.*
Assigned To: wez
New Comment:
But why can't the mysql-driver set the last Statement to NULL, perhaps
in mysql_handle_doer() -
http://cvs.php.net/co.php/php-src/ext/pdo_mysql/mysql_driver.c?r=1.65#236
?
Shouldn't the API across all drivers be as consistent as possible?
The docs don't mention that you have to set the last statement to NULL
("for one of the drivers"), and don't mention that PDO::query() could
return FALSE.
Perhaps at least an exception should be thrown instead of returning
FALSE.
And you're right, with another PDO driver like sqlite I get a result
like:
output:
-
object(PDOStatement)#2 ...
object(PDOStatement)#3 ...
object(PDOStatement)#4 ...
Previous Comments:
[2005-10-24 10:32:21] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The MySql driver uses the old mysql protocol which is not capable of
this. We need someone to write a mysqlI driver and may want to find a
way to issue an error if used like this.
----
[2005-10-24 04:05:06] akorthaus at web dot de
that's how this problem could also look like:
query('SELECT * FROM table1');
var_dump($stmt);
$stmt = $db->query('SELECT * FROM table2');
var_dump($stmt);
$stmt = $db->query('SELECT * FROM table3');
var_dump($stmt);
?>
output:
-
object(PDOStatement)#2 ...
bool(false)
object(PDOStatement)#2 ...
Only if I do this:
query('SELECT * FROM table1');
var_dump($stmt);
$stmt = NULL;
$stmt = $db->query('SELECT * FROM table2');
var_dump($stmt);
$stmt = NULL;
$stmt = $db->query('SELECT * FROM table3');
var_dump($stmt);
$stmt = NULL;
?>
output:
-
object(PDOStatement)#2 ...
object(PDOStatement)#2 ...
object(PDOStatement)#2 ...
This seems to work. But should this really be the way to go? I hope
it's a but ;-)
[2005-10-24 03:52:50] akorthaus at web dot de
Description:
If I want to use PDO::query() more than one time in a script, I have to
set the last PDOStatement to NULL, before I can use the second query.
Only If I add:
$stmt1 = NULL;
before
$stmt2 = $db->query ...
in the example below, I can work with the second query.
But - how can I work with two statments at the same time? I often have
to do this! I don't understand it because I use two different variables
for the statements here.
I have used the pdo_mysql driver (MySQL 4.1.14), pdo and pdo_mysql were
compiled from latest CVS.
Reproduce code:
---
query('SELECT * FROM table1');
var_dump($stmt1);
$stmt2 = $db->query('SELECT * FROM table2');
var_dump($stmt1);
?>
Expected result:
object(PDOStatement)#2 ...
object(PDOStatement)#2 ...
Actual result:
--
object(PDOStatement)#2 ...
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=34964&edit=1
#34964 [Opn]: using PDO::query() more than once
ID: 34964
User updated by: akorthaus at web dot de
Reported By: akorthaus at web dot de
Status: Open
Bug Type: PDO related
Operating System: all
PHP Version: 5.0.5
New Comment:
that's how this problem could also look like:
query('SELECT * FROM table1');
var_dump($stmt);
$stmt = $db->query('SELECT * FROM table2');
var_dump($stmt);
$stmt = $db->query('SELECT * FROM table3');
var_dump($stmt);
?>
output:
-
object(PDOStatement)#2 ...
bool(false)
object(PDOStatement)#2 ...
Only if I do this:
query('SELECT * FROM table1');
var_dump($stmt);
$stmt = NULL;
$stmt = $db->query('SELECT * FROM table2');
var_dump($stmt);
$stmt = NULL;
$stmt = $db->query('SELECT * FROM table3');
var_dump($stmt);
$stmt = NULL;
?>
output:
-
object(PDOStatement)#2 ...
object(PDOStatement)#2 ...
object(PDOStatement)#2 ...
This seems to work. But should this really be the way to go? I hope
it's a but ;-)
Previous Comments:
----------------
[2005-10-24 03:52:50] akorthaus at web dot de
Description:
If I want to use PDO::query() more than one time in a script, I have to
set the last PDOStatement to NULL, before I can use the second query.
Only If I add:
$stmt1 = NULL;
before
$stmt2 = $db->query ...
in the example below, I can work with the second query.
But - how can I work with two statments at the same time? I often have
to do this! I don't understand it because I use two different variables
for the statements here.
I have used the pdo_mysql driver (MySQL 4.1.14), pdo and pdo_mysql were
compiled from latest CVS.
Reproduce code:
---
query('SELECT * FROM table1');
var_dump($stmt1);
$stmt2 = $db->query('SELECT * FROM table2');
var_dump($stmt1);
?>
Expected result:
object(PDOStatement)#2 ...
object(PDOStatement)#2 ...
Actual result:
--
object(PDOStatement)#2 ...
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=34964&edit=1
#34964 [NEW]: using PDO::query() more than once
From: akorthaus at web dot de
Operating system: all
PHP version: 5.0.5
PHP Bug Type: PDO related
Bug description: using PDO::query() more than once
Description:
If I want to use PDO::query() more than one time in a script, I have to
set the last PDOStatement to NULL, before I can use the second query. Only
If I add:
$stmt1 = NULL;
before
$stmt2 = $db->query ...
in the example below, I can work with the second query.
But - how can I work with two statments at the same time? I often have to
do this! I don't understand it because I use two different variables for
the statements here.
I have used the pdo_mysql driver (MySQL 4.1.14), pdo and pdo_mysql were
compiled from latest CVS.
Reproduce code:
---
query('SELECT * FROM table1');
var_dump($stmt1);
$stmt2 = $db->query('SELECT * FROM table2');
var_dump($stmt1);
?>
Expected result:
object(PDOStatement)#2 ...
object(PDOStatement)#2 ...
Actual result:
--
object(PDOStatement)#2 ...
bool(false)
--
Edit bug report at http://bugs.php.net/?id=34964&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34964&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34964&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34964&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34964&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34964&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34964&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34964&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34964&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34964&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34964&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34964&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34964&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34964&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34964&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34964&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34964&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34964&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34964&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34964&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34964&r=mysqlcfg
#34909 [Com]: Defaut FetchMode for PDOStatements in PDO class
ID: 34909
Comment by: akorthaus at web dot de
Reported By: mcka at gmx dot net
Status: Open
Bug Type: Feature/Change Request
Operating System: all
PHP Version: 5.1.0RC3
New Comment:
I have posted a simple patch on pecl.php.dev, which implements a
PDO::setDefaultFetchMode() methodes, but it's not complete yet, it only
supports simple FetchModes, without additional parameters.
http://news.php.net/php.pecl.dev/3122
Previous Comments:
[2005-10-18 20:08:53] akorthaus at web dot de
That's exactly the same issue I ran into. It would be great to write
simple/clean code without setting the fetch mode of every
statement/query, when you don't want to use PDO::FETCH_BOTH.
This is the only issue which forces me to wrap PDO. And I think it
would be a good idea to avoid that by managing a default fetch mode by
the PDO API.
I have looked at the PDO source and tried to write a patch for that, it
does not look very difficult, but it's quite difficult for me because
I'm not a C developer ;-)
The default fetch mode is hardcoded everywhere. This must be changed to
a property of the PDO DBH class/struct. A "PDO::setDefaultFetchMode()"
methode could change this value, and it has to be passed to every
PDOStatement object created. There must be a property for the default
fetch mode in PDOStatement too. So methodes in PDOStatement can check
this default fetch mode property, instead of the hardcoded fetch mode.
This has also been suggested in the PECL bug-tracker by someone else
some time ago: http://pecl.php.net/bugs/bug.php?id=4732
[2005-10-18 18:50:27] mcka at gmx dot net
Hm, in pdo_dbh.c I can find:
/* {{{ proto object PDO::query(string sql [,
PDOStatement::setFetchMode() args])
Prepare and execute $sql; returns the statement object for iteration
*/
static PHP_METHOD(PDO, query)
{
[...]
http://cvs.php.net/co.php/php-src/ext/pdo/pdo_dbh.c?r=1.99#976
But this only saves one simple line in my "PDOwithDefaultFetchMode"
class, I still can't completely avoid such a workaround, I still can
only use $db->query($sql) when I'm happy with the default FetchMode,
and I think that's a problem of the API.
The problem is the same why PDOStatement::setFetchMode() exists. It
should make working with PDOStatement::fetch()... the same for each
FetchMode.
A default FetchMode for the whole PDO object is the only way to make
PDO::query()... work with the same simple code for other FetchModes
beside the default PDO::FETCH_BOTH.
Probably it's too late for PHP 5.1, but it would be great to have such
a possibility in PDO. In my opinion something like that belongs
"behind" the API of a database abstraction, not in userspace code.
[2005-10-18 18:18:41] [EMAIL PROTECTED]
I think we have a documentation bug, because I'm pretty sure you can do
this:
$db->query("select ...", PDO::FETCH_OBJ)
[2005-10-18 17:34:25] mcka at gmx dot net
A small example to illustrate the problem
If I want to write some simple code like the code from PDO::query()
docs, only with PDO::FETCH_MODE_OBJ (not tested, only to get the
idea):
query($sql) as $row) {
print $row->name . "\t";
print$row->colour . "\t";
print $row->calories . "\n";
}
?>
I have to create at least a PDO wrapper, or extend PDO (with all the
disadvantages of doing that):
setFetchMode(self::DEFAULT_FETCH_MODE);
return $stmt;
}
}
?>
You allways have to do this, if you are not happy with the FetchMode
which is selected as "default" by PDO. IMHO code like that should be
part of PDO, not userspace.
Of course you can add a
$stmt->setFetchMode(PDO::FETCH_MODE_OBJ);
to every statement in the code, but if you have a lot of statements in
the code, and a lot of PHP scripts, I don't think it's a good option.
[2005-10-18 17:07:47] mcka at gmx dot net
Description:
If I don't want to use the PDO_FETCH_BOTH FetchMode (which returns an
array indexed by both column names and numbers), I have to pass my
desired FetchMode to every PDOStatement and/or fetch() call everywhere
in the PHP scripts!
So why not offer a methode in PDO class which sets the default
FetchMode only once in a script like PDO::setDefaultFetchMode(), or at
least add an attribute like PDO_DEFAULT_FETCH_MODE which could be set
by PDO::setAttribute(PDO_DEFAULT_FETCH_MODE...)?
Makes live much easier for people who don't want to use PDO_
#34909 [Com]: Defaut FetchMode for PDOStatements in PDO class
ID: 34909
Comment by: akorthaus at web dot de
Reported By: mcka at gmx dot net
Status: Open
Bug Type: PDO related
Operating System: all
PHP Version: 5.1.0RC3
New Comment:
That's exactly the same issue I ran into. It would be great to write
simple/clean code without setting the fetch mode of every
statement/query, when you don't want to use PDO::FETCH_BOTH.
This is the only issue which forces me to wrap PDO. And I think it
would be a good idea to avoid that by managing a default fetch mode by
the PDO API.
I have looked at the PDO source and tried to write a patch for that, it
does not look very difficult, but it's quite difficult for me because
I'm not a C developer ;-)
The default fetch mode is hardcoded everywhere. This must be changed to
a property of the PDO DBH class/struct. A "PDO::setDefaultFetchMode()"
methode could change this value, and it has to be passed to every
PDOStatement object created. There must be a property for the default
fetch mode in PDOStatement too. So methodes in PDOStatement can check
this default fetch mode property, instead of the hardcoded fetch mode.
This has also been suggested in the PECL bug-tracker by someone else
some time ago: http://pecl.php.net/bugs/bug.php?id=4732
Previous Comments:
[2005-10-18 18:50:27] mcka at gmx dot net
Hm, in pdo_dbh.c I can find:
/* {{{ proto object PDO::query(string sql [,
PDOStatement::setFetchMode() args])
Prepare and execute $sql; returns the statement object for iteration
*/
static PHP_METHOD(PDO, query)
{
[...]
http://cvs.php.net/co.php/php-src/ext/pdo/pdo_dbh.c?r=1.99#976
But this only saves one simple line in my "PDOwithDefaultFetchMode"
class, I still can't completely avoid such a workaround, I still can
only use $db->query($sql) when I'm happy with the default FetchMode,
and I think that's a problem of the API.
The problem is the same why PDOStatement::setFetchMode() exists. It
should make working with PDOStatement::fetch()... the same for each
FetchMode.
A default FetchMode for the whole PDO object is the only way to make
PDO::query()... work with the same simple code for other FetchModes
beside the default PDO::FETCH_BOTH.
Probably it's too late for PHP 5.1, but it would be great to have such
a possibility in PDO. In my opinion something like that belongs
"behind" the API of a database abstraction, not in userspace code.
[2005-10-18 18:18:41] [EMAIL PROTECTED]
I think we have a documentation bug, because I'm pretty sure you can do
this:
$db->query("select ...", PDO::FETCH_OBJ)
[2005-10-18 17:34:25] mcka at gmx dot net
A small example to illustrate the problem
If I want to write some simple code like the code from PDO::query()
docs, only with PDO::FETCH_MODE_OBJ (not tested, only to get the
idea):
query($sql) as $row) {
print $row->name . "\t";
print$row->colour . "\t";
print $row->calories . "\n";
}
?>
I have to create at least a PDO wrapper, or extend PDO (with all the
disadvantages of doing that):
setFetchMode(self::DEFAULT_FETCH_MODE);
return $stmt;
}
}
?>
You allways have to do this, if you are not happy with the FetchMode
which is selected as "default" by PDO. IMHO code like that should be
part of PDO, not userspace.
Of course you can add a
$stmt->setFetchMode(PDO::FETCH_MODE_OBJ);
to every statement in the code, but if you have a lot of statements in
the code, and a lot of PHP scripts, I don't think it's a good option.
[2005-10-18 17:07:47] mcka at gmx dot net
Description:
If I don't want to use the PDO_FETCH_BOTH FetchMode (which returns an
array indexed by both column names and numbers), I have to pass my
desired FetchMode to every PDOStatement and/or fetch() call everywhere
in the PHP scripts!
So why not offer a methode in PDO class which sets the default
FetchMode only once in a script like PDO::setDefaultFetchMode(), or at
least add an attribute like PDO_DEFAULT_FETCH_MODE which could be set
by PDO::setAttribute(PDO_DEFAULT_FETCH_MODE...)?
Makes live much easier for people who don't want to use PDO_FETCH_BOTH,
but PDO_FETCH_ASSOC, PDO_FETCH_OBJ, PDO_FETCH_NUM... - without forcing
them to extend or wrap PDO AND extend or wrap PDOStatement to implement
something like that!
--
Edit this bug report at http://bugs.php.net/?id=34909&edit=1
#34900 [Opn]: [patch] pdo_odbc.c:115: undefined reference to `REGISTER_PDO_CONST_LONG'
ID: 34900
User updated by: akorthaus at web dot de
-Summary: make fails: pdo_odbc.c:115: undefined reference to
`REGISTER_PDO_CONST_LONG'
Reported By: akorthaus at web dot de
Status: Open
Bug Type: PDO related
Operating System: Linux 2.4.31 (gentoo)
PHP Version: 5CVS-2005-10-18 (CVS)
New Comment:
the following patch solves the issue for me:
--- ext/pdo_odbc/pdo_odbc.c_orig2005-10-18 02:37:01.0
+0200
+++ ext/pdo_odbc/pdo_odbc.c 2005-10-18 02:39:35.0 +0200
@@ -112,10 +112,10 @@
}
#endif
- REGISTER_PDO_CONST_LONG("ODBC_ATTR_USE_CURSOR_LIBRARY",
PDO_ODBC_ATTR_USE_CURSOR_LIBRARY);
- REGISTER_PDO_CONST_LONG("ODBC_SQL_USE_IF_NEEDED",
SQL_CUR_USE_IF_NEEDED);
- REGISTER_PDO_CONST_LONG("ODBC_SQL_USE_DRIVER",
SQL_CUR_USE_DRIVER);
- REGISTER_PDO_CONST_LONG("ODBC_SQL_USE_ODBC",
SQL_CUR_USE_ODBC);
+ REGISTER_PDO_CLASS_CONST_LONG("ODBC_ATTR_USE_CURSOR_LIBRARY",
PDO_ODBC_ATTR_USE_CURSOR_LIBRARY);
+ REGISTER_PDO_CLASS_CONST_LONG("ODBC_SQL_USE_IF_NEEDED",
SQL_CUR_USE_IF_NEEDED);
+ REGISTER_PDO_CLASS_CONST_LONG("ODBC_SQL_USE_DRIVER",
SQL_CUR_USE_DRIVER);
+ REGISTER_PDO_CLASS_CONST_LONG("ODBC_SQL_USE_ODBC",
SQL_CUR_USE_ODBC);
return SUCCESS;
}
Previous Comments:
--------------------
[2005-10-18 02:08:53] akorthaus at web dot de
Description:
I tried to compile PHP 5.1.0 RC3 with pdo-odbc extension, but make
failed.
Reproduce code:
---
./configure --prefix=$PHP_PREFIX --disable-all --enable-pdo
--with-pdo-odbc=unixODBC,/usr
make
Expected result:
should compile PHP 5.1.0 RC3 with pdo_odbc
Actual result:
--
/bin/sh /home/akorthaus/src/php-5.1.0RC3/libtool --silent
--preserve-dup-deps --mode=link gcc -export-dynamic -g -O2
ext/date/php_date.lo ext/date/lib/dow.lo ext/date/lib/parse_date.lo
ext/date/lib/parse_tz.lo ext/date/lib/timelib.lo
ext/date/lib/tm2unixtime.lo ext/date/lib/unixtime2tm.lo ext/pdo/pdo.lo
ext/pdo/pdo_dbh.lo ext/pdo/pdo_stmt.lo ext/pdo/pdo_sql_parser.lo
ext/pdo/pdo_sqlstate.lo ext/pdo_odbc/pdo_odbc.lo
ext/pdo_odbc/odbc_driver.lo ext/pdo_odbc/odbc_stmt.lo regex/regcomp.lo
regex/regexec.lo regex/regerror.lo regex/regfree.lo
ext/standard/array.lo ext/standard/base64.lo
ext/standard/basic_functions.lo ext/standard/browscap.lo
ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo
ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo
ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo
ext/standard/filestat.lo ext/standard/flock_compat.lo
ext/standard/formatted_print.lo ext/standard/fsock.lo
ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo
ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo
ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo
ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo
ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/quot_print.lo
ext/standard/rand.lo ext/standard/reg.lo ext/standard/soundex.lo
ext/standard/string.lo ext/standard/scanf.lo ext/standard/syslog.lo
ext/standard/type.lo ext/standard/uniqid.lo ext/standard/url.lo
ext/standard/url_scanner.lo ext/standard/var.lo
ext/standard/versioning.lo ext/standard/assert.lo
ext/standard/strnatcmp.lo ext/standard/levenshtein.lo
ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo
ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo
ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo
ext/standard/css.lo ext/standard/var_unserializer.lo
ext/standard/ftok.lo ext/standard/sha1.lo ext/standard/user_filters.lo
ext/standard/uuencode.lo ext/standard/filters.lo
ext/standard/proc_open.lo ext/standard/sunfuncs.lo
ext/standard/streamsfuncs.lo ext/standard/http.lo TSRM/TSRM.lo
TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo
main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo
main/fopen_wrappers.lo main/alloca.lo main/php_scandir.lo
main/php_ini.lo main/SAPI.lo main/rfc1867.lo main/php_content_types.lo
main/strlcpy.lo main/strlcat.lo main/mergesort.lo main/reentrancy.lo
main/php_variables.lo main/php_ticks.lo main/network.lo
main/php_open_temporary_file.lo main/php_logos.lo main/output.lo
main/streams/streams.lo main/streams/cast.lo main/streams/memory.lo
main/streams/filter.lo main/streams/plain_wrapper.lo
main/streams/userspace.lo main/streams/transports.lo
main/streams/xp_socket.lo main/streams/mmap.lo
Zend/zend_language_parser.lo Zend/zend_language_scanner.lo
Zend/zend_ini_parser.lo Zend/zend_ini_scanner.lo Zend/zend_alloc.lo
Zend/zend_compile.lo Zend/zend_constants.lo Zend/zend_dynamic_array.lo
Zend/zend_execute_API.lo Zend/zend_highlight.lo Zend/zend_llist.lo
Zend/zend_opcode.lo Zend/zend_operators.lo Zend/zend_ptr_
#34900 [NEW]: make fails: pdo_odbc.c:115: undefined reference to `REGISTER_PDO_CONST_LONG'
From: akorthaus at web dot de Operating system: Linux 2.4.31 (gentoo) PHP version: 5CVS-2005-10-18 (CVS) PHP Bug Type: PDO related Bug description: make fails: pdo_odbc.c:115: undefined reference to `REGISTER_PDO_CONST_LONG' Description: I tried to compile PHP 5.1.0 RC3 with pdo-odbc extension, but make failed. Reproduce code: --- ./configure --prefix=$PHP_PREFIX --disable-all --enable-pdo --with-pdo-odbc=unixODBC,/usr make Expected result: should compile PHP 5.1.0 RC3 with pdo_odbc Actual result: -- /bin/sh /home/akorthaus/src/php-5.1.0RC3/libtool --silent --preserve-dup-deps --mode=link gcc -export-dynamic -g -O2 ext/date/php_date.lo ext/date/lib/dow.lo ext/date/lib/parse_date.lo ext/date/lib/parse_tz.lo ext/date/lib/timelib.lo ext/date/lib/tm2unixtime.lo ext/date/lib/unixtime2tm.lo ext/pdo/pdo.lo ext/pdo/pdo_dbh.lo ext/pdo/pdo_stmt.lo ext/pdo/pdo_sql_parser.lo ext/pdo/pdo_sqlstate.lo ext/pdo_odbc/pdo_odbc.lo ext/pdo_odbc/odbc_driver.lo ext/pdo_odbc/odbc_stmt.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo ext/standard/versioning.lo ext/standard/assert.lo ext/standard/strnatcmp.lo ext/standard/levenshtein.lo ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo ext/standard/css.lo ext/standard/var_unserializer.lo ext/standard/ftok.lo ext/standard/sha1.lo ext/standard/user_filters.lo ext/standard/uuencode.lo ext/standard/filters.lo ext/standard/proc_open.lo ext/standard/sunfuncs.lo ext/standard/streamsfuncs.lo ext/standard/http.lo TSRM/TSRM.lo TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo main/fopen_wrappers.lo main/alloca.lo main/php_scandir.lo main/php_ini.lo main/SAPI.lo main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo main/strlcat.lo main/mergesort.lo main/reentrancy.lo main/php_variables.lo main/php_ticks.lo main/network.lo main/php_open_temporary_file.lo main/php_logos.lo main/output.lo main/streams/streams.lo main/streams/cast.lo main/streams/memory.lo main/streams/filter.lo main/streams/plain_wrapper.lo main/streams/userspace.lo main/streams/transports.lo main/streams/xp_socket.lo main/streams/mmap.lo Zend/zend_language_parser.lo Zend/zend_language_scanner.lo Zend/zend_ini_parser.lo Zend/zend_ini_scanner.lo Zend/zend_alloc.lo Zend/zend_compile.lo Zend/zend_constants.lo Zend/zend_dynamic_array.lo Zend/zend_execute_API.lo Zend/zend_highlight.lo Zend/zend_llist.lo Zend/zend_opcode.lo Zend/zend_operators.lo Zend/zend_ptr_stack.lo Zend/zend_stack.lo Zend/zend_variables.lo Zend/zend.lo Zend/zend_API.lo Zend/zend_extensions.lo Zend/zend_hash.lo Zend/zend_list.lo Zend/zend_indent.lo Zend/zend_builtin_functions.lo Zend/zend_sprintf.lo Zend/zend_ini.lo Zend/zend_qsort.lo Zend/zend_multibyte.lo Zend/zend_ts_hash.lo Zend/zend_stream.lo Zend/zend_iterators.lo Zend/zend_interfaces.lo Zend/zend_exceptions.lo Zend/zend_strtod.lo Zend/zend_objects.lo Zend/zend_object_handlers.lo Zend/zend_objects_API.lo Zend/zend_mm.lo Zend/zend_default_classes.lo Zend/zend_reflection_api.lo Zend/zend_execute.lo sapi/cgi/cgi_main.lo sapi/cgi/getopt.lo main/internal_functions.lo -lcrypt -lcrypt -lresolv -lm -ldl -lnsl -lodbc -lcrypt -lcrypt -o sapi/cgi/php ext/pdo_odbc/pdo_odbc.o(.text+0xac): In function `zm_startup_pdo_odbc': /home/akorthaus/src/php-5.1.0RC3/ext/pdo_odbc/pdo_odbc.c:115: undefined reference to `REGISTER_PDO_CONST_LONG' ext/pdo_odbc/pdo_odbc.o(.text+0xbe):/home/akorthaus/src/php-5.1.0RC3/ext/pdo_odbc/pdo_odbc.c:116: undefined reference to `REGISTER_PDO_CONST_LONG' ext/pdo_odbc/pdo_odbc.o(.text+0xd3):/home/akorthaus/src/php-5.1.0RC3/ext/pdo_odbc/pdo_odbc.c:117: undefined reference to `REGISTER_PDO_CONST_LONG' ext/pdo_odbc/pdo_odbc.o(.text+0xe8):/home/akorthaus/src/php-5.1.0RC3/ex
#34899 [Opn]: make fails: missing template file "lempar.c"
ID: 34899 User updated by: akorthaus at web dot de Reported By: akorthaus at web dot de Status: Open Bug Type: SQLite related Operating System: Linux 2.4.31 (gentoo) PHP Version: 5CVS-2005-10-18 (CVS) New Comment: I can't find where "lempar.c" is included there, but I can find the file itself only under ext/pdo_sqlite/sqlite/tool/lempar.c btw.: I used --prefix=/home/akorthaus/src/php-5.1.0RC3 to get empty include/... directories for the test. Previous Comments: [2005-10-18 01:02:45] akorthaus at web dot de Description: I tried to compile PHP 5.1.0 RC3 with sqlite extension, but it failed. Reproduce code: --- ./configure --with-sqlite make Expected result: should compile PHP 5.1.0 RC3 with sqlite, as it has worked with RC1. Actual result: -- /bin/sh /home/akorthaus/src/php-5.1.0RC3/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/sqlite/libsqlite/src -I/home/akorthaus/src/php-5.1.0RC3/ext -Iext/sqlite/ -I/home/akorthaus/src/php-5.1.0RC3/ext/sqlite/ -DPHP_ATOM_INC -I/home/akorthaus/src/php-5.1.0RC3/include -I/home/akorthaus/src/php-5.1.0RC3/main -I/home/akorthaus/src/php-5.1.0RC3 -I/usr/include/libxml2 -I/home/akorthaus/src/php-5.1.0RC3/ext/date/lib -I/home/akorthaus/src/php-5.1.0RC3/TSRM -I/home/akorthaus/src/php-5.1.0RC3/Zend-g -O2 -c /home/akorthaus/src/php-5.1.0RC3/ext/sqlite/libsqlite/src/opcodes.c -o ext/sqlite/libsqlite/src/opcodes.lo Can't open the template file "lempar.c". make: *** [/home/akorthaus/src/php-5.1.0RC3/ext/sqlite/libsqlite/src/parse.c] Error 1 -- Edit this bug report at http://bugs.php.net/?id=34899&edit=1
#34899 [NEW]: make fails: missing template file "lempar.c"
From: akorthaus at web dot de Operating system: Linux 2.4.31 (gentoo) PHP version: 5CVS-2005-10-18 (CVS) PHP Bug Type: SQLite related Bug description: make fails: missing template file "lempar.c" Description: I tried to compile PHP 5.1.0 RC3 with sqlite extension, but it failed. Reproduce code: --- ./configure --with-sqlite make Expected result: should compile PHP 5.1.0 RC3 with sqlite, as it has worked with RC1. Actual result: -- /bin/sh /home/akorthaus/src/php-5.1.0RC3/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/sqlite/libsqlite/src -I/home/akorthaus/src/php-5.1.0RC3/ext -Iext/sqlite/ -I/home/akorthaus/src/php-5.1.0RC3/ext/sqlite/ -DPHP_ATOM_INC -I/home/akorthaus/src/php-5.1.0RC3/include -I/home/akorthaus/src/php-5.1.0RC3/main -I/home/akorthaus/src/php-5.1.0RC3 -I/usr/include/libxml2 -I/home/akorthaus/src/php-5.1.0RC3/ext/date/lib -I/home/akorthaus/src/php-5.1.0RC3/TSRM -I/home/akorthaus/src/php-5.1.0RC3/Zend-g -O2 -c /home/akorthaus/src/php-5.1.0RC3/ext/sqlite/libsqlite/src/opcodes.c -o ext/sqlite/libsqlite/src/opcodes.lo Can't open the template file "lempar.c". make: *** [/home/akorthaus/src/php-5.1.0RC3/ext/sqlite/libsqlite/src/parse.c] Error 1 -- Edit bug report at http://bugs.php.net/?id=34899&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34899&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34899&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34899&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34899&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34899&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34899&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34899&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34899&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34899&r=support Expected behavior: http://bugs.php.net/fix.php?id=34899&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34899&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34899&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34899&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34899&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34899&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34899&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34899&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34899&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34899&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34899&r=mysqlcfg
#34010 [NEW]: bundled sqlite version:2, pdo-sqlite:3
From: akorthaus at web dot de Operating system: Linux 2.4.31 (gentoo) PHP version: 5.1.0b3 PHP Bug Type: SQLite related Bug description: bundled sqlite version:2, pdo-sqlite:3 Description: If I install php with sqlite (and sqlite-utf8), I geht the following version: SQLite SQLite support enabled PECL Module version 2.0-dev $Id: sqlite.c,v 1.165 2005/06/17 16:42:53 sniper Exp $ SQLite Library 2.8.14 SQLite Encoding UTF-8 If I install pdo-sqlite, I get the following version: pdo_sqlite PDO Driver for SQLite 3.x enabled PECL Module version (bundled) 0.9 $Id: pdo_sqlite.c,v 1.10 2005/07/27 04:07:11 wez Exp $ SQLite Library 3.2.2 Would be great of the two versions could be more in sync, to make it possible to use both php-extensions with the same data-files. -- Edit bug report at http://bugs.php.net/?id=34010&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34010&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34010&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34010&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34010&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34010&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34010&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34010&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34010&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34010&r=support Expected behavior: http://bugs.php.net/fix.php?id=34010&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34010&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34010&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34010&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34010&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34010&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34010&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34010&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34010&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34010&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34010&r=mysqlcfg
#33632 [NEW]: cannot use "Subject" as classname
From: akorthaus at web dot de Operating system: Linux 2.4.31 (gentoo) PHP version: 5.1.0b2 PHP Bug Type: Scripting Engine problem Bug description: cannot use "Subject" as classname Description: I have a class called "Subject" which I use for a long time now, but when I tried to use the code with 5.1b2 I got: Fatal error: Cannot redeclare class subject... Simple renaming the class to MailSubject fixes the problem. But I did not redeclare this class, I did a search like "grep -ir subject *" I tried some test-scrips: bool(false) Fatal error: Cannot redeclare class subject in /var/www/localhost/htdocs/subject.php on line 3 Fatal error: Cannot redeclare class subject in /var/www/localhost/htdocs/subject.php on line 4 (If I extend, error is found in line 4, not 3 ?!). I'm using Apache-sapi with Apache 1.3.33. Reproduce code: --- Expected result: empty page Actual result: -- Fatal error: Cannot redeclare class subject in /var/www/localhost/htdocs/subject.php on line 2 -- Edit bug report at http://bugs.php.net/?id=33632&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33632&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33632&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33632&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33632&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33632&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33632&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33632&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33632&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33632&r=support Expected behavior: http://bugs.php.net/fix.php?id=33632&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33632&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33632&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33632&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33632&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33632&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33632&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33632&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33632&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33632&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33632&r=mysqlcfg
#32479 [Csd]: number-strings in xml are converted to int, not float
ID: 32479
User updated by: akorthaus at web dot de
Reported By: akorthaus at web dot de
Status: Closed
Bug Type: SimpleXML related
Operating System: Linux 2.4.28 (Gentoo)
PHP Version: 5.0.3
New Comment:
Thank you!
In the manual only casting to (string) is mentioned. If casting to
float is necessary too, I think it should be mentioned in the manual,
because it is not "usual php behaviour".
btw. I don't understand why casting must be necessary here, because it
is not necessary when using arrays or anything else. I think it's
confusing for many people.
Previous Comments:
[2005-03-29 11:38:08] [EMAIL PROTECTED]
Works with latest CVS. (you need to cast the stuff to float / string
though)
[2005-03-29 10:44:46] akorthaus at web dot de
Description:
If I want to calculate with numbers (decimals) from an xml file/string
parsed by simplexml, php does not convert these strings (e.g. "1.2") to
float (1.2), it converts them to integer (1).
Reproduce code:
---
1.2
0.2
0.5
XML;
$xml = simplexml_load_string($xmlstr);
foreach ($xml->num as $number) {
echo $number, " * 3 = ", $number * 3, "\n";
echo "var_dump: ", var_dump($number), "\n";
}
$number_array = array('1.2', '0.2', '0.5');
foreach ($number_array as $number) {
echo $number, " * 3 = ", $number * 3, "\n";
echo "var_dump: ", var_dump($number), "\n";
}
?>
Expected result:
The following loop:
foreach ($xml->num as $number) {
echo $number, " * 3 = ", $number * 3, "\n";
}
should display:
1.2 * 3 = 3.6
0.2 * 3 = 0.6
0.5 * 3 = 1.5
(as it actually works with $number_array)
Actual result:
--
1.2 * 3 = 3
0.2 * 3 = 0
0.5 * 3 = 0
--
Edit this bug report at http://bugs.php.net/?id=32479&edit=1
#32479 [NEW]: number-strings in xml are converted to int, not float
From: akorthaus at web dot de
Operating system: Linux 2.4.28 (Gentoo)
PHP version: 5.0.3
PHP Bug Type: SimpleXML related
Bug description: number-strings in xml are converted to int, not float
Description:
If I want to calculate with numbers (decimals) from an xml file/string
parsed by simplexml, php does not convert these strings (e.g. "1.2") to
float (1.2), it converts them to integer (1).
Reproduce code:
---
1.2
0.2
0.5
XML;
$xml = simplexml_load_string($xmlstr);
foreach ($xml->num as $number) {
echo $number, " * 3 = ", $number * 3, "\n";
echo "var_dump: ", var_dump($number), "\n";
}
$number_array = array('1.2', '0.2', '0.5');
foreach ($number_array as $number) {
echo $number, " * 3 = ", $number * 3, "\n";
echo "var_dump: ", var_dump($number), "\n";
}
?>
Expected result:
The following loop:
foreach ($xml->num as $number) {
echo $number, " * 3 = ", $number * 3, "\n";
}
should display:
1.2 * 3 = 3.6
0.2 * 3 = 0.6
0.5 * 3 = 1.5
(as it actually works with $number_array)
Actual result:
--
1.2 * 3 = 3
0.2 * 3 = 0
0.5 * 3 = 0
--
Edit bug report at http://bugs.php.net/?id=32479&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32479&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32479&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32479&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32479&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32479&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32479&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32479&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32479&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32479&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32479&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32479&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32479&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32479&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32479&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32479&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32479&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32479&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32479&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32479&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32479&r=mysqlcfg
#31515 [Opn]: scandir() is slower than user-function
ID: 31515
User updated by: akorthaus at web dot de
Reported By: akorthaus at web dot de
Status: Open
Bug Type: Performance problem
Operating System: Linux 2.4.28 (Gentoo)
PHP Version: 5.0.3
New Comment:
I tried php5-STABLE-200501140930 with the same result
The size of the directory-listing ("files"):
number of files:
ls -1 files | wc -l
1
Number of bytes:
ls -1 files | wc -c
33
Previous Comments:
[2005-01-13 03:43:06] akorthaus at web dot de
the same with php5-STABLE-200501130130
[2005-01-13 03:09:46] akorthaus at web dot de
I tried php5-STABLE-200501122330:
./configure \
--prefix=/home/akorthaus/bin/php5-STABLE-200501122330 \
--disable-all \
--with-pcre-regex \
--enable-memory-limit
With the following results:
scandir (foreach:500, files:527)
mem: 2M
time: 10.242558956146s
my_scandir (foreach:500, files:527)
mem: 0M
time: 2.3772580623627s
scandir (foreach:1, files:1)
mem: 40M
time: 0.40674495697021s
my_scandir (foreach:1, files:1)
mem: 1M
time: 0.17293095588684s
scandir (foreach:100, files:1)
mem: 40M
time: 41.659919977188s
my_scandir (foreach:100, files:1)
mem: 1M
time: 20.631703853607s
[2005-01-13 02:10:35] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
That's amazing. Try 5.0.4-dev.
[2005-01-12 23:59:15] akorthaus at web dot de
With a small directory I get:
my_scandir:
count: 71
1.63159513474
scandir:
count: 71
3.12091302872
With 100.000 files it takes too long, and scandir() runs into
memory_limit (which is 500 MB!)
scandir() seems to need much more memory!
I added the following line to the scripts:
echo "mem: ".number_format(memory_get_usage()/1048576) . "M\n";
so I get:
my_scandir:
mem: 10M
count: 12
1.38867807388
scandir:
mem: 397M
count: 12
1.75003910065
If I put in (scandir version):
foreach(range(1, 2) as $unused)
I get:
Fatal error: Allowed memory size of 524288000 bytes exhausted (tried to
allocate 4096 bytes) in /home/akorthaus/test/scan.php on line 5
If I put in (my_scandir version):
foreach(range(1, 10) as $unused)
mem: 10M
count: 12
16.7273759842
which is the same as with only one cycle.
[2005-01-12 21:51:42] [EMAIL PROTECTED]
count: 2034
251.505897045
count: 2034
155.706785917
Only difference:
foreach(range(1, 5000) as $unused)
$files = scandir('C:\WINDOWS\System32');
So, not on Win32. Do a foreach like I have done and spread the function
call over quite a few calls, because with repeated execution of a single
function call, it went back and forth for me.
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/31515
--
Edit this bug report at http://bugs.php.net/?id=31515&edit=1
#31515 [Opn]: scandir() is slower than user-function
ID: 31515
User updated by: akorthaus at web dot de
Reported By: akorthaus at web dot de
Status: Open
Bug Type: Performance problem
Operating System: Linux 2.4.28 (Gentoo)
PHP Version: 5.0.3
New Comment:
the same with php5-STABLE-200501130130
Previous Comments:
[2005-01-13 03:09:46] akorthaus at web dot de
I tried php5-STABLE-200501122330:
./configure \
--prefix=/home/akorthaus/bin/php5-STABLE-200501122330 \
--disable-all \
--with-pcre-regex \
--enable-memory-limit
With the following results:
scandir (foreach:500, files:527)
mem: 2M
time: 10.242558956146s
my_scandir (foreach:500, files:527)
mem: 0M
time: 2.3772580623627s
scandir (foreach:1, files:1)
mem: 40M
time: 0.40674495697021s
my_scandir (foreach:1, files:1)
mem: 1M
time: 0.17293095588684s
scandir (foreach:100, files:1)
mem: 40M
time: 41.659919977188s
my_scandir (foreach:100, files:1)
mem: 1M
time: 20.631703853607s
[2005-01-13 02:10:35] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
That's amazing. Try 5.0.4-dev.
[2005-01-12 23:59:15] akorthaus at web dot de
With a small directory I get:
my_scandir:
count: 71
1.63159513474
scandir:
count: 71
3.12091302872
With 100.000 files it takes too long, and scandir() runs into
memory_limit (which is 500 MB!)
scandir() seems to need much more memory!
I added the following line to the scripts:
echo "mem: ".number_format(memory_get_usage()/1048576) . "M\n";
so I get:
my_scandir:
mem: 10M
count: 12
1.38867807388
scandir:
mem: 397M
count: 12
1.75003910065
If I put in (scandir version):
foreach(range(1, 2) as $unused)
I get:
Fatal error: Allowed memory size of 524288000 bytes exhausted (tried to
allocate 4096 bytes) in /home/akorthaus/test/scan.php on line 5
If I put in (my_scandir version):
foreach(range(1, 10) as $unused)
mem: 10M
count: 12
16.7273759842
which is the same as with only one cycle.
[2005-01-12 21:51:42] [EMAIL PROTECTED]
count: 2034
251.505897045
count: 2034
155.706785917
Only difference:
foreach(range(1, 5000) as $unused)
$files = scandir('C:\WINDOWS\System32');
So, not on Win32. Do a foreach like I have done and spread the function
call over quite a few calls, because with repeated execution of a single
function call, it went back and forth for me.
----
[2005-01-12 13:48:34] akorthaus at web dot de
Description:
I do not understand why the new scandir() function is slower than an
own PHP-function which does the same (I used the "Example 2. PHP 4
alternatives to scandir()" from manual).
I tried this with 50 - 100.000 files, but the result is allways the
same.
my_scandir() is about 50%-100% faster. If I don't sort, it is about
400% faster.
Reproduce code:
---
Expected result:
I expect the c-function to be faster
Actual result:
--
the php-function is about 50-100% faster
--
Edit this bug report at http://bugs.php.net/?id=31515&edit=1
#31515 [Fbk->Opn]: scandir() is slower than user-function
ID: 31515
User updated by: akorthaus at web dot de
Reported By: akorthaus at web dot de
-Status: Feedback
+Status: Open
Bug Type: Performance problem
Operating System: Linux 2.4.28 (Gentoo)
PHP Version: 5.0.3
New Comment:
I tried php5-STABLE-200501122330:
./configure \
--prefix=/home/akorthaus/bin/php5-STABLE-200501122330 \
--disable-all \
--with-pcre-regex \
--enable-memory-limit
With the following results:
scandir (foreach:500, files:527)
mem: 2M
time: 10.242558956146s
my_scandir (foreach:500, files:527)
mem: 0M
time: 2.3772580623627s
scandir (foreach:1, files:1)
mem: 40M
time: 0.40674495697021s
my_scandir (foreach:1, files:1)
mem: 1M
time: 0.17293095588684s
scandir (foreach:100, files:1)
mem: 40M
time: 41.659919977188s
my_scandir (foreach:100, files:1)
mem: 1M
time: 20.631703853607s
Previous Comments:
[2005-01-13 02:10:35] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
That's amazing. Try 5.0.4-dev.
[2005-01-12 23:59:15] akorthaus at web dot de
With a small directory I get:
my_scandir:
count: 71
1.63159513474
scandir:
count: 71
3.12091302872
With 100.000 files it takes too long, and scandir() runs into
memory_limit (which is 500 MB!)
scandir() seems to need much more memory!
I added the following line to the scripts:
echo "mem: ".number_format(memory_get_usage()/1048576) . "M\n";
so I get:
my_scandir:
mem: 10M
count: 12
1.38867807388
scandir:
mem: 397M
count: 12
1.75003910065
If I put in (scandir version):
foreach(range(1, 2) as $unused)
I get:
Fatal error: Allowed memory size of 524288000 bytes exhausted (tried to
allocate 4096 bytes) in /home/akorthaus/test/scan.php on line 5
If I put in (my_scandir version):
foreach(range(1, 10) as $unused)
mem: 10M
count: 12
16.7273759842
which is the same as with only one cycle.
[2005-01-12 21:51:42] [EMAIL PROTECTED]
count: 2034
251.505897045
count: 2034
155.706785917
Only difference:
foreach(range(1, 5000) as $unused)
$files = scandir('C:\WINDOWS\System32');
So, not on Win32. Do a foreach like I have done and spread the function
call over quite a few calls, because with repeated execution of a single
function call, it went back and forth for me.
----
[2005-01-12 13:48:34] akorthaus at web dot de
Description:
I do not understand why the new scandir() function is slower than an
own PHP-function which does the same (I used the "Example 2. PHP 4
alternatives to scandir()" from manual).
I tried this with 50 - 100.000 files, but the result is allways the
same.
my_scandir() is about 50%-100% faster. If I don't sort, it is about
400% faster.
Reproduce code:
---
Expected result:
I expect the c-function to be faster
Actual result:
--
the php-function is about 50-100% faster
--
Edit this bug report at http://bugs.php.net/?id=31515&edit=1
#31515 [Fbk->Opn]: scandir() is slower than user-function
ID: 31515
User updated by: akorthaus at web dot de
Reported By: akorthaus at web dot de
-Status: Feedback
+Status: Open
Bug Type: Performance problem
Operating System: Linux 2.4.28 (Gentoo)
PHP Version: 5.0.3
New Comment:
With a small directory I get:
my_scandir:
count: 71
1.63159513474
scandir:
count: 71
3.12091302872
With 100.000 files it takes too long, and scandir() runs into
memory_limit (which is 500 MB!)
scandir() seems to need much more memory!
I added the following line to the scripts:
echo "mem: ".number_format(memory_get_usage()/1048576) . "M\n";
so I get:
my_scandir:
mem: 10M
count: 12
1.38867807388
scandir:
mem: 397M
count: 12
1.75003910065
If I put in (scandir version):
foreach(range(1, 2) as $unused)
I get:
Fatal error: Allowed memory size of 524288000 bytes exhausted (tried to
allocate 4096 bytes) in /home/akorthaus/test/scan.php on line 5
If I put in (my_scandir version):
foreach(range(1, 10) as $unused)
mem: 10M
count: 12
16.7273759842
which is the same as with only one cycle.
Previous Comments:
[2005-01-12 21:51:42] [EMAIL PROTECTED]
count: 2034
251.505897045
count: 2034
155.706785917
Only difference:
foreach(range(1, 5000) as $unused)
$files = scandir('C:\WINDOWS\System32');
So, not on Win32. Do a foreach like I have done and spread the function
call over quite a few calls, because with repeated execution of a single
function call, it went back and forth for me.
----
[2005-01-12 13:48:34] akorthaus at web dot de
Description:
I do not understand why the new scandir() function is slower than an
own PHP-function which does the same (I used the "Example 2. PHP 4
alternatives to scandir()" from manual).
I tried this with 50 - 100.000 files, but the result is allways the
same.
my_scandir() is about 50%-100% faster. If I don't sort, it is about
400% faster.
Reproduce code:
---
Expected result:
I expect the c-function to be faster
Actual result:
--
the php-function is about 50-100% faster
--
Edit this bug report at http://bugs.php.net/?id=31515&edit=1
#31515 [NEW]: scandir() is slower than user-function
From: akorthaus at web dot de Operating system: Linux 2.4.28 (Gentoo) PHP version: 5.0.3 PHP Bug Type: Performance problem Bug description: scandir() is slower than user-function Description: I do not understand why the new scandir() function is slower than an own PHP-function which does the same (I used the "Example 2. PHP 4 alternatives to scandir()" from manual). I tried this with 50 - 100.000 files, but the result is allways the same. my_scandir() is about 50%-100% faster. If I don't sort, it is about 400% faster. Reproduce code: --- Expected result: I expect the c-function to be faster Actual result: -- the php-function is about 50-100% faster -- Edit bug report at http://bugs.php.net/?id=31515&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31515&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31515&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31515&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31515&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31515&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31515&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31515&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31515&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31515&r=support Expected behavior: http://bugs.php.net/fix.php?id=31515&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31515&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31515&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31515&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31515&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31515&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31515&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31515&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31515&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31515&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31515&r=mysqlcfg
#29063 [NEW]: no error is logged if php error_log could not be opened
From: akorthaus at web dot de Operating system: Linux 2.4.26 PHP version: 4.3.7 PHP Bug Type: Apache related Bug description: no error is logged if php error_log could not be opened Description: I have the following settings in php.in + phpinfo(): log_errors = On error_log = "/var/log/apache/php_error.log" Server API: Apache (mod_php) Apache-Version: 1.3.31 But if I produce a php-error, this error gets logged into Apache error-log: /var/log/apache/error_log, and not into /var/log/apache/php_error.log, as configured. The reason was that mod_php not like mod_gzip and mod_ssl, loggs errors with rights of the apache child-process. The Apache user cannot create files in /var/log/apache, and cannot write to files owned by root. But there is no error-message in Apaches error_log, I would expect something like "could not open '/var/log/apache/php_error.log', permission denied". Only php-errors itself get logged into Apaches error_log. perhaps its a "feature request". -- Edit bug report at http://bugs.php.net/?id=29063&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29063&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29063&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29063&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29063&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29063&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29063&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29063&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29063&r=support Expected behavior: http://bugs.php.net/fix.php?id=29063&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29063&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29063&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29063&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29063&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29063&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29063&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29063&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29063&r=float
#27520 [NEW]: parse-error if using var-name: "$status-typ"
From: akorthaus at web dot de Operating system: RedHat Linux (Kernel 2.4) PHP version: 4.3.4 PHP Bug Type: Scripting Engine problem Bug description: parse-error if using var-name: "$status-typ" Description: If I run the following Script (Apache 1.3.29, mod_php): I get: Parse error: parse error in /path/to/php/script.php on line 2 Reproduce code: --- Expected result: empty page Actual result: -- Parse error: parse error in /path/to/php/script.php on line 2 -- Edit bug report at http://bugs.php.net/?id=27520&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27520&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27520&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27520&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27520&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27520&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27520&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27520&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27520&r=support Expected behavior: http://bugs.php.net/fix.php?id=27520&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27520&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27520&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27520&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27520&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27520&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27520&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27520&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27520&r=float
#24603 [Bgs]: all timefunctions don't give back correct time
ID: 24603 User updated by: akorthaus at web dot de Reported By: akorthaus at web dot de Status: Bogus Bug Type: Date/time related Operating System: RedHat-Linux 7.3, kernel 2.4.20 PHP Version: 4.3.2 New Comment: If it was a problem of DST, the output should have been: 17:20:09 CET 16:20:09 GMT Fri Jul 11 18:20:09 CEST 2003 CET : Central Europe Time CEST : Central Europe Summer Time BST : British Summer Time Previous Comments: [2003-07-11 11:25:34] akorthaus at web dot de That's what I get with your code: 17:20:09 BST 16:20:09 GMT Fri Jul 11 18:20:09 CEST 2003 No, The Problem is, that PHP doesn't use my local time, it doesn't use CEST as "date" in shell does, it uses BST. Why does PHP use a timezone I nerver used somewhere? Where does PHP get this information from? Or is it set at compile-time? Because at that time it was BST not, CEST. [2003-07-11 10:51:16] [EMAIL PROTECTED] We are happy to tell you that you just discovered Daylight Savings Time. For more information see: http://webexhibits.org/daylightsaving/b.html Instead of using mktime/date consider using gmmktime and gmdate which do not suffer from DST. Borked system. Works fine here: 18:49:44 EEST 15:49:44 GMT Fri Jul 11 18:49:44 EEST 2003 script: Remember the DST... ---- [2003-07-11 08:01:18] akorthaus at web dot de Description: Hi! Now I'm trying to solve this problem for more then 10 houres, nad nobody seems to know what is going wrong here. If I try this: That displays: 12:36:36 11:36:36 What I would expect would be the same like date in shell: # date Fri Jul 11 13:37:39 CEST 2003 the correspondent Apache access-log: [11/Jul/2003:12:36:36 +0100] # /sbin/hwclock returns Fri 11 Jul 2003 13:36:42 PM CEST 0.707042 seconds and it could not be set by # /sbin/hwclock --systohc --utc but I think thats not important # ls -l /etc/localtime lrwxrwxrwx1 root root 33 Jul 11 09:33 /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin which is what I want(my timezone). It's GMT + 1. PHP _has_ these difference of one hour between time() and gmtime(), but both are an extra hour too late. I also restartet Apache, I tried to change /etc/sysconfig/clock, which is now: # cat /etc/sysconfig/clock ZONE="Europe/Berlin" UTC=true ARC=false But PHP did not take care about changes in it, PHP also did not care about changing my timezone, this 1 hour too late stays. also ntpdate did not help, the time was changed about 3 seconds. Im Using RedHat Linux 7.3 min.-Installation I compiled Apache 1.3.27 with PHP 4.3.2 as static module. My PHP-./configure: ./configure --with-apache=../apache_1.3.27 --with-mysql --with-gd --with-jpeg-dir=/usr --with-png-dir=/usr --with-ttf --with-zlib --enable-gd-native-ttf --enable-trans-sid --disable-cgi --enable-ftp I'm using PHP-Accelerator. I have asked a lot of people and searched for people with similar problems, but I did not find any. So my last Idea is that it's a PHP-Bug. Reproduce code: --- Expected result: date: +-0 hours gmdate -1 hour Actual result: -- date: -1 hour gmdate -2 hours -- Edit this bug report at http://bugs.php.net/?id=24603&edit=1
#24603 [Bgs]: all timefunctions don't give back correct time
ID: 24603 User updated by: akorthaus at web dot de Reported By: akorthaus at web dot de Status: Bogus Bug Type: Date/time related Operating System: RedHat-Linux 7.3, kernel 2.4.20 PHP Version: 4.3.2 New Comment: That's what I get with your code: 17:20:09 BST 16:20:09 GMT Fri Jul 11 18:20:09 CEST 2003 No, The Problem is, that PHP doesn't use my local time, it doesn't use CEST as "date" in shell does, it uses BST. Why does PHP use a timezone I nerver used somewhere? Where does PHP get this information from? Or is it set at compile-time? Because at that time it was BST not, CEST. Previous Comments: [2003-07-11 10:51:16] [EMAIL PROTECTED] We are happy to tell you that you just discovered Daylight Savings Time. For more information see: http://webexhibits.org/daylightsaving/b.html Instead of using mktime/date consider using gmmktime and gmdate which do not suffer from DST. Borked system. Works fine here: 18:49:44 EEST 15:49:44 GMT Fri Jul 11 18:49:44 EEST 2003 script: Remember the DST... ---- [2003-07-11 08:01:18] akorthaus at web dot de Description: Hi! Now I'm trying to solve this problem for more then 10 houres, nad nobody seems to know what is going wrong here. If I try this: That displays: 12:36:36 11:36:36 What I would expect would be the same like date in shell: # date Fri Jul 11 13:37:39 CEST 2003 the correspondent Apache access-log: [11/Jul/2003:12:36:36 +0100] # /sbin/hwclock returns Fri 11 Jul 2003 13:36:42 PM CEST 0.707042 seconds and it could not be set by # /sbin/hwclock --systohc --utc but I think thats not important # ls -l /etc/localtime lrwxrwxrwx1 root root 33 Jul 11 09:33 /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin which is what I want(my timezone). It's GMT + 1. PHP _has_ these difference of one hour between time() and gmtime(), but both are an extra hour too late. I also restartet Apache, I tried to change /etc/sysconfig/clock, which is now: # cat /etc/sysconfig/clock ZONE="Europe/Berlin" UTC=true ARC=false But PHP did not take care about changes in it, PHP also did not care about changing my timezone, this 1 hour too late stays. also ntpdate did not help, the time was changed about 3 seconds. Im Using RedHat Linux 7.3 min.-Installation I compiled Apache 1.3.27 with PHP 4.3.2 as static module. My PHP-./configure: ./configure --with-apache=../apache_1.3.27 --with-mysql --with-gd --with-jpeg-dir=/usr --with-png-dir=/usr --with-ttf --with-zlib --enable-gd-native-ttf --enable-trans-sid --disable-cgi --enable-ftp I'm using PHP-Accelerator. I have asked a lot of people and searched for people with similar problems, but I did not find any. So my last Idea is that it's a PHP-Bug. Reproduce code: --- Expected result: date: +-0 hours gmdate -1 hour Actual result: -- date: -1 hour gmdate -2 hours -- Edit this bug report at http://bugs.php.net/?id=24603&edit=1
#24603 [NEW]: all timefunctions don't give back correct time
From: akorthaus at web dot de Operating system: RedHat-Linux 7.3, kernel 2.4.20 PHP version: 4.3.2 PHP Bug Type: Date/time related Bug description: all timefunctions don't give back correct time Description: Hi! Now I'm trying to solve this problem for more then 10 houres, nad nobody seems to know what is going wrong here. If I try this: That displays: 12:36:36 11:36:36 What I would expect would be the same like date in shell: # date Fri Jul 11 13:37:39 CEST 2003 the correspondent Apache access-log: [11/Jul/2003:12:36:36 +0100] # /sbin/hwclock returns Fri 11 Jul 2003 13:36:42 PM CEST 0.707042 seconds and it could not be set by # /sbin/hwclock --systohc --utc but I think thats not important # ls -l /etc/localtime lrwxrwxrwx1 root root 33 Jul 11 09:33 /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin which is what I want(my timezone). It's GMT + 1. PHP _has_ these difference of one hour between time() and gmtime(), but both are an extra hour too late. I also restartet Apache, I tried to change /etc/sysconfig/clock, which is now: # cat /etc/sysconfig/clock ZONE="Europe/Berlin" UTC=true ARC=false But PHP did not take care about changes in it, PHP also did not care about changing my timezone, this 1 hour too late stays. also ntpdate did not help, the time was changed about 3 seconds. Im Using RedHat Linux 7.3 min.-Installation I compiled Apache 1.3.27 with PHP 4.3.2 as static module. My PHP-./configure: ./configure --with-apache=../apache_1.3.27 --with-mysql --with-gd --with-jpeg-dir=/usr --with-png-dir=/usr --with-ttf --with-zlib --enable-gd-native-ttf --enable-trans-sid --disable-cgi --enable-ftp I'm using PHP-Accelerator. I have asked a lot of people and searched for people with similar problems, but I did not find any. So my last Idea is that it's a PHP-Bug. Reproduce code: --- Expected result: date: +-0 hours gmdate -1 hour Actual result: -- date: -1 hour gmdate -2 hours -- Edit bug report at http://bugs.php.net/?id=24603&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24603&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24603&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24603&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24603&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24603&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24603&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24603&r=support Expected behavior: http://bugs.php.net/fix.php?id=24603&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24603&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24603&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24603&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24603&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24603&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24603&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24603&r=gnused
