Bug #53696 [Csd]: erroneous automatic entry into httpd.conf
Edit report at http://bugs.php.net/bug.php?id=53696edit=1 ID: 53696 User updated by:helge dot rowold at datendrexler dot de Reported by:helge dot rowold at datendrexler dot de Summary:erroneous automatic entry into httpd.conf Status: Closed Type: Bug Package:Apache2 related Operating System: Windows 7 PHP Version:5.3.5 Assigned To:jmertic Block user comment: N Private report: N New Comment: Hello masikwha, in my opinion you should be able to fix the error on Vista, too, by adding the following two lines to your httpd.conf file (in case you would like to use PHP as Apache module and *not* via CGI): PHPIniDir php_partition_char:/php_program_path/php_dir_name/ LoadModule php5_module php_partition_char:/php_program_path/php5apache2_2.dll The strings php_partition_char, php_program_path, and php_dir_name have to be replaced with the real path to your PHP installation directory, of course. Previous Comments: [2011-03-16 04:48:04] masikwha at yahoo dot com the problems discussed here for windows 7 seems to be far different than what I am experincing on Vista. After successful installatioin of Apache 2.2.17 on Vista, php-5.3.5-Win32-VC9-x86 (Thread safe) installer seems to add following lines on httpd.conf file, #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL ScriptAlias /php/ Action application/x-httpd-php php-cgi.exe #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL (Note there is no PHPIniDir ) On restarting the apache it gives error saying, ScriptAlias takes two names, fake name and real name... I tried commenting #CriptAlias /php/ , Apache runs ok but it doesn't php is not working. For proper installation of PHP 5.3.5 is that all the changes necessary ?? (which however is not working )? [2011-01-19 21:57:49] jmer...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2011-01-10 11:18:51] alvaro at demogracia dot com Same symptoms here under Windows XP. Apache cannot find php5apache2_2.dll even if at default location: The Apache service named reported the following error: httpd.exe: Syntax error on line 516 of C:/Archivos de programa/Apache Software Foundation/Apache2.2/conf/httpd.conf: Cannot load C:/Archivos de programa/Apache Software Foundation/Apache2.2/php5apache2_2.dll into server: No se puede encontrar el m\xf3dulo . Copying settings from PHP/5.3.4 fixes the issue: #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL PHPIniDir C:/Archivos de programa/PHP/ LoadModule php5_module C:/Archivos de programa/PHP/php5apache2_2.dll #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL [2011-01-08 14:57:09] paj...@php.net hi John, Something went wrong in the last installer update. [2011-01-08 14:53:42] helge dot rowold at datendrexler dot de Description: After having installed httpd-2.2.17-win32-x86-openssl-0.9.8o.msi successfully, but NOT at the default path but at a separate HDD partition with a non-default root directory, I was able to install the php-5.3.5-Win32-VC6-x86.msi at the same partition in a non-default directory, too. The installer echoed that everything would have been done well. But the Apache Service did not start, then! At the end I was able to fix the issue: In httpd.conf, the PHP installer had tried to add the default linkage from HTTPD to PHP by adding the lines #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL PHPIniDir LoadModule php5_module php5apache2_2.dll #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL - i. e., PHP was NOT able to set the correct (non-default) path to its own directory (which would have been, by the way, D:/Programme/PHP535/). Test script: --- Please see above - addition of the correct path in httpd.conf did fix the error. -- Edit this bug report at http://bugs.php.net/bug.php?id=53696edit=1
Req #54117 [Opn]: Parameter 'z' false
Edit report at http://bugs.php.net/bug.php?id=54117edit=1 ID: 54117 User updated by:a dot borngesser at berlin dot de Reported by:a dot borngesser at berlin dot de Summary:Parameter 'z' false Status: Open Type: Feature/Change Request Package:Date/time related Operating System: Irrelevant PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Is someone working on this issue or shut I open a new thread (and of course in english this time)? Previous Comments: [2011-02-28 11:29:03] a dot borngesser at berlin dot de Sorry, my text now in english. The parameter 'z' is false from its basic set-up. The first day of the year is '1' not '0'. I know, that the count starts with 0, but it would be better to change the code of the parameter, than to leave it to the programmers. (I had some cases where it was used simply as is. The results where simply false, and when using it in a very basic way by just displaying it, you don't think of a mistake.) If a parameter is for returning the incremented day of the year, it should do exactly this, and not the incremented day of the year -1. [2011-02-28 11:11:34] paj...@php.net Please report your bug in English. [2011-02-28 11:10:18] a dot borngesser at berlin dot de Description: --- From manual page: http://www.php.net/function.date#Parameter-Liste --- Parameter ist im Grundaufbau falsch. z Der Tag des Jahres (von 0 beginnend)0 bis365 === = Der erste Tag des Jahres ist nicht '0' sondern '1'! Natürlich ist es normal, das von 0 die Zählung beginnt, aber man sollte evtl. bei einem Parameter dies intern gleich um +1 hochzählen und nicht den Programmierern überlassen. Ich habe jetzt schon mehrere Fälle gehabt, wo der Parameter direkt genutzt wurde, was dann zu falschen Ergebnissen geführt hat. Wenn ein Parameter den hochgezählten Tag des Jahres angeben soll, sollte dies auch so sein und nicht 'der hochgezählte Tag des Jahres -1'. Test script: --- echo Der 1.1. 2010 hatte die LOS#: .date (z,mktime(0,0,0,1,1,2010)); Expected result: Der 1.1. 2010 hatte die LOS#: 1 Actual result: -- Der 1.1. 2010 hatte die LOS#: 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=54117edit=1
[PHP-BUG] Bug #54270 [NEW]: .user.ini not working on network shared DOCUMENT_ROOT
From: Operating system: Windows PHP version: 5.3.5 Package: PHP options/info functions Bug Type: Bug Bug description:.user.ini not working on network shared DOCUMENT_ROOT Description: From phpinfo for the file: _SERVER[DOCUMENT_ROOT]//htdocserv/htdocsns/ _SERVER[SCRIPT_FILENAME] //htdocserv/htdocsns/user/hernst/head/xml/iwat/tools/version.php In processmonitor I only see one access try to \\htdocserv\htdocsns\user\hernst\head\xml\iwat\tools\.user.ini and not to \\htdocserv\htdocsns\user\hernst\head\xml\iwat\.user.ini \\htdocserv\htdocsns\user\hernst\head\xml\.user.ini ... I have one .user.ini file in C:\dir \\htdocserv\htdocsns\user\hernst\head\xml\*.ini Volume in drive \\htdocserv\htdocsns is htdocsns Volume Serial Number is AF3D-2838 Directory of \\htdocserv\htdocsns\user\hernst\head\xml 16.03.2011 11:4019 .user.ini 1 File(s) 19 bytes Seems the alogrith does not work properly with the network shares on windows and trying to macht the Document-Root to the current file -- Edit bug report at http://bugs.php.net/bug.php?id=54270edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54270r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54270r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54270r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54270r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54270r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54270r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54270r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54270r=needscript Try newer version: http://bugs.php.net/fix.php?id=54270r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54270r=support Expected behavior: http://bugs.php.net/fix.php?id=54270r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54270r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54270r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54270r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54270r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54270r=dst IIS Stability: http://bugs.php.net/fix.php?id=54270r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54270r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54270r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54270r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54270r=mysqlcfg
Bug #54270 [Opn-Fbk]: .user.ini not working on network shared DOCUMENT_ROOT
Edit report at http://bugs.php.net/bug.php?id=54270edit=1 ID: 54270 Updated by: paj...@php.net Reported by:j dot henge-ernst at interexa dot de Summary:.user.ini not working on network shared DOCUMENT_ROOT -Status: Open +Status: Feedback Type: Bug Package:PHP options/info functions Operating System: Windows PHP Version:5.3.5 -Assigned To: +Assigned To:pajoye Block user comment: N Private report: N New Comment: Any reason why you don't mount it instead? However it should work anyway, but can you try by mounting this path as a folder or drive please? Previous Comments: [2011-03-16 13:20:03] j dot henge-ernst at interexa dot de Description: From phpinfo for the file: _SERVER[DOCUMENT_ROOT]//htdocserv/htdocsns/ _SERVER[SCRIPT_FILENAME] //htdocserv/htdocsns/user/hernst/head/xml/iwat/tools/version.php In processmonitor I only see one access try to \\htdocserv\htdocsns\user\hernst\head\xml\iwat\tools\.user.ini and not to \\htdocserv\htdocsns\user\hernst\head\xml\iwat\.user.ini \\htdocserv\htdocsns\user\hernst\head\xml\.user.ini ... I have one .user.ini file in C:\dir \\htdocserv\htdocsns\user\hernst\head\xml\*.ini Volume in drive \\htdocserv\htdocsns is htdocsns Volume Serial Number is AF3D-2838 Directory of \\htdocserv\htdocsns\user\hernst\head\xml 16.03.2011 11:4019 .user.ini 1 File(s) 19 bytes Seems the alogrith does not work properly with the network shares on windows and trying to macht the Document-Root to the current file -- Edit this bug report at http://bugs.php.net/bug.php?id=54270edit=1
Bug #49532 [Com]: php5ts.dll access violation exception php5ts!_zend_mm_free_int
Edit report at http://bugs.php.net/bug.php?id=49532edit=1
ID: 49532
Comment by: mdurovic at gmail dot com
Reported by:matroy at investpsp dot ca
Summary:php5ts.dll access violation exception
php5ts!_zend_mm_free_int
Status: Feedback
Type: Bug
Package:*General Issues
Operating System: win32 only - Windows 2003 SP2
PHP Version:5.2.11
Block user comment: N
Private report: N
New Comment:
It looks like httpd crashes after this error msg in the event viewer.
PHP Fatal error: Maximum execution time of 30 seconds exceeded in
C:\ftproot\LocalUser\linkmarket\framework\common\php\session.class.php
on line 71.
That is public function write($id, $data) from the code below:
?php
class Session
{
/**
* a database connection resource
* @var resource
*/
private $_sess_db;
/**
* Open the session
* @return bool
*/
public function open() {
if ($this-_sess_db = mysql_connect('server:port',
'user',
'pw')) {
return mysql_select_db('db', $this-_sess_db);
}
return false;
}
/**
* Close the session
* @return bool
*/
public function close() {
if(is_resource($this-_sess_db))
{
return mysql_close($this-_sess_db);
}
return false;
}
/**
* Read the session
* @param int session id
* @return string string of the sessoin
*/
public function read($id) {
$id = mysql_real_escape_string($id);
$sql = sprintf(SELECT data FROM sessions WHERE id = '%s',
$id);
if ($result = mysql_query($sql, $this-_sess_db))
{
if (mysql_num_rows($result))
{
$record = mysql_fetch_assoc($result);
//free mysql result
mysql_free_result($result);
return $record['data'];
}
}
return '';
}
/**
* Write the session
* @param int session id
* @param string data of the session
*/
public function write($id, $data) {
$sql = sprintf(REPLACE INTO sessions (id,data,timestamp,ip,url)
VALUES('%s', '%s', '%s','%s','%s'),
mysql_real_escape_string($id),
mysql_real_escape_string($data),
mysql_real_escape_string(time()),
mysql_real_escape_string($_SERVER['REMOTE_ADDR']),
mysql_real_escape_string(http://.$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI']));
return mysql_query($sql, $this-_sess_db);
}
/**
* Destoroy the session
* @param int session id
* @return bool
*/
public function destroy($id) {
$sql = sprintf(DELETE FROM sessions WHERE id = '%s', $id);
return mysql_query($sql, $this-_sess_db);
}
/**
* Garbage Collector
* @param int life time (sec.)
* @return bool
* @see session.gc_divisor 100
* @see session.gc_maxlifetime 1440
* @see session.gc_probability1
* @usage execution rate 1/100
*(session.gc_probability/session.gc_divisor)
*/
public function gc($max) {
$sql = sprintf(DELETE FROM sessions WHERE timestamp '%s',
mysql_real_escape_string(time() - $max));
return mysql_query($sql, $this-_sess_db);
}
}
//ini_set('session.gc_probability', 50);
ini_set('session.save_handler', 'user');
$session = new Session();
session_set_save_handler(array($session, 'open'),
array($session, 'close'),
array($session, 'read'),
array($session, 'write'),
array($session, 'destroy'),
array($session, 'gc'));
?
Previous Comments:
Bug #54270 [Fbk-Asn]: .user.ini not working on network shared DOCUMENT_ROOT
Edit report at http://bugs.php.net/bug.php?id=54270edit=1 ID: 54270 User updated by:j dot henge-ernst at interexa dot de Reported by:j dot henge-ernst at interexa dot de Summary:.user.ini not working on network shared DOCUMENT_ROOT -Status: Feedback +Status: Assigned Type: Bug Package:PHP options/info functions Operating System: Windows PHP Version:5.3.5 Assigned To:pajoye Block user comment: N Private report: N New Comment: Can't use it as drive because apache does not start then: DocumentRoot z:/ DocumentRoot z: DocumentRoot z:/ leads to a Syntax error on line 6 of C:/Program Files/Zend/Apache2/conf/default-with-letter.conf Using DocumentRoot //htdocserv/htdocsns works This might happen for apache as Z: is not available in that context. Running apache as Service with NT AUTHORITY\NetworkService Account. Previous Comments: [2011-03-16 13:39:05] paj...@php.net Any reason why you don't mount it instead? However it should work anyway, but can you try by mounting this path as a folder or drive please? [2011-03-16 13:20:03] j dot henge-ernst at interexa dot de Description: From phpinfo for the file: _SERVER[DOCUMENT_ROOT]//htdocserv/htdocsns/ _SERVER[SCRIPT_FILENAME] //htdocserv/htdocsns/user/hernst/head/xml/iwat/tools/version.php In processmonitor I only see one access try to \\htdocserv\htdocsns\user\hernst\head\xml\iwat\tools\.user.ini and not to \\htdocserv\htdocsns\user\hernst\head\xml\iwat\.user.ini \\htdocserv\htdocsns\user\hernst\head\xml\.user.ini ... I have one .user.ini file in C:\dir \\htdocserv\htdocsns\user\hernst\head\xml\*.ini Volume in drive \\htdocserv\htdocsns is htdocsns Volume Serial Number is AF3D-2838 Directory of \\htdocserv\htdocsns\user\hernst\head\xml 16.03.2011 11:4019 .user.ini 1 File(s) 19 bytes Seems the alogrith does not work properly with the network shares on windows and trying to macht the Document-Root to the current file -- Edit this bug report at http://bugs.php.net/bug.php?id=54270edit=1
[PHP-BUG] Bug #54273 [NEW]: php-fpm SAPI fails to build on AIX 6.1 (on IBM POWER6 arch)
From: Operating system: AIX 6.1 PHP version: 5.3.5 Package: FPM related Bug Type: Bug Bug description:php-fpm SAPI fails to build on AIX 6.1 (on IBM POWER6 arch) Description: Attempting to build php with the php-fpm SAPI fails on AIX 6.1. It's clearly because the processor type isn't defined in php-5.3.5/sapi/fpm/fpm/fpm_atomic.h. I have no idea what the appropriate typedefs for this architecture should be. Additionally, I'm compiling with the IBM xlc compiler. I can successfully compile every other part of PHP with my toolchain. Output of uname -pM: powerpc IBM,8203-E4A (This is arch and machine model number - an IBM Power 520 Express) PHP's configure line: ./configure \ --cache-file=../config.cache \ --prefix=/opt/freeware \ --with-config-file-path=/opt/freeware/etc \ --enable-shared --enable-static \ --without-pear \ --with-gd=/opt/freeware \ --with-openssl=/opt/freeware \ --with-zlib \ --with-bz2 \ --with-curl=/opt/freeware \ --with-t1lib=/opt/freeware \ --with-freetype-dir=/opt/freeware \ --with-jpeg-dir=/opt/freeware \ --with-png-dir=/opt/freeware \ --with-xpm-dir=/opt/freeware \ --with-zlib-dir=/opt/freeware \ --enable-soap \ --enable-bcmath \ --enable-ftp \ --with-iconv \ --enable-dom \ --enable-json \ --with-pcre-regex=/opt/freeware \ --enable-fpm End of the compile output: /opt/freeware/bin/bash /opt/freeware/src/packages/BUILD/php-5.3.5/build-php- fpm/libtool --silent --preserve-dup-deps --mode=compile xlc - I/opt/freeware/src/packages/BUILD/php-5.3.5/sapi/fpm -Isapi/fpm/ - I/opt/freeware/src/packages/BUILD/php-5.3.5/sapi/fpm/ -DPHP_ATOM_INC - I/opt/freeware/src/packages/BUILD/php-5.3.5/build-php-fpm/include - I/opt/freeware/src/packages/BUILD/php-5.3.5/build-php-fpm/main - I/opt/freeware/src/packages/BUILD/php-5.3.5 - I/opt/freeware/src/packages/BUILD/php-5.3.5/build-php-fpm/ext/date/lib - I/opt/freeware/src/packages/BUILD/php-5.3.5/ext/date/lib - I/opt/freeware/src/packages/BUILD/php-5.3.5/ext/ereg/regex - I/opt/freeware/include/libxml2 -I/opt/freeware/include - I/opt/freeware/include/freetype2 -I/opt/freeware/src/packages/BUILD/php- 5.3.5/ext/sqlite3/libsqlite -I/opt/freeware/src/packages/BUILD/php-5.3.5/build- php-fpm/TSRM -I/opt/freeware/src/packages/BUILD/php-5.3.5/build-php-fpm/Zend - I/opt/freeware/src/packages/BUILD/php-5.3.5/main - I/opt/freeware/src/packages/BUILD/php-5.3.5/Zend - I/opt/freeware/src/packages/BUILD/php-5.3.5/TSRM - I/opt/freeware/src/packages/BUILD/php-5.3.5/build-php-fpm/ -I/usr/include - qmaxmem=16384 -DSYSV -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_AIX52 - D_AIX53 -D_AIX61 -D_ALL_SOURCE -DFUNCPROTO=15 -O -I/opt/freeware/include -c /opt/freeware/src/packages/BUILD/php-5.3.5/sapi/fpm/fpm/fpm_children.c -o sapi/fpm/fpm/fpm_children.lo /opt/freeware/src/packages/BUILD/php-5.3.5/Zend/zend.h, line 179.10: 1506-236 (W) Macro name __restrict__ has been redefined. /opt/freeware/src/packages/BUILD/php-5.3.5/Zend/zend.h, line 179.10: 1506-358 (I) __restrict__ is defined on line 186 of /usr/include/standards.h. /opt/freeware/src/packages/BUILD/php-5.3.5/sapi/fpm/fpm/fpm_atomic.h, line 142.2: 1506-205 (S) #error Unsupported processor. Please open a bug report (bugs.php.net). /opt/freeware/src/packages/BUILD/php-5.3.5/sapi/fpm/fpm/fpm_atomic.h, line 146.41: 1506-277 (S) Syntax error: possible missing ')' or ','? /opt/freeware/src/packages/BUILD/php-5.3.5/sapi/fpm/fpm/fpm_atomic.h, line 149.39: 1506-045 (S) Undeclared identifier lock. /opt/freeware/src/packages/BUILD/php-5.3.5/sapi/fpm/fpm/fpm_shm_slots.h, line 16.17: 1506-046 (S) Syntax error. gmake: *** [sapi/fpm/fpm/fpm_children.lo] Error 1 Expected result: php compiles with the php-fpm. -- Edit bug report at http://bugs.php.net/bug.php?id=54273edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54273r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54273r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54273r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54273r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54273r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54273r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54273r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54273r=needscript Try newer version: http://bugs.php.net/fix.php?id=54273r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54273r=support Expected behavior: http://bugs.php.net/fix.php?id=54273r=notwrong Not enough info:
Bug #54270 [Asn]: .user.ini not working on network shared DOCUMENT_ROOT
Edit report at http://bugs.php.net/bug.php?id=54270edit=1 ID: 54270 Updated by: paj...@php.net Reported by:j dot henge-ernst at interexa dot de Summary:.user.ini not working on network shared DOCUMENT_ROOT Status: Assigned Type: Bug Package:PHP options/info functions Operating System: Windows PHP Version:5.3.5 Assigned To:pajoye Block user comment: N Private report: N New Comment: That's rather weird, it works just fine here. But that's hardly a php problem (the conf error). What if you use a folder? Mounting the share as c:\apache\htdocs for example? Previous Comments: [2011-03-16 14:00:34] j dot henge-ernst at interexa dot de Can't use it as drive because apache does not start then: DocumentRoot z:/ DocumentRoot z: DocumentRoot z:/ leads to a Syntax error on line 6 of C:/Program Files/Zend/Apache2/conf/default-with-letter.conf Using DocumentRoot //htdocserv/htdocsns works This might happen for apache as Z: is not available in that context. Running apache as Service with NT AUTHORITY\NetworkService Account. [2011-03-16 13:39:05] paj...@php.net Any reason why you don't mount it instead? However it should work anyway, but can you try by mounting this path as a folder or drive please? [2011-03-16 13:20:03] j dot henge-ernst at interexa dot de Description: From phpinfo for the file: _SERVER[DOCUMENT_ROOT]//htdocserv/htdocsns/ _SERVER[SCRIPT_FILENAME] //htdocserv/htdocsns/user/hernst/head/xml/iwat/tools/version.php In processmonitor I only see one access try to \\htdocserv\htdocsns\user\hernst\head\xml\iwat\tools\.user.ini and not to \\htdocserv\htdocsns\user\hernst\head\xml\iwat\.user.ini \\htdocserv\htdocsns\user\hernst\head\xml\.user.ini ... I have one .user.ini file in C:\dir \\htdocserv\htdocsns\user\hernst\head\xml\*.ini Volume in drive \\htdocserv\htdocsns is htdocsns Volume Serial Number is AF3D-2838 Directory of \\htdocserv\htdocsns\user\hernst\head\xml 16.03.2011 11:4019 .user.ini 1 File(s) 19 bytes Seems the alogrith does not work properly with the network shares on windows and trying to macht the Document-Root to the current file -- Edit this bug report at http://bugs.php.net/bug.php?id=54270edit=1
Bug #54273 [Opn]: php-fpm SAPI fails to build on AIX 6.1 (on IBM POWER6 arch)
Edit report at http://bugs.php.net/bug.php?id=54273edit=1 ID: 54273 User updated by:a dot sykes at ucl dot ac dot uk Reported by:a dot sykes at ucl dot ac dot uk Summary:php-fpm SAPI fails to build on AIX 6.1 (on IBM POWER6 arch) Status: Open Type: Bug Package:FPM related Operating System: AIX 6.1 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Should've mentioned that I've looked at the patch in this bug: http://bugs.php.net/bug.php?id=51772 But it doesn't seem relevant against PHP 5.3.5. I'd be happy to test (and stability test) any patch. Previous Comments: [2011-03-16 14:12:44] a dot sykes at ucl dot ac dot uk Description: Attempting to build php with the php-fpm SAPI fails on AIX 6.1. It's clearly because the processor type isn't defined in php-5.3.5/sapi/fpm/fpm/fpm_atomic.h. I have no idea what the appropriate typedefs for this architecture should be. Additionally, I'm compiling with the IBM xlc compiler. I can successfully compile every other part of PHP with my toolchain. Output of uname -pM: powerpc IBM,8203-E4A (This is arch and machine model number - an IBM Power 520 Express) PHP's configure line: ./configure \ --cache-file=../config.cache \ --prefix=/opt/freeware \ --with-config-file-path=/opt/freeware/etc \ --enable-shared --enable-static \ --without-pear \ --with-gd=/opt/freeware \ --with-openssl=/opt/freeware \ --with-zlib \ --with-bz2 \ --with-curl=/opt/freeware \ --with-t1lib=/opt/freeware \ --with-freetype-dir=/opt/freeware \ --with-jpeg-dir=/opt/freeware \ --with-png-dir=/opt/freeware \ --with-xpm-dir=/opt/freeware \ --with-zlib-dir=/opt/freeware \ --enable-soap \ --enable-bcmath \ --enable-ftp \ --with-iconv \ --enable-dom \ --enable-json \ --with-pcre-regex=/opt/freeware \ --enable-fpm End of the compile output: /opt/freeware/bin/bash /opt/freeware/src/packages/BUILD/php-5.3.5/build-php- fpm/libtool --silent --preserve-dup-deps --mode=compile xlc - I/opt/freeware/src/packages/BUILD/php-5.3.5/sapi/fpm -Isapi/fpm/ - I/opt/freeware/src/packages/BUILD/php-5.3.5/sapi/fpm/ -DPHP_ATOM_INC - I/opt/freeware/src/packages/BUILD/php-5.3.5/build-php-fpm/include - I/opt/freeware/src/packages/BUILD/php-5.3.5/build-php-fpm/main - I/opt/freeware/src/packages/BUILD/php-5.3.5 - I/opt/freeware/src/packages/BUILD/php-5.3.5/build-php-fpm/ext/date/lib - I/opt/freeware/src/packages/BUILD/php-5.3.5/ext/date/lib - I/opt/freeware/src/packages/BUILD/php-5.3.5/ext/ereg/regex - I/opt/freeware/include/libxml2 -I/opt/freeware/include - I/opt/freeware/include/freetype2 -I/opt/freeware/src/packages/BUILD/php- 5.3.5/ext/sqlite3/libsqlite -I/opt/freeware/src/packages/BUILD/php-5.3.5/build- php-fpm/TSRM -I/opt/freeware/src/packages/BUILD/php-5.3.5/build-php-fpm/Zend - I/opt/freeware/src/packages/BUILD/php-5.3.5/main - I/opt/freeware/src/packages/BUILD/php-5.3.5/Zend - I/opt/freeware/src/packages/BUILD/php-5.3.5/TSRM - I/opt/freeware/src/packages/BUILD/php-5.3.5/build-php-fpm/ -I/usr/include - qmaxmem=16384 -DSYSV -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_AIX52 - D_AIX53 -D_AIX61 -D_ALL_SOURCE -DFUNCPROTO=15 -O -I/opt/freeware/include -c /opt/freeware/src/packages/BUILD/php-5.3.5/sapi/fpm/fpm/fpm_children.c -o sapi/fpm/fpm/fpm_children.lo /opt/freeware/src/packages/BUILD/php-5.3.5/Zend/zend.h, line 179.10: 1506-236 (W) Macro name __restrict__ has been redefined. /opt/freeware/src/packages/BUILD/php-5.3.5/Zend/zend.h, line 179.10: 1506-358 (I) __restrict__ is defined on line 186 of /usr/include/standards.h. /opt/freeware/src/packages/BUILD/php-5.3.5/sapi/fpm/fpm/fpm_atomic.h, line 142.2: 1506-205 (S) #error Unsupported processor. Please open a bug report (bugs.php.net). /opt/freeware/src/packages/BUILD/php-5.3.5/sapi/fpm/fpm/fpm_atomic.h, line 146.41: 1506-277 (S) Syntax error: possible missing ')' or ','? /opt/freeware/src/packages/BUILD/php-5.3.5/sapi/fpm/fpm/fpm_atomic.h, line 149.39: 1506-045 (S) Undeclared identifier lock. /opt/freeware/src/packages/BUILD/php-5.3.5/sapi/fpm/fpm/fpm_shm_slots.h, line 16.17: 1506-046 (S) Syntax error. gmake: *** [sapi/fpm/fpm/fpm_children.lo] Error 1 Expected result: php compiles with the php-fpm. -- Edit this bug report at http://bugs.php.net/bug.php?id=54273edit=1
Bug #54270 [Asn]: .user.ini not working on network shared DOCUMENT_ROOT
Edit report at http://bugs.php.net/bug.php?id=54270edit=1 ID: 54270 User updated by:j dot henge-ernst at interexa dot de Reported by:j dot henge-ernst at interexa dot de Summary:.user.ini not working on network shared DOCUMENT_ROOT Status: Assigned Type: Bug Package:PHP options/info functions -Operating System: Windows +Operating System: Windows Server 2003 R2 SP2 PHP Version:5.3.5 Assigned To:pajoye Block user comment: N Private report: N New Comment: Sorry, can't get the network share to map to a sirectory. The typical thing with junction and mklink commands does not seem to work on Windows Server 2003 R2 SP2. Or is there any other command to map the share to a directory in Windows Server 2003 R2? Previous Comments: [2011-03-16 14:22:40] paj...@php.net That's rather weird, it works just fine here. But that's hardly a php problem (the conf error). What if you use a folder? Mounting the share as c:\apache\htdocs for example? [2011-03-16 14:00:34] j dot henge-ernst at interexa dot de Can't use it as drive because apache does not start then: DocumentRoot z:/ DocumentRoot z: DocumentRoot z:/ leads to a Syntax error on line 6 of C:/Program Files/Zend/Apache2/conf/default-with-letter.conf Using DocumentRoot //htdocserv/htdocsns works This might happen for apache as Z: is not available in that context. Running apache as Service with NT AUTHORITY\NetworkService Account. [2011-03-16 13:39:05] paj...@php.net Any reason why you don't mount it instead? However it should work anyway, but can you try by mounting this path as a folder or drive please? [2011-03-16 13:20:03] j dot henge-ernst at interexa dot de Description: From phpinfo for the file: _SERVER[DOCUMENT_ROOT]//htdocserv/htdocsns/ _SERVER[SCRIPT_FILENAME] //htdocserv/htdocsns/user/hernst/head/xml/iwat/tools/version.php In processmonitor I only see one access try to \\htdocserv\htdocsns\user\hernst\head\xml\iwat\tools\.user.ini and not to \\htdocserv\htdocsns\user\hernst\head\xml\iwat\.user.ini \\htdocserv\htdocsns\user\hernst\head\xml\.user.ini ... I have one .user.ini file in C:\dir \\htdocserv\htdocsns\user\hernst\head\xml\*.ini Volume in drive \\htdocserv\htdocsns is htdocsns Volume Serial Number is AF3D-2838 Directory of \\htdocserv\htdocsns\user\hernst\head\xml 16.03.2011 11:4019 .user.ini 1 File(s) 19 bytes Seems the alogrith does not work properly with the network shares on windows and trying to macht the Document-Root to the current file -- Edit this bug report at http://bugs.php.net/bug.php?id=54270edit=1
Bug #54270 [Asn]: .user.ini not working on network shared DOCUMENT_ROOT
Edit report at http://bugs.php.net/bug.php?id=54270edit=1 ID: 54270 Updated by: paj...@php.net Reported by:j dot henge-ernst at interexa dot de Summary:.user.ini not working on network shared DOCUMENT_ROOT Status: Assigned Type: Bug Package:PHP options/info functions Operating System: Windows Server 2003 R2 SP2 PHP Version:5.3.5 Assigned To:pajoye Block user comment: N Private report: N New Comment: Ah right, junctions are only for local data, sorry. However the drive letter issue is weird, sounds like a problem in the zend server's apache, please report the issue to them. I will take a look at the initial problem as soon as possible. Previous Comments: [2011-03-16 15:26:30] j dot henge-ernst at interexa dot de Sorry, can't get the network share to map to a sirectory. The typical thing with junction and mklink commands does not seem to work on Windows Server 2003 R2 SP2. Or is there any other command to map the share to a directory in Windows Server 2003 R2? [2011-03-16 14:22:40] paj...@php.net That's rather weird, it works just fine here. But that's hardly a php problem (the conf error). What if you use a folder? Mounting the share as c:\apache\htdocs for example? [2011-03-16 14:00:34] j dot henge-ernst at interexa dot de Can't use it as drive because apache does not start then: DocumentRoot z:/ DocumentRoot z: DocumentRoot z:/ leads to a Syntax error on line 6 of C:/Program Files/Zend/Apache2/conf/default-with-letter.conf Using DocumentRoot //htdocserv/htdocsns works This might happen for apache as Z: is not available in that context. Running apache as Service with NT AUTHORITY\NetworkService Account. [2011-03-16 13:39:05] paj...@php.net Any reason why you don't mount it instead? However it should work anyway, but can you try by mounting this path as a folder or drive please? [2011-03-16 13:20:03] j dot henge-ernst at interexa dot de Description: From phpinfo for the file: _SERVER[DOCUMENT_ROOT]//htdocserv/htdocsns/ _SERVER[SCRIPT_FILENAME] //htdocserv/htdocsns/user/hernst/head/xml/iwat/tools/version.php In processmonitor I only see one access try to \\htdocserv\htdocsns\user\hernst\head\xml\iwat\tools\.user.ini and not to \\htdocserv\htdocsns\user\hernst\head\xml\iwat\.user.ini \\htdocserv\htdocsns\user\hernst\head\xml\.user.ini ... I have one .user.ini file in C:\dir \\htdocserv\htdocsns\user\hernst\head\xml\*.ini Volume in drive \\htdocserv\htdocsns is htdocsns Volume Serial Number is AF3D-2838 Directory of \\htdocserv\htdocsns\user\hernst\head\xml 16.03.2011 11:4019 .user.ini 1 File(s) 19 bytes Seems the alogrith does not work properly with the network shares on windows and trying to macht the Document-Root to the current file -- Edit this bug report at http://bugs.php.net/bug.php?id=54270edit=1
[PHP-BUG] Bug #54275 [NEW]: Exception thrown in error_handler is swallowed
From:
Operating system: all
PHP version: 5.3.5
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Exception thrown in error_handler is swallowed
Description:
Exception thrown in error_handler is swallowed if fatal error occurs after
error in same instruction
somewhat related (closed) bugs:
http://bugs.php.net/bug.php?id=36773
http://bugs.php.net/bug.php?id=51463
Test script:
---
function error($code, $message, $file = null, $line = 0) {
echo convert error to exceptionbr\n;
throw new \ErrorException($message, $code, null, $file, $line);
}
function shutdown() {
echo shutdown function calledbr\n;
}
set_error_handler('error');
register_shutdown_function('shutdown');
try {
echo $crypto-compress();
} catch (\Exception $e) {
echo exception catchedbr\n;
}
echo after fatal errorbr\n;
Expected result:
exception should be catched as in (note the @ operator to suppress a FATAL
ERROR!):
function error($code, $message, $file = null, $line = 0) {
echo convert error to exceptionbr\n;
throw new \ErrorException($message, $code, null, $file, $line);
}
function shutdown() {
echo shutdown function calledbr\n;
}
set_error_handler('error');
register_shutdown_function('shutdown');
try {
echo @$crypto-compress();
} catch (\Exception $e) {
echo exception catchedbr\n;
}
echo after fatal errorbr\n;
Actual result:
--
1. Exception thrown in error_handler is swallowed
2. the fatal error after Undefined variable occurs
--
Edit bug report at http://bugs.php.net/bug.php?id=54275edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54275r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54275r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54275r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54275r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54275r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54275r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54275r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54275r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54275r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54275r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54275r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54275r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54275r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54275r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54275r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54275r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54275r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54275r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54275r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54275r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54275r=mysqlcfg
[PHP-BUG] Bug #54276 [NEW]: ini_get can't read pdo.dsn.*
From:
Operating system: Win 7
PHP version: 5.3.5
Package: PDO related
Bug Type: Bug
Bug description:ini_get can't read pdo.dsn.*
Description:
ini_get can't read pdo.dsn.* in the php.ini
Test script:
---
//ini : pdo.dsn.test = sqlite::memory:
$dbh = new PDO('test');
var_dump(ini_get('pdo.dsn.test'));
Expected result:
string(15) sqlite::memory:
Actual result:
--
bool(false)
--
Edit bug report at http://bugs.php.net/bug.php?id=54276edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54276r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54276r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54276r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54276r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54276r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54276r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54276r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54276r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54276r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54276r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54276r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54276r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54276r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54276r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54276r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54276r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54276r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54276r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54276r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54276r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54276r=mysqlcfg
Bug #54276 [Opn-Bgs]: ini_get can't read pdo.dsn.*
Edit report at http://bugs.php.net/bug.php?id=54276edit=1
ID: 54276
Updated by: johan...@php.net
Reported by:jinmoku at hotmail dot com
Summary:ini_get can't read pdo.dsn.*
-Status: Open
+Status: Bogus
Type: Bug
Package:PDO related
Operating System: Win 7
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The is no such ini entries. ini_get() only works for settings defined by
PHP.
Previous Comments:
[2011-03-16 16:55:05] jinmoku at hotmail dot com
Description:
ini_get can't read pdo.dsn.* in the php.ini
Test script:
---
//ini : pdo.dsn.test = sqlite::memory:
$dbh = new PDO('test');
var_dump(ini_get('pdo.dsn.test'));
Expected result:
string(15) sqlite::memory:
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/bug.php?id=54276edit=1
Bug #54250 [Bgs]: date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call
Edit report at http://bugs.php.net/bug.php?id=54250edit=1 ID: 54250 Updated by: johan...@php.net Reported by:maciej at wiercinski dot net Summary:date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call Status: Bogus Type: Bug Package:Date/time related Operating System: Linux 2.6 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: vJust a small comment on The PHP tzdata changes are mixed in with the mainline development, and sometimes depend on other changes within the engine, so it's not really feasible to cherry pick out the changes into a stable release, even if we wanted to. This is not true. Distributions can distribute the timezone update using the pecl/timzeone package. No messing with engine stuff needed. Previous Comments: [2011-03-15 18:52:29] seanius at debian dot org Hi guys, We'll take up further discussion on the bug over there, but thought I would cut/paste the (slightly amended) initial response here just for posterity's sake. === Hi Maciej, Does this actually cause a quantifiable and significant performance regression? This possibility of performance issues was discussed some time ago but it was decided that the stat calls would just hit the kernel fs cache and not cause any serious problems. If there are indeed problems, there are certainly ways this could be worked around, but it would add even further complexity to the patch which we'd all prefer to avoid if possible. To give you some extra background, since the PHP authors certainly have their own take on the situation: EVERY serious linux distribution ships this patch in some form. Redhat, Fedora, Debian, Ubuntu, SLES, Opensuse (okay, maybe not Gentoo, but anyway...) all ship with this patch. So please keep that in mind when you here both sides of this argument :) The problem is that when the OS distributors release a timezone update, they don't want to *also* have to go package by package updating individual and customized timezone databases that might be embedded in a given application. Neither do they want to continuously update the version of PHP in their stable releases and have to deal with the numerous regressions that would result. The PHP tzdata changes are mixed in with the mainline development, and sometimes depend on other changes within the engine, so it's not really feasible to cherry pick out the changes into a stable release, even if we wanted to. This is a point of disagreement with the PHP authors, who want to have control over this aspect of the engine themselves (and they certainly have their justifications, such as systems with outdated or nonexistant tzdata, plus they add some extra TZ annotations in their private copy). Unfortunately they are not interested in providing any other way to work around this issue, despite the periodic overture from us or RedHat. The invitation is still open to try and find a reasonable technical solution for this, but I have been led to beleive that Derick has really dug in his heels on the issue and it's not worth any of our time to raise a big stink about it. [2011-03-15 13:01:55] maciej at wiercinski dot net Thanks for the update, it's indeed Debian's fault. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618462 [2011-03-14 19:36:38] der...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Complain at your distribution for messing it up. [2011-03-14 19:27:58] ras...@php.net I think this is going to make Derick's head explode :) This is likely due to the fact that Ubuntu patches PHP to use the system timezone info as opposed to the default bundled data. If you build a clean version of PHP on Ubuntu using the code we actually distribute, I think you will find that the problem goes away. [2011-03-14 19:11:29] maciej at wiercinski dot net Description: Upon first call to date_default_timezone_set, PHP syscalls stat() on all the files in /usr/share/zoneinfo. It can be easily checked by running: $ strace -s 100 -r php -n
[PHP-BUG] Bug #54278 [NEW]: mysqli extension compiles against mysql-5.5.9 but does not run
From: Operating system: Linux PHP version: Irrelevant Package: Reproducible crash Bug Type: Bug Bug description:mysqli extension compiles against mysql-5.5.9 but does not run Description: PHP-5.1.6 mysqli extension compiles against mysql-5.5.9 but fails to load. The failure message is: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so: undefined symbol: mysql_disable_reads_from_master in Unknown on line 0 The reason for this is that the msql_disable_ functions were removed from mysql, as per the following bug: http://bugs.mysql.com/bug.php?id=31952 Please update such that php-5.1.6 is compatible with mysql-5.5 Thanks! -- Edit bug report at http://bugs.php.net/bug.php?id=54278edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54278r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54278r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54278r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54278r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54278r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54278r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54278r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54278r=needscript Try newer version: http://bugs.php.net/fix.php?id=54278r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54278r=support Expected behavior: http://bugs.php.net/fix.php?id=54278r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54278r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54278r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54278r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54278r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54278r=dst IIS Stability: http://bugs.php.net/fix.php?id=54278r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54278r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54278r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54278r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54278r=mysqlcfg
Bug #54278 [Opn-Bgs]: mysqli extension compiles against mysql-5.5.9 but does not run
Edit report at http://bugs.php.net/bug.php?id=54278edit=1 ID: 54278 Updated by: johan...@php.net Reported by:michael at nileguide dot com Summary:mysqli extension compiles against mysql-5.5.9 but does not run -Status: Open +Status: Bogus Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: This feature was removed with PHP 5.3.0. PHP 5.1 is not supported anymore for a lng time. Previous Comments: [2011-03-16 19:10:05] michael at nileguide dot com Description: PHP-5.1.6 mysqli extension compiles against mysql-5.5.9 but fails to load. The failure message is: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so: undefined symbol: mysql_disable_reads_from_master in Unknown on line 0 The reason for this is that the msql_disable_ functions were removed from mysql, as per the following bug: http://bugs.mysql.com/bug.php?id=31952 Please update such that php-5.1.6 is compatible with mysql-5.5 Thanks! -- Edit this bug report at http://bugs.php.net/bug.php?id=54278edit=1
Bug #53696 [Com]: erroneous automatic entry into httpd.conf
Edit report at http://bugs.php.net/bug.php?id=53696edit=1 ID: 53696 Comment by: masikwha at yahoo dot com Reported by:helge dot rowold at datendrexler dot de Summary:erroneous automatic entry into httpd.conf Status: Closed Type: Bug Package:Apache2 related Operating System: Windows 7 PHP Version:5.3.5 Assigned To:jmertic Block user comment: N Private report: N New Comment: Adding to http.conf following: PHPInidir C:/PHP LoadModule php5_module php5apache2_2.dll Error: Invalid command 'PHPIniDir' perhaps misspelled or defined by a module not included in the server configuration.. While installing php 5.3.5 with installer, gives you option to choose web server from a list of many, I chose Apache 2.2x module, but this adds to http.conf #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL ScriptAlias /php/ Action application/x-httpd-php php-cgi.exe #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL So tried installing php5.3.3 without selecting web server, this adds nothing to http.conf file but adding PHPIniDir ... gives error I have repeated the installation process of PHP manually as well by extracting zipped files to C:/PHP folder same result. Seems like PHIIniDir directive in http.conf file is not understood by Apache 2.2.17, hence I tried installing apache 2.2.064(previous version) but the same result. Previous Comments: [2011-03-16 08:09:30] helge dot rowold at datendrexler dot de Hello masikwha, in my opinion you should be able to fix the error on Vista, too, by adding the following two lines to your httpd.conf file (in case you would like to use PHP as Apache module and *not* via CGI): PHPIniDir php_partition_char:/php_program_path/php_dir_name/ LoadModule php5_module php_partition_char:/php_program_path/php5apache2_2.dll The strings php_partition_char, php_program_path, and php_dir_name have to be replaced with the real path to your PHP installation directory, of course. [2011-03-16 04:48:04] masikwha at yahoo dot com the problems discussed here for windows 7 seems to be far different than what I am experincing on Vista. After successful installatioin of Apache 2.2.17 on Vista, php-5.3.5-Win32-VC9-x86 (Thread safe) installer seems to add following lines on httpd.conf file, #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL ScriptAlias /php/ Action application/x-httpd-php php-cgi.exe #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL (Note there is no PHPIniDir ) On restarting the apache it gives error saying, ScriptAlias takes two names, fake name and real name... I tried commenting #CriptAlias /php/ , Apache runs ok but it doesn't php is not working. For proper installation of PHP 5.3.5 is that all the changes necessary ?? (which however is not working )? [2011-01-19 21:57:49] jmer...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2011-01-10 11:18:51] alvaro at demogracia dot com Same symptoms here under Windows XP. Apache cannot find php5apache2_2.dll even if at default location: The Apache service named reported the following error: httpd.exe: Syntax error on line 516 of C:/Archivos de programa/Apache Software Foundation/Apache2.2/conf/httpd.conf: Cannot load C:/Archivos de programa/Apache Software Foundation/Apache2.2/php5apache2_2.dll into server: No se puede encontrar el m\xf3dulo . Copying settings from PHP/5.3.4 fixes the issue: #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL PHPIniDir C:/Archivos de programa/PHP/ LoadModule php5_module C:/Archivos de programa/PHP/php5apache2_2.dll #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL [2011-01-08 14:57:09] paj...@php.net hi John, Something went wrong in the last installer update. 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/bug.php?id=53696 -- Edit this bug report at http://bugs.php.net/bug.php?id=53696edit=1
Bug #54256 [Opn-Fbk]: DirectoryIterator isn't iterable with a foreach
Edit report at http://bugs.php.net/bug.php?id=54256edit=1
ID: 54256
Updated by: johan...@php.net
Reported by:gege2061 at homecomputing dot fr
Summary:DirectoryIterator isn't iterable with a foreach
-Status: Open
+Status: Feedback
Type: Bug
Package:SPL related
Operating System: Debian unstable
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works perfectly for me. PHP version: 5.3.5-1 is none of our version
numbers. MAybe your distribution has patched this somehow. Please test
our version or talk to the distributor.
Previous Comments:
[2011-03-15 15:23:26] gege2061 at homecomputing dot fr
Description:
Hello,
DirectoryIterator is iterable in a while but not in a foreach.
This bug is reproductible only on a vboxsf filesystem. I run this script
on Debian sid hosted on Windows XP (NTFS formated hd).
I have no problem when I execute this script on Windows or on a virtual
disk.
Test script:
---
?php
function test_iterator($dirname) {
$files = array();
$dir = new DirectoryIterator($dirname);
while($dir-valid()) {
$files[] = (string)$dir-current();
$dir-next();
}
return $files;
}
function test_iterator_bug($dirname) {
$files = array();
$dir = new DirectoryIterator($dirname);
foreach($dir as $file) {
$files[] = (string)$file;
}
return $files;
}
echo 'PHP version: ' . phpversion() . \n\n;
$dirname = dirname(__FILE__);
foreach (array('iterator', 'iterator_bug') as $test_name) {
echo --- {$test_name} ---\n;
$foo = test_{$test_name};
var_dump($foo($dirname));
echo \n;
}
Expected result:
PHP version: 5.3.5-1
--- iterator ---
array(3) {
[0]=
string(1) .
[1]=
string(2) ..
[2]=
string(9) index.php
}
--- iterator_bug ---
array(3) {
[0]=
string(1) .
[1]=
string(2) ..
[2]=
string(9) index.php
}
Actual result:
--
PHP version: 5.3.5-1
--- iterator ---
array(3) {
[0]=
string(1) .
[1]=
string(2) ..
[2]=
string(9) index.php
}
--- iterator_bug ---
array(0) {
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=54256edit=1
Bug #54250 [Com]: date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call
Edit report at http://bugs.php.net/bug.php?id=54250edit=1 ID: 54250 Comment by: maciej at wiercinski dot net Reported by:maciej at wiercinski dot net Summary:date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call Status: Bogus Type: Bug Package:Date/time related Operating System: Linux 2.6 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: johan...@php.net: I can see at least two problems Debian (and other distribution) maintainers will have with the solution you have proposed. They would have to make PHP dependent on PECL, which is currently not the case (at least not in Debian). On other hand it will eventually lead to a situation in which PHP's timezone update has been rolled out and system's not, or vice-versa. Previous Comments: [2011-03-16 18:56:32] johan...@php.net vJust a small comment on The PHP tzdata changes are mixed in with the mainline development, and sometimes depend on other changes within the engine, so it's not really feasible to cherry pick out the changes into a stable release, even if we wanted to. This is not true. Distributions can distribute the timezone update using the pecl/timzeone package. No messing with engine stuff needed. [2011-03-15 18:52:29] seanius at debian dot org Hi guys, We'll take up further discussion on the bug over there, but thought I would cut/paste the (slightly amended) initial response here just for posterity's sake. === Hi Maciej, Does this actually cause a quantifiable and significant performance regression? This possibility of performance issues was discussed some time ago but it was decided that the stat calls would just hit the kernel fs cache and not cause any serious problems. If there are indeed problems, there are certainly ways this could be worked around, but it would add even further complexity to the patch which we'd all prefer to avoid if possible. To give you some extra background, since the PHP authors certainly have their own take on the situation: EVERY serious linux distribution ships this patch in some form. Redhat, Fedora, Debian, Ubuntu, SLES, Opensuse (okay, maybe not Gentoo, but anyway...) all ship with this patch. So please keep that in mind when you here both sides of this argument :) The problem is that when the OS distributors release a timezone update, they don't want to *also* have to go package by package updating individual and customized timezone databases that might be embedded in a given application. Neither do they want to continuously update the version of PHP in their stable releases and have to deal with the numerous regressions that would result. The PHP tzdata changes are mixed in with the mainline development, and sometimes depend on other changes within the engine, so it's not really feasible to cherry pick out the changes into a stable release, even if we wanted to. This is a point of disagreement with the PHP authors, who want to have control over this aspect of the engine themselves (and they certainly have their justifications, such as systems with outdated or nonexistant tzdata, plus they add some extra TZ annotations in their private copy). Unfortunately they are not interested in providing any other way to work around this issue, despite the periodic overture from us or RedHat. The invitation is still open to try and find a reasonable technical solution for this, but I have been led to beleive that Derick has really dug in his heels on the issue and it's not worth any of our time to raise a big stink about it. [2011-03-15 13:01:55] maciej at wiercinski dot net Thanks for the update, it's indeed Debian's fault. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618462 [2011-03-14 19:36:38] der...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Complain at your distribution for messing it up. [2011-03-14 19:27:58] ras...@php.net I think this is going to make Derick's head explode :) This is likely due to the fact that Ubuntu patches PHP to use the system timezone info as opposed
Bug #54250 [Bgs]: date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call
Edit report at http://bugs.php.net/bug.php?id=54250edit=1 ID: 54250 Updated by: ras...@php.net Reported by:maciej at wiercinski dot net Summary:date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call Status: Bogus Type: Bug Package:Date/time related Operating System: Linux 2.6 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Why not just make pecl/timezone dependent on the system timezone update. It seems easy enough to me. Your PHP package depends on pecl/timezone and pecl/timezone depends on the system timezone package. That should keep it all in synch. Previous Comments: [2011-03-16 22:52:34] maciej at wiercinski dot net johan...@php.net: I can see at least two problems Debian (and other distribution) maintainers will have with the solution you have proposed. They would have to make PHP dependent on PECL, which is currently not the case (at least not in Debian). On other hand it will eventually lead to a situation in which PHP's timezone update has been rolled out and system's not, or vice-versa. [2011-03-16 18:56:32] johan...@php.net vJust a small comment on The PHP tzdata changes are mixed in with the mainline development, and sometimes depend on other changes within the engine, so it's not really feasible to cherry pick out the changes into a stable release, even if we wanted to. This is not true. Distributions can distribute the timezone update using the pecl/timzeone package. No messing with engine stuff needed. [2011-03-15 18:52:29] seanius at debian dot org Hi guys, We'll take up further discussion on the bug over there, but thought I would cut/paste the (slightly amended) initial response here just for posterity's sake. === Hi Maciej, Does this actually cause a quantifiable and significant performance regression? This possibility of performance issues was discussed some time ago but it was decided that the stat calls would just hit the kernel fs cache and not cause any serious problems. If there are indeed problems, there are certainly ways this could be worked around, but it would add even further complexity to the patch which we'd all prefer to avoid if possible. To give you some extra background, since the PHP authors certainly have their own take on the situation: EVERY serious linux distribution ships this patch in some form. Redhat, Fedora, Debian, Ubuntu, SLES, Opensuse (okay, maybe not Gentoo, but anyway...) all ship with this patch. So please keep that in mind when you here both sides of this argument :) The problem is that when the OS distributors release a timezone update, they don't want to *also* have to go package by package updating individual and customized timezone databases that might be embedded in a given application. Neither do they want to continuously update the version of PHP in their stable releases and have to deal with the numerous regressions that would result. The PHP tzdata changes are mixed in with the mainline development, and sometimes depend on other changes within the engine, so it's not really feasible to cherry pick out the changes into a stable release, even if we wanted to. This is a point of disagreement with the PHP authors, who want to have control over this aspect of the engine themselves (and they certainly have their justifications, such as systems with outdated or nonexistant tzdata, plus they add some extra TZ annotations in their private copy). Unfortunately they are not interested in providing any other way to work around this issue, despite the periodic overture from us or RedHat. The invitation is still open to try and find a reasonable technical solution for this, but I have been led to beleive that Derick has really dug in his heels on the issue and it's not worth any of our time to raise a big stink about it. [2011-03-15 13:01:55] maciej at wiercinski dot net Thanks for the update, it's indeed Debian's fault. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618462 [2011-03-14 19:36:38] der...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you.
[PHP-BUG] Bug #54279 [NEW]: preg_grep does not recognize this regex '/[0-9]*$/' to filter numbers out
From:
Operating system: Ubuntu 10.10
PHP version: 5.3SVN-2011-03-16 (SVN)
Package: PCRE related
Bug Type: Bug
Bug description:preg_grep does not recognize this regex '/[0-9]*$/' to filter
numbers out
Description:
I am trying to filter numbers from the end of a string in a array.
i have a array full of these strings :
$testArr = array('foto_1','foto_45');
$resArr = preg_grep('/[0-9]*$/',$testArr);
and the $resArr array that gets returned from preg_grep, contains the same
strings, i am looking for a array that contains just the numbers that were
filtered using the regex
Test script:
---
?php
$testArr = array('foto_1','foto_45');
$resArr = preg_grep('/[0-9]*$/',$testArr);
print_r($resArr);
?
Expected result:
to see a array full of the numbers what were at the end of the string in
the
input array
something like this :
Array
(
[0] = 1
[1] = 45
)
Actual result:
--
Array
(
[0] = foto_1
[1] = foto_45
)
--
Edit bug report at http://bugs.php.net/bug.php?id=54279edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54279r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54279r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54279r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54279r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54279r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54279r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54279r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54279r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54279r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54279r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54279r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54279r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54279r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54279r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54279r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54279r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54279r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54279r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54279r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54279r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54279r=mysqlcfg
Bug #54279 [Opn-Bgs]: preg_grep does not recognize this regex '/[0-9]*$/' to filter numbers out
Edit report at http://bugs.php.net/bug.php?id=54279edit=1
ID: 54279
Updated by: fel...@php.net
Reported by:donciprian at gmail dot com
Summary:preg_grep does not recognize this regex '/[0-9]*$/'
to filter numbers out
-Status: Open
+Status: Bogus
Type: Bug
Package:PCRE related
Operating System: Ubuntu 10.10
PHP Version:5.3SVN-2011-03-16 (SVN)
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
There is no bug here... preg_grep is not meant to return the group
captured data separately... You need to use
preg_match()/preg_match_all() for such.
Previous Comments:
[2011-03-16 23:26:42] donciprian at gmail dot com
Description:
I am trying to filter numbers from the end of a string in a array.
i have a array full of these strings :
$testArr = array('foto_1','foto_45');
$resArr = preg_grep('/[0-9]*$/',$testArr);
and the $resArr array that gets returned from preg_grep, contains the
same
strings, i am looking for a array that contains just the numbers that
were
filtered using the regex
Test script:
---
?php
$testArr = array('foto_1','foto_45');
$resArr = preg_grep('/[0-9]*$/',$testArr);
print_r($resArr);
?
Expected result:
to see a array full of the numbers what were at the end of the string in
the
input array
something like this :
Array
(
[0] = 1
[1] = 45
)
Actual result:
--
Array
(
[0] = foto_1
[1] = foto_45
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=54279edit=1
Bug #54279 [Com]: preg_grep does not recognize this regex '/[0-9]*$/' to filter numbers out
Edit report at http://bugs.php.net/bug.php?id=54279edit=1
ID: 54279
Comment by: donciprian at gmail dot com
Reported by:donciprian at gmail dot com
Summary:preg_grep does not recognize this regex '/[0-9]*$/'
to filter numbers out
Status: Bogus
Type: Bug
Package:PCRE related
Operating System: Ubuntu 10.10
PHP Version:5.3SVN-2011-03-16 (SVN)
Block user comment: N
Private report: N
New Comment:
oops, my mistake ;)
Previous Comments:
[2011-03-16 23:42:02] fel...@php.net
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
There is no bug here... preg_grep is not meant to return the group
captured data separately... You need to use
preg_match()/preg_match_all() for such.
[2011-03-16 23:26:42] donciprian at gmail dot com
Description:
I am trying to filter numbers from the end of a string in a array.
i have a array full of these strings :
$testArr = array('foto_1','foto_45');
$resArr = preg_grep('/[0-9]*$/',$testArr);
and the $resArr array that gets returned from preg_grep, contains the
same
strings, i am looking for a array that contains just the numbers that
were
filtered using the regex
Test script:
---
?php
$testArr = array('foto_1','foto_45');
$resArr = preg_grep('/[0-9]*$/',$testArr);
print_r($resArr);
?
Expected result:
to see a array full of the numbers what were at the end of the string in
the
input array
something like this :
Array
(
[0] = 1
[1] = 45
)
Actual result:
--
Array
(
[0] = foto_1
[1] = foto_45
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=54279edit=1
Bug #54250 [Com]: date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call
Edit report at http://bugs.php.net/bug.php?id=54250edit=1 ID: 54250 Comment by: maciej at wiercinski dot net Reported by:maciej at wiercinski dot net Summary:date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call Status: Bogus Type: Bug Package:Date/time related Operating System: Linux 2.6 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: ras...@php.net: It will still force them to distribute PECL (may be a concern for people building embedded/very small systems shipped with PHP). I don't really know PHP code, had just a very brief look at the patch itself and related functions, so what I'm saying may be completely invalid. What about compiling timezone data into dynamically loaded library, which they could ship separately of PECL/PHP itself / easily replace with calls to theirs? Previous Comments: [2011-03-16 22:56:15] ras...@php.net Why not just make pecl/timezone dependent on the system timezone update. It seems easy enough to me. Your PHP package depends on pecl/timezone and pecl/timezone depends on the system timezone package. That should keep it all in synch. [2011-03-16 22:52:34] maciej at wiercinski dot net johan...@php.net: I can see at least two problems Debian (and other distribution) maintainers will have with the solution you have proposed. They would have to make PHP dependent on PECL, which is currently not the case (at least not in Debian). On other hand it will eventually lead to a situation in which PHP's timezone update has been rolled out and system's not, or vice-versa. [2011-03-16 18:56:32] johan...@php.net vJust a small comment on The PHP tzdata changes are mixed in with the mainline development, and sometimes depend on other changes within the engine, so it's not really feasible to cherry pick out the changes into a stable release, even if we wanted to. This is not true. Distributions can distribute the timezone update using the pecl/timzeone package. No messing with engine stuff needed. [2011-03-15 18:52:29] seanius at debian dot org Hi guys, We'll take up further discussion on the bug over there, but thought I would cut/paste the (slightly amended) initial response here just for posterity's sake. === Hi Maciej, Does this actually cause a quantifiable and significant performance regression? This possibility of performance issues was discussed some time ago but it was decided that the stat calls would just hit the kernel fs cache and not cause any serious problems. If there are indeed problems, there are certainly ways this could be worked around, but it would add even further complexity to the patch which we'd all prefer to avoid if possible. To give you some extra background, since the PHP authors certainly have their own take on the situation: EVERY serious linux distribution ships this patch in some form. Redhat, Fedora, Debian, Ubuntu, SLES, Opensuse (okay, maybe not Gentoo, but anyway...) all ship with this patch. So please keep that in mind when you here both sides of this argument :) The problem is that when the OS distributors release a timezone update, they don't want to *also* have to go package by package updating individual and customized timezone databases that might be embedded in a given application. Neither do they want to continuously update the version of PHP in their stable releases and have to deal with the numerous regressions that would result. The PHP tzdata changes are mixed in with the mainline development, and sometimes depend on other changes within the engine, so it's not really feasible to cherry pick out the changes into a stable release, even if we wanted to. This is a point of disagreement with the PHP authors, who want to have control over this aspect of the engine themselves (and they certainly have their justifications, such as systems with outdated or nonexistant tzdata, plus they add some extra TZ annotations in their private copy). Unfortunately they are not interested in providing any other way to work around this issue, despite the periodic overture from us or RedHat. The invitation is still open to try and find a reasonable technical solution for this, but I have been led to beleive that Derick has really dug in his heels on the issue and it's not worth any of our time to raise a big stink about it. [2011-03-15 13:01:55] maciej at wiercinski dot net Thanks for the update, it's indeed Debian's
Bug #54250 [Bgs]: date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call
Edit report at http://bugs.php.net/bug.php?id=54250edit=1 ID: 54250 Updated by: ras...@php.net Reported by:maciej at wiercinski dot net Summary:date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call Status: Bogus Type: Bug Package:Date/time related Operating System: Linux 2.6 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: No it won't. You can distribute a binary pecl extension without needing PECL. I'm not even sure what you mean by PECL here. An individual pecl extension is just a simple shared library. Nothing more. Previous Comments: [2011-03-17 00:02:47] maciej at wiercinski dot net ras...@php.net: It will still force them to distribute PECL (may be a concern for people building embedded/very small systems shipped with PHP). I don't really know PHP code, had just a very brief look at the patch itself and related functions, so what I'm saying may be completely invalid. What about compiling timezone data into dynamically loaded library, which they could ship separately of PECL/PHP itself / easily replace with calls to theirs? [2011-03-16 22:56:15] ras...@php.net Why not just make pecl/timezone dependent on the system timezone update. It seems easy enough to me. Your PHP package depends on pecl/timezone and pecl/timezone depends on the system timezone package. That should keep it all in synch. [2011-03-16 22:52:34] maciej at wiercinski dot net johan...@php.net: I can see at least two problems Debian (and other distribution) maintainers will have with the solution you have proposed. They would have to make PHP dependent on PECL, which is currently not the case (at least not in Debian). On other hand it will eventually lead to a situation in which PHP's timezone update has been rolled out and system's not, or vice-versa. [2011-03-16 18:56:32] johan...@php.net vJust a small comment on The PHP tzdata changes are mixed in with the mainline development, and sometimes depend on other changes within the engine, so it's not really feasible to cherry pick out the changes into a stable release, even if we wanted to. This is not true. Distributions can distribute the timezone update using the pecl/timzeone package. No messing with engine stuff needed. [2011-03-15 18:52:29] seanius at debian dot org Hi guys, We'll take up further discussion on the bug over there, but thought I would cut/paste the (slightly amended) initial response here just for posterity's sake. === Hi Maciej, Does this actually cause a quantifiable and significant performance regression? This possibility of performance issues was discussed some time ago but it was decided that the stat calls would just hit the kernel fs cache and not cause any serious problems. If there are indeed problems, there are certainly ways this could be worked around, but it would add even further complexity to the patch which we'd all prefer to avoid if possible. To give you some extra background, since the PHP authors certainly have their own take on the situation: EVERY serious linux distribution ships this patch in some form. Redhat, Fedora, Debian, Ubuntu, SLES, Opensuse (okay, maybe not Gentoo, but anyway...) all ship with this patch. So please keep that in mind when you here both sides of this argument :) The problem is that when the OS distributors release a timezone update, they don't want to *also* have to go package by package updating individual and customized timezone databases that might be embedded in a given application. Neither do they want to continuously update the version of PHP in their stable releases and have to deal with the numerous regressions that would result. The PHP tzdata changes are mixed in with the mainline development, and sometimes depend on other changes within the engine, so it's not really feasible to cherry pick out the changes into a stable release, even if we wanted to. This is a point of disagreement with the PHP authors, who want to have control over this aspect of the engine themselves (and they certainly have their justifications, such as systems with outdated or nonexistant tzdata, plus they add some extra TZ annotations in their private copy). Unfortunately they are not interested in providing any other way to work around this issue, despite the periodic overture from us or RedHat. The invitation is still open to try and find a reasonable technical solution for this, but I have
Bug #54250 [Com]: date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call
Edit report at http://bugs.php.net/bug.php?id=54250edit=1 ID: 54250 Comment by: maciej at wiercinski dot net Reported by:maciej at wiercinski dot net Summary:date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call Status: Bogus Type: Bug Package:Date/time related Operating System: Linux 2.6 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: I thought you've meant triggering pecl upgrade upon installing the new version of php-timezone package. Previous Comments: [2011-03-17 00:10:44] ras...@php.net No it won't. You can distribute a binary pecl extension without needing PECL. I'm not even sure what you mean by PECL here. An individual pecl extension is just a simple shared library. Nothing more. [2011-03-17 00:02:47] maciej at wiercinski dot net ras...@php.net: It will still force them to distribute PECL (may be a concern for people building embedded/very small systems shipped with PHP). I don't really know PHP code, had just a very brief look at the patch itself and related functions, so what I'm saying may be completely invalid. What about compiling timezone data into dynamically loaded library, which they could ship separately of PECL/PHP itself / easily replace with calls to theirs? [2011-03-16 22:56:15] ras...@php.net Why not just make pecl/timezone dependent on the system timezone update. It seems easy enough to me. Your PHP package depends on pecl/timezone and pecl/timezone depends on the system timezone package. That should keep it all in synch. [2011-03-16 22:52:34] maciej at wiercinski dot net johan...@php.net: I can see at least two problems Debian (and other distribution) maintainers will have with the solution you have proposed. They would have to make PHP dependent on PECL, which is currently not the case (at least not in Debian). On other hand it will eventually lead to a situation in which PHP's timezone update has been rolled out and system's not, or vice-versa. [2011-03-16 18:56:32] johan...@php.net vJust a small comment on The PHP tzdata changes are mixed in with the mainline development, and sometimes depend on other changes within the engine, so it's not really feasible to cherry pick out the changes into a stable release, even if we wanted to. This is not true. Distributions can distribute the timezone update using the pecl/timzeone package. No messing with engine stuff needed. 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/bug.php?id=54250 -- Edit this bug report at http://bugs.php.net/bug.php?id=54250edit=1
