Bug #53311 [PATCH]: startup failed.
Edit report at http://bugs.php.net/bug.php?id=53311&edit=1 ID: 53311 Patch added by: f...@php.net Reported by:paulgao at yeah dot net Summary:startup failed. Status: Feedback Type: Bug Package:FPM related Operating System: Centos 64-bit 5.5 PHP Version:5.3SVN-2010-11-15 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: fpm-zlog_set_fd.v2.patch Revision: 1289894719 URL: http://bugs.php.net/patch-display.php?bug=53311&patch=fpm-zlog_set_fd.v2.patch&revision=1289894719 Previous Comments: [2010-11-16 03:24:22] paulgao at yeah dot net -tt output: Nov 16 10:23:42.631153 [NOTICE] [General] Nov 16 10:23:42.631199 [NOTICE] pid = /home/php-fpm.pid Nov 16 10:23:42.631205 [NOTICE] daemonize = yes Nov 16 10:23:42.631232 [NOTICE] error_log = /home/logs/fpm.log Nov 16 10:23:42.631239 [NOTICE] log_level = NOTICE Nov 16 10:23:42.631244 [NOTICE] process_control_timeout = 5s Nov 16 10:23:42.631250 [NOTICE] emergency_restart_interval = 60s Nov 16 10:23:42.631256 [NOTICE] emergency_restart_threshold = 10 Nov 16 10:23:42.631268 [NOTICE] Nov 16 10:23:42.631283 [NOTICE] [www] Nov 16 10:23:42.631288 [NOTICE] prefix = undefined Nov 16 10:23:42.631294 [NOTICE] user = nobody Nov 16 10:23:42.631303 [NOTICE] group = nobody Nov 16 10:23:42.631308 [NOTICE] chroot = Nov 16 10:23:42.631323 [NOTICE] chdir = Nov 16 10:23:42.631329 [NOTICE] listen = 0.0.0.0:8001 Nov 16 10:23:42.631334 [NOTICE] listen.backlog = -1 Nov 16 10:23:42.631340 [NOTICE] listen.owner = undefined Nov 16 10:23:42.631352 [NOTICE] listen.group = undefined Nov 16 10:23:42.631359 [NOTICE] listen.mode = 0666 Nov 16 10:23:42.631364 [NOTICE] listen.allowed_clients = undefined Nov 16 10:23:42.631370 [NOTICE] pm = dynamic Nov 16 10:23:42.631375 [NOTICE] pm.max_children = 48 Nov 16 10:23:42.631381 [NOTICE] pm.max_requests = 0 Nov 16 10:23:42.631391 [NOTICE] pm.start_servers = 16 Nov 16 10:23:42.631405 [NOTICE] pm.min_spare_servers = 16 Nov 16 10:23:42.631411 [NOTICE] pm.max_spare_servers = 32 Nov 16 10:23:42.631417 [NOTICE] pm.status_path = /fpm_status Nov 16 10:23:42.631423 [NOTICE] ping.path = /fpm_ping Nov 16 10:23:42.631428 [NOTICE] ping.response = pong Nov 16 10:23:42.631452 [NOTICE] catch_workers_output = yes Nov 16 10:23:42.631458 [NOTICE] request_terminate_timeout = 0s Nov 16 10:23:42.631464 [NOTICE] request_slowlog_timeout = 1s Nov 16 10:23:42.631478 [NOTICE] slowlog = /home/logs/fpm_slow.log Nov 16 10:23:42.631484 [NOTICE] rlimit_files = 51200 Nov 16 10:23:42.631489 [NOTICE] rlimit_core = 0 Nov 16 10:23:42.631495 [NOTICE] Nov 16 10:23:42.631515 [NOTICE] configuration file /home/codebase/server-config/php-fpm-api-test.ini test is successful [2010-11-16 03:21:51] paulgao at yeah dot net I patched, -tt is work, but startup failed, core dumped. (gdb) bt #0 _zend_mm_free_int (heap=0x18a01810, p=0x7fff93d7dbbe) at /root/PHP53/Zend/zend_alloc.c:2018 #1 0x006ba01f in fpm_cleanups_run (type=2) at /root/PHP53/sapi/fpm/fpm/fpm_cleanup.c:46 #2 0x006c3bcc in fpm_unix_init_main () at /root/PHP53/sapi/fpm/fpm/fpm_unix.c:232 #3 0x006b96ab in fpm_init (argc=, argv=, config=, prefix=, test_conf=0, base=0xda1748) at /root/PHP53/sapi/fpm/fpm/fpm.c:33 #4 0x006be10e in main (argc=3, argv=0x7fff93d7d658) at /root/PHP53/sapi/fpm/fpm/fpm_main.c:1783 [2010-11-16 01:52:26] f...@php.net Can you try the attached patch and try again please ? don't forget to run ./buildconf && ./configure ... [2010-11-16 01:50:53] f...@php.net The following patch has been added/updated: Patch Name: fpm-zlog_set_fd.v1.patch Revision: 1289868651 URL: http://bugs.php.net/patch-display.php?bug=53311&patch=fpm-zlog_set_fd.v1.patch&revision=1289868651 [2010-11-16 01:42:21] f...@php.net Can you look in the fpm error log ? (%prefix%/var/log/php-fpm.log if you didn't change the default value) 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=53311 -- Edit this bug report at http://bugs.php.net/bug.p
Bug #53311 [Com]: startup failed.
Edit report at http://bugs.php.net/bug.php?id=53311&edit=1 ID: 53311 Comment by: f...@php.net Reported by:paulgao at yeah dot net Summary:startup failed. Status: Feedback Type: Bug Package:FPM related Operating System: Centos 64-bit 5.5 PHP Version:5.3SVN-2010-11-15 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: Please use fpm-zlog_set_fd.v2.patch instead of fpm-zlog_set_fd.v1.patch. thx Previous Comments: [2010-11-16 09:05:19] f...@php.net The following patch has been added/updated: Patch Name: fpm-zlog_set_fd.v2.patch Revision: 1289894719 URL: http://bugs.php.net/patch-display.php?bug=53311&patch=fpm-zlog_set_fd.v2.patch&revision=1289894719 [2010-11-16 03:24:22] paulgao at yeah dot net -tt output: Nov 16 10:23:42.631153 [NOTICE] [General] Nov 16 10:23:42.631199 [NOTICE] pid = /home/php-fpm.pid Nov 16 10:23:42.631205 [NOTICE] daemonize = yes Nov 16 10:23:42.631232 [NOTICE] error_log = /home/logs/fpm.log Nov 16 10:23:42.631239 [NOTICE] log_level = NOTICE Nov 16 10:23:42.631244 [NOTICE] process_control_timeout = 5s Nov 16 10:23:42.631250 [NOTICE] emergency_restart_interval = 60s Nov 16 10:23:42.631256 [NOTICE] emergency_restart_threshold = 10 Nov 16 10:23:42.631268 [NOTICE] Nov 16 10:23:42.631283 [NOTICE] [www] Nov 16 10:23:42.631288 [NOTICE] prefix = undefined Nov 16 10:23:42.631294 [NOTICE] user = nobody Nov 16 10:23:42.631303 [NOTICE] group = nobody Nov 16 10:23:42.631308 [NOTICE] chroot = Nov 16 10:23:42.631323 [NOTICE] chdir = Nov 16 10:23:42.631329 [NOTICE] listen = 0.0.0.0:8001 Nov 16 10:23:42.631334 [NOTICE] listen.backlog = -1 Nov 16 10:23:42.631340 [NOTICE] listen.owner = undefined Nov 16 10:23:42.631352 [NOTICE] listen.group = undefined Nov 16 10:23:42.631359 [NOTICE] listen.mode = 0666 Nov 16 10:23:42.631364 [NOTICE] listen.allowed_clients = undefined Nov 16 10:23:42.631370 [NOTICE] pm = dynamic Nov 16 10:23:42.631375 [NOTICE] pm.max_children = 48 Nov 16 10:23:42.631381 [NOTICE] pm.max_requests = 0 Nov 16 10:23:42.631391 [NOTICE] pm.start_servers = 16 Nov 16 10:23:42.631405 [NOTICE] pm.min_spare_servers = 16 Nov 16 10:23:42.631411 [NOTICE] pm.max_spare_servers = 32 Nov 16 10:23:42.631417 [NOTICE] pm.status_path = /fpm_status Nov 16 10:23:42.631423 [NOTICE] ping.path = /fpm_ping Nov 16 10:23:42.631428 [NOTICE] ping.response = pong Nov 16 10:23:42.631452 [NOTICE] catch_workers_output = yes Nov 16 10:23:42.631458 [NOTICE] request_terminate_timeout = 0s Nov 16 10:23:42.631464 [NOTICE] request_slowlog_timeout = 1s Nov 16 10:23:42.631478 [NOTICE] slowlog = /home/logs/fpm_slow.log Nov 16 10:23:42.631484 [NOTICE] rlimit_files = 51200 Nov 16 10:23:42.631489 [NOTICE] rlimit_core = 0 Nov 16 10:23:42.631495 [NOTICE] Nov 16 10:23:42.631515 [NOTICE] configuration file /home/codebase/server-config/php-fpm-api-test.ini test is successful [2010-11-16 03:21:51] paulgao at yeah dot net I patched, -tt is work, but startup failed, core dumped. (gdb) bt #0 _zend_mm_free_int (heap=0x18a01810, p=0x7fff93d7dbbe) at /root/PHP53/Zend/zend_alloc.c:2018 #1 0x006ba01f in fpm_cleanups_run (type=2) at /root/PHP53/sapi/fpm/fpm/fpm_cleanup.c:46 #2 0x006c3bcc in fpm_unix_init_main () at /root/PHP53/sapi/fpm/fpm/fpm_unix.c:232 #3 0x006b96ab in fpm_init (argc=, argv=, config=, prefix=, test_conf=0, base=0xda1748) at /root/PHP53/sapi/fpm/fpm/fpm.c:33 #4 0x006be10e in main (argc=3, argv=0x7fff93d7d658) at /root/PHP53/sapi/fpm/fpm/fpm_main.c:1783 [2010-11-16 01:52:26] f...@php.net Can you try the attached patch and try again please ? don't forget to run ./buildconf && ./configure ... [2010-11-16 01:50:53] f...@php.net The following patch has been added/updated: Patch Name: fpm-zlog_set_fd.v1.patch Revision: 1289868651 URL: http://bugs.php.net/patch-display.php?bug=53311&patch=fpm-zlog_set_fd.v1.patch&revision=1289868651 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=53311 -- Edit this bug report at http://bugs.php.net/bug.php?id=53311&edit=1
Bug #53311 [Com]: startup failed.
Edit report at http://bugs.php.net/bug.php?id=53311&edit=1 ID: 53311 Comment by: f...@php.net Reported by:paulgao at yeah dot net Summary:startup failed. Status: Feedback Type: Bug Package:FPM related Operating System: Centos 64-bit 5.5 PHP Version:5.3SVN-2010-11-15 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: can you: 1- stop FPM 2- remove or move /home/logs/fpm.log 3- set log level to DEBUG 4- run FPM 5- dump the content of /home/logs/fpm.log here thx Previous Comments: [2010-11-16 09:05:46] f...@php.net Please use fpm-zlog_set_fd.v2.patch instead of fpm-zlog_set_fd.v1.patch. thx [2010-11-16 09:05:19] f...@php.net The following patch has been added/updated: Patch Name: fpm-zlog_set_fd.v2.patch Revision: 1289894719 URL: http://bugs.php.net/patch-display.php?bug=53311&patch=fpm-zlog_set_fd.v2.patch&revision=1289894719 [2010-11-16 03:24:22] paulgao at yeah dot net -tt output: Nov 16 10:23:42.631153 [NOTICE] [General] Nov 16 10:23:42.631199 [NOTICE] pid = /home/php-fpm.pid Nov 16 10:23:42.631205 [NOTICE] daemonize = yes Nov 16 10:23:42.631232 [NOTICE] error_log = /home/logs/fpm.log Nov 16 10:23:42.631239 [NOTICE] log_level = NOTICE Nov 16 10:23:42.631244 [NOTICE] process_control_timeout = 5s Nov 16 10:23:42.631250 [NOTICE] emergency_restart_interval = 60s Nov 16 10:23:42.631256 [NOTICE] emergency_restart_threshold = 10 Nov 16 10:23:42.631268 [NOTICE] Nov 16 10:23:42.631283 [NOTICE] [www] Nov 16 10:23:42.631288 [NOTICE] prefix = undefined Nov 16 10:23:42.631294 [NOTICE] user = nobody Nov 16 10:23:42.631303 [NOTICE] group = nobody Nov 16 10:23:42.631308 [NOTICE] chroot = Nov 16 10:23:42.631323 [NOTICE] chdir = Nov 16 10:23:42.631329 [NOTICE] listen = 0.0.0.0:8001 Nov 16 10:23:42.631334 [NOTICE] listen.backlog = -1 Nov 16 10:23:42.631340 [NOTICE] listen.owner = undefined Nov 16 10:23:42.631352 [NOTICE] listen.group = undefined Nov 16 10:23:42.631359 [NOTICE] listen.mode = 0666 Nov 16 10:23:42.631364 [NOTICE] listen.allowed_clients = undefined Nov 16 10:23:42.631370 [NOTICE] pm = dynamic Nov 16 10:23:42.631375 [NOTICE] pm.max_children = 48 Nov 16 10:23:42.631381 [NOTICE] pm.max_requests = 0 Nov 16 10:23:42.631391 [NOTICE] pm.start_servers = 16 Nov 16 10:23:42.631405 [NOTICE] pm.min_spare_servers = 16 Nov 16 10:23:42.631411 [NOTICE] pm.max_spare_servers = 32 Nov 16 10:23:42.631417 [NOTICE] pm.status_path = /fpm_status Nov 16 10:23:42.631423 [NOTICE] ping.path = /fpm_ping Nov 16 10:23:42.631428 [NOTICE] ping.response = pong Nov 16 10:23:42.631452 [NOTICE] catch_workers_output = yes Nov 16 10:23:42.631458 [NOTICE] request_terminate_timeout = 0s Nov 16 10:23:42.631464 [NOTICE] request_slowlog_timeout = 1s Nov 16 10:23:42.631478 [NOTICE] slowlog = /home/logs/fpm_slow.log Nov 16 10:23:42.631484 [NOTICE] rlimit_files = 51200 Nov 16 10:23:42.631489 [NOTICE] rlimit_core = 0 Nov 16 10:23:42.631495 [NOTICE] Nov 16 10:23:42.631515 [NOTICE] configuration file /home/codebase/server-config/php-fpm-api-test.ini test is successful [2010-11-16 03:21:51] paulgao at yeah dot net I patched, -tt is work, but startup failed, core dumped. (gdb) bt #0 _zend_mm_free_int (heap=0x18a01810, p=0x7fff93d7dbbe) at /root/PHP53/Zend/zend_alloc.c:2018 #1 0x006ba01f in fpm_cleanups_run (type=2) at /root/PHP53/sapi/fpm/fpm/fpm_cleanup.c:46 #2 0x006c3bcc in fpm_unix_init_main () at /root/PHP53/sapi/fpm/fpm/fpm_unix.c:232 #3 0x006b96ab in fpm_init (argc=, argv=, config=, prefix=, test_conf=0, base=0xda1748) at /root/PHP53/sapi/fpm/fpm/fpm.c:33 #4 0x006be10e in main (argc=3, argv=0x7fff93d7d658) at /root/PHP53/sapi/fpm/fpm/fpm_main.c:1783 [2010-11-16 01:52:26] f...@php.net Can you try the attached patch and try again please ? don't forget to run ./buildconf && ./configure ... 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=53311 -- Edit this bug report at http://bugs.php.net/bug.php?id=53311&edit=1
Bug #53311 [Com]: startup failed.
Edit report at http://bugs.php.net/bug.php?id=53311&edit=1 ID: 53311 Comment by: paulgao at yeah dot net Reported by:paulgao at yeah dot net Summary:startup failed. Status: Feedback Type: Bug Package:FPM related Operating System: Centos 64-bit 5.5 PHP Version:5.3SVN-2010-11-15 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: I use patch V2. if old fpm.log not remove, startup still failed. but old fpm.log removed, startup is OK. restart is OK too. what problem? Previous Comments: [2010-11-16 09:17:44] f...@php.net can you: 1- stop FPM 2- remove or move /home/logs/fpm.log 3- set log level to DEBUG 4- run FPM 5- dump the content of /home/logs/fpm.log here thx [2010-11-16 09:05:46] f...@php.net Please use fpm-zlog_set_fd.v2.patch instead of fpm-zlog_set_fd.v1.patch. thx [2010-11-16 09:05:19] f...@php.net The following patch has been added/updated: Patch Name: fpm-zlog_set_fd.v2.patch Revision: 1289894719 URL: http://bugs.php.net/patch-display.php?bug=53311&patch=fpm-zlog_set_fd.v2.patch&revision=1289894719 [2010-11-16 03:24:22] paulgao at yeah dot net -tt output: Nov 16 10:23:42.631153 [NOTICE] [General] Nov 16 10:23:42.631199 [NOTICE] pid = /home/php-fpm.pid Nov 16 10:23:42.631205 [NOTICE] daemonize = yes Nov 16 10:23:42.631232 [NOTICE] error_log = /home/logs/fpm.log Nov 16 10:23:42.631239 [NOTICE] log_level = NOTICE Nov 16 10:23:42.631244 [NOTICE] process_control_timeout = 5s Nov 16 10:23:42.631250 [NOTICE] emergency_restart_interval = 60s Nov 16 10:23:42.631256 [NOTICE] emergency_restart_threshold = 10 Nov 16 10:23:42.631268 [NOTICE] Nov 16 10:23:42.631283 [NOTICE] [www] Nov 16 10:23:42.631288 [NOTICE] prefix = undefined Nov 16 10:23:42.631294 [NOTICE] user = nobody Nov 16 10:23:42.631303 [NOTICE] group = nobody Nov 16 10:23:42.631308 [NOTICE] chroot = Nov 16 10:23:42.631323 [NOTICE] chdir = Nov 16 10:23:42.631329 [NOTICE] listen = 0.0.0.0:8001 Nov 16 10:23:42.631334 [NOTICE] listen.backlog = -1 Nov 16 10:23:42.631340 [NOTICE] listen.owner = undefined Nov 16 10:23:42.631352 [NOTICE] listen.group = undefined Nov 16 10:23:42.631359 [NOTICE] listen.mode = 0666 Nov 16 10:23:42.631364 [NOTICE] listen.allowed_clients = undefined Nov 16 10:23:42.631370 [NOTICE] pm = dynamic Nov 16 10:23:42.631375 [NOTICE] pm.max_children = 48 Nov 16 10:23:42.631381 [NOTICE] pm.max_requests = 0 Nov 16 10:23:42.631391 [NOTICE] pm.start_servers = 16 Nov 16 10:23:42.631405 [NOTICE] pm.min_spare_servers = 16 Nov 16 10:23:42.631411 [NOTICE] pm.max_spare_servers = 32 Nov 16 10:23:42.631417 [NOTICE] pm.status_path = /fpm_status Nov 16 10:23:42.631423 [NOTICE] ping.path = /fpm_ping Nov 16 10:23:42.631428 [NOTICE] ping.response = pong Nov 16 10:23:42.631452 [NOTICE] catch_workers_output = yes Nov 16 10:23:42.631458 [NOTICE] request_terminate_timeout = 0s Nov 16 10:23:42.631464 [NOTICE] request_slowlog_timeout = 1s Nov 16 10:23:42.631478 [NOTICE] slowlog = /home/logs/fpm_slow.log Nov 16 10:23:42.631484 [NOTICE] rlimit_files = 51200 Nov 16 10:23:42.631489 [NOTICE] rlimit_core = 0 Nov 16 10:23:42.631495 [NOTICE] Nov 16 10:23:42.631515 [NOTICE] configuration file /home/codebase/server-config/php-fpm-api-test.ini test is successful [2010-11-16 03:21:51] paulgao at yeah dot net I patched, -tt is work, but startup failed, core dumped. (gdb) bt #0 _zend_mm_free_int (heap=0x18a01810, p=0x7fff93d7dbbe) at /root/PHP53/Zend/zend_alloc.c:2018 #1 0x006ba01f in fpm_cleanups_run (type=2) at /root/PHP53/sapi/fpm/fpm/fpm_cleanup.c:46 #2 0x006c3bcc in fpm_unix_init_main () at /root/PHP53/sapi/fpm/fpm/fpm_unix.c:232 #3 0x006b96ab in fpm_init (argc=, argv=, config=, prefix=, test_conf=0, base=0xda1748) at /root/PHP53/sapi/fpm/fpm/fpm.c:33 #4 0x006be10e in main (argc=3, argv=0x7fff93d7d658) at /root/PHP53/sapi/fpm/fpm/fpm_main.c:1783 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=53311 -- Edit this bug report at http://bugs.php.net/bug.php?id=53311&edit=1
Bug #50027 [Com]: $this becomes a non-object
Edit report at http://bugs.php.net/bug.php?id=50027&edit=1
ID: 50027
Comment by: bsteinbrink at saltation dot de
Reported by:phpbugs at colin dot guthr dot ie
Summary:$this becomes a non-object
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Mandriva Linux (Cooker x86_64)
PHP Version:5.3.1RC2
Block user comment: N
Private report: N
New Comment:
We encountered this bug yesterday (we could reproduce it quite easily
with our code, but unfortunately we cannot disclose it), debugged it,
found out that it was due to the GC corrupting the std_object_handlers
prototype and once we knew that, we checked with the svn repo and saw
that that was fixed in r303016.
The corruption that happens is that the read_property field of
std_object_handlers gets set to NULL, because the GC treated the handler
as a zval.
The report from lukas about the failure to set a property seems like an
independent bug, as a different field got corrupted (and he had the gc
turned off anyway).
Previous Comments:
[2010-11-10 15:44:51] lukas at twobits dot cz
Bad news. Just got the same bug again, with PHP 5.3.3 and GC switched
OFF. Again, only one Apache process fails. The process begun failing
immediately after Apache restart. A simple reproduce class:
Reproduce code:
---
class Test
{
private $data = NULL;
public function __construct($data)
{
echo "";
var_dump($this);
echo "";
$this->data = $data;
}
public function getData()
{
echo "";
var_dump($this);
echo "";
return $this->data;
}
}
echo "PID: " . getmypid();
$foo = new Test('Hello');
echo $foo->getData();
Correct output:
---
PID: 22839
object(Test)#1 (1) {
["data":"Test":private]=>
NULL
}
object(Test)#1 (1) {
["data":"Test":private]=>
string(5) "Hello"
}
Hello
Malfunctioning Apache process output:
-
PID: 22818
object(Test)#1 (1) {
["data":"Test":private]=>
NULL
}
Warning: Attempt to assign property of non-object in
/var/www/html/testthis.php on line 16
object(Test)#1 (1) {
["data":"Test":private]=>
NULL
}
[2010-05-15 19:06:58] phpbugs at colin dot guthr dot ie
Just for reference, I just tested and this bug is still a problem with
5.3.2.
[2010-04-28 10:05:16] ahar...@php.net
The way this bug tracker works is that the bug doesn't get automatically
re-opened from the Feedback status when someone posts a comment; it's
only if the original reporter or a PHP developer actually resets it to
Open.
Reopening, anyway, since feedback was provided.
[2010-04-28 09:47:53] lukas at twobits dot cz
I am unfortunately unable to provide more feedback except that we have
never encountered this problem again with GC off. We have now been using
5.3.2. If we decide to test it with the garbage collector one once
again, I'll provide some more feedback.
[2010-04-27 13:08:07] phpbugs at colin dot guthr dot ie
I'm curious as to why this bug is set to "No Feedback"... Lukas has
provided more information about the topic to nail it down to a Garbage
Collection issue.
I will try and upgrade sometime soon on my development machine to see if
I can retrigger the problem, but in the meantime, has there been any
progress? Are there now some potentially duplicate bugs and even a fix?
Does the issue still cause you problems Lukas?
Thanks :)
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=50027
--
Edit this bug report at http://bugs.php.net/bug.php?id=50027&edit=1
Bug #50027 [Com]: $this becomes a non-object
Edit report at http://bugs.php.net/bug.php?id=50027&edit=1
ID: 50027
Comment by: phpbugs at colin dot guthr dot ie
Reported by:phpbugs at colin dot guthr dot ie
Summary:$this becomes a non-object
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Mandriva Linux (Cooker x86_64)
PHP Version:5.3.1RC2
Block user comment: N
Private report: N
New Comment:
So far so good! I updated to PHP 5.3.3 again and reproduced the error
(and got four nice core dumps), then applied the patch and tried to
reproduce again and so far, I'm coreless.
Thanks for highlighting the patch. Just with this bug had lead to more
investigations earlier as I've had to jump through hoops to avoid
updating to PHP 5.3.x because of this problem. Still hopefully looking
good now :)
Previous Comments:
[2010-11-16 09:38:23] bsteinbrink at saltation dot de
We encountered this bug yesterday (we could reproduce it quite easily
with our code, but unfortunately we cannot disclose it), debugged it,
found out that it was due to the GC corrupting the std_object_handlers
prototype and once we knew that, we checked with the svn repo and saw
that that was fixed in r303016.
The corruption that happens is that the read_property field of
std_object_handlers gets set to NULL, because the GC treated the handler
as a zval.
The report from lukas about the failure to set a property seems like an
independent bug, as a different field got corrupted (and he had the gc
turned off anyway).
[2010-11-10 15:44:51] lukas at twobits dot cz
Bad news. Just got the same bug again, with PHP 5.3.3 and GC switched
OFF. Again, only one Apache process fails. The process begun failing
immediately after Apache restart. A simple reproduce class:
Reproduce code:
---
class Test
{
private $data = NULL;
public function __construct($data)
{
echo "";
var_dump($this);
echo "";
$this->data = $data;
}
public function getData()
{
echo "";
var_dump($this);
echo "";
return $this->data;
}
}
echo "PID: " . getmypid();
$foo = new Test('Hello');
echo $foo->getData();
Correct output:
---
PID: 22839
object(Test)#1 (1) {
["data":"Test":private]=>
NULL
}
object(Test)#1 (1) {
["data":"Test":private]=>
string(5) "Hello"
}
Hello
Malfunctioning Apache process output:
-
PID: 22818
object(Test)#1 (1) {
["data":"Test":private]=>
NULL
}
Warning: Attempt to assign property of non-object in
/var/www/html/testthis.php on line 16
object(Test)#1 (1) {
["data":"Test":private]=>
NULL
}
[2010-05-15 19:06:58] phpbugs at colin dot guthr dot ie
Just for reference, I just tested and this bug is still a problem with
5.3.2.
[2010-04-28 10:05:16] ahar...@php.net
The way this bug tracker works is that the bug doesn't get automatically
re-opened from the Feedback status when someone posts a comment; it's
only if the original reporter or a PHP developer actually resets it to
Open.
Reopening, anyway, since feedback was provided.
[2010-04-28 09:47:53] lukas at twobits dot cz
I am unfortunately unable to provide more feedback except that we have
never encountered this problem again with GC off. We have now been using
5.3.2. If we decide to test it with the garbage collector one once
again, I'll provide some more feedback.
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=50027
--
Edit this bug report at http://bugs.php.net/bug.php?id=50027&edit=1
Bug #53320 [Opn->Fbk]: Segmentation fault (core dumped) by using timezone_identifiers_list function
Edit report at http://bugs.php.net/bug.php?id=53320&edit=1 ID: 53320 Updated by: fel...@php.net Reported by:kitani at cseas dot kyoto-u dot ac dot jp Summary:Segmentation fault (core dumped) by using timezone_identifiers_list function -Status: Open +Status: Feedback Type: Bug Package:Reproducible crash Operating System: Redhat Linux ES5 PHP Version:5.3.3 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/ Previous Comments: [2010-11-16 07:34:57] kitani at cseas dot kyoto-u dot ac dot jp Description: By using timezone_identifiers_list function, "Segmentation fault (core dumped)" error occurs. Test script: --- php -r 'var_dump ( timezone_identifiers_list() );' -- Edit this bug report at http://bugs.php.net/bug.php?id=53320&edit=1
Bug #51818 [Com]: var_dump(): Couldn't fetch mysqli
Edit report at http://bugs.php.net/bug.php?id=51818&edit=1
ID: 51818
Comment by: php at ianco dot co dot uk
Reported by:zeusgerde at arcor dot de
Summary:var_dump(): Couldn't fetch mysqli
Status: Wont fix
Type: Bug
Package:MySQLi related
Operating System: Linux
PHP Version:5.3.2
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
I have a shopping cart object stored serialized in a database session.
This object has a mysqli object as a property, which is left open for
reuse.
I was getting the "Couldn't fetch" error every time a new Ajax call
tried to access the mysqli object (with OOP) (unless this was a brand
new session and the mysqli object had only just been created).
I think the problem is that the database connection is lost between Ajax
calls. I have solved it for now by adding a destructor to the cart
object, which does mysqli->close() (if the object exists - my cart only
instantiates it if needed, not in the cart constructor).
I haven't checked, but it might also be possible to solve the problem
with __sleep. Or you could just be more ruthless and ensure that you
never ever leave the mysqli object open.
Previous Comments:
[2010-06-17 17:58:23] robert dot schlak at alcatel-lucent dot com
The intent of the connect_errno method is to determine if an connection
error occurred...one would think. The programmer is expecting the chance
a connection error occurred. Don't error-out if he asks.
$host = 'bad_host';// FORCE AN ERROR -- debug
$mysqli = @new mysqli($host, NTSM_USER, PWD_NTSM, NTSM_INSTANCE);
if ($mysqli->connect_errno) {
do something
}
One would expect the code above to not annoy the user with an echoed
warning. I have to use @$mysqli->connect_errno, but I have no return
from the method call. Instead I receive 'Couldn't fetch mysqli in', why
is a fetch even attempted with this method? Look at the local object and
see if it contains an error status and return it.
[2010-05-25 18:55:35] and...@php.net
I think this is a won't fix. The properties of the mysqli or
mysql_result object are invalid if the connection establishment or the
connection is closed. In case of mysql_result is something wrong
happens.
The extension needs different design, new mysqli(...) tries to connect,
if something wrong happens it should throw an exception, it doesn't now.
The design can't be changed that easily in a minor release.
[2010-05-14 03:47:55] zeusgerde at arcor dot de
Description:
E_WARNING when accessing properties or methods of MySQLi object if
connection fails
I know other people already reported this kind of issue:
http://bugs.php.net/bug.php?id=33635
http://bugs.php.net/bug.php?id=34828
http://bugs.php.net/bug.php?id=36949
http://bugs.php.net/bug.php?id=45935
http://bugs.php.net/bug.php?id=45940
http://bugs.php.net/bug.php?id=50772
though I think telling the user "couldn't fetch *mysqli*" is just wrong
because PHP is able to use the MySQLi object and even some of its
properties or methods (e.g. MySQLi::$client_version or
MySQLi::$connect_errno)
i am not sure if this is a real bug report or may be a feature request.
but I think it would help other people if the warning says something
like "mysqli is not connected" or may be E_WARNING should not be raised
at all.
--
PHP 5.3.2 (cli) (built: May 14 2010 03:25:13)
MySQLi Client API library version 5.1.45
Test script:
---
Expected result:
object(mysqli)#1 (17) {
/* ... */
}
Actual result:
--
Lots of "Warning: var_dump(): Couldn't fetch mysqli in [...]" (for
nearly every single key in mysqli)
object(mysqli)#1 (17) {
/* content as expected */
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=51818&edit=1
[PHP-BUG] Req #53322 [NEW]: zend_mm_heap corrupted
From: Operating system: gentoo (kernel 2.6.32-r2) PHP version: 5.3.3 Package: Apache2 related Bug Type: Feature/Change Request Bug description:zend_mm_heap corrupted Description: After updating php from 5.2.14 version to 5.3.3-r1 site didn't work in different moments of time. Apache error log showed this: [Fri Nov 12 00:14:52 2010] [notice] child pid 1389 exit signal Segmentation fault (11) [Fri Nov 12 00:14:55 2010] [notice] child pid 1361 exit signal Segmentation fault (11) zend_mm_heap corrupted zend_mm_heap corrupted After downgrading php from 5.3.3-r1 version to 5.2.14 problem has gone away. php was compiled without problems(I didn't receive any error or warning messages) php was compiled with next USE flags: apache2 bcmath berkdb bzip2 calendar cgi cli crypt ctype curl curlwrappers exif fileinfo filter flatfile ftp gd gdbm hash iconv imap ipv6 json mysql mysqli nls pcntl phar posix readline session simplexml snmp soap sockets ssl sysvipc threads tokenizer truetype unicode wddx xml xmlreader xmlrpc xmlwriter xsl zip zlib All deprecated INI directives was changed in php.ini file and deprecated functions were replaced in site code. All dev-php5/* modules were recompiled. Here they are: dev-php5/pecl-http-1.6.6 dev-php5/pecl-memcache-3.0.5 dev-php5/xcache-1.3.0 Please, can you suggest what caused this problem? If it is fixed in CVS, can you provide me with php version that hasn't this problem? So I can wait for it in gentoo portage. -- Edit bug report at http://bugs.php.net/bug.php?id=53322&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53322&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53322&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53322&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53322&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53322&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53322&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53322&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53322&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53322&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53322&r=support Expected behavior: http://bugs.php.net/fix.php?id=53322&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53322&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53322&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53322&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53322&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53322&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53322&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53322&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53322&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53322&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53322&r=mysqlcfg
Req #53322 [Opn->Bgs]: zend_mm_heap corrupted
Edit report at http://bugs.php.net/bug.php?id=53322&edit=1 ID: 53322 Updated by: der...@php.net Reported by:alex at bintime dot com Summary:zend_mm_heap corrupted -Status: Open +Status: Bogus Type: Feature/Change Request Package:Apache2 related Operating System: gentoo (kernel 2.6.32-r2) PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Do not file bugs when you have Zend extensions (zend_extension=) loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache, APC, Xdebug and ionCube loader. These extensions often modify engine behavior which is not related to PHP itself. . Previous Comments: [2010-11-16 17:01:35] alex at bintime dot com Description: After updating php from 5.2.14 version to 5.3.3-r1 site didn't work in different moments of time. Apache error log showed this: [Fri Nov 12 00:14:52 2010] [notice] child pid 1389 exit signal Segmentation fault (11) [Fri Nov 12 00:14:55 2010] [notice] child pid 1361 exit signal Segmentation fault (11) zend_mm_heap corrupted zend_mm_heap corrupted After downgrading php from 5.3.3-r1 version to 5.2.14 problem has gone away. php was compiled without problems(I didn't receive any error or warning messages) php was compiled with next USE flags: apache2 bcmath berkdb bzip2 calendar cgi cli crypt ctype curl curlwrappers exif fileinfo filter flatfile ftp gd gdbm hash iconv imap ipv6 json mysql mysqli nls pcntl phar posix readline session simplexml snmp soap sockets ssl sysvipc threads tokenizer truetype unicode wddx xml xmlreader xmlrpc xmlwriter xsl zip zlib All deprecated INI directives was changed in php.ini file and deprecated functions were replaced in site code. All dev-php5/* modules were recompiled. Here they are: dev-php5/pecl-http-1.6.6 dev-php5/pecl-memcache-3.0.5 dev-php5/xcache-1.3.0 Please, can you suggest what caused this problem? If it is fixed in CVS, can you provide me with php version that hasn't this problem? So I can wait for it in gentoo portage. -- Edit this bug report at http://bugs.php.net/bug.php?id=53322&edit=1
[PHP-BUG] Bug #53323 [NEW]: Some calls to pdo_firebird getAttribute crash
From: Operating system: PHP version: 5.3.3 Package: PDO related Bug Type: Bug Bug description:Some calls to pdo_firebird getAttribute crash Description: There is a bug and a few omissions in firebird_handle_get_attribute. Most significantly it declares tmp[200] which is used to store the server version. Unfortunately, a typical server version string is now over 300 bytes long. So this call just blows the driver out of the water, leaves this error in the apache log: *** stack smashing detected ***: /usr/sbin/httpd2-prefork terminated [Tue Nov 16 13:42:53 2010] [notice] child pid 11656 exit signal Segmentation fault (11) and the user is left staring at a server timeout error in the browser. This is easily fixed by declaring tmp[] to be larger. Less seriously, these attributes are not handled: PDO_ATTR_PREFETCH, PDO_ATTR_TIMEOUT, PDO_ATTR_FETCH_TABLE_NAMES so if they are called outside a try..catch then the call will fail badly. It is not obvious that a try..catch should be required so it is probably better to just handle these cases in the driver. I've attached a patch which fixes all of these issues. -- Edit bug report at http://bugs.php.net/bug.php?id=53323&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53323&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53323&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53323&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53323&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53323&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53323&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53323&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53323&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53323&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53323&r=support Expected behavior: http://bugs.php.net/fix.php?id=53323&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53323&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53323&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53323&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53323&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53323&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53323&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53323&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53323&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53323&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53323&r=mysqlcfg
Req #53310 [Com]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1
ID: 53310
Comment by: sriram dot natarajan at gmail dot com
Reported by:stefan at whocares dot de
Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work
on v8
Status: Analyzed
Type: Feature/Change Request
Package:FPM related
Operating System: Linux (Debian for Sparc)
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
May I know as to why you need to compile with v8 ? compiling with v9
does not
automatically make your application 64-bit . if that is the reason you
want to
choose -v8 in here.
v8 sparc instruction is decade old - http://en.wikipedia.org/wiki/SPARC
and is not
being used in any hardware. so, i see no reason as to why we need to use
/ support
this specific instruction set.
Previous Comments:
[2010-11-15 03:05:11] stefan at whocares dot de
Well, I blatantly copied from PostgreSQL's s_lock.h and came up with
this:
diff -Nau fpm_atomic.h.org fpm_atomic.h
--- fpm_atomic.h.org2009-12-14 09:18:53.0 +
+++ fpm_atomic.h2010-11-15 01:50:31.0 +
@@ -82,7 +82,7 @@
#endif /* defined (__GNUC__) &&... */
#elif ( __sparc__ || __sparc ) /* Marcin Ochab */
-
+#if (__sparc_v9__)
#if (__arch64__ || __arch64)
typedef uint64_tatomic_uint_t;
typedef volatile atomic_uint_t atomic_t;
@@ -118,7 +118,23 @@
}
/* }}} */
#endif
+#else /* sparcv9 */
+typedef uint32_tatomic_uint_t;
+typedef volatile atomic_uint_t atomic_t;
+static inline int atomic_cas_32(atomic_t *lock) /* {{{ */
+{
+ register atomic_uint_t _res;
+ __asm__ __volatile__("ldstub [%2], %0" : "=r"(_res),
"+m"(*lock) : "r"(lock) : "memory");
+ return (int) _res;
+}
+/* }}} */
+
+static inline atomic_uint_t atomic_cmp_set(atomic_t *lock,
atomic_uint_t old,
atomic_uint_t set) /* {{{ */
+{
+ return (atomic_cas_32(lock)==0);
+}
+/* }}} */
#else
#error unsupported processor. please write a patch and send it to me
Rationale:
If I'm reading the original code correctly, there's no actual locking
done but
instead the code only tests whether it could acquire a lock. 'ldstub'
works such
that it returns the current value of the memory region specified and
sets it to
all '1' afterwards. Thus, if the return value is '-1' the lock was
already set
by another process whereas if it's '0' we acquired the lock. Well, at
least in
my certainly flawed logic ;) Since ldstub is atomic I didn't see a need
to
explicitly "lock;" the code.
The patch should leave the 'cas' code intact when being compiled on v9
type
SPARC systems. Tested (for successful compilation only!) on Debian
(etch) using
gcc 3.3.5. Thus I believe further testing is necessary to verify this is
actually working.
Well, please test and incorporate if you feel the code is doing what
it's
supposed to do.
[2010-11-15 00:53:49] f...@php.net
As the sparc documentation says
(http://developers.sun.com/solaris/articles/atomic_sparc/#CAS):
The SPARC v9 manual introduced the newest atomic instruction: compare
and swap
(cas)
I don't know how to fix this right now. If you know someone who can,
he's
welcome. I've already asked for help.
wait and see
[2010-11-15 00:21:50] stefan at whocares dot de
Description:
Compiling with PHP-FPM enabled on an older SPARC system will result in
/tmp/cc6w5Fh0.s: Assembler messages:
/tmp/cc6w5Fh0.s:39: Error: Architecture mismatch on "cas".
/tmp/cc6w5Fh0.s:39: (Requires v9|v9a|v9b; requested architecture is
sparclite.)
Unfortunately my knowledge of SPARC assembly language isn't nearly good
enough to fix that. I know that the v9 "cas" opcode does an atomic
"compare and swap" operation but I wouldn't know how to translate that
into v8 code.
Test script:
---
Copy /sapi/fpm/fpm/fpm_atomic.h to fpm_atomic.c and add bogus main()
function:
int main () {
int result;
atomic_t mylock;
result = fpm_spinlock(&mylock, 1);
}
Compile using "gcc -mcpu=v8 fpm_atomic.c" will result in error message
given.
Expected result:
Should compile without error.
Actual result:
--
sparky:~# gcc -mcpu=v8 fpm_atomic.c
/tmp/cciAbMrC.s: Assembler messages:
/tmp/cciAbMrC.s:121: Error: Architecture mismatch on "cas".
/tmp/cciAbMrC.s:121: (Requires v9|v9a|v9b; requested architecture is
sparclite.)
sparky:~#
--
Edit this bug
Bug #53323 [Opn->Csd]: pdo_firebird getAttribute() crash
Edit report at http://bugs.php.net/bug.php?id=53323&edit=1 ID: 53323 Updated by: fel...@php.net Reported by:preeves at ibphoenix dot com -Summary:Some calls to pdo_firebird getAttribute crash +Summary:pdo_firebird getAttribute() crash -Status: Open +Status: Closed Type: Bug Package:PDO related PHP Version:5.3.3 -Assigned To: +Assigned To:felipe 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/. Thank you for the report, and for helping us make PHP better. Thanks for the patch! I've modified a bit the patch, I removed the lines adding PDO_ATTR_PREFETCH, PDO_ATTR_TIMEOUT, as this is not a pdo_firebird problem, but the pdo drivers works in this way. Previous Comments: [2010-11-16 22:02:16] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=305416 Log: - Fixed bug #53323 (pdo_firebird getAttribute() crash) patch by: preeves at ibphoenix dot com [2010-11-16 17:44:58] preeves at ibphoenix dot com Description: There is a bug and a few omissions in firebird_handle_get_attribute. Most significantly it declares tmp[200] which is used to store the server version. Unfortunately, a typical server version string is now over 300 bytes long. So this call just blows the driver out of the water, leaves this error in the apache log: *** stack smashing detected ***: /usr/sbin/httpd2-prefork terminated [Tue Nov 16 13:42:53 2010] [notice] child pid 11656 exit signal Segmentation fault (11) and the user is left staring at a server timeout error in the browser. This is easily fixed by declaring tmp[] to be larger. Less seriously, these attributes are not handled: PDO_ATTR_PREFETCH, PDO_ATTR_TIMEOUT, PDO_ATTR_FETCH_TABLE_NAMES so if they are called outside a try..catch then the call will fail badly. It is not obvious that a try..catch should be required so it is probably better to just handle these cases in the driver. I've attached a patch which fixes all of these issues. -- Edit this bug report at http://bugs.php.net/bug.php?id=53323&edit=1
Bug #53311 [Com]: startup failed.
Edit report at http://bugs.php.net/bug.php?id=53311&edit=1 ID: 53311 Comment by: f...@php.net Reported by:paulgao at yeah dot net Summary:startup failed. Status: Feedback Type: Bug Package:FPM related Operating System: Centos 64-bit 5.5 PHP Version:5.3SVN-2010-11-15 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: with which user do you run FPM ? Try to set daemonize = off in php-fpm.conf and run it again. Previous Comments: [2010-11-16 09:23:02] paulgao at yeah dot net I use patch V2. if old fpm.log not remove, startup still failed. but old fpm.log removed, startup is OK. restart is OK too. what problem? [2010-11-16 09:17:44] f...@php.net can you: 1- stop FPM 2- remove or move /home/logs/fpm.log 3- set log level to DEBUG 4- run FPM 5- dump the content of /home/logs/fpm.log here thx [2010-11-16 09:05:46] f...@php.net Please use fpm-zlog_set_fd.v2.patch instead of fpm-zlog_set_fd.v1.patch. thx [2010-11-16 09:05:19] f...@php.net The following patch has been added/updated: Patch Name: fpm-zlog_set_fd.v2.patch Revision: 1289894719 URL: http://bugs.php.net/patch-display.php?bug=53311&patch=fpm-zlog_set_fd.v2.patch&revision=1289894719 [2010-11-16 03:24:22] paulgao at yeah dot net -tt output: Nov 16 10:23:42.631153 [NOTICE] [General] Nov 16 10:23:42.631199 [NOTICE] pid = /home/php-fpm.pid Nov 16 10:23:42.631205 [NOTICE] daemonize = yes Nov 16 10:23:42.631232 [NOTICE] error_log = /home/logs/fpm.log Nov 16 10:23:42.631239 [NOTICE] log_level = NOTICE Nov 16 10:23:42.631244 [NOTICE] process_control_timeout = 5s Nov 16 10:23:42.631250 [NOTICE] emergency_restart_interval = 60s Nov 16 10:23:42.631256 [NOTICE] emergency_restart_threshold = 10 Nov 16 10:23:42.631268 [NOTICE] Nov 16 10:23:42.631283 [NOTICE] [www] Nov 16 10:23:42.631288 [NOTICE] prefix = undefined Nov 16 10:23:42.631294 [NOTICE] user = nobody Nov 16 10:23:42.631303 [NOTICE] group = nobody Nov 16 10:23:42.631308 [NOTICE] chroot = Nov 16 10:23:42.631323 [NOTICE] chdir = Nov 16 10:23:42.631329 [NOTICE] listen = 0.0.0.0:8001 Nov 16 10:23:42.631334 [NOTICE] listen.backlog = -1 Nov 16 10:23:42.631340 [NOTICE] listen.owner = undefined Nov 16 10:23:42.631352 [NOTICE] listen.group = undefined Nov 16 10:23:42.631359 [NOTICE] listen.mode = 0666 Nov 16 10:23:42.631364 [NOTICE] listen.allowed_clients = undefined Nov 16 10:23:42.631370 [NOTICE] pm = dynamic Nov 16 10:23:42.631375 [NOTICE] pm.max_children = 48 Nov 16 10:23:42.631381 [NOTICE] pm.max_requests = 0 Nov 16 10:23:42.631391 [NOTICE] pm.start_servers = 16 Nov 16 10:23:42.631405 [NOTICE] pm.min_spare_servers = 16 Nov 16 10:23:42.631411 [NOTICE] pm.max_spare_servers = 32 Nov 16 10:23:42.631417 [NOTICE] pm.status_path = /fpm_status Nov 16 10:23:42.631423 [NOTICE] ping.path = /fpm_ping Nov 16 10:23:42.631428 [NOTICE] ping.response = pong Nov 16 10:23:42.631452 [NOTICE] catch_workers_output = yes Nov 16 10:23:42.631458 [NOTICE] request_terminate_timeout = 0s Nov 16 10:23:42.631464 [NOTICE] request_slowlog_timeout = 1s Nov 16 10:23:42.631478 [NOTICE] slowlog = /home/logs/fpm_slow.log Nov 16 10:23:42.631484 [NOTICE] rlimit_files = 51200 Nov 16 10:23:42.631489 [NOTICE] rlimit_core = 0 Nov 16 10:23:42.631495 [NOTICE] Nov 16 10:23:42.631515 [NOTICE] configuration file /home/codebase/server-config/php-fpm-api-test.ini test is successful 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=53311 -- Edit this bug report at http://bugs.php.net/bug.php?id=53311&edit=1
Req #53310 [Ana->Wfx]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1
ID: 53310
Updated by: f...@php.net
Reported by:stefan at whocares dot de
Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work
on v8
-Status: Analyzed
+Status: Wont fix
Type: Feature/Change Request
Package:FPM related
Operating System: Linux (Debian for Sparc)
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
we've decided sparc < v9 won't be supported. I've just updated the
source code to
warn specificaly about this.
Previous Comments:
[2010-11-16 23:02:38] f...@php.net
Automatic comment from SVN on behalf of fat
Revision: http://svn.php.net/viewvc/?view=revision&revision=305417
Log: - Fixed #53310 (sparc < v9 won't is not supported)
[2010-11-16 19:48:36] sriram dot natarajan at gmail dot com
May I know as to why you need to compile with v8 ? compiling with v9
does not
automatically make your application 64-bit . if that is the reason you
want to
choose -v8 in here.
v8 sparc instruction is decade old - http://en.wikipedia.org/wiki/SPARC
and is not
being used in any hardware. so, i see no reason as to why we need to use
/ support
this specific instruction set.
[2010-11-15 03:05:11] stefan at whocares dot de
Well, I blatantly copied from PostgreSQL's s_lock.h and came up with
this:
diff -Nau fpm_atomic.h.org fpm_atomic.h
--- fpm_atomic.h.org2009-12-14 09:18:53.0 +
+++ fpm_atomic.h2010-11-15 01:50:31.0 +
@@ -82,7 +82,7 @@
#endif /* defined (__GNUC__) &&... */
#elif ( __sparc__ || __sparc ) /* Marcin Ochab */
-
+#if (__sparc_v9__)
#if (__arch64__ || __arch64)
typedef uint64_tatomic_uint_t;
typedef volatile atomic_uint_t atomic_t;
@@ -118,7 +118,23 @@
}
/* }}} */
#endif
+#else /* sparcv9 */
+typedef uint32_tatomic_uint_t;
+typedef volatile atomic_uint_t atomic_t;
+static inline int atomic_cas_32(atomic_t *lock) /* {{{ */
+{
+ register atomic_uint_t _res;
+ __asm__ __volatile__("ldstub [%2], %0" : "=r"(_res),
"+m"(*lock) : "r"(lock) : "memory");
+ return (int) _res;
+}
+/* }}} */
+
+static inline atomic_uint_t atomic_cmp_set(atomic_t *lock,
atomic_uint_t old,
atomic_uint_t set) /* {{{ */
+{
+ return (atomic_cas_32(lock)==0);
+}
+/* }}} */
#else
#error unsupported processor. please write a patch and send it to me
Rationale:
If I'm reading the original code correctly, there's no actual locking
done but
instead the code only tests whether it could acquire a lock. 'ldstub'
works such
that it returns the current value of the memory region specified and
sets it to
all '1' afterwards. Thus, if the return value is '-1' the lock was
already set
by another process whereas if it's '0' we acquired the lock. Well, at
least in
my certainly flawed logic ;) Since ldstub is atomic I didn't see a need
to
explicitly "lock;" the code.
The patch should leave the 'cas' code intact when being compiled on v9
type
SPARC systems. Tested (for successful compilation only!) on Debian
(etch) using
gcc 3.3.5. Thus I believe further testing is necessary to verify this is
actually working.
Well, please test and incorporate if you feel the code is doing what
it's
supposed to do.
[2010-11-15 00:53:49] f...@php.net
As the sparc documentation says
(http://developers.sun.com/solaris/articles/atomic_sparc/#CAS):
The SPARC v9 manual introduced the newest atomic instruction: compare
and swap
(cas)
I don't know how to fix this right now. If you know someone who can,
he's
welcome. I've already asked for help.
wait and see
[2010-11-15 00:21:50] stefan at whocares dot de
Description:
Compiling with PHP-FPM enabled on an older SPARC system will result in
/tmp/cc6w5Fh0.s: Assembler messages:
/tmp/cc6w5Fh0.s:39: Error: Architecture mismatch on "cas".
/tmp/cc6w5Fh0.s:39: (Requires v9|v9a|v9b; requested architecture is
sparclite.)
Unfortunately my knowledge of SPARC assembly language isn't nearly good
enough to fix that. I know that the v9 "cas" opcode does an atomic
"compare and swap" operation but I wouldn't know how to translate that
into v8 code.
Test script:
---
Copy /sapi/fpm/fpm/fpm_atomic.h to fpm_atomic.c and add bogus main()
function:
int main () {
int result;
atomic_t mylock;
result = fp
Bug #53319 [Opn->Tbd]: Strip_tags() may strip '' incorrectly
Edit report at http://bugs.php.net/bug.php?id=53319&edit=1 ID: 53319 Updated by: fel...@php.net Reported by:Ray dot Paseur at Gmail dot com Summary:Strip_tags() may strip '' incorrectly -Status: Open +Status: To be documented Type: Bug Package:Strings related Operating System: Linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: I've fixed the bug related to '' is stripping in the string. About strip_tags($str, ''): The allowed tags should not contains slash char. This must be documented though. Previous Comments: [2010-11-16 23:16:46] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=305418 Log: - Fixed bug #53319 (strip_tags() may strip '
' incorrectly) [2010-11-16 01:22:26] Ray dot Paseur at Gmail dot com Description: --- >From manual page: http://www.php.net/function.strip-tags#Return Values --- Test script: --- USDCDN'; $new = strip_tags($str); echo $new; // Prints USDCDN // TRY TO PRESERVE ALLOWABLE TAGS $new = strip_tags($str, ''); echo $new; // Prints USDCDN -- The break tag is not preserved $new = strip_tags($str, ''); echo $new; // Prints USDCDN // SELF-CLOSING TAGS WITHOUT SPACES $str = 'USDCDN'; $new = strip_tags($str, ''); echo $new; // Prints USDCDN Expected result: strip_tags() should preserve the allowable_tags Actual result: -- strip_tags did not always preserve the allowable_tags -- Edit this bug report at http://bugs.php.net/bug.php?id=53319&edit=1
Bug #53140 [Com]: PHP-CGI (FastCGI IIS) crashes when creating DOTNET instance every second time
Edit report at http://bugs.php.net/bug.php?id=53140&edit=1
ID: 53140
Comment by: davidphp at limegreensocks dot com
Reported by:jeyb88 at gmail dot com
Summary:PHP-CGI (FastCGI IIS) crashes when creating DOTNET
instance every second time
Status: Open
Type: Bug
Package:COM related
Operating System: XP, Vista, Win 7,Win Server 2008
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
It appears this behavior was intentionally introduced by WEZ back in
2003.
http://svn.php.net/viewvc/php/php-src/trunk/ext/com_dotnet/com_dotnet.c?r1=137794&r2=146718
I don't know what problem he was trying to fix back then, so I'm not
sure of the implications of adding these two lines back. But if you are
using fastcgi, then jeyb88 is absolutely correct: this will crash every
other time the code is run.
My repro is even simpler than jeyb88's. I don't even have to call any
methods on the .net object. I have a 1 line php file that calls the
"new" against my .net class:
The constructor for my .net class is empty:
[ComVisible(true),
ClassInterface(ClassInterfaceType.None),
Guid("53C74B01-EC09-45a4-A741-42727858B2A1")]
public class Impersonation
{
public Impersonation()
{
}
// more code follows
When I first browse to the page, it (correctly) shows nothing. Then I
hit refresh, and I get the "FastCGI process exited unexpectedly"
0xc005. If I hit refresh again, the page again (correctly) shows
nothing, next time, fastcgi AVs again.
I am using php 5.3.3, Windows Server 2003, and I have tried both .Net
2.0 and .Net 3.5.
The pattern here is easily reproducible, causes an unrecoverable access
violation, and there is no workaround. A fix here would be greatly
appreciated.
Previous Comments:
[2010-10-22 15:59:15] jeyb88 at gmail dot com
Description:
The php-cgi.exe will crash after every second refresh when I make an
instance of the DOTNET class. The Website is hostet via IIS 7 and PHP is
configured as FastCGI module. When I configure PHP on IIS as CGI module
everything works fine, but I can not do without FastCGI. I have made a
change in the com_dotnet.c file in function php_com_dotnet_rshutdown.
The variable called stuff from type dotnet_runtime_stuff will not be
released like in the function php_com_dotnet_mshutdown. So I have added
this two lines to the function php_com_dotnet_rshutdown:
free(stuff);
COMG(dotnet_runtime_stuff) = NULL;
After that I have compiled PHP 5.3.3 with Visual Studio 2008 (VC9) x86
with almost the same configuration like in the PHP 5.3.3 nts version but
without zlib:
configure "--enable-snapshot-build" "--enable-debug-pack"
"--disable-zts" "--disable-isapi" "--disable-nsapi" "--without-mssql"
"--without-pdo-mssql" "--without-pi3web" "--with-pdo-oci" "--with-oci8"
"--with-oci8-11g" "--with-enchant=shared"
"--enable-object-out-dir=../obj/" "--enable-com-dotnet"
"--with-mcrypt=static" "--disable-zlib"
The include and lib files are relative to the configuration file (in the
deps folder). I have earned following error and that's why I have
disabled zlib:
php5.dll.def : error LNK2001: unresolved external symbol compressBound
php5.dll.def : error LNK2001: unresolved external symbol deflateBound
php5.dll.def : error LNK2001: unresolved external symbol deflatePrime
php5.dll.def : error LNK2001: unresolved external symbol gzclearerr
php5.dll.def : error LNK2001: unresolved external symbol gzungetc
php5.dll.def : error LNK2001: unresolved external symbol inflateBack
php5.dll.def : error LNK2001: unresolved external symbol inflateBackEnd
php5.dll.def : error LNK2001: unresolved external symbol
inflateBackInit_
php5.dll.def : error LNK2001: unresolved external symbol inflateCopy
php5.dll.def : error LNK2001: unresolved external symbol
zlibCompileFlags
The error in the com_dotnet.c file was the error, because now with the
new compiled version, fastcgi will not be terminated. Is the zlib
extension necessary for complex php websites like Joomla? Because now
the compiled php version can interpret the sample shown below and it can
interpret simple php scripts, but when I try to load a Joomla site, the
FastCGI will crash. What is wrong with the made configuration? Can you
give me an important hint of how to compile php5.3.3 like in the
original php version?
Best regards, JeyB
Test script:
---
Push(".Net");
$stack->Push("Hello ");
echo $stack->Pop() . $stack->Pop();
}
catch(Exception $lEx)
{
echo "Error occurred:".$lEx->getMessage();
}
?>
--
Edit this bug report at http://bugs.php.net/bug.php?
Req #53310 [Wfx]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1
ID: 53310
User updated by:stefan at whocares dot de
Reported by:stefan at whocares dot de
Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work
on v8
Status: Wont fix
Type: Feature/Change Request
Package:FPM related
Operating System: Linux (Debian for Sparc)
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
Of course you may ask: because I'm porting PHP to the ReadyNAS platform
which
happens to use a SPARC v8 compatible CPU and thus *needs* the v8
instruction set.
Seeing that you've already made up your mind though, so I guess there's
nothing
more to add here. Makes me wonder why I can't get a response in > 24
hours as to
my patch but you can't wait for me to answer for like 4 hours.
Previous Comments:
[2010-11-16 23:05:04] f...@php.net
we've decided sparc < v9 won't be supported. I've just updated the
source code to
warn specificaly about this.
[2010-11-16 23:02:38] f...@php.net
Automatic comment from SVN on behalf of fat
Revision: http://svn.php.net/viewvc/?view=revision&revision=305417
Log: - Fixed #53310 (sparc < v9 won't is not supported)
[2010-11-16 19:48:36] sriram dot natarajan at gmail dot com
May I know as to why you need to compile with v8 ? compiling with v9
does not
automatically make your application 64-bit . if that is the reason you
want to
choose -v8 in here.
v8 sparc instruction is decade old - http://en.wikipedia.org/wiki/SPARC
and is not
being used in any hardware. so, i see no reason as to why we need to use
/ support
this specific instruction set.
[2010-11-15 03:05:11] stefan at whocares dot de
Well, I blatantly copied from PostgreSQL's s_lock.h and came up with
this:
diff -Nau fpm_atomic.h.org fpm_atomic.h
--- fpm_atomic.h.org2009-12-14 09:18:53.0 +
+++ fpm_atomic.h2010-11-15 01:50:31.0 +
@@ -82,7 +82,7 @@
#endif /* defined (__GNUC__) &&... */
#elif ( __sparc__ || __sparc ) /* Marcin Ochab */
-
+#if (__sparc_v9__)
#if (__arch64__ || __arch64)
typedef uint64_tatomic_uint_t;
typedef volatile atomic_uint_t atomic_t;
@@ -118,7 +118,23 @@
}
/* }}} */
#endif
+#else /* sparcv9 */
+typedef uint32_tatomic_uint_t;
+typedef volatile atomic_uint_t atomic_t;
+static inline int atomic_cas_32(atomic_t *lock) /* {{{ */
+{
+ register atomic_uint_t _res;
+ __asm__ __volatile__("ldstub [%2], %0" : "=r"(_res),
"+m"(*lock) : "r"(lock) : "memory");
+ return (int) _res;
+}
+/* }}} */
+
+static inline atomic_uint_t atomic_cmp_set(atomic_t *lock,
atomic_uint_t old,
atomic_uint_t set) /* {{{ */
+{
+ return (atomic_cas_32(lock)==0);
+}
+/* }}} */
#else
#error unsupported processor. please write a patch and send it to me
Rationale:
If I'm reading the original code correctly, there's no actual locking
done but
instead the code only tests whether it could acquire a lock. 'ldstub'
works such
that it returns the current value of the memory region specified and
sets it to
all '1' afterwards. Thus, if the return value is '-1' the lock was
already set
by another process whereas if it's '0' we acquired the lock. Well, at
least in
my certainly flawed logic ;) Since ldstub is atomic I didn't see a need
to
explicitly "lock;" the code.
The patch should leave the 'cas' code intact when being compiled on v9
type
SPARC systems. Tested (for successful compilation only!) on Debian
(etch) using
gcc 3.3.5. Thus I believe further testing is necessary to verify this is
actually working.
Well, please test and incorporate if you feel the code is doing what
it's
supposed to do.
[2010-11-15 00:53:49] f...@php.net
As the sparc documentation says
(http://developers.sun.com/solaris/articles/atomic_sparc/#CAS):
The SPARC v9 manual introduced the newest atomic instruction: compare
and swap
(cas)
I don't know how to fix this right now. If you know someone who can,
he's
welcome. I've already asked for help.
wait and see
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=53310
--
Edit this bug report at http://bugs.php.net/bug.php?id=53310&edit=1
Req #53310 [Com]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1
ID: 53310
Comment by: f...@php.net
Reported by:stefan at whocares dot de
Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work
on v8
Status: Wont fix
Type: Feature/Change Request
Package:FPM related
Operating System: Linux (Debian for Sparc)
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
you should be able to compile with a gcc version which provides the
__sync_bool_compare_and_swap builtin function (>= 4.1).
It's supported by FPM. If with this version of GCC FPM is not able to be
compiled,
there is a bug in FPM. We'll take care of it.
It this a reasonable solution ?
Previous Comments:
[2010-11-16 23:52:42] stefan at whocares dot de
Of course you may ask: because I'm porting PHP to the ReadyNAS platform
which
happens to use a SPARC v8 compatible CPU and thus *needs* the v8
instruction set.
Seeing that you've already made up your mind though, so I guess there's
nothing
more to add here. Makes me wonder why I can't get a response in > 24
hours as to
my patch but you can't wait for me to answer for like 4 hours.
[2010-11-16 23:05:04] f...@php.net
we've decided sparc < v9 won't be supported. I've just updated the
source code to
warn specificaly about this.
[2010-11-16 23:02:38] f...@php.net
Automatic comment from SVN on behalf of fat
Revision: http://svn.php.net/viewvc/?view=revision&revision=305417
Log: - Fixed #53310 (sparc < v9 won't is not supported)
[2010-11-16 19:48:36] sriram dot natarajan at gmail dot com
May I know as to why you need to compile with v8 ? compiling with v9
does not
automatically make your application 64-bit . if that is the reason you
want to
choose -v8 in here.
v8 sparc instruction is decade old - http://en.wikipedia.org/wiki/SPARC
and is not
being used in any hardware. so, i see no reason as to why we need to use
/ support
this specific instruction set.
[2010-11-15 03:05:11] stefan at whocares dot de
Well, I blatantly copied from PostgreSQL's s_lock.h and came up with
this:
diff -Nau fpm_atomic.h.org fpm_atomic.h
--- fpm_atomic.h.org2009-12-14 09:18:53.0 +
+++ fpm_atomic.h2010-11-15 01:50:31.0 +
@@ -82,7 +82,7 @@
#endif /* defined (__GNUC__) &&... */
#elif ( __sparc__ || __sparc ) /* Marcin Ochab */
-
+#if (__sparc_v9__)
#if (__arch64__ || __arch64)
typedef uint64_tatomic_uint_t;
typedef volatile atomic_uint_t atomic_t;
@@ -118,7 +118,23 @@
}
/* }}} */
#endif
+#else /* sparcv9 */
+typedef uint32_tatomic_uint_t;
+typedef volatile atomic_uint_t atomic_t;
+static inline int atomic_cas_32(atomic_t *lock) /* {{{ */
+{
+ register atomic_uint_t _res;
+ __asm__ __volatile__("ldstub [%2], %0" : "=r"(_res),
"+m"(*lock) : "r"(lock) : "memory");
+ return (int) _res;
+}
+/* }}} */
+
+static inline atomic_uint_t atomic_cmp_set(atomic_t *lock,
atomic_uint_t old,
atomic_uint_t set) /* {{{ */
+{
+ return (atomic_cas_32(lock)==0);
+}
+/* }}} */
#else
#error unsupported processor. please write a patch and send it to me
Rationale:
If I'm reading the original code correctly, there's no actual locking
done but
instead the code only tests whether it could acquire a lock. 'ldstub'
works such
that it returns the current value of the memory region specified and
sets it to
all '1' afterwards. Thus, if the return value is '-1' the lock was
already set
by another process whereas if it's '0' we acquired the lock. Well, at
least in
my certainly flawed logic ;) Since ldstub is atomic I didn't see a need
to
explicitly "lock;" the code.
The patch should leave the 'cas' code intact when being compiled on v9
type
SPARC systems. Tested (for successful compilation only!) on Debian
(etch) using
gcc 3.3.5. Thus I believe further testing is necessary to verify this is
actually working.
Well, please test and incorporate if you feel the code is doing what
it's
supposed to do.
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=53310
--
Edit this bug report at http://bugs.php.net/bug.php?id=53310&edit=1
Req #53310 [Wfx]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1 ID: 53310 Updated by: paj...@php.net Reported by:stefan at whocares dot de Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work on v8 Status: Wont fix Type: Feature/Change Request Package:FPM related Operating System: Linux (Debian for Sparc) PHP Version:5.3.3 Assigned To:fat Block user comment: N Private report: N New Comment: And you can still use FastCGI, btw. FPM is fairly new, and if new SAPIs have to support soon to be dead OSes, then we will cruelly need more developers to maintain everything :) Previous Comments: [2010-11-17 00:03:57] f...@php.net you should be able to compile with a gcc version which provides the __sync_bool_compare_and_swap builtin function (>= 4.1). It's supported by FPM. If with this version of GCC FPM is not able to be compiled, there is a bug in FPM. We'll take care of it. It this a reasonable solution ? [2010-11-16 23:52:42] stefan at whocares dot de Of course you may ask: because I'm porting PHP to the ReadyNAS platform which happens to use a SPARC v8 compatible CPU and thus *needs* the v8 instruction set. Seeing that you've already made up your mind though, so I guess there's nothing more to add here. Makes me wonder why I can't get a response in > 24 hours as to my patch but you can't wait for me to answer for like 4 hours. [2010-11-16 23:05:04] f...@php.net we've decided sparc < v9 won't be supported. I've just updated the source code to warn specificaly about this. [2010-11-16 23:02:38] f...@php.net Automatic comment from SVN on behalf of fat Revision: http://svn.php.net/viewvc/?view=revision&revision=305417 Log: - Fixed #53310 (sparc < v9 won't is not supported) [2010-11-16 19:48:36] sriram dot natarajan at gmail dot com May I know as to why you need to compile with v8 ? compiling with v9 does not automatically make your application 64-bit . if that is the reason you want to choose -v8 in here. v8 sparc instruction is decade old - http://en.wikipedia.org/wiki/SPARC and is not being used in any hardware. so, i see no reason as to why we need to use / support this specific instruction set. 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=53310 -- Edit this bug report at http://bugs.php.net/bug.php?id=53310&edit=1
Req #53310 [Wfx]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1
ID: 53310
User updated by:stefan at whocares dot de
Reported by:stefan at whocares dot de
Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work
on v8
Status: Wont fix
Type: Feature/Change Request
Package:FPM related
Operating System: Linux (Debian for Sparc)
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
As you may have read in my initial post, the compiler I (have to) use is
gcc
3.3.5 which falls a bit short of 4.1 ;) Also, you may want to read the
backend/port/tas/solaris_sparc.s file from the official PostgreSQL
sources:
! "cas" only works on sparcv9 and sparcv8plus chips, and
! requies a compiler targeting these CPUs. It will fail
! on a compiler targeting sparcv8, and of course will not
! be understood by a sparcv8 CPU. gcc continues to use
! "ldstub" because it targets sparcv7.
There they work around this by using a condition (for the SUN compiler)
like
this:
#if defined(__sparcv9) || defined(__sparcv8plus)
cas [%o0],%o2,%o1
#else
ldstub [%o0],%o1
#endif
and in their actual generic lock implementation
(src/include/storage/s_lock.h)
the code is this:
#if defined(__sparc__) /* Sparc */
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
#define TAS(lock) tas(lock)
static __inline__ int
tas(volatile slock_t *lock)
{
register slock_t _res;
/*
* See comment in /pg/backend/port/tas/solaris_sparc.s for
why this
* uses "ldstub", and that file uses "cas". gcc currently
generates
* sparcv7-targeted binaries, so "cas" use isn't possible.
*/
__asm__ __volatile__(
" ldstub [%2], %0\n"
: "=r"(_res), "+m"(*lock)
: "r"(lock)
: "memory");
return (int) _res;
}
#endif /* __sparc__ */
Now my general idea was that if there's a reason for PostgreSQL to keep
that
code around, there might be a reason for PHP to do so as well. Obviously
I was
wrong there.
I also do not see the real advantage of 'cas' over 'ldstub' in the
current
scenario since both are atomic, both are supported (ldstub even on v7)
and both
do the job perfectly well.
Previous Comments:
[2010-11-17 00:22:59] paj...@php.net
And you can still use FastCGI, btw. FPM is fairly new, and if new SAPIs
have to support soon to be dead OSes, then we will cruelly need more
developers to maintain everything :)
[2010-11-17 00:03:57] f...@php.net
you should be able to compile with a gcc version which provides the
__sync_bool_compare_and_swap builtin function (>= 4.1).
It's supported by FPM. If with this version of GCC FPM is not able to be
compiled,
there is a bug in FPM. We'll take care of it.
It this a reasonable solution ?
[2010-11-16 23:52:42] stefan at whocares dot de
Of course you may ask: because I'm porting PHP to the ReadyNAS platform
which
happens to use a SPARC v8 compatible CPU and thus *needs* the v8
instruction set.
Seeing that you've already made up your mind though, so I guess there's
nothing
more to add here. Makes me wonder why I can't get a response in > 24
hours as to
my patch but you can't wait for me to answer for like 4 hours.
[2010-11-16 23:05:04] f...@php.net
we've decided sparc < v9 won't be supported. I've just updated the
source code to
warn specificaly about this.
[2010-11-16 23:02:38] f...@php.net
Automatic comment from SVN on behalf of fat
Revision: http://svn.php.net/viewvc/?view=revision&revision=305417
Log: - Fixed #53310 (sparc < v9 won't is not supported)
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=53310
--
Edit this bug report at http://bugs.php.net/bug.php?id=53310&edit=1
Req #53310 [Wfx]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1
ID: 53310
User updated by:stefan at whocares dot de
Reported by:stefan at whocares dot de
Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work
on v8
Status: Wont fix
Type: Feature/Change Request
Package:FPM related
Operating System: Linux (Debian for Sparc)
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
@paj...@php.net
Did it ever occur to you that I found this bug/problem because I
*specifically
wanted to use FPM* in the first place? Had I wanted to use FastCGI I'd
have
certainly done so. Seeing that there already was a solution for Sparc v9
I
thought there might be interest in a solution that would allow PHP to
run on
older machines.
Hardware that maybe you're laughing about. But hardware that's still in
fairly
wide use. And, come to think of it, hardware that may also be the only
hardware
people in poorer countries than the one you're obviously living in are
able to
get their hands on. So I first asked and then got my hands dirty and
even
provided a possible solution - and one that could be easily implemented,
too.
And what for? Only to get ignorance and witty remarks in return. Well, I
almost
forgot that the PHP project has such a bad reputation when it comes to
bugs and
patches. Thanks for reminding me why. Now you can safely go back to your
ivory
tower and think about supporting next decade's hardware only. For my
part, I
promise to keep any bugs/problems in PHP I may find in the future to
myself and
will do the same for any patches I may come up with.
Btw: the boxes I'm talking about are running Linux (which you could have
seen by
looking at the "OS:" tag) and I really have no idea why you'd call that
a "soon
to be dead OS". If you have a problem understanding the difference
between a CPU
and an OS, may I ask what exactly makes you think you can give some
valuable
input here? As for the "cruelly needed developers" you mention: I don't
see why
you should need those as long as the community comes up with patches you
could
use. Ok, if you keep driving away people like this, I start to have an
idea as
to why ;)
Previous Comments:
[2010-11-17 00:24:30] stefan at whocares dot de
As you may have read in my initial post, the compiler I (have to) use is
gcc
3.3.5 which falls a bit short of 4.1 ;) Also, you may want to read the
backend/port/tas/solaris_sparc.s file from the official PostgreSQL
sources:
! "cas" only works on sparcv9 and sparcv8plus chips, and
! requies a compiler targeting these CPUs. It will fail
! on a compiler targeting sparcv8, and of course will not
! be understood by a sparcv8 CPU. gcc continues to use
! "ldstub" because it targets sparcv7.
There they work around this by using a condition (for the SUN compiler)
like
this:
#if defined(__sparcv9) || defined(__sparcv8plus)
cas [%o0],%o2,%o1
#else
ldstub [%o0],%o1
#endif
and in their actual generic lock implementation
(src/include/storage/s_lock.h)
the code is this:
#if defined(__sparc__) /* Sparc */
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
#define TAS(lock) tas(lock)
static __inline__ int
tas(volatile slock_t *lock)
{
register slock_t _res;
/*
* See comment in /pg/backend/port/tas/solaris_sparc.s for
why this
* uses "ldstub", and that file uses "cas". gcc currently
generates
* sparcv7-targeted binaries, so "cas" use isn't possible.
*/
__asm__ __volatile__(
" ldstub [%2], %0\n"
: "=r"(_res), "+m"(*lock)
: "r"(lock)
: "memory");
return (int) _res;
}
#endif /* __sparc__ */
Now my general idea was that if there's a reason for PostgreSQL to keep
that
code around, there might be a reason for PHP to do so as well. Obviously
I was
wrong there.
I also do not see the real advantage of 'cas' over 'ldstub' in the
current
scenario since both are atomic, both are supported (ldstub even on v7)
and both
do the job perfectly well.
[2010-11-17 00:22:59] paj...@php.net
And you can still use FastCGI, btw. FPM is fairly new, and if new SAPIs
have to support soon to be dead OSes, then we will cruelly need more
developers to maintain everything :)
[2010-11-17 00:03:57] f...@php.net
you should be able to compile with a gcc version which provides the
__sync_bool_compare_and_swap builtin function (>= 4.1).
It's supported by FPM. If with
Req #53310 [Wfx]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1
ID: 53310
Updated by: paj...@php.net
Reported by:stefan at whocares dot de
Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work
on v8
Status: Wont fix
Type: Feature/Change Request
Package:FPM related
Operating System: Linux (Debian for Sparc)
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
It was not badly meant, only trying to show you alternative.
I can't know nor judge the reason why you need v8 support, but have been
there many times in the past for my numerous projects.
We have to make decisions about which platforms we can support, and also
which we stop to support. There is nothing personal or aggressive in our
replies, only trying to explain the status and the reasoning behind it.
Sorry if you took it so badly, that's not the aim of our comments, or
mines in particular.
Previous Comments:
[2010-11-17 01:09:51] stefan at whocares dot de
@paj...@php.net
Did it ever occur to you that I found this bug/problem because I
*specifically
wanted to use FPM* in the first place? Had I wanted to use FastCGI I'd
have
certainly done so. Seeing that there already was a solution for Sparc v9
I
thought there might be interest in a solution that would allow PHP to
run on
older machines.
Hardware that maybe you're laughing about. But hardware that's still in
fairly
wide use. And, come to think of it, hardware that may also be the only
hardware
people in poorer countries than the one you're obviously living in are
able to
get their hands on. So I first asked and then got my hands dirty and
even
provided a possible solution - and one that could be easily implemented,
too.
And what for? Only to get ignorance and witty remarks in return. Well, I
almost
forgot that the PHP project has such a bad reputation when it comes to
bugs and
patches. Thanks for reminding me why. Now you can safely go back to your
ivory
tower and think about supporting next decade's hardware only. For my
part, I
promise to keep any bugs/problems in PHP I may find in the future to
myself and
will do the same for any patches I may come up with.
Btw: the boxes I'm talking about are running Linux (which you could have
seen by
looking at the "OS:" tag) and I really have no idea why you'd call that
a "soon
to be dead OS". If you have a problem understanding the difference
between a CPU
and an OS, may I ask what exactly makes you think you can give some
valuable
input here? As for the "cruelly needed developers" you mention: I don't
see why
you should need those as long as the community comes up with patches you
could
use. Ok, if you keep driving away people like this, I start to have an
idea as
to why ;)
[2010-11-17 00:24:30] stefan at whocares dot de
As you may have read in my initial post, the compiler I (have to) use is
gcc
3.3.5 which falls a bit short of 4.1 ;) Also, you may want to read the
backend/port/tas/solaris_sparc.s file from the official PostgreSQL
sources:
! "cas" only works on sparcv9 and sparcv8plus chips, and
! requies a compiler targeting these CPUs. It will fail
! on a compiler targeting sparcv8, and of course will not
! be understood by a sparcv8 CPU. gcc continues to use
! "ldstub" because it targets sparcv7.
There they work around this by using a condition (for the SUN compiler)
like
this:
#if defined(__sparcv9) || defined(__sparcv8plus)
cas [%o0],%o2,%o1
#else
ldstub [%o0],%o1
#endif
and in their actual generic lock implementation
(src/include/storage/s_lock.h)
the code is this:
#if defined(__sparc__) /* Sparc */
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
#define TAS(lock) tas(lock)
static __inline__ int
tas(volatile slock_t *lock)
{
register slock_t _res;
/*
* See comment in /pg/backend/port/tas/solaris_sparc.s for
why this
* uses "ldstub", and that file uses "cas". gcc currently
generates
* sparcv7-targeted binaries, so "cas" use isn't possible.
*/
__asm__ __volatile__(
" ldstub [%2], %0\n"
: "=r"(_res), "+m"(*lock)
: "r"(lock)
: "memory");
return (int) _res;
}
#endif /* __sparc__ */
Now my general idea was that if there's a reason for PostgreSQL to keep
that
code around, there might be a reason for PHP to do so as well. Obviously
I was
wrong there.
I also do not see the real advantage of 'cas' over 'ldstub' in the
current
scenario since both are atomic, both are supporte
Req #53310 [Wfx]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1
ID: 53310
Updated by: paj...@php.net
Reported by:stefan at whocares dot de
Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work
on v8
Status: Wont fix
Type: Feature/Change Request
Package:FPM related
Operating System: Linux (Debian for Sparc)
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
and I was wiling to write arch, not OS
Previous Comments:
[2010-11-17 01:15:26] paj...@php.net
It was not badly meant, only trying to show you alternative.
I can't know nor judge the reason why you need v8 support, but have been
there many times in the past for my numerous projects.
We have to make decisions about which platforms we can support, and also
which we stop to support. There is nothing personal or aggressive in our
replies, only trying to explain the status and the reasoning behind it.
Sorry if you took it so badly, that's not the aim of our comments, or
mines in particular.
[2010-11-17 01:09:51] stefan at whocares dot de
@paj...@php.net
Did it ever occur to you that I found this bug/problem because I
*specifically
wanted to use FPM* in the first place? Had I wanted to use FastCGI I'd
have
certainly done so. Seeing that there already was a solution for Sparc v9
I
thought there might be interest in a solution that would allow PHP to
run on
older machines.
Hardware that maybe you're laughing about. But hardware that's still in
fairly
wide use. And, come to think of it, hardware that may also be the only
hardware
people in poorer countries than the one you're obviously living in are
able to
get their hands on. So I first asked and then got my hands dirty and
even
provided a possible solution - and one that could be easily implemented,
too.
And what for? Only to get ignorance and witty remarks in return. Well, I
almost
forgot that the PHP project has such a bad reputation when it comes to
bugs and
patches. Thanks for reminding me why. Now you can safely go back to your
ivory
tower and think about supporting next decade's hardware only. For my
part, I
promise to keep any bugs/problems in PHP I may find in the future to
myself and
will do the same for any patches I may come up with.
Btw: the boxes I'm talking about are running Linux (which you could have
seen by
looking at the "OS:" tag) and I really have no idea why you'd call that
a "soon
to be dead OS". If you have a problem understanding the difference
between a CPU
and an OS, may I ask what exactly makes you think you can give some
valuable
input here? As for the "cruelly needed developers" you mention: I don't
see why
you should need those as long as the community comes up with patches you
could
use. Ok, if you keep driving away people like this, I start to have an
idea as
to why ;)
[2010-11-17 00:24:30] stefan at whocares dot de
As you may have read in my initial post, the compiler I (have to) use is
gcc
3.3.5 which falls a bit short of 4.1 ;) Also, you may want to read the
backend/port/tas/solaris_sparc.s file from the official PostgreSQL
sources:
! "cas" only works on sparcv9 and sparcv8plus chips, and
! requies a compiler targeting these CPUs. It will fail
! on a compiler targeting sparcv8, and of course will not
! be understood by a sparcv8 CPU. gcc continues to use
! "ldstub" because it targets sparcv7.
There they work around this by using a condition (for the SUN compiler)
like
this:
#if defined(__sparcv9) || defined(__sparcv8plus)
cas [%o0],%o2,%o1
#else
ldstub [%o0],%o1
#endif
and in their actual generic lock implementation
(src/include/storage/s_lock.h)
the code is this:
#if defined(__sparc__) /* Sparc */
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
#define TAS(lock) tas(lock)
static __inline__ int
tas(volatile slock_t *lock)
{
register slock_t _res;
/*
* See comment in /pg/backend/port/tas/solaris_sparc.s for
why this
* uses "ldstub", and that file uses "cas". gcc currently
generates
* sparcv7-targeted binaries, so "cas" use isn't possible.
*/
__asm__ __volatile__(
" ldstub [%2], %0\n"
: "=r"(_res), "+m"(*lock)
: "r"(lock)
: "memory");
return (int) _res;
}
#endif /* __sparc__ */
Now my general idea was that if there's a reason for PostgreSQL to keep
that
code around, there might be a reason for PHP to do so as well. Obvio
Req #53310 [Com]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1
ID: 53310
Comment by: f...@php.net
Reported by:stefan at whocares dot de
Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work
on v8
Status: Wont fix
Type: Feature/Change Request
Package:FPM related
Operating System: Linux (Debian for Sparc)
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
@stefan at whocares dot de
Did you run your patch on a ReadyNAS box ? If you test it and tell us it
works,
there is not reason not to integrate it. As far as I know, it's not been
tested
but for compilation only.
We don't want to leave someone behind, but as pierre told you there is
priorities.
We'll be glad if you help us.
Previous Comments:
[2010-11-17 01:16:15] paj...@php.net
and I was wiling to write arch, not OS
[2010-11-17 01:15:26] paj...@php.net
It was not badly meant, only trying to show you alternative.
I can't know nor judge the reason why you need v8 support, but have been
there many times in the past for my numerous projects.
We have to make decisions about which platforms we can support, and also
which we stop to support. There is nothing personal or aggressive in our
replies, only trying to explain the status and the reasoning behind it.
Sorry if you took it so badly, that's not the aim of our comments, or
mines in particular.
[2010-11-17 01:09:51] stefan at whocares dot de
@paj...@php.net
Did it ever occur to you that I found this bug/problem because I
*specifically
wanted to use FPM* in the first place? Had I wanted to use FastCGI I'd
have
certainly done so. Seeing that there already was a solution for Sparc v9
I
thought there might be interest in a solution that would allow PHP to
run on
older machines.
Hardware that maybe you're laughing about. But hardware that's still in
fairly
wide use. And, come to think of it, hardware that may also be the only
hardware
people in poorer countries than the one you're obviously living in are
able to
get their hands on. So I first asked and then got my hands dirty and
even
provided a possible solution - and one that could be easily implemented,
too.
And what for? Only to get ignorance and witty remarks in return. Well, I
almost
forgot that the PHP project has such a bad reputation when it comes to
bugs and
patches. Thanks for reminding me why. Now you can safely go back to your
ivory
tower and think about supporting next decade's hardware only. For my
part, I
promise to keep any bugs/problems in PHP I may find in the future to
myself and
will do the same for any patches I may come up with.
Btw: the boxes I'm talking about are running Linux (which you could have
seen by
looking at the "OS:" tag) and I really have no idea why you'd call that
a "soon
to be dead OS". If you have a problem understanding the difference
between a CPU
and an OS, may I ask what exactly makes you think you can give some
valuable
input here? As for the "cruelly needed developers" you mention: I don't
see why
you should need those as long as the community comes up with patches you
could
use. Ok, if you keep driving away people like this, I start to have an
idea as
to why ;)
[2010-11-17 00:24:30] stefan at whocares dot de
As you may have read in my initial post, the compiler I (have to) use is
gcc
3.3.5 which falls a bit short of 4.1 ;) Also, you may want to read the
backend/port/tas/solaris_sparc.s file from the official PostgreSQL
sources:
! "cas" only works on sparcv9 and sparcv8plus chips, and
! requies a compiler targeting these CPUs. It will fail
! on a compiler targeting sparcv8, and of course will not
! be understood by a sparcv8 CPU. gcc continues to use
! "ldstub" because it targets sparcv7.
There they work around this by using a condition (for the SUN compiler)
like
this:
#if defined(__sparcv9) || defined(__sparcv8plus)
cas [%o0],%o2,%o1
#else
ldstub [%o0],%o1
#endif
and in their actual generic lock implementation
(src/include/storage/s_lock.h)
the code is this:
#if defined(__sparc__) /* Sparc */
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
#define TAS(lock) tas(lock)
static __inline__ int
tas(volatile slock_t *lock)
{
register slock_t _res;
/*
* See comment in /pg/backend/port/tas/solaris_sparc.s for
why this
* uses "ldstub", and that file uses "cas". gcc currently
generates
* sparcv7-targ
[PHP-BUG] Bug #53327 [NEW]: Determine parameter names in ReflectionMethod::invokeArgs
From: Operating system: Windows 7, Ubuntu 10.10, Gentoo PHP version: Irrelevant Package: Reflection related Bug Type: Bug Bug description:Determine parameter names in ReflectionMethod::invokeArgs Description: I would like to use the names of parameters to execute methods with specific arguments. But invokeArgs not correctly sends the names with those on the method. I think this result is not correct. It should not obey the parameter names? Test script: --- http://pastebin.com/fuF4tWGq Expected result: arg1: orange arg2: apple arg3: -- and also report a warning because of missing arg3, i.e. Actual result: -- arg1: orange arg2: apple arg3: bad error -- Edit bug report at http://bugs.php.net/bug.php?id=53327&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53327&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53327&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53327&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53327&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53327&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53327&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53327&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53327&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53327&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53327&r=support Expected behavior: http://bugs.php.net/fix.php?id=53327&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53327&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53327&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53327&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53327&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53327&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53327&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53327&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53327&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53327&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53327&r=mysqlcfg
Req #53310 [Wfx]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1 ID: 53310 User updated by:stefan at whocares dot de Reported by:stefan at whocares dot de Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work on v8 Status: Wont fix Type: Feature/Change Request Package:FPM related Operating System: Linux (Debian for Sparc) PHP Version:5.3.3 Assigned To:fat Block user comment: N Private report: N New Comment: First of all: thanks for not taking my rant badly :) Of course I can run this code and, well "test" it. I would have been happier however if someone besides me had looked over the code and said "yes, that looks like it could work" ;) Right now it *is* running on two ReadyNAS (Sparc) boxes as well as on my SunFire 280R. It doesn't segfault which to me is a good sign and it's producing normale output from the small test scripts I have run. Haven't done extensive testing so far but will try running Wordpress and Drupal in the next couple of days. If there's any special test you'd like to see me run against the patched version of PHP, let me know. Previous Comments: [2010-11-17 01:18:49] f...@php.net @stefan at whocares dot de Did you run your patch on a ReadyNAS box ? If you test it and tell us it works, there is not reason not to integrate it. As far as I know, it's not been tested but for compilation only. We don't want to leave someone behind, but as pierre told you there is priorities. We'll be glad if you help us. [2010-11-17 01:16:15] paj...@php.net and I was wiling to write arch, not OS [2010-11-17 01:15:26] paj...@php.net It was not badly meant, only trying to show you alternative. I can't know nor judge the reason why you need v8 support, but have been there many times in the past for my numerous projects. We have to make decisions about which platforms we can support, and also which we stop to support. There is nothing personal or aggressive in our replies, only trying to explain the status and the reasoning behind it. Sorry if you took it so badly, that's not the aim of our comments, or mines in particular. [2010-11-17 01:09:51] stefan at whocares dot de @paj...@php.net Did it ever occur to you that I found this bug/problem because I *specifically wanted to use FPM* in the first place? Had I wanted to use FastCGI I'd have certainly done so. Seeing that there already was a solution for Sparc v9 I thought there might be interest in a solution that would allow PHP to run on older machines. Hardware that maybe you're laughing about. But hardware that's still in fairly wide use. And, come to think of it, hardware that may also be the only hardware people in poorer countries than the one you're obviously living in are able to get their hands on. So I first asked and then got my hands dirty and even provided a possible solution - and one that could be easily implemented, too. And what for? Only to get ignorance and witty remarks in return. Well, I almost forgot that the PHP project has such a bad reputation when it comes to bugs and patches. Thanks for reminding me why. Now you can safely go back to your ivory tower and think about supporting next decade's hardware only. For my part, I promise to keep any bugs/problems in PHP I may find in the future to myself and will do the same for any patches I may come up with. Btw: the boxes I'm talking about are running Linux (which you could have seen by looking at the "OS:" tag) and I really have no idea why you'd call that a "soon to be dead OS". If you have a problem understanding the difference between a CPU and an OS, may I ask what exactly makes you think you can give some valuable input here? As for the "cruelly needed developers" you mention: I don't see why you should need those as long as the community comes up with patches you could use. Ok, if you keep driving away people like this, I start to have an idea as to why ;) [2010-11-17 00:24:30] stefan at whocares dot de As you may have read in my initial post, the compiler I (have to) use is gcc 3.3.5 which falls a bit short of 4.1 ;) Also, you may want to read the backend/port/tas/solaris_sparc.s file from the official PostgreSQL sources: ! "cas" only works on sparcv9 and sparcv8plus chips, and ! requies a compiler targeting these CPUs. It will fail ! on a compiler targeting sparcv8, and of course will not ! be understood by a sparcv8 CPU. gcc continues to use
Bug #53311 [Com]: startup failed.
Edit report at http://bugs.php.net/bug.php?id=53311&edit=1 ID: 53311 Comment by: paulgao at yeah dot net Reported by:paulgao at yeah dot net Summary:startup failed. Status: Feedback Type: Bug Package:FPM related Operating System: Centos 64-bit 5.5 PHP Version:5.3SVN-2010-11-15 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: I change log level = debug, and daemonize = off: [r...@host-c11 logs]# /home/codebase/shell/php-fpm-api-test.sh start Starting php-fpm Nov 17 09:49:46.600069 [DEBUG] pid 24660, fpm_event_init_main(), line 93: libevent 1.4.14b-stable: using epoll Nov 17 09:49:46.600466 [NOTICE] pid 24660, fpm_init(), line 52: fpm is running, pid 24660 Nov 17 09:49:46.602313 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24661 started Nov 17 09:49:46.603101 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24662 started Nov 17 09:49:46.605003 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24664 started Nov 17 09:49:46.606135 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24665 started Nov 17 09:49:46.607143 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24666 started Nov 17 09:49:46.608088 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24667 started Nov 17 09:49:46.609757 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24669 started Nov 17 09:49:46.610090 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24670 started Nov 17 09:49:46.611090 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24671 started Nov 17 09:49:46.612089 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24673 started Nov 17 09:49:46.613112 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24674 started Nov 17 09:49:46.614087 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24676 started Nov 17 09:49:46.615136 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24677 started Nov 17 09:49:46.616087 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24679 started Nov 17 09:49:46.617097 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24680 started Nov 17 09:49:46.618087 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24682 started Nov 17 09:49:46.618121 [NOTICE] pid 24660, fpm_event_loop(), line 111: ready to handle connections Nov 17 09:49:46.618155 [DEBUG] pid 24660, fpm_got_signal(), line 48: received SIGCHLD Nov 17 09:49:46.618203 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24661 exited with code 1 after 0.015918 seconds from start Nov 17 09:49:46.619091 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24683 started Nov 17 09:49:46.619126 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24662 exited with code 1 after 0.016037 seconds from start Nov 17 09:49:46.620113 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24685 started Nov 17 09:49:46.620147 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24664 exited with code 1 after 0.015152 seconds from start Nov 17 09:49:46.621129 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24686 started Nov 17 09:49:46.621170 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24665 exited with code 1 after 0.015041 seconds from start Nov 17 09:49:46.622087 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24688 started Nov 17 09:49:46.622120 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24666 exited with code 1 after 0.014983 seconds from start Nov 17 09:49:46.623089 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24689 started Nov 17 09:49:46.623121 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24667 exited with code 1 after 0.015042 seconds from start Nov 17 09:49:46.624087 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24691 started Nov 17 09:49:46.624123 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24669 exited with code 1 after 0.014373 seconds from start Nov 17 09:49:46.625096 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24692 started non-stop output... :-( Previous Comments: [2010-11-16 22:26:37] f...@php.net with which user do you run FPM ? Try to set daemonize = off in php-fpm.conf and run it again. [2010-11-16 09:23:02] paulgao at yeah dot net I use patch V2. if old fpm.log not remove, startup still failed. but old fpm.log removed, startup is OK. restart is OK too. what
Bug #53319 [Tbd]: strip_tags() may strip '' incorrectly
Edit report at http://bugs.php.net/bug.php?id=53319&edit=1 ID: 53319 User updated by:Ray dot Paseur at Gmail dot com Reported by:Ray dot Paseur at Gmail dot com Summary:strip_tags() may strip '' incorrectly Status: To be documented Type: Bug Package:Strings related Operating System: Linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Thanks, Felipe! Previous Comments: [2010-11-16 23:21:15] fel...@php.net I've fixed the bug related to '' is stripping in the string. About strip_tags($str, ''): The allowed tags should not contains slash char. This must be documented though. [2010-11-16 23:16:46] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=305418 Log: - Fixed bug #53319 (strip_tags() may strip '
' incorrectly) [2010-11-16 01:22:26] Ray dot Paseur at Gmail dot com Description: --- >From manual page: http://www.php.net/function.strip-tags#Return Values --- Test script: --- USDCDN'; $new = strip_tags($str); echo $new; // Prints USDCDN // TRY TO PRESERVE ALLOWABLE TAGS $new = strip_tags($str, ''); echo $new; // Prints USDCDN -- The break tag is not preserved $new = strip_tags($str, ''); echo $new; // Prints USDCDN // SELF-CLOSING TAGS WITHOUT SPACES $str = 'USDCDN'; $new = strip_tags($str, ''); echo $new; // Prints USDCDN Expected result: strip_tags() should preserve the allowable_tags Actual result: -- strip_tags did not always preserve the allowable_tags -- Edit this bug report at http://bugs.php.net/bug.php?id=53319&edit=1
[PHP-BUG] Bug #53328 [NEW]: stream_flush error does not cause copy to return false
From: Operating system: Linux PHP version: 5.2.14 Package: Streams related Bug Type: Bug Bug description:stream_flush error does not cause copy to return false Description: In a custom stream wrapper if stream_flush() returns false as the documentation says it may, parent copy operations do not return false. Test script: --- http://labs.silverorange.com/files/php-stream-wrapper/test.phps http://labs.silverorange.com/files/php-stream-wrapper/test.txt Expected result: copy should return false. Actual result: -- copy returns true. -- Edit bug report at http://bugs.php.net/bug.php?id=53328&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53328&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53328&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53328&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53328&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53328&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53328&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53328&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53328&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53328&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53328&r=support Expected behavior: http://bugs.php.net/fix.php?id=53328&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53328&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53328&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53328&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53328&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53328&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53328&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53328&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53328&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53328&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53328&r=mysqlcfg
Req #53310 [Com]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1 ID: 53310 Comment by: f...@php.net Reported by:stefan at whocares dot de Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work on v8 Status: Wont fix Type: Feature/Change Request Package:FPM related Operating System: Linux (Debian for Sparc) PHP Version:5.3.3 Assigned To:fat Block user comment: N Private report: N New Comment: one simple test is to make php core the less as possible. You can create a file test.php wich does nothing but an "echo". Then you stress this page with FPM with ab (ab -c 100 -n 1 http://ip:port/test.php While the test is running you check the status page and see how it's goin' on. it should be a good primary test. Previous Comments: [2010-11-17 02:19:15] stefan at whocares dot de First of all: thanks for not taking my rant badly :) Of course I can run this code and, well "test" it. I would have been happier however if someone besides me had looked over the code and said "yes, that looks like it could work" ;) Right now it *is* running on two ReadyNAS (Sparc) boxes as well as on my SunFire 280R. It doesn't segfault which to me is a good sign and it's producing normale output from the small test scripts I have run. Haven't done extensive testing so far but will try running Wordpress and Drupal in the next couple of days. If there's any special test you'd like to see me run against the patched version of PHP, let me know. [2010-11-17 01:18:49] f...@php.net @stefan at whocares dot de Did you run your patch on a ReadyNAS box ? If you test it and tell us it works, there is not reason not to integrate it. As far as I know, it's not been tested but for compilation only. We don't want to leave someone behind, but as pierre told you there is priorities. We'll be glad if you help us. [2010-11-17 01:16:15] paj...@php.net and I was wiling to write arch, not OS [2010-11-17 01:15:26] paj...@php.net It was not badly meant, only trying to show you alternative. I can't know nor judge the reason why you need v8 support, but have been there many times in the past for my numerous projects. We have to make decisions about which platforms we can support, and also which we stop to support. There is nothing personal or aggressive in our replies, only trying to explain the status and the reasoning behind it. Sorry if you took it so badly, that's not the aim of our comments, or mines in particular. [2010-11-17 01:09:51] stefan at whocares dot de @paj...@php.net Did it ever occur to you that I found this bug/problem because I *specifically wanted to use FPM* in the first place? Had I wanted to use FastCGI I'd have certainly done so. Seeing that there already was a solution for Sparc v9 I thought there might be interest in a solution that would allow PHP to run on older machines. Hardware that maybe you're laughing about. But hardware that's still in fairly wide use. And, come to think of it, hardware that may also be the only hardware people in poorer countries than the one you're obviously living in are able to get their hands on. So I first asked and then got my hands dirty and even provided a possible solution - and one that could be easily implemented, too. And what for? Only to get ignorance and witty remarks in return. Well, I almost forgot that the PHP project has such a bad reputation when it comes to bugs and patches. Thanks for reminding me why. Now you can safely go back to your ivory tower and think about supporting next decade's hardware only. For my part, I promise to keep any bugs/problems in PHP I may find in the future to myself and will do the same for any patches I may come up with. Btw: the boxes I'm talking about are running Linux (which you could have seen by looking at the "OS:" tag) and I really have no idea why you'd call that a "soon to be dead OS". If you have a problem understanding the difference between a CPU and an OS, may I ask what exactly makes you think you can give some valuable input here? As for the "cruelly needed developers" you mention: I don't see why you should need those as long as the community comes up with patches you could use. Ok, if you keep driving away people like this, I start to have an idea as to why ;) The remainder of the comments for this report are too long. To view the rest of the comments, pleas
Bug #53311 [Com]: startup failed.
Edit report at http://bugs.php.net/bug.php?id=53311&edit=1 ID: 53311 Comment by: f...@php.net Reported by:paulgao at yeah dot net Summary:startup failed. Status: Feedback Type: Bug Package:FPM related Operating System: Centos 64-bit 5.5 PHP Version:5.3SVN-2010-11-15 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: with which user do you launch FPM ? Previous Comments: [2010-11-17 02:52:24] paulgao at yeah dot net I change log level = debug, and daemonize = off: [r...@host-c11 logs]# /home/codebase/shell/php-fpm-api-test.sh start Starting php-fpm Nov 17 09:49:46.600069 [DEBUG] pid 24660, fpm_event_init_main(), line 93: libevent 1.4.14b-stable: using epoll Nov 17 09:49:46.600466 [NOTICE] pid 24660, fpm_init(), line 52: fpm is running, pid 24660 Nov 17 09:49:46.602313 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24661 started Nov 17 09:49:46.603101 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24662 started Nov 17 09:49:46.605003 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24664 started Nov 17 09:49:46.606135 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24665 started Nov 17 09:49:46.607143 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24666 started Nov 17 09:49:46.608088 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24667 started Nov 17 09:49:46.609757 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24669 started Nov 17 09:49:46.610090 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24670 started Nov 17 09:49:46.611090 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24671 started Nov 17 09:49:46.612089 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24673 started Nov 17 09:49:46.613112 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24674 started Nov 17 09:49:46.614087 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24676 started Nov 17 09:49:46.615136 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24677 started Nov 17 09:49:46.616087 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24679 started Nov 17 09:49:46.617097 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24680 started Nov 17 09:49:46.618087 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24682 started Nov 17 09:49:46.618121 [NOTICE] pid 24660, fpm_event_loop(), line 111: ready to handle connections Nov 17 09:49:46.618155 [DEBUG] pid 24660, fpm_got_signal(), line 48: received SIGCHLD Nov 17 09:49:46.618203 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24661 exited with code 1 after 0.015918 seconds from start Nov 17 09:49:46.619091 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24683 started Nov 17 09:49:46.619126 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24662 exited with code 1 after 0.016037 seconds from start Nov 17 09:49:46.620113 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24685 started Nov 17 09:49:46.620147 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24664 exited with code 1 after 0.015152 seconds from start Nov 17 09:49:46.621129 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24686 started Nov 17 09:49:46.621170 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24665 exited with code 1 after 0.015041 seconds from start Nov 17 09:49:46.622087 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24688 started Nov 17 09:49:46.622120 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24666 exited with code 1 after 0.014983 seconds from start Nov 17 09:49:46.623089 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24689 started Nov 17 09:49:46.623121 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24667 exited with code 1 after 0.015042 seconds from start Nov 17 09:49:46.624087 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24691 started Nov 17 09:49:46.624123 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24669 exited with code 1 after 0.014373 seconds from start Nov 17 09:49:46.625096 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24692 started non-stop output... :-( [2010-11-16 22:26:37] f...@php.net with which user do you run FPM ? Try to set daemonize = off in php-fpm.conf and run it again. [2010-11-16 09:23:02] paulgao at yeah
