Bug #62197 [Nab]: Starting Apache failed
Edit report at https://bugs.php.net/bug.php?id=62197edit=1 ID: 62197 User updated by:thierry dot tisserand at lu dot nomura dot com Reported by:thierry dot tisserand at lu dot nomura dot com Summary:Starting Apache failed Status: Not a bug Type: Bug Package:Apache related Operating System: AIX 7100-01-02-1150 (64 bits) PHP Version:5.3.13 Block user comment: N Private report: N New Comment: Helle As far, no clue. I use httpd-2.2.21 with php-5.3.13. Regards Previous Comments: [2012-06-07 08:56:28] thierry dot tisserand at lu dot nomura dot com Thank you for your answer. I'm going to contact the package manager. [2012-06-04 23:46:20] johan...@php.net We don't provide those packages. Wehave no control over them. [2012-06-03 01:46:24] omg00dness at yahoo dot com Have you taken steps to contact the package manager? Have you posted on forums/mailing lists for your operating system or package manager? What makes you sure this is a PHP Bug and not user error or the package? Have you installed from source? I consider the bug reporting system to be more for bugs than a troubleshooting forum. That's why I'm asking all those questions, since not many people may be able to replicate your setup. The error seems to be pretty straight forward and you appear to be missing modules. That may be from the packager. [2012-06-01 07:21:28] thierry dot tisserand at lu dot nomura dot com httpd-2.2.21 and (php-5.3.8 ou php-5.3.13) OK httpd-2.4.2 and (php-5.3.8 ou php-5.3.13) KO, = rtld: 0712-001 Symbol ap_log_error was referenced [2012-05-31 10:42:26] thierry dot tisserand at lu dot nomura dot com Description: Apache 2.4.2 and php-5.3.13-1.aix5.1 has been installed with RPM (http://www.perzl.org/aix) Apache only (Include conf/extra/httpd-php.conf has been comment in the f)ile httpd.conf) start without error. If I try to start Apache wtih php, I had an error: Test script: --- /opt/freeware/sbin/apachectl -k start Actual result: -- httpd: Syntax error on line 513 of /opt/freeware/etc/httpd/conf/httpd.conf: Syntax error on line 6 of /opt/freeware/etc/httpd/conf/extra/httpd-php.conf: Cannot load /opt/freeware/lib/httpd/modules/libphp5.so into server: rtld: 0712-001 Symbol ap_log_error was referenced\n from module /opt/freeware/lib/httpd/modules/libphp5.so(), but a runtime definition\n\t of the symbol was not found.\nrtld: 0712-001 Symbol ap_log_rerror was referenced\n from module /opt/freeware/lib/httpd/modules/libphp5.so(), but a runtime definition\n\tof the symbol was not found.\nrtld: 0712-001 Symbol ap_get_server_version was referenced\n from module /opt/freeware/lib/httpd/modules/libphp5.so(), but a runtime definition\n\t of the symbol was not found.\nrtld: 0712-001 Symbol unixd_config was referenced\n from module /opt/freeware/lib/httpd/modules/libphp5.so(), but a runtime definition\n\tof the symbol was not found. -- Edit this bug report at https://bugs.php.net/bug.php?id=62197edit=1
Bug #54254 [Opn-Csd]: cal_from_jd returns month = 6 when there is only one Adar
Edit report at https://bugs.php.net/bug.php?id=54254edit=1 ID: 54254 Updated by: s...@php.net Reported by:asphp at dsgml dot com Summary:cal_from_jd returns month = 6 when there is only one Adar -Status: Open +Status: Closed Type: Bug Package:Calendar related PHP Version:5.3.5 -Assigned To: +Assigned To:stas Block user comment: N Private report: N New Comment: 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. fixed in master Previous Comments: [2012-03-29 18:33:50] asphp at dsgml dot com woordengeschrift you misunderstand the Hebrew calendar. In non-leap years there is a gap, the calendar months go: 4,5,7,8 - month 6 is skipped. Unfortunately PHP does 4,5,6,8 - it skips month 7 instead of 6 which is incorrect. In a leap year it is AdarI that is added - AdarII is the same as Adar. Yes, I know you would expect the second one to be the extra, but that's not how the calendar works. [2012-03-29 12:13:03] info at woordengeschrift dot nl In NON-leap years, there is only the unnumbered month of Adar. [2012-03-29 12:09:41] info at woordengeschrift dot nl In leap years, there is only the unnumbered month of Adar. Numbered Adars only occur in leap years: Adar_I (the actual leap month), followed by Adar_II. [2011-03-15 09:53:50] asphp at dsgml dot com Description: cal_from_jd() returns 6 for Adar when there is only one Adar, (it should return 7, since if there is only one Adar it's AdarII). It also says AdarI, which is wrong (it should be either Adar or at least AdarII). Furthermore the cal_days_in_month() (correctly) only works with month 7, and not 6 as returned by cal_from_jd. Test script: --- ? print_r(cal_from_jd(2456005, CAL_JEWISH)); echo cal_days_in_month(CAL_JEWISH, 6, 5772) . \n; echo cal_days_in_month(CAL_JEWISH, 7, 5772) . \n; ? Expected result: The month in cal_from_jd should be 7. The second two lines demonstrate how cal_days_in_month also expects the month to be 7. Actual result: -- Array ( [date] = 6/24/5772 [month] = 6 [day] = 24 [year] = 5772 [dow] = 0 [abbrevdayname] = Sun [dayname] = Sunday [abbrevmonth] = AdarI [monthname] = AdarI ) 0 29 -- Edit this bug report at https://bugs.php.net/bug.php?id=54254edit=1
Req #49705 [Com]: DOMDocument::loadHTML should have a way to override charset
Edit report at https://bugs.php.net/bug.php?id=49705edit=1 ID: 49705 Comment by: glen_scott at yahoo dot co dot uk Reported by:lyngvi at gmail dot com Summary:DOMDocument::loadHTML should have a way to override charset Status: Open Type: Feature/Change Request Package:DOM XML related Operating System: linux PHP Version:5.3.0 Block user comment: N Private report: N New Comment: To workaround this issue, you may want to use this extended DOMDocument which allows you to specify the character encoding when loading HTML documents: https://github.com/glenscott/dom-document-charset Please let me know if it is of use. Previous Comments: [2009-09-29 04:09:26] lyngvi at gmail dot com Description: I propose that DOMDocument::loadHTML($data) be extended to DOMDocument::loadHTML($data, $forceCharset=null); loadXML might be able to use the same feature, though fixing the XML charset would be easier than HTML's. Requiring the charset to be specified as a meta http-equiv content-type inside the raw HTML data is clumsy, especially since HTML is often so poorly formed. Generally I try to know my charset a priori, a good practice usually, but, in this case, one that I am being punished for. The situation I most recently came across was a in loading data off a site serving proper UTF-8 data, with *HTTP* content-type text/html charset utf-8, but the redundant meta http-equiv reporting charset iso-8859-1. See the repro code below. Ideally I could fix the serving site, I know. I can't in this case. Ideally, there would be no famine and no war. Thanks! Reproduce code: --- ?php header(Content-Type: text/html; charset=utf-8); $htmldata = HTMLDATA HTMlheadtitlei our pooryl writn web page meta http-equiv=content-type content=text/html; charset=iso-8859-1; / /head bodythis is a utf8 apostrophe: /body /html HTMLDATA; $doc = DOMDocument::loadHTML($htmldata); echo $doc-getElementsByTagName(body)-item(0)-textContent; ? Expected result: this is a utf8 apostrophe: (the apostrophe shows up correctly - I don't want DOMDocument to mutilate my text) Actual result: -- this is a utf8 apostrophe: â#128;#153; (I get a with a ^ on top, and the illegal characters \u0080 and \u0099 - that is, loadHTML re-encoded \u2019 (e2 80 99) to get \u00e2 \u0080 \u0099 (c3 a2 c2 80 c2 93)) -- Edit this bug report at https://bugs.php.net/bug.php?id=49705edit=1
Bug #60724 [Opn]: Includes fails at compile time when using bracketed namespaces
Edit report at https://bugs.php.net/bug.php?id=60724edit=1
ID: 60724
User updated by:nicolas dot grekas+php at gmail dot com
Reported by:nicolas dot grekas+php at gmail dot com
Summary:Includes fails at compile time when using bracketed
namespaces
Status: Open
Type: Bug
Package:Scripting Engine problem
-PHP Version:5.4.0RC5
+PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
The bug is still there is the latest version of PHP
Previous Comments:
[2012-01-12 10:25:09] nicolas dot grekas+php at gmail dot com
Description:
Tested in 5.3.8, 5.2.9 and 5.4RC5, APC not enabled.
At compile time, two nested includes fail when both use bracketed namespaces or
mix bracketed and unbracketed ones.
The compile time behavior of PHP is described in:
https://bugs.php.net/bug.php?id=42098
I found a workaround that makes me think that some internal state is not
initialized correctly when using namespaces.
See test script for more details.
Test script:
---
?php
// This test script uses eval, but the same arise when including files.
error_reporting(E_ALL | E_STRICT);
set_error_handler('eh');
// The code in the eval triggers an E_DEPRECATED because of = new
// so eh() is called to handle the error, _at_compile_time_.
// Note the unbracketed namespace declaration.
eval('namespace b; $a = new \stdClass; ');
function eh()
{
// dynamically load class a\abc,
// using bracketed namespace declaration
// but this fails with fatal error.
// uncomment the following line, and things work again perfectly.
//eval(';');
eval('namespace a{ class abc{} }');
print_r(new a\abc);
}
Expected result:
No error
Actual result:
--
Fatal error: Cannot mix bracketed namespace declarations with unbracketed
namespace declarations
--
Edit this bug report at https://bugs.php.net/bug.php?id=60724edit=1
[PHP-BUG] Bug #62769 [NEW]: Inconsistent notice reporting using []
From: julien at palard dot fr
Operating system:
PHP version: 5.4.5
Package: Output Control
Bug Type: Bug
Bug description:Inconsistent notice reporting using []
Description:
Error reported for invalid [] access seems inconsistent :
echo NULL[bar] - Parse error
echo [][bar] - Parse error
$foo = NULL; echo $foo[bar] - Fails silently
$foo = []; echo $foo[bar] - Notice: Undefined index
class Bar {} ; $foo = new Bar(); echo $foo[bar]; - PHP Fatal error
I whish :
[][bar] to trigger Notice: Undefined index
NULL[bar] to trigger something catcheable with set_error_handler
$foo = NULL; $foo[bar] to trigger a catcheable Notice.
Test script:
---
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); echo [][bar];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); echo NULL[bar];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); $foo = NULL;
$foo[bar];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); $foo = [];
$foo[bar];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); class Bar {} ; $foo =
new Bar(); echo $foo[bar];'
Expected result:
At least get a Notice on :
$foo = NULL;
echo $foo[bar];
Actual result:
--
Fails silently.
--
Edit bug report at https://bugs.php.net/bug.php?id=62769edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62769r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62769r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62769r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62769r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62769r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62769r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62769r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62769r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62769r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62769r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62769r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62769r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62769r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62769r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62769r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62769r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62769r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62769r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62769r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62769r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62769r=mysqlcfg
[PHP-BUG] Bug #62770 [NEW]: fputscv not terminating correctly
From: mcharman at magimedia dot co dot uk Operating system: ALL PHP version: 5.4.6RC1 Package: Testing related Bug Type: Bug Bug description:fputscv not terminating correctly Description: --- From manual page: http://www.php.net/function.fputcsv#refsect1-function.fputcsv-description --- fputcsv outputs a newline character, but many systems also require carriage return. The resulting CSV files do not work with software that supports CSV such as Ship@Ease (DPD). -- Edit bug report at https://bugs.php.net/bug.php?id=62770edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62770r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62770r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62770r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62770r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62770r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62770r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62770r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62770r=needscript Try newer version: https://bugs.php.net/fix.php?id=62770r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62770r=support Expected behavior: https://bugs.php.net/fix.php?id=62770r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62770r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62770r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62770r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62770r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62770r=dst IIS Stability: https://bugs.php.net/fix.php?id=62770r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62770r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62770r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62770r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62770r=mysqlcfg
[PHP-BUG] Bug #62771 [NEW]: Compiling with Imap-2007f is failed
From: gencer at cmail dot cm Operating system: CentOS 6.3 PHP version: 5.4.5 Package: Compile Failure Bug Type: Bug Bug description:Compiling with Imap-2007f is failed Description: When i try to compile with IMAP, it just thrown an error and say error: utf8_mime2text() has old signature, but U8T_CANONICAL is present. This should not happen. Check config.log for additional information. I am trying to use imap-2007f from source. I did make on imap-2007f before compiling PHP and imap relays on /usr/local/imap-2007f I also tried imap-2007e. And yes, libc-client and libc-client-devel is installed by RPM. But the version is 2007e. As i said both 2007e and 2007f gives the same exact error. Here is the config.log - http://www.mediafire.com/?1qpg27j7xd19l6o I built PHP many times with the exact this configure parameters before. All of them on CentOS 5.8. I am getting this error on 6.3. Weird. Same parameters with centos 5.8 did the job. Most weird thing is; If i only use --with-imap (without path) it gives me the same error. Test script: --- './configure' '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib64' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--enable-gd-native-ttf' '--with-t1lib=/usr' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-pcre-regex' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-sockets' '--with-kerberos' '--enable-ucd-snmp-hack' '--enable-shmop' '--enable-calendar' '--with-libxml-dir=/usr' '--enable-libxml' '--with-xmlrpc' '--enable-xml' '--with-system-tzdata' '--with-mhash' '--with-mysql' '--with-gd' '--enable-dom' '--disable-dba' '--without-unixODBC--disable-xmlreader' '--disable-xmlwriter' '--without-sqlite' '--with-sqlite3' '--enable-phar' '--enable-fileinfo' '--enable-json' '--without-pspell' '--disable-wddx' '--disable-posix' '--disable-sysvmsg' '--disable-sysvshm' '--disable-sysvsem' '--enable-pdo' '--enable-mbstring' '--enable-fastcgi' '--with-mcrypt' '--enable-fpm' '--with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd' '--enable-pcntl' '--with-imap=../imap-2007f' '--with-imap-ssl' '--with-pgsql=/usr/pgsql-9.2' '--with-pdo-pgsql=/usr/pgsql-9.2' '--with-curl=../curl-7.26.0' Expected result: PHP compiles as it did before on CentOS 5.8. Actual result: -- checking if your cpp allows macro usage in include lines... yes checking for IMAP support... yes checking for IMAP Kerberos support... yes checking for IMAP SSL support... yes checking for utf8_mime2text signature... (cached) old checking for U8T_DECOMPOSE... configure: error: utf8_mime2text() has old signature, but U8T_CANONICAL is present. This should not happen. Check config.log for additional information. -- Edit bug report at https://bugs.php.net/bug.php?id=62771edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62771r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62771r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62771r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62771r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62771r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62771r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62771r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62771r=needscript Try newer version: https://bugs.php.net/fix.php?id=62771r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62771r=support Expected behavior: https://bugs.php.net/fix.php?id=62771r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62771r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62771r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62771r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62771r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62771r=dst IIS Stability: https://bugs.php.net/fix.php?id=62771r=isapi
Bug #62568 [Nab]: MySQL connect commands do not work
Edit report at https://bugs.php.net/bug.php?id=62568edit=1 ID: 62568 User updated by:brandonskypimenta at gmail dot com Reported by:brandonskypimenta at gmail dot com Summary:MySQL connect commands do not work Status: Not a bug Type: Bug Package:MySQL related Operating System: Mac OS X -PHP Version:Irrelevant +PHP Version:five point three point zero Block user comment: N Private report: N New Comment: change php version Previous Comments: [2012-07-15 04:35:56] ras...@php.net Nothing PHP can do about that. Your client and server don't match. But we do give you an easy work-around by letting you specify the right path using http://www.php.net/manual/en/mysql.configuration.php#ini.mysql.default-socket [2012-07-15 04:16:56] brandonskypimenta at gmail dot com Description: When you try to run mysql_connect() under MySQL under OS X 10.6.2 with MySQL installed (under PHP 5.3.0), you will get an error saying the MySQL socket file doesn't exist. Here's an example with vBulletin 3.8.5: mysql_connect(): No such file or directory /path/to/vbulletin/root/includes/class_core.php on line 314 Expected result: The database could have connected properly. Actual result: -- mysql_connect(): No such file or directory /Users/sky/Sites/vb/includes/class_core.php on line 314 -- Edit this bug report at https://bugs.php.net/bug.php?id=62568edit=1
Bug #61557 [Com]: Crasher (SIGSEGV) bug in tt-rss backend.php
Edit report at https://bugs.php.net/bug.php?id=61557edit=1 ID: 61557 Comment by: niki at guldbrand dot net Reported by:ond...@php.net Summary:Crasher (SIGSEGV) bug in tt-rss backend.php Status: Open Type: Bug Package:*XML functions Operating System: Linux i386 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Is there any status update on getting this fixed/included ? As I'm also hitting this issue on ArchLinux x86_64 with php 5.4.5. And the patch attached to this bug works nicely here too. /Niki Previous Comments: [2012-05-14 12:38:15] bugs-php at antipoul dot fr OK, I've applied this patch on top of all others patches from Debian testing package. After 4h07 compiling (yes, I have a small Via C7 ;) ), I got the package working. Final result: the patch solves the problem. I'm happy. Many thanks to you! [2012-05-11 21:52:38] i dot am dot jack dot mail at gmail dot com I've also experienced this problem after switching to 5.4. Looked into it, and here's what I was able to find : This only happens to CGI/FPM. The first time I trigger a request it works, the second time it crashes. Explains why it appears to work sometimes and others not : it works only once per process. Then it segfaults, a new one is started, repeat. This seems to be linked to the use of libxml_use_internal_errors (w/ TRUE). Apparently the first time it will set an internal error handler in PHP, which remains set after processing the request is done. Then, when another request is processed and libxml_use_internal_errors hasn't been called, that handler can be triggered, only the memory has been reset, resulting in the segfault. As far as I can tell, seems this was introduced with d8bddb9665637d96f20dc4a2ae5668ba376f3b17 which made it that CGI/FPM would not setup/reset libxml callbacks on each request but only once. Only it also included the callback for structured errors, which shouldn't be affected/should still be reset on each new request. I'll attach a patch that should fix this, resetting the callback for each request. Also, I'm not sure/haven't looked into it, but looking at the backtrace I believe that https://bugs.php.net/bug.php?id=61325 might be another manifestation of the same problem. [2012-05-06 20:11:09] j dot nespolo at gmail dot com Hi, I am affected by the same bug, although I wasn't able to generate a backtrace (app running on an openvz container). My setup is as follows: - Debian Sid (fully updated as of 2012/05/06) - latest tt-rss master (last updated on 2012/05/06), https://github.com/gothfox/Tiny-Tiny-RSS - mysql-server 5.1.62-1 - lighttpd 1.4.30-1 with the following modules enabled: auth, fastcgi, fastcgi-php - php 5.4.2-1 The feed reader displays the headings, but shortly after they disappear. The time they survive is quite variable. When this happens, lighttpd's log then says: 2012-05-06 20:06:46: (mod_fastcgi.c.2566) unexpected end-of-file (perhaps the fastcgi process died): pid: 20184 socket: unix:/tmp/php.socket-0 2012-05-06 20:06:46: (mod_fastcgi.c.3352) response not received, request sent: 1381 on socket: unix:/tmp/php.socket-0 for /tt-rss/backend.php?, closing connection Thanks a lot, J [2012-04-01 16:38:25] bugs-php at antipoul dot fr Hi, I just want to say that I have the same issue with FPM. It seems normal, since it's a core issue. [2012-03-30 06:46:28] reeze dot xia at gmaill dot com I can't reproduce it in : - Mac OS X 10.7.3 - libxml 2.2 - PHP-5.4.0 - Tiny Tiny RSS trunk - PHP5.4.0 built-in webserver. more crash detail would be appreciated I will setup a VM like the user and trying to reproduce and trying to find out what happened. 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 https://bugs.php.net/bug.php?id=61557 -- Edit this bug report at https://bugs.php.net/bug.php?id=61557edit=1
Bug #62464 [Com]: implementing two interfaces with same signature no longer gives a fatal error
Edit report at https://bugs.php.net/bug.php?id=62464edit=1
ID: 62464
Comment by: valderrama dot christopher at gmail dot com
Reported by:j dot henge-ernst at interexa dot de
Summary:implementing two interfaces with same signature no
longer gives a fatal error
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: linux
PHP Version:5.3Git-2012-07-02 (Git)
Block user comment: N
Private report: N
New Comment:
The certification guide states that a object can't implement two interfaces
that
share the same method, but the code still runs ok.
So if classes are going to be allowed two implement two interfaces that share
the
same method, I think that the certification exam should be changed to reflect
this change.
Previous Comments:
[2012-07-02 22:11:54] j dot henge-ernst at interexa dot de
Your example is ok and should work correctly as both interfaces extend the same
base interface and add different methods. In my given example AInterface and
BInterface do not extend from a common interface. So the class which implements
RewindableIterator, ReversableIterator must implement
from Iterator:
function current();
function key();
function next();
function valid();
from RewindableIterator:
function rewind();
from ReversableIterator:
function prev();
So lets change my example to:
interface AInterface {
/** @return Aclass[] */
public function getObjects();
}
interface BInterface {
/** @return Bclass[] */
public function getObjects();
}
class CClass implements AInterface, BInterface
{
public function getObjects() {
return ???;
}
}
class AClass {
public function foo() { echo foo;}
}
class BClass {
public function bar() { echo bar;}
}
[2012-07-02 17:50:10] ni...@php.net
I'm not sure I see the problem. If the class satisfies both interfaces, why
should there be an error?
E.g., consider:
interface Iterator {
function current();
function key();
function next();
function valid();
}
interface RewindableIterator extends Iterator {
function rewind();
}
interface ReversableIterator extends Iterator {
function prev();
}
class Foo implements RewindableIterator, ReversableIterator {
// ...
}
Why shouldn't the class be able to implement both, as long as the method
declarations don't disagree?
[2012-07-02 16:11:52] j dot henge-ernst at interexa dot de
Description:
having two different interfaces with same method no longer causes a fatal error
like in php 5.3.8. With fix for bug #43200 (my guess) it is now possible to
inherit another interface which has the same method signature as a previous
interface.
implementing an interface with methods which collide with a method name which
is already implemented by another interface should cause an error.
From my point of OOP it does not make sense as the meaning of the colliding
interface method do not express the same, else both interfaces with the same
signature part should extend that base interface.
It's the opposite of bug #46705
Such a change of the language should not be done in a minor release.
Test script:
---
?php
interface AInterface {
public function getLogicalKey();
}
interface BInterface {
public function getLogicalKey();
}
class AClass implements AInterface {
public function getLogicalKey() { return 1; }
}
class BClass extends AClass implements BInterface { }
Expected result:
Fatal error: Can't inherit abstract function BInterface::getLogicalKey()
(previously declared abstract in AInterface) in x.php on line 12
--
Edit this bug report at https://bugs.php.net/bug.php?id=62464edit=1
Bug #54037 [Csd-ReO]: [PATCH] Adds the ability to pass options to loadHTML
Edit report at https://bugs.php.net/bug.php?id=54037edit=1 ID: 54037 Updated by: phi...@php.net Reported by:fxmulder at gmail dot com Summary:[PATCH] Adds the ability to pass options to loadHTML -Status: Closed +Status: Re-Opened Type: Bug Package:DOM XML related PHP Version:trunk-SVN-2011-02-17 (SVN) Assigned To:tyrael Block user comment: N Private report: N New Comment: The documentation patch was not committed. Previous Comments: [2012-07-22 23:39:47] tyr...@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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. I've opened a separate bug for the documentation issue: https://bugs.php.net/bug.php?id=62635 [2011-08-12 21:07:45] fxmulder at gmail dot com I've included a patch for proposed documentation changes for the new options [2011-07-11 11:30:30] chr...@php.net Committed to trunk and PHP_5_4 branch [2011-03-29 22:27:40] fxmulder at gmail dot com That works for me, this still good to be committed to the trunk? [2011-03-03 08:12:00] chr...@php.net The following patch has been added/updated: Patch Name: patch-for-adding-loadhtml-options.patch Revision: 1299136320 URL: http://bugs.php.net/patch-display.php?bug=54037patch=patch-for-adding-loadhtml-options.patchrevision=1299136320 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 https://bugs.php.net/bug.php?id=54037 -- Edit this bug report at https://bugs.php.net/bug.php?id=54037edit=1
Bug #40459 [ReO]: Stat and Dir stream wrapper methods do not call constructor
Edit report at https://bugs.php.net/bug.php?id=40459edit=1
ID: 40459
Updated by: s...@php.net
Reported by:clay at killersoft dot com
Summary:Stat and Dir stream wrapper methods do not call
constructor
Status: Re-Opened
Type: Bug
Package:Streams related
Operating System: irrelevant
PHP Version:5.2.1
Assigned To:stas
Block user comment: N
Private report: N
New Comment:
See also: https://github.com/php/php-src/pull/93
Previous Comments:
[2012-05-04 12:47:27] jschipp...@php.net
I believe this issue is still present. I have attached a test case to
demonstrate the problem.
When looking at main/streams/userspace.c, it is clear that only in
user_wrapper_opener() the constructor of the user space class is called (the
if (uwrap-ce-constructor) {} block).
[2012-05-04 12:46:05] jschipp...@php.net
The following patch has been added/updated:
Patch Name: bug-40459
Revision: 1336135565
URL:
https://bugs.php.net/patch-display.php?bug=40459patch=bug-40459revision=1336135565
[2008-07-21 01:00:02] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2008-07-13 15:56:45] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2007-02-13 07:01:33] clay at killersoft dot com
Description:
The following methods in a userspace stream wrapper will not call the
constructor:
url_stat()
dir_opendir()
rmdir()
mkdir()
rename()
unlink()
Reproduce code:
---
http://killersoft.com/misc/Test_Stream.php.txt
Expected result:
Any time a line of output beginning with '== [method] CALLED' appears, that
line should contain an 'obj: ' value with a uniqid value, indicating that the
constructor was called.
Actual result:
--
== dir_opendir METHOD CALLED (obj: ) ==
...
== dir_readdir METHOD CALLED (obj: ) ==
...
== dir_closedir METHOD CALLED (obj: ) ==
...
== url_stat METHOD CALLED (obj: ) ==
...
== mkdir METHOD CALLED (obj: ) ==
...
== rmdir METHOD CALLED (obj: ) ==
...
== unlink METHOD CALLED (obj: ) ==
...
== rename METHOD CALLED (obj: ) ==
...
--
Edit this bug report at https://bugs.php.net/bug.php?id=40459edit=1
Bug #62769 [Opn]: Inconsistent notice reporting using []
Edit report at https://bugs.php.net/bug.php?id=62769edit=1
ID: 62769
Updated by: larue...@php.net
Reported by:julien at palard dot fr
Summary:Inconsistent notice reporting using []
Status: Open
Type: Bug
Package:Output Control
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
const array dereference is only in trunk
Previous Comments:
[2012-08-07 14:42:36] julien at palard dot fr
Description:
Error reported for invalid [] access seems inconsistent :
echo NULL[bar] - Parse error
echo [][bar] - Parse error
$foo = NULL; echo $foo[bar] - Fails silently
$foo = []; echo $foo[bar] - Notice: Undefined index
class Bar {} ; $foo = new Bar(); echo $foo[bar]; - PHP Fatal error
I whish :
[][bar] to trigger Notice: Undefined index
NULL[bar] to trigger something catcheable with set_error_handler
$foo = NULL; $foo[bar] to trigger a catcheable Notice.
Test script:
---
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); echo [][bar];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); echo NULL[bar];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); $foo = NULL; $foo[bar];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); $foo = []; $foo[bar];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); class Bar {} ; $foo = new
Bar(); echo $foo[bar];'
Expected result:
At least get a Notice on :
$foo = NULL;
echo $foo[bar];
Actual result:
--
Fails silently.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62769edit=1
