Re: [PHP-DEV] 5.2.4RC1 Released
On 04.08.2007 10:42, Lester Caine wrote: I'm not saying that you do nothing, but I'm not sure that complaining about the bad state of pdo_firebird is really helpful. See the other post. I am not 'complaining' about the fact that no one is willing to spend unpaid time on pdo_firebird, just trying to explain WHY. If the Firebird Foundation had the deep pockets of IBM, Oracle, MySQL etc. then we would actually PAY someone to do it, but for now it has to have a reason to be worked on and no one has a reason :( It's not about money in the first place. I started maintaining OCI8 because _I_ was using it quite hard, so I was interested in OCI8 to be stable and feature-rich to make my own life easier. For some reason I expect people to do the same when they really need something, at the very least I expect people to understand that silently waiting (or loudly complaining in their blogs, that's the same) for a good guy that should come and do everything for them is not very productive. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Christopher Jones wrote: Lester Caine wrote: I keep being told that the PDO drivers can be extended to include all of the things already available in the native driver, but the second you do that they become incompatible, so in addition to the PDO driver you need to also run the native driver simply to provide the areas NOT covered by PDO. We need a generic framework that addresses the real problems not one that creates an artificial lowest common denominator strangle hold :( PDO could evolve into that, but not with it's current restrictions. Can you list the current restrictions as you see them? Actually the very first one has been addressed and has nothing to do with PDO. Up until recently is was essential to provide backwards compatibility with PHP4 and all of the projects I currently work with WOULD still install on PHP4. Although *I* never used it in production, the continued support meant that there was a large base that insisted on retaining it. So ADOdb's continued underlying support for PHP4 is useful and until there are a higher percentage of PHP5 users than PHP4 - PDO takes second place as it is not available on a large number of hosts? The next problem builds on the above one. From the PDO manual PDO does not provide a database abstraction; it doesn't rewrite SQL or emulate missing features. You should use a full-blown abstraction layer if you need that facility. ADOdb will run PDO drivers quite happily, but on current information the performance of the PDO drivers is slower than using the same native driver. So given a choice the native one is preferable and currently essential for PHP4 support. NEITHER of the above are restricted to Firebird and apply equally to all databases, but they are the main reason to date that no one has had the inclination to fix the pdo_firebird driver as it's deployment potential is currently limited. The internals of PDO restrict things to using SQL access to the database. While it will probably be said that the database should ONLY provide SQL access to everything, Firebird has a services interface which is used for such things as backup, user management, and the event handler. How should all those be handled if they are moved to the PDO driver? PDO provides a basic transaction control that hides the transaction modes. It can't handle retaining the context of the transaction following a commit or roll back, or selection a more appropriate transaction mode? CONCURRENCY for reports at a fixed time point over COMMITTED to handle changes made in other transactions. How does one switch between a 'wait' and 'nowait' transaction? The one that prompted this discussion. How do you return a simple handle to a BLOB object so that you DON'T have to download the whole blob. It can be useful to hold the blob id so that you only access a sub set of the data from the blob object. This seems to be missing in PDO? HAVING to maintain PHP4 support has meant that I have not gone into PDO with a fine tooth comb, and most of my understanding of the problems of PDO is based on what has been said elsewhere, but at present I can't see how some of these fundamental facilities provided by the php_interbase driver would be mirrored in PDO. I stand to be corrected, and perhaps when PHP4 has died THEN the supposed advantage of PDO may be a more attractive development path? But at present there is simply no incentive to move over :( -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Pierre wrote: And what do you suggest to improve this situation? One of my suggestions is to have more DB developers (as in DB internals, if I can say so :) involved. Oracle and IBM (to name the largest and most active) understood that and actively participate. And IBM have a commercial interest in making it easy for them to sell licenses, so they support EVERY well used development platform ;) Since a large percentage of their server users were probably running free copies of PHP anyway, they saw a support revenue stream? I'm not saying that you do nothing, but I'm not sure that complaining about the bad state of pdo_firebird is really helpful. See the other post. I am not 'complaining' about the fact that no one is willing to spend unpaid time on pdo_firebird, just trying to explain WHY. If the Firebird Foundation had the deep pockets of IBM, Oracle, MySQL etc. then we would actually PAY someone to do it, but for now it has to have a reason to be worked on and no one has a reason :( THAT is why the damage to the php_interbase driver was such a problem! -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Hi Lester, On 8/4/07, Lester Caine [EMAIL PROTECTED] wrote: Pierre wrote: And what do you suggest to improve this situation? One of my suggestions is to have more DB developers (as in DB internals, if I can say so :) involved. Oracle and IBM (to name the largest and most active) understood that and actively participate. And IBM have a commercial interest in making it easy for them to sell licenses, so they support EVERY well used development platform ;) Since a large percentage of their server users were probably running free copies of PHP anyway, they saw a support revenue stream? Not only that, they also saw customers (no fact to confirm that but that's obvious) moving away to other DBs because PHP support (naitve, community, etc.) is better. I'm not saying that you do nothing, but I'm not sure that complaining about the bad state of pdo_firebird is really helpful. See the other post. I am not 'complaining' about the fact that no one is willing to spend unpaid time on pdo_firebird, just trying to explain WHY. If the Firebird Foundation had the deep pockets of IBM, Oracle, MySQL etc. then we would actually PAY someone to do it, but for now it has to have a reason to be worked on and no one has a reason :( THAT is why the damage to the php_interbase driver was such a problem! I understood that but that does not make pdo support less critical for firebird's future with PHP. And that's why I disagree with no reason to improve it. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
Configuring on Solaris (2.10) no longer works, ist the old problem with test that is more strict on solaris: ... checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no Generating files ./configure: test: argument expected [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ config.log does not show anything special: ... configure:113510: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -fPIC -DPIC conftest.cpp 15 configure:113514: $? = 0 configure:113552: checking if c++ supports -c -o file.o configure:113572: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -o out/conftest2.o conftest.cpp 15 configure:113576: $? = 0 configure:113623: checking whether the c++ linker (/usr/ccs/bin/ld) supports shared libraries configure:113709: checking dynamic linker characteristics configure:114283: checking how to hardcode library paths into programs configure:114321: checking whether stripping libraries is possible Uwe - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 1:37 AM To: PHP Internals Subject: [PHP-DEV] 5.2.4RC1 Released As promised two weeks ago, the 5.2.4RC1 was released today and the sources for the release can be found here: http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2 (md5sum: 43e28d2aa55b6c8bcd67da16e24b225a) Windows binaries should become available in short order as well. This release have been long in the making so the changelog is a bit intimidating, so we definitely need a lot of testing for this release. I would like to ask everyone to give this RC a shot and see how it behaves with their code and hopefully not find any regressions. If you do find any, please let us know. Now that RC1 is out, I would like to ask all developers to refrain from making any feature additions to 5.2.4 at this time and only apply bug fixes. I am hoping to have RC2 released within 2 weeks from now and if it proves to be stable move onto the final release a week from then. So, if all goes well we should have 5.2.4 out within a month or less. One exception to the rule I'd like to make known is Stas' ini system patch, which I feel we should include, but that's still being currently discussed. Aside from those, no feature additions, please. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Ilia Alshanetsky wrote: As promised two weeks ago, the 5.2.4RC1 was released today Ilia please can you make sure that the bug http://bugs.php.net/bug.php?id=41429 is at least rolled back to the 5.2.1 state for 5.2.4 - as it currently stands it is causing problems. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
Hello again, got it configured on Solaris with bash configure The following two things are problematic: 1) @-operator before function names does not suppress warning messages anymore? Whats wrong? I got for example messages like cannot open file... even when it was opened with @fopen(...). 2) make test is broken: [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ gmake test Build complete. Don't forget to run 'make test'. /bin/sh: syntax error at line 1: `;' unexpected gmake: [test] Error 2 (ignored) - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 1:37 AM To: PHP Internals Subject: [PHP-DEV] 5.2.4RC1 Released As promised two weeks ago, the 5.2.4RC1 was released today and the sources for the release can be found here: http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2 (md5sum: 43e28d2aa55b6c8bcd67da16e24b225a) Windows binaries should become available in short order as well. This release have been long in the making so the changelog is a bit intimidating, so we definitely need a lot of testing for this release. I would like to ask everyone to give this RC a shot and see how it behaves with their code and hopefully not find any regressions. If you do find any, please let us know. Now that RC1 is out, I would like to ask all developers to refrain from making any feature additions to 5.2.4 at this time and only apply bug fixes. I am hoping to have RC2 released within 2 weeks from now and if it proves to be stable move onto the final release a week from then. So, if all goes well we should have 5.2.4 out within a month or less. One exception to the rule I'd like to make known is Stas' ini system patch, which I feel we should include, but that's still being currently discussed. Aside from those, no feature additions, please. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 11:48, Lester Caine wrote: Ilia Alshanetsky wrote: As promised two weeks ago, the 5.2.4RC1 was released today Ilia please can you make sure that the bug http://bugs.php.net/bug.php?id=41429 is at least rolled back to the 5.2.1 state for 5.2.4 - as it currently stands it is causing problems. Lester, why don't you just try and fix it? Blindly reverting something is no fix, those changes were done for a good reason, even though Marcus didn't test them very good (but that's what RCs are for, isn't it?). I can even tell you which lines were changed since 5_1: http://cvs.php.net/viewvc.cgi/php-src/ext/interbase/ibase_blobs.c?r1=1.13r2=1.9.2.2 -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
Cannot reproduce this, configure went just fine on Solaris. Can you please see on which line in configure script it complains? How can I find that out? Is there a debug parameter? Config.log does not show anything. Could it be that on your solaris system the default shell in /bin/sh is bash? It's definitely not bash (cause I have to run bash manually to get a usable shell). # ls -l /bin/sh -r-xr-xr-x 4 root root 95320 Jul 30 2004 /bin/sh [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ ls -l /bin/sh lrwxrwxrwx 1 root root 13 Apr 13 10:40 /bin/sh - ../../sbin/sh [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ ls -l /sbin/sh -r-xr-xr-x 1 root root 82468 Oct 18 2006 /sbin/sh Until now, I have no error location. I think I will look into the changes in configure.in and look for test calls and try to modify them. Starting configure with sh -v did not work it only prints a few messages at beginning but then switches to another shell (???). The problem is fixed if you start configure with bash configure. But it would be good to fix this. You are right with CLI it works. But there seems to be a problem with INI parsing. The web application that produced this error was started with an overwritten error_reporting value running in Sun Java System Webserver which worked correctly with 5.2.3: Service fn=php5_execute type=magnus-internal/x-httpd-php error_reporting=2039 allow_url_include=1 This works just fine either: ./sapi/cli/php -d error_reporting=2039 -r 'error_reporting(2039); @fopen(, r); No idea how the sun webserver passes options to PHP, though. I looked into it: The problem seems to be ZTS specific. What we have: * First, the value looks correct in phpinfo(). * Second setting the value to 6039 (which is the default from php.ini) produces now a lot of _more_ and very strange error messages when running PHP scripts. It seems that the webserver puts the value somewhere to a global place because after that *ALL* PHP scripts print very strange things (even those where this value is not explicitely set). Could it be that there happened a ZTS regression when updating the ini scanner? In 5.2.3 it worked correctly. I think I write now a bug report and paste this mail conversation into it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 14:07, Uwe Schindler wrote: Until now, I have no error location. I think I will look into the changes in configure.in and look for test calls and try to modify them. Thanks. Starting configure with sh -v did not work it only prints a few messages at beginning but then switches to another shell (???). The problem is fixed if you start configure with bash configure. But it would be good to fix this. Yes, I've already CCed Jani, who's responsible for this part. I looked into it: The problem seems to be ZTS specific. What we have: * First, the value looks correct in phpinfo(). * Second setting the value to 6039 (which is the default from php.ini) produces now a lot of _more_ and very strange error messages when running PHP scripts. It seems that the webserver puts the value somewhere to a global place because after that *ALL* PHP scripts print very strange things (even those where this value is not explicitely set). How EXACTLY does the web-server put the value? To me it looks like you're using some global config file, so no wonder it's put globally. Could it be that there happened a ZTS regression when updating the ini scanner? In 5.2.3 it worked correctly. I don't know what exactly is the problem and how to reproduce it, so it makes little sense to ask _me_ about it. Do you have a short reproduce case that doesn't require Solaris, Sun Web server and other stuff we don't have? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
On Fri, 2007-08-03 at 08:32 +0200, Uwe Schindler wrote: Generating files /configure: test: argument expected [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ It might be the configure options macro I added..but I can't see why any 'test' calls in it wouldn't work? Anyways, to get more output from configure you can change the hashbang line in it to: #! /bin/sh -x And then run configure something like this: # ./configure 2 err Then 'err' will contain the debug output.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 14:48, Uwe Schindler wrote: How EXACTLY does the web-server put the value? To me it looks like you're using some global config file, so no wonder it's put globally. It is not global. The overwritten value is set only for a specific path (you can be sure that I know how Sun Webserver works, I maintain the NSAPI module... :-) ). The changed value then corrupts the ini entry complete. I found out why this is so, so this is a _bug_. The following patch, when reverted fixes it and restores the old behaviour: http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_ini.c?r1=1.39.2.2.2.8r2=1.39 .2.2.2.9pathrev=PHP_5_2 It's done to prevent overwriting settings set in httpd.conf (aka php_admin_value's). I do not know why, but it seems that this request specific code tries to overwrite the definition of the ini entry and corrupts it in a ZTS environment. After that every request this webserver handles (even when not affected by a overwritten value produces nice error messages. I don't know what exactly is the problem and how to reproduce it, so it makes little sense to ask _me_ about it. Do you have a short reproduce case that doesn't require Solaris, Sun Web server and other stuff we don't have? Take Apache on Windows... :) Do you mean you were able to reproduce it with Apache on Windows? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 15:48, Scott MacVicar wrote: Edin, Can you upgrade the bundled MySQL libraries so we can get #41350 fixed, the code is already there it just needs the latest libraries on Windows. We also need the latest t1lib and libtidy on Windows. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Antony Dovgal wrote: On 03.08.2007 14:12, Lester Caine wrote: Blindly reverting something is no fix, those changes were done for a good reason, even though Marcus didn't test them very good (but that's what RCs are for, isn't it?). Obviously they were not tested at all? I don't know of any people using Interbase except for you and Ard (who maintains all interbase extensions). So even if somebody did run the tests against an RC, he/she didn't tell a word to us. The main reason this problem has now become a problem is a number of long time PHP4 users who have been convinced to move to PHP5 - only to fall at the first hurdle :( Currently the php_interbase driver is almost unusable in PHP5.2 as shipped, but the 5.2.1 copy works fine. Try the very next snapshot, I applied a patch after a discussion with Marcus. Once it pops out as a windows build ;) -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 17:29, Uwe Schindler wrote: I reopened the original bug reported that lead to your change. At the moment I am trying to fix that. I moved your code a few lines down in zend_alter_ini_entry but until now with no success. No, that won't work I guess. At the moment I can only think of a special hashtable storing all the values that were set during the INI_SYSTEM stage, so that users could not override them in their scripts. I suppose there is something special with error reporting that corrupts it. That special thing is in your config file =) It seems that it does not like it to be changed to ZEND_INI_SYSTEM because the @operator tries to change the value (e.g. in zend_vm_execute.h), which fails silently: This's a special case and it's really great you noticed it in RC.. We need a workaround for this special case, as if we make all INI directives set using php_admin_value non-changeable, we break the @ thing. So we either need to change the @ not to use zend_alter_ini_entry, or make an exception in that function, which I believe would be a hack. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
Hallo Jani, thanks, the configure error is gone! gmake test still fails with /bin/sh: syntax error at line 1: `;' unexpected - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany From: Jani Taskinen [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 12:48 PM To: Uwe Schindler Subject: RE: [PHP-DEV] 5.2.4RC1 Released I changed one added 'test' line in acinclude.m4 and committed it..so try the latest PHP_5_2 checkout. --Jani On Fri, 2007-08-03 at 08:32 +0200, Uwe Schindler wrote: Configuring on Solaris (2.10) no longer works, ist the old problem with test that is more strict on solaris: .. checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no Generating files /configure: test: argument expected [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ config.log does not show anything special: .. configure:113510: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -fPIC -DPIC conftest.cpp 15 configure:113514: $? = 0 configure:113552: checking if c++ supports -c -o file.o configure:113572: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -o out/conftest2.o conftest.cpp 15 configure:113576: $? = 0 configure:113623: checking whether the c++ linker (/usr/ccs/bin/ld) supports shared libraries configure:113709: checking dynamic linker characteristics configure:114283: checking how to hardcode library paths into programs configure:114321: checking whether stripping libraries is possible Uwe - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 1:37 AM To: PHP Internals Subject: [PHP-DEV] 5.2.4RC1 Released As promised two weeks ago, the 5.2.4RC1 was released today and the sources for the release can be found here: http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2 (md5sum: 43e28d2aa55b6c8bcd67da16e24b225a) Windows binaries should become available in short order as well. This release have been long in the making so the changelog is a bit intimidating, so we definitely need a lot of testing for this release. I would like to ask everyone to give this RC a shot and see how it behaves with their code and hopefully not find any regressions. If you do find any, please let us know. Now that RC1 is out, I would like to ask all developers to refrain from making any feature additions to 5.2.4 at this time and only apply bug fixes. I am hoping to have RC2 released within 2 weeks from now and if it proves to be stable move onto the final release a week from then. So, if all goes well we should have 5.2.4 out within a month or less. One exception to the rule I'd like to make known is Stas' ini system patch, which I feel we should include, but that's still being currently discussed. Aside from those, no feature additions, please. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 14:48, Uwe Schindler wrote:
How EXACTLY does the web-server put the value?
To me it looks like you're using some global config file, so no wonder
it's put globally.
It is not global. The overwritten value is set only for a specific path
(you
can be sure that I know how Sun Webserver works, I maintain the NSAPI
module... :-) ).
The changed value then corrupts the ini entry complete. I found out why
this
is so, so this is a _bug_.
The following patch, when reverted fixes it and restores the old
behaviour:
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_ini.c?r1=1.39.2.2.2.8r2=1.
39
.2.2.2.9pathrev=PHP_5_2
It's done to prevent overwriting settings set in httpd.conf (aka
php_admin_value's).
I know how this is meant. But without the added patch, it does not corrupt
error_reporting. The problem is that your patch is not compatible to a
webserver that runs more than one request per process (a multithreaded one),
because it modifies the ini setting in a way that affects later running
threads.
I try to find a way to reproduce it in other webservers.
This is the code that NSAPI uses to modify the INI entries:
entry-param-name is the nullterminated ini key name, entry-param-value
is the nullteminated value. This code runs on every request (like in apache
a php_(admin)_value) that needs to set some specific ini-values. The server
runs only *one* process that handles all requests in its lifetime because it
is multithreaded:
if (zend_alter_ini_entry(entry-param-name, strlen(entry-param-name)+1,
entry-param-value, strlen(entry-param-value),
PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE)==FAILURE) {
log_error(LOG_WARN, pblock_findval(fn, NSG(pb)), NSG(sn), NSG(rq),
Cannot change php.ini key \%s\ to \%s\, entry-param-name,
entry-param-value);
}
. It is always runned with admin privileges because SJSWS does not have
htaccess files. The big advantage to have the possibility to set ini values
is, that it is not server-wide you can change the call to PHP SAPI e.g. per
virtual server or URI path (see documentation of NSAPI).
Uwe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Edin, Can you upgrade the bundled MySQL libraries so we can get #41350 fixed, the code is already there it just needs the latest libraries on Windows. Scott Edin Kadribasic wrote: The windows build is now ready and can be downloded from: http://downloads.php.net/edink/php-5.2.4RC1-Win32.zip http://downloads.php.net/edink/php-5.2.4RC1-win32-installer.msi http://downloads.php.net/edink/pecl-5.2.4RC1-Win32.zip http://downloads.php.net/edink/php-debug-pack-5.2.4RC1-Win32.zip Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 17:50, Lester Caine wrote: Obviously they were not tested at all? I don't know of any people using Interbase except for you and Ard (who maintains all interbase extensions). So even if somebody did run the tests against an RC, he/she didn't tell a word to us. The main reason this problem has now become a problem is a number of long time PHP4 users who have been convinced to move to PHP5 - only to fall at the first hurdle :( It's good to hear that PHP4 users finally decided to move to PHP5. Currently the php_interbase driver is almost unusable in PHP5.2 as shipped, but the 5.2.1 copy works fine. Try the very next snapshot, I applied a patch after a discussion with Marcus. Once it pops out as a windows build ;) It should be already there, please check it out. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
This's a special case and it's really great you noticed it in RC.. We need a workaround for this special case, as if we make all INI directives set using php_admin_value non-changeable, we break the @ thing. So we either need to change the @ not to use zend_alter_ini_entry, or make an exception in that function, which I believe would be a hack. Thats correct. An idea would be to make the @ operator only change EG(error_reporting) without changing the whole ini-entry by alter_ini_entry (which is a big slowdown...). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 8/3/07, Antony Dovgal [EMAIL PROTECTED] wrote: On 03.08.2007 14:12, Lester Caine wrote: Blindly reverting something is no fix, those changes were done for a good reason, even though Marcus didn't test them very good (but that's what RCs are for, isn't it?). Obviously they were not tested at all? Each PHP releases have RCs. Maybe this extension needs more tests (written in php) so one (for example you :) can quickly run the tests using a given RC or release. Currently the php_interbase driver is almost unusable in PHP5.2 as shipped, but the 5.2.1 copy works fine. Try the very next snapshot, I applied a patch after a discussion with Marcus. Meaning not the Aug 03, 2007 08:30 UTC snap but the next one :) --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
One down, one to go.. :) --Jani On Fri, 2007-08-03 at 14:42 +0200, Uwe Schindler wrote: Hallo Jani, thanks, the configure error is gone! gmake test still fails with /bin/sh: syntax error at line 1: `;' unexpected - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany From: Jani Taskinen [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 12:48 PM To: Uwe Schindler Subject: RE: [PHP-DEV] 5.2.4RC1 Released I changed one added 'test' line in acinclude.m4 and committed it..so try the latest PHP_5_2 checkout. --Jani On Fri, 2007-08-03 at 08:32 +0200, Uwe Schindler wrote: Configuring on Solaris (2.10) no longer works, ist the old problem with test that is more strict on solaris: .. checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no Generating files /configure: test: argument expected [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ config.log does not show anything special: .. configure:113510: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -fPIC -DPIC conftest.cpp 15 configure:113514: $? = 0 configure:113552: checking if c++ supports -c -o file.o configure:113572: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -o out/conftest2.o conftest.cpp 15 configure:113576: $? = 0 configure:113623: checking whether the c++ linker (/usr/ccs/bin/ld) supports shared libraries configure:113709: checking dynamic linker characteristics configure:114283: checking how to hardcode library paths into programs configure:114321: checking whether stripping libraries is possible Uwe - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 1:37 AM To: PHP Internals Subject: [PHP-DEV] 5.2.4RC1 Released As promised two weeks ago, the 5.2.4RC1 was released today and the sources for the release can be found here: http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2 (md5sum: 43e28d2aa55b6c8bcd67da16e24b225a) Windows binaries should become available in short order as well. This release have been long in the making so the changelog is a bit intimidating, so we definitely need a lot of testing for this release. I would like to ask everyone to give this RC a shot and see how it behaves with their code and hopefully not find any regressions. If you do find any, please let us know. Now that RC1 is out, I would like to ask all developers to refrain from making any feature additions to 5.2.4 at this time and only apply bug fixes. I am hoping to have RC2 released within 2 weeks from now and if it proves to be stable move onto the final release a week from then. So, if all goes well we should have 5.2.4 out within a month or less. One exception to the rule I'd like to make known is Stas' ini system patch, which I feel we should include, but that's still being currently discussed. Aside from those, no feature additions, please. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
This's a special case and it's really great you noticed it in RC.. We need a workaround for this special case, as if we make all INI directives set using php_admin_value non-changeable, we break the @ thing. So we either need to change the @ not to use zend_alter_ini_entry, or make an exception in that function, which I believe would be a hack. Thats correct. An idea would be to make the @ operator only change EG(error_reporting) without changing the whole ini-entry by alter_ini_entry (which is a big slowdown...). The problem with that fix that a crash would potentially leave the error blocking on, and INI clean up will not reset it. The problem with the original fix of antony was the same: The first time any thread started to modify any INI entry it was marked as admin-only for the whole PHP server until a restart and it stayed in that state because the flag was changed *before* the hash table was replicated. This is a second bug. So at least the lines of antony must moved a few lines down in code... I attached a patch. This patch must be applied in all cases. A second thing is to remove breakage of the @ operator. Oh I forgot, this does not help, too. Because the ADMIN-only status given by antonys patch (change of ini_entry-modifiable) is not rolled back after request shutdown. For the Apache-Not-Multithreaded people a description of the problem: An Apache server administrator has 2 virtual servers: * One with the original php.ini configuration and no php_admin_values. * One with a modified value that is set by php_admin_value. The setting is overwritten on the first request of the second virtual server. This is ok, because the value is restored after the request finishes. But the problem is that Antonys patch marked the flag as admin only, which is not reverted at end of request. The first virtual server without the php_admin_value will also have the ini-setting marked as ADMIN only until end of time :( Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 3-Aug-07, at 9:51 AM, Uwe Schindler wrote: This's a special case and it's really great you noticed it in RC.. We need a workaround for this special case, as if we make all INI directives set using php_admin_value non-changeable, we break the @ thing. So we either need to change the @ not to use zend_alter_ini_entry, or make an exception in that function, which I believe would be a hack. Thats correct. An idea would be to make the @ operator only change EG(error_reporting) without changing the whole ini-entry by alter_ini_entry (which is a big slowdown...). The problem with that fix that a crash would potentially leave the error blocking on, and INI clean up will not reset it. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
On 3-Aug-07, at 9:51 AM, Uwe Schindler wrote:
This's a special case and it's really great you noticed it in RC..
We need a workaround for this special case, as if we make all INI
directives set
using php_admin_value non-changeable, we break the @ thing.
So we either need to change the @ not to use zend_alter_ini_entry,
or make
an
exception in that function, which I believe would be a hack.
Thats correct. An idea would be to make the @ operator only change
EG(error_reporting) without changing the whole ini-entry by
alter_ini_entry
(which is a big slowdown...).
The problem with that fix that a crash would potentially leave the
error blocking on, and INI clean up will not reset it.
The problem with the original fix of antony was the same: The first time
any
thread started to modify any INI entry it was marked as admin-only for
the
whole PHP server until a restart and it stayed in that state because the
flag was changed *before* the hash table was replicated. This is a second
bug. So at least the lines of antony must moved a few lines down in
code...
I attached a patch. This patch must be applied in all cases. A second thing
is to remove breakage of the @ operator.
Uwe
Index: zend_ini.c
===
RCS file: /repository/ZendEngine2/zend_ini.c,v
retrieving revision 1.39.2.2.2.10
diff -u -r1.39.2.2.2.10 zend_ini.c
--- zend_ini.c 17 Jun 2007 14:31:12 - 1.39.2.2.2.10
+++ zend_ini.c 3 Aug 2007 14:46:30 -
@@ -243,10 +243,6 @@
return FAILURE;
}
- if (stage == ZEND_INI_STAGE_ACTIVATE modify_type == ZEND_INI_SYSTEM)
{
- ini_entry-modifiable = ZEND_INI_SYSTEM;
- }
-
if (!(ini_entry-modifiable modify_type)) {
return FAILURE;
}
@@ -264,6 +260,10 @@
zend_hash_add(EG(modified_ini_directives), name, name_length,
ini_entry, sizeof(zend_ini_entry*), NULL);
}
+ if (stage == ZEND_INI_STAGE_ACTIVATE modify_type == ZEND_INI_SYSTEM)
{
+ ini_entry-modifiable = ZEND_INI_SYSTEM;
+ }
+
duplicate = estrndup(new_value, new_value_length);
if (!ini_entry-on_modify
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
I reopened the original bug reported that lead to your change.
At the moment I am trying to fix that. I moved your code a few lines down in
zend_alter_ini_entry but until now with no success.
I suppose there is something special with error reporting that corrupts it.
It seems that it does not like it to be changed to ZEND_INI_SYSTEM because
the @operator tries to change the value (e.g. in zend_vm_execute.h), which
fails silently:
static int ZEND_BEGIN_SILENCE_SPEC_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
zend_op *opline = EX(opline);
Z_LVAL(EX_T(opline-result.u.var).tmp_var) = EG(error_reporting);
Z_TYPE(EX_T(opline-result.u.var).tmp_var) = IS_LONG; /* shouldn't
be necessary */
if (EX(old_error_reporting) == NULL) {
EX(old_error_reporting) =
EX_T(opline-result.u.var).tmp_var;
}
if (EG(error_reporting)) {
zend_alter_ini_entry(error_reporting,
sizeof(error_reporting), 0, 1, ZEND_INI_USER, ZEND_INI_STAGE_RUNTIME);
}
ZEND_VM_NEXT_OPCODE();
}
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-Original Message-
From: Antony Dovgal [mailto:[EMAIL PROTECTED]
Sent: Friday, August 03, 2007 3:15 PM
To: Uwe Schindler
Cc: 'Ilia Alshanetsky'; 'PHP Internals'
Subject: Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 16:04, Uwe Schindler wrote:
I know how this is meant. But without the added patch, it does not
corrupt
error_reporting. The problem is that your patch is not compatible to a
webserver that runs more than one request per process (a multithreaded
one),
because it modifies the ini setting in a way that affects later running
threads.
Ok, I see.
Please fill a bug report and assign it to me, I'll deal with it.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Antony Dovgal wrote: On 03.08.2007 11:48, Lester Caine wrote: Ilia Alshanetsky wrote: As promised two weeks ago, the 5.2.4RC1 was released today Ilia please can you make sure that the bug http://bugs.php.net/bug.php?id=41429 is at least rolled back to the 5.2.1 state for 5.2.4 - as it currently stands it is causing problems. Lester, why don't you just try and fix it? Not yet been able to BUILD my own copy of PHP on windows and I don't have time as I am still TESTING 5.2.3!!! Blindly reverting something is no fix, those changes were done for a good reason, even though Marcus didn't test them very good (but that's what RCs are for, isn't it?). Obviously they were not tested at all? There may be some subtle reason why this has been changed and OUR current fix is to load a copy of the 5.2.1 version which fixes the bug - so until someone explains why it was changed then reverting works fine. I had to give up switching to 5.2 as I did not have the time to fix all the problems that it was throwing up. 5.1.6 has been running fine in production! I created some time to work through all the problems and I now have a working 5.2.3 installation - with some hacks to get round this bug, and now I need to spend time with 5.2.4RC1 WHEN the windows build is up. I can even tell you which lines were changed since 5_1: http://cvs.php.net/viewvc.cgi/php-src/ext/interbase/ibase_blobs.c?r1=1.13r2=1.9.2.2 Then it should be possible for someone who HAS commit rights to actually make it work? Currently the php_interbase driver is almost unusable in PHP5.2 as shipped, but the 5.2.1 copy works fine. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 14:12, Lester Caine wrote: Blindly reverting something is no fix, those changes were done for a good reason, even though Marcus didn't test them very good (but that's what RCs are for, isn't it?). Obviously they were not tested at all? I don't know of any people using Interbase except for you and Ard (who maintains all interbase extensions). So even if somebody did run the tests against an RC, he/she didn't tell a word to us. There may be some subtle reason why this has been changed and OUR current fix is to load a copy of the 5.2.1 version which fixes the bug - so until someone explains why it was changed then reverting works fine. I had to give up switching to 5.2 as I did not have the time to fix all the problems that it was throwing up. What kind of problems? Then it should be possible for someone who HAS commit rights to actually make it work? Yes, if only this somebody has Windows build env, Interbase and will to help us. Unfortunately we don't have such people in PHP community. Edin and Pierre are two people doing windows builds, but none of them use Interbase as far as I know. I must also note that you don't have to have commit rights to cook a patch and send it to the list. Currently the php_interbase driver is almost unusable in PHP5.2 as shipped, but the 5.2.1 copy works fine. Try the very next snapshot, I applied a patch after a discussion with Marcus. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 10:32, Uwe Schindler wrote: Configuring on Solaris (2.10) no longer works, ist the old problem with test that is more strict on solaris: ... checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no Generating files ./configure: test: argument expected [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ Cannot reproduce this, configure went just fine on Solaris. Can you please see on which line in configure script it complains? The following two things are problematic: 1) @-operator before function names does not suppress warning messages anymore? Whats wrong? I got for example messages like cannot open file... even when it was opened with @fopen(...). Not reproducible either. ./sapi/cli/php -r 'fopen(a, r);' Warning: fopen(a): failed to open stream: No such file or directory in Command line code on line 1 ./sapi/cli/php -r '@fopen(a, r);' silence 2) make test is broken: [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ gmake test Build complete. Don't forget to run 'make test'. /bin/sh: syntax error at line 1: `;' unexpected gmake: [test] Error 2 (ignored) Confirmed, Jani's configure.in tweaks do not work with broken shell on Solaris. Jani, please take a look at it, it complains each time I try to use $(PHP_TEST_SHARED_EXTENSIONS). -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 10:32, Uwe Schindler wrote:
Configuring on Solaris (2.10) no longer works, ist the old problem with
test that is more strict on solaris:
...
checking dynamic linker characteristics... solaris2.10 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
Generating files
./configure: test: argument expected
[EMAIL PROTECTED]:~/install/php-5.2.4RC1$
Cannot reproduce this, configure went just fine on Solaris.
Can you please see on which line in configure script it complains?
How can I find that out? Is there a debug parameter? Config.log does not
show anything.
Could it be that on your solaris system the default shell in /bin/sh is
bash?
The following two things are problematic:
1) @-operator before function names does not suppress warning messages
anymore? Whats wrong?
I got for example messages like cannot open file... even when it was
opened with @fopen(...).
Not reproducible either.
./sapi/cli/php -r 'fopen(a, r);'
Warning: fopen(a): failed to open stream: No such file or directory in
Command line code on line 1
./sapi/cli/php -r '@fopen(a, r);'
silence
You are right with CLI it works. But there seems to be a problem with INI
parsing. The web application that produced this error was started with an
overwritten error_reporting value running in Sun Java System Webserver
which worked correctly with 5.2.3:
Service fn=php5_execute type=magnus-internal/x-httpd-php
error_reporting=2039 allow_url_include=1
Removing the error_reporting fixed the problem. Was there a change somewhere
that error_reporting with 2039 set by...
if (zend_alter_ini_entry(entry-param-name, strlen(entry-param-name)+1,
entry-param-value, strlen(entry-param-value),
PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE)==FAILURE) {
log_error(LOG_WARN, pblock_findval(fn, NSG(pb)), NSG(sn), NSG(rq),
Cannot change php.ini key \%s\ to \%s\, entry-param-name,
entry-param-value);
}
...may not work? Just for interest, I am sure that this NSAPI option was not
correct because it was a relict from former days.
I removed the wrong error reporting now, but it is interesting that the same
value worked before.
Uwe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 13:10, Uwe Schindler wrote: Cannot reproduce this, configure went just fine on Solaris. Can you please see on which line in configure script it complains? How can I find that out? Is there a debug parameter? Config.log does not show anything. Could it be that on your solaris system the default shell in /bin/sh is bash? It's definitely not bash (cause I have to run bash manually to get a usable shell). # ls -l /bin/sh -r-xr-xr-x 4 root root 95320 Jul 30 2004 /bin/sh You are right with CLI it works. But there seems to be a problem with INI parsing. The web application that produced this error was started with an overwritten error_reporting value running in Sun Java System Webserver which worked correctly with 5.2.3: Service fn=php5_execute type=magnus-internal/x-httpd-php error_reporting=2039 allow_url_include=1 This works just fine either: ./sapi/cli/php -d error_reporting=2039 -r 'error_reporting(2039); @fopen(, r); No idea how the sun webserver passes options to PHP, though. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
I looked into it: The problem seems to be ZTS specific. What we have: * First, the value looks correct in phpinfo(). * Second setting the value to 6039 (which is the default from php.ini) produces now a lot of _more_ and very strange error messages when running PHP scripts. It seems that the webserver puts the value somewhere to a global place because after that *ALL* PHP scripts print very strange things (even those where this value is not explicitely set). How EXACTLY does the web-server put the value? To me it looks like you're using some global config file, so no wonder it's put globally. It is not global. The overwritten value is set only for a specific path (you can be sure that I know how Sun Webserver works, I maintain the NSAPI module... :-) ). The changed value then corrupts the ini entry complete. I found out why this is so, so this is a _bug_. The following patch, when reverted fixes it and restores the old behaviour: http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_ini.c?r1=1.39.2.2.2.8r2=1.39 .2.2.2.9pathrev=PHP_5_2 I do not know why, but it seems that this request specific code tries to overwrite the definition of the ini entry and corrupts it in a ZTS environment. After that every request this webserver handles (even when not affected by a overwritten value produces nice error messages. Could it be that there happened a ZTS regression when updating the ini scanner? In 5.2.3 it worked correctly. I don't know what exactly is the problem and how to reproduce it, so it makes little sense to ask _me_ about it. Do you have a short reproduce case that doesn't require Solaris, Sun Web server and other stuff we don't have? Take Apache on Windows... :) I doid not want to ask you alone, the mail was to [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
On 3-Aug-07, at 9:51 AM, Uwe Schindler wrote: This's a special case and it's really great you noticed it in RC.. We need a workaround for this special case, as if we make all INI directives set using php_admin_value non-changeable, we break the @ thing. So we either need to change the @ not to use zend_alter_ini_entry, or make an exception in that function, which I believe would be a hack. Thats correct. An idea would be to make the @ operator only change EG(error_reporting) without changing the whole ini-entry by alter_ini_entry (which is a big slowdown...). The problem with that fix that a crash would potentially leave the error blocking on, and INI clean up will not reset it. The problem with the original fix of antony was the same: The first time any thread started to modify any INI entry it was marked as admin-only for the whole PHP server until a restart and it stayed in that state because the flag was changed *before* the hash table was replicated. This is a second bug. So at least the lines of antony must moved a few lines down in code... Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 16:04, Uwe Schindler wrote: I know how this is meant. But without the added patch, it does not corrupt error_reporting. The problem is that your patch is not compatible to a webserver that runs more than one request per process (a multithreaded one), because it modifies the ini setting in a way that affects later running threads. Ok, I see. Please fill a bug report and assign it to me, I'll deal with it. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Antony Dovgal wrote: On 03.08.2007 17:50, Lester Caine wrote: Obviously they were not tested at all? I don't know of any people using Interbase except for you and Ard (who maintains all interbase extensions). So even if somebody did run the tests against an RC, he/she didn't tell a word to us. The main reason this problem has now become a problem is a number of long time PHP4 users who have been convinced to move to PHP5 - only to fall at the first hurdle :( It's good to hear that PHP4 users finally decided to move to PHP5. I still have a couple of problems to investigate, but I'm sure that they are just the differences in the much improved version of php_interbase that is shipped with PHP5. A lot of the good stuff was never ported back :( Currently the php_interbase driver is almost unusable in PHP5.2 as shipped, but the 5.2.1 copy works fine. Try the very next snapshot, I applied a patch after a discussion with Marcus. Once it pops out as a windows build ;) It should be already there, please check it out. OK - Thanks Antony - that is looking fine. I'm happier now to move it to a production machine and see what the results are with a bit of load. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 21:45, Lester Caine wrote: It should be already there, please check it out. OK - Thanks Antony - that is looking fine. I'm happier now to move it to a production machine and see what the results are with a bit of load. Does this mean you've tested it and it works fine now? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Hi, Ilia Alshanetsky wrote: As promised two weeks ago, the 5.2.4RC1 was released today and the sources for the release can be found here: Not sure if it'a bug... a broken script in PHP 5.2.4RC1 halts execution because of memory limit: Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 24 bytes) in /foo/bar.php on line 88 while 5.2.3 was stopping with: Fatal error: Nesting level too deep - recursive dependency? in /foo/bar.php on line 41 Best regards -- Matteo Beccati Openads - http://www.openads.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Antony Dovgal wrote: Blindly reverting something is no fix, those changes were done for a good reason, even though Marcus didn't test them very good (but that's what RCs are for, isn't it?). Obviously they were not tested at all? I don't know of any people using Interbase except for you and Ard (who maintains all interbase extensions). I do (btw, I'm the maintainer of PEAR::MDB2, including the ibase driver), and I know a lot of people using Firebird/Interbase. Unfortunately, since PDO_Firebird is completely broken [1] and Ard isn't active anymore, the only option left is using the current php_interbase extension. So even if somebody did run the tests against an RC, he/she didn't tell a word to us. I left a message on the open bug report. I thought the bug tracker was the best place to confirm such issues... Try the very next snapshot, I applied a patch after a discussion with Marcus. the latest snapshot works for me, many thanks! Best regards, -- Lorenzo Alberton http://pear.php.net/user/quipo [1] http://www.alberton.info/php_pdo_firebird_status.html Quipo Free Internet: sicuro e veloce senza costi di attivazione e senza canone, 2 e-mail da 25 Mb, 150 Mb di spazio web e molto di più! Registrati gratis: http://www.quipo.it -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Antony Dovgal wrote: On 03.08.2007 21:45, Lester Caine wrote: It should be already there, please check it out. OK - Thanks Antony - that is looking fine. I'm happier now to move it to a production machine and see what the results are with a bit of load. Does this mean you've tested it and it works fine now? Yep - all the combinations that are failing on 5.2.3 are working fine on the snapshot, and the debugger is showing '0x000f0123' instead of the incorrect '0x %i' And my site stuff is all working as I expect. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Lorenzo Alberton wrote: Antony Dovgal wrote: Blindly reverting something is no fix, those changes were done for a good reason, even though Marcus didn't test them very good (but that's what RCs are for, isn't it?). Obviously they were not tested at all? I don't know of any people using Interbase except for you and Ard (who maintains all interbase extensions). I do (btw, I'm the maintainer of PEAR::MDB2, including the ibase driver), and I know a lot of people using Firebird/Interbase. Unfortunately, since PDO_Firebird is completely broken [1] and Ard isn't active anymore, the only option left is using the current php_interbase extension. Ard was amongst the list of people who could not see any need to develop a second driver since the php_interbase one IS working fine. It would be nice to build a Firebird version against the modern client, and do away with the need to build a legacy client to allow it to work. That IS in the pipeline, but as yet no-one who uses Firebird/PHP in production has seen any need to spend time on a more limited PDO driver ;) Ard had built a lot of capability into the driver, and has added all the hooks for an fbird port already for a split, which is probably now due given the extensive work Firebird has received in the version 2 builds, and the new service facilities that it would be nice to support directly. But even the existing php_interbase handles FB2.x without a problem. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 23:11, Lester Caine wrote: Antony Dovgal wrote: On 03.08.2007 21:45, Lester Caine wrote: It should be already there, please check it out. OK - Thanks Antony - that is looking fine. I'm happier now to move it to a production machine and see what the results are with a bit of load. Does this mean you've tested it and it works fine now? Yep - all the combinations that are failing on 5.2.3 are working fine on the snapshot, and the debugger is showing '0x000f0123' instead of the incorrect '0x %i' And my site stuff is all working as I expect. Great, thanks for your feedback! -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Hi Lester, On 8/3/07, Lester Caine [EMAIL PROTECTED] wrote: Ard was amongst the list of people who could not see any need to develop a second driver since the php_interbase one IS working fine. It would be nice to build a Firebird version against the modern client, and do away with the need to build a legacy client to allow it to work. That IS in the pipeline, but as yet no-one who uses Firebird/PHP in production has seen any need to spend time on a more limited PDO driver ;) Ard had built a lot of capability into the driver, and has added all the hooks for an fbird port already for a split, which is probably now due given the extensive work Firebird has received in the version 2 builds, and the new service facilities that it would be nice to support directly. But even the existing php_interbase handles FB2.x without a problem. That's nice and I'm sure Ard's work is highly appreciated by the firebird users. But I completely disagree with this strategy (mysql follows it too). In the long run you will simply loose more php market in favour of databases with good PDO support. I'm not saying that PDO is perfect (it is not), but pdo adoptions is growing and to be supported by PDO becomes more and more a must. I would to see more databases developers helping the PDO developers to improve it, to add what they need to write good drivers. It will be all benefits for the PHP users and for the DB developers (if they want more customers/users). /utopia --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Lester Caine wrote: I keep being told that the PDO drivers can be extended to include all of the things already available in the native driver, but the second you do that they become incompatible, so in addition to the PDO driver you need to also run the native driver simply to provide the areas NOT covered by PDO. We need a generic framework that addresses the real problems not one that creates an artificial lowest common denominator strangle hold :( PDO could evolve into that, but not with it's current restrictions. Hi Lester, Can you list the current restrictions as you see them? Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Hi Lester, On 8/3/07, Lester Caine [EMAIL PROTECTED] wrote: Sorry Pierre I have to disagree there. Most flexible projects are built on ADOdb, and while you CAN use PDO as an alternative driver, for the best performance the raw drivers are preferable. I don't see anything to replace the SQL handling that ADOdb provides although the ADOdbLite does work well if you do not want a fully featured interface and can do without some of the more advanced SQL code. Sorry, I was not clear enough. I did not say that PDO is perfect or can replace MDB2 or ADODb, it is not its goal. Being able to build a project for ANY database is nice to have but requires you manage the SQL as well as the data, and if you are not building a generic project then you don't need a generic driver. A common base is already a (very) good start. We obviously need more and it is unclear how far PHP should go (talking about internals only here). I keep being told that the PDO drivers can be extended to include all of the things already available in the native driver, but the second you do that they become incompatible, so in addition to the PDO driver you need to also run the native driver simply to provide the areas NOT covered by PDO. We need a generic framework that addresses the real problems not one that creates an artificial lowest common denominator strangle hold :( PDO could evolve into that, but not with it's current restrictions. And what do you suggest to improve this situation? One of my suggestions is to have more DB developers (as in DB internals, if I can say so :) involved. Oracle and IBM (to name the largest and most active) understood that and actively participate. I'm not saying that you do nothing, but I'm not sure that complaining about the bad state of pdo_firebird is really helpful. Cheers, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The windows build is now ready and can be downloded from: http://downloads.php.net/edink/php-5.2.4RC1-Win32.zip http://downloads.php.net/edink/php-5.2.4RC1-win32-installer.msi http://downloads.php.net/edink/pecl-5.2.4RC1-Win32.zip http://downloads.php.net/edink/php-debug-pack-5.2.4RC1-Win32.zip Edin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGsqgAoL7jghV9D6gRAlHnAJ4zqzKikiBgffzvQBQqLBsASJoa3wCgy+fR bSR1MvfCW25LqASgYiELIpo= =j3j0 -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
