Bug #60627 [PATCH]: httpd.worker segfault on startup
Edit report at https://bugs.php.net/bug.php?id=60627&edit=1 ID: 60627 Patch added by: larue...@php.net Reported by:fedora at famillecollet dot com Summary:httpd.worker segfault on startup Status: Analyzed Type: Bug Package:Apache2 related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2011-12-30 (snap) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug60627.patch Revision: 1325663174 URL: https://bugs.php.net/patch-display.php?bug=60627&patch=bug60627.patch&revision=1325663174 Previous Comments: [2012-01-04 07:32:22] larue...@php.net hmm, the problem is when the real_value_hnd is called, the signal_startup has not been called yet... [2012-01-01 19:22:16] public at wernig dot net Just tried with 5.3.9RC4, and the problem does not occur. Seems to be something in 5.4 [2012-01-01 19:05:57] public at wernig dot net I have the same problem on Solaris 11 (express) i86pc. I'm not sure about ZTS mode (I have NOT set --enable-maintainer-zts) I have compiled php-5.4 (various versions, the latest one being 5.4.0RC4) with the following configure flags: --with-apxs2=/usr/local/apache2/bin/apxs --with-openssl=/usr/local/ssl --with-openssl-dir=/usr/local/ssl --with-zlib --enable-sockets --enable-shared=yes --enable-static=yes --prefix=/usr/local/apache2/php --enable-calendar --disable-ftp --with-mysql=/usr/local/mysql --with-imap=/usr/local/imap --with-imap-ssl=/usr/local/ssl --enable-flatfile --without-recode --disable-ipv6 --with-mysql-sock=/var/run/mysql/mysql.sock --with-gettext=/opt/csw --enable-libxml --with-db4=/usr/local/BerkeleyDB Builds and installs fine. But during apache (2.2.21) startup, it segfaults and dumps core: # /usr/local/svc/init.d/apache2 restart Restarting Apache2 httpd ... /usr/local/apache2/bin/apachectl: line 80: 17568: Memory fault(coredump) In fact, uncommenting all php_admin_value lines from apache config file, apache starts normally. When compiling and installing 5.3.6 with the same configure options, the problem does not occur. [2011-12-31 07:21:41] fedora at famillecollet dot com segfault occurs during apache config analyse. If config doesnt have any php_flag, php_value,... apache starts and works as expected. [2011-12-30 19:10:16] fedora at famillecollet dot com Description: With PHP build in ZTS mode, apache in worker mode segfault during launch Test script: --- $ gdb /usr/sbin/httpd.worker (gdb) run -X Expected result: no error Actual result: -- (gdb) run -X ... Program received signal SIGSEGV, Segmentation fault. 0x7fffec8ca897 in _zend_hash_add_or_update (ht=0x5585a2e8, arKey=, nKeyLength=17, pData=0x7fffde70, nDataSize=24, pDest=0x0, flag=1) at /usr/src/debug/php5.4-201112300630/Zend/zend_hash.c:268 268 HANDLE_BLOCK_INTERRUPTIONS(); (gdb) bt #0 0x7fffec8ca897 in _zend_hash_add_or_update (ht=0x5585a2e8, arKey=, nKeyLength=17, pData=0x7fffde70, nDataSize=24, pDest=0x0, flag=1) at /usr/src/debug/php5.4-201112300630/Zend/zend_hash.c:268 #1 0x7fffec979217 in real_value_hnd (cmd=0x7fffe1a0, dummy=0x5585a2e8, name=0x558c40b8 "register_globals", value=0x7fffded0 "0", status=4) at /usr/src/debug/php5.4-201112300630/sapi/apache2handler/apache_config.c:73 #2 0x7fffec9792ae in real_flag_hnd (cmd=0x7fffe1a0, dummy=0x5585a2e8, arg1=0x558c40b8 "register_globals", arg2=0x558c40d0 "off", status=) at /usr/src/debug/php5.4-201112300630/sapi/apache2handler/apache_config.c:98 #3 0x55580483 in invoke_cmd (cmd=0x7fffecc918f8, parms=0x7fffe1a0, mconfig=0x5585a2e8, args=0x5582f224 "") at /usr/src/debug/httpd-2.2.21/server/config.c:810 #4 0x555826fa in ap_walk_config_sub (section_vector=0x557dc798, parms=0x7fffe1a0, current=0x5582f1d0) at /usr/src/debug/httpd-2.2.21/server/config.c:1163 #5 ap_walk_config (current=0x5582f1d0, parms=0x7fffe1a0, section_vector=0x557dc798) at /usr/src/debug/httpd-2.2.21/server/config.c:1196 #6 0x55583612 in ap_process_config_tree (s=, conftree=, p=0x557b7158, ptemp=) at /usr/src/debug/httpd-2.2.21/server/config.c:1765 #7 0x5556c314 in main (argc=2, argv=0x7fffe418) at /usr/src/debug/httpd-2.2.21/server/main.c:644 -- Edit this
Bug #60627 [Opn->Ana]: httpd.worker segfault on startup
Edit report at https://bugs.php.net/bug.php?id=60627&edit=1 ID: 60627 Updated by: larue...@php.net Reported by:fedora at famillecollet dot com Summary:httpd.worker segfault on startup -Status: Open +Status: Analyzed Type: Bug Package:Apache2 related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2011-12-30 (snap) Block user comment: N Private report: N New Comment: hmm, the problem is when the real_value_hnd is called, the signal_startup has not been called yet... Previous Comments: [2012-01-01 19:22:16] public at wernig dot net Just tried with 5.3.9RC4, and the problem does not occur. Seems to be something in 5.4 [2012-01-01 19:05:57] public at wernig dot net I have the same problem on Solaris 11 (express) i86pc. I'm not sure about ZTS mode (I have NOT set --enable-maintainer-zts) I have compiled php-5.4 (various versions, the latest one being 5.4.0RC4) with the following configure flags: --with-apxs2=/usr/local/apache2/bin/apxs --with-openssl=/usr/local/ssl --with-openssl-dir=/usr/local/ssl --with-zlib --enable-sockets --enable-shared=yes --enable-static=yes --prefix=/usr/local/apache2/php --enable-calendar --disable-ftp --with-mysql=/usr/local/mysql --with-imap=/usr/local/imap --with-imap-ssl=/usr/local/ssl --enable-flatfile --without-recode --disable-ipv6 --with-mysql-sock=/var/run/mysql/mysql.sock --with-gettext=/opt/csw --enable-libxml --with-db4=/usr/local/BerkeleyDB Builds and installs fine. But during apache (2.2.21) startup, it segfaults and dumps core: # /usr/local/svc/init.d/apache2 restart Restarting Apache2 httpd ... /usr/local/apache2/bin/apachectl: line 80: 17568: Memory fault(coredump) In fact, uncommenting all php_admin_value lines from apache config file, apache starts normally. When compiling and installing 5.3.6 with the same configure options, the problem does not occur. [2011-12-31 07:21:41] fedora at famillecollet dot com segfault occurs during apache config analyse. If config doesnt have any php_flag, php_value,... apache starts and works as expected. [2011-12-30 19:10:16] fedora at famillecollet dot com Description: With PHP build in ZTS mode, apache in worker mode segfault during launch Test script: --- $ gdb /usr/sbin/httpd.worker (gdb) run -X Expected result: no error Actual result: -- (gdb) run -X ... Program received signal SIGSEGV, Segmentation fault. 0x7fffec8ca897 in _zend_hash_add_or_update (ht=0x5585a2e8, arKey=, nKeyLength=17, pData=0x7fffde70, nDataSize=24, pDest=0x0, flag=1) at /usr/src/debug/php5.4-201112300630/Zend/zend_hash.c:268 268 HANDLE_BLOCK_INTERRUPTIONS(); (gdb) bt #0 0x7fffec8ca897 in _zend_hash_add_or_update (ht=0x5585a2e8, arKey=, nKeyLength=17, pData=0x7fffde70, nDataSize=24, pDest=0x0, flag=1) at /usr/src/debug/php5.4-201112300630/Zend/zend_hash.c:268 #1 0x7fffec979217 in real_value_hnd (cmd=0x7fffe1a0, dummy=0x5585a2e8, name=0x558c40b8 "register_globals", value=0x7fffded0 "0", status=4) at /usr/src/debug/php5.4-201112300630/sapi/apache2handler/apache_config.c:73 #2 0x7fffec9792ae in real_flag_hnd (cmd=0x7fffe1a0, dummy=0x5585a2e8, arg1=0x558c40b8 "register_globals", arg2=0x558c40d0 "off", status=) at /usr/src/debug/php5.4-201112300630/sapi/apache2handler/apache_config.c:98 #3 0x55580483 in invoke_cmd (cmd=0x7fffecc918f8, parms=0x7fffe1a0, mconfig=0x5585a2e8, args=0x5582f224 "") at /usr/src/debug/httpd-2.2.21/server/config.c:810 #4 0x555826fa in ap_walk_config_sub (section_vector=0x557dc798, parms=0x7fffe1a0, current=0x5582f1d0) at /usr/src/debug/httpd-2.2.21/server/config.c:1163 #5 ap_walk_config (current=0x5582f1d0, parms=0x7fffe1a0, section_vector=0x557dc798) at /usr/src/debug/httpd-2.2.21/server/config.c:1196 #6 0x55583612 in ap_process_config_tree (s=, conftree=, p=0x557b7158, ptemp=) at /usr/src/debug/httpd-2.2.21/server/config.c:1765 #7 0x5556c314 in main (argc=2, argv=0x7fffe418) at /usr/src/debug/httpd-2.2.21/server/main.c:644 -- Edit this bug report at https://bugs.php.net/bug.php?id=60627&edit=1
Bug #60457 [Com]: gc_zval_possible_root SIGSEGV
Edit report at https://bugs.php.net/bug.php?id=60457&edit=1
ID: 60457
Comment by: no at snaxor dot com
Reported by:Sjon at hortensius dot net
Summary:gc_zval_possible_root SIGSEGV
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
I may be bumping into this one as well, Similarly, I cannot provide a script to
reproduce it since it happens in a project with many classes, but I'll see if I
can narrow it down and create one.
It is very inconsistent. It will die one the same page but with different data
it will be fine. What seems to be sparking it in my case is Smarty, with lots
of
sub-template files. The content is rendered correctly, but during Smarty's
cleanup is when it dies.
It is trigger-able via php command line or apache module.
gc_disable() doesn't unfortunately have any effect.
PHP Version: 5.3.8 on OSX.
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x003dca9fd2f1
0x000100359618 in gc_zval_possible_root ()
(gdb) bt
#0 0x000100359618 in gc_zval_possible_root ()
#1 0x00010034a765 in zend_hash_destroy ()
#2 0x00010035c86c in zend_object_std_dtor ()
#3 0x00010035c4f8 in zend_objects_free_object_storage ()
#4 0x00010035faae in zend_objects_store_del_ref_by_handle_ex ()
#5 0x00010035fb64 in zend_objects_store_del_ref ()
#6 0x000100334e2d in _zval_ptr_dtor ()
#7 0x00010034a765 in zend_hash_destroy ()
#8 0x00010033f1b0 in _zval_dtor_func ()
#9 0x000100334e2d in _zval_ptr_dtor ()
#10 0x00010034a765 in zend_hash_destroy ()
#11 0x00010035c86c in zend_object_std_dtor ()
#12 0x00010035c4f8 in zend_objects_free_object_storage ()
#13 0x00010035f6eb in zend_objects_store_free_object_storage ()
#14 0x000100337750 in shutdown_executor ()
#15 0x00010033feae in zend_deactivate ()
#16 0x0001002f08b1 in php_request_shutdown ()
#17 0x0001003ba366 in main ()
#18 0x000110ec in start ()
Previous Comments:
[2011-12-12 15:58:33] Sjon at hortensius dot net
I am afraid not, gc_disable() doesn't solve this segfault unfortunately
[2011-12-11 19:41:22] arekm at maven dot pl
Isn't this something similar to last comments of #40479 (there is
reproduction script there).
[2011-12-07 14:05:33] Sjon at hortensius dot net
Description:
Our application segfaults after completely finishing the request.
Unfortunately I cannot provide a script to reproduce this as it occurs in an
application consisting of many classes. I have been poking at this with gdb for
a
while, but can't find the cause for this problem.
How can I supply you with the information you need to resolve this? We can
'fix'
the problem by die()-ing in the __destruct of the class that seems to cause this
Actual result:
--
#0 0x005bf0e9 in gc_zval_possible_root (zv=0x1985580) at
/usr/src/debug/php-5.3.8/Zend/zend_gc.c:143
#1 0x005aeb28 in zend_hash_destroy (ht=0x1363998) at
/usr/src/debug/php-5.3.8/Zend/zend_hash.c:529
#2 0x005c0609 in zend_object_std_dtor (object=0x1363970) at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:45
#3 0x005c0629 in zend_objects_free_object_storage (object=0x1985580)
at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:126
#4 0x005c46d6 in zend_objects_store_free_object_storage
(objects=0x91bef8) at /usr/src/debug/php-5.3.8/Zend/zend_objects_API.c:92
#5 0x00595757 in shutdown_executor () at /usr/src/debug/php-
5.3.8/Zend/zend_execute_API.c:304
#6 0x005a1fc2 in zend_deactivate () at /usr/src/debug/php-
5.3.8/Zend/zend.c:891
#7 0x0054f2ce in php_request_shutdown (dummy=) at
/usr/src/debug/php-5.3.8/main/main.c:1640
#8 0x0062b10f in main (argc=3, argv=0x7fffea88) at
/usr/src/debug/php-5.3.8/sapi/cli/php_cli.c:1363
(gdb) frame 2
#2 0x005c0609 in zend_object_std_dtor (object=0x1363970) at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:45
45 zend_hash_destroy(object->properties);
(gdb) print *object->ce
$1 = {type = 2 '\002', name = 0xcdce30 "React_Introspection_Controller",
name_length = 30, parent = 0xcb3e78, refcount = 1, constants_updated = 1
'\001',
ce_flags = 0, function_table = {nTableSize = 32,
nTableMask = 31, nNumOfElements = 27, nNextFreeElement = 0,
pInternalPointer
= 0xcde7b0, pListHead = 0xcde7b0, pListTail = 0xce9d10, arBuckets = 0xce8fa8,
pDestructor = 0x599450 ,
persistent = 0 '\000', nApplyCount = 0 '\000', bApplyProtection = 0
'\000'},
default_properties = {nTableSize = 8, nTabl
Bug #60613 [Csd]: Segmentation fault with $cls->{expr}() syntax
Edit report at https://bugs.php.net/bug.php?id=60613&edit=1
ID: 60613
User updated by:do dot hiroaki at gmail dot com
Reported by:do dot hiroaki at gmail dot com
Summary:Segmentation fault with $cls->{expr}() syntax
Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: CentOS5.6
PHP Version:5.4SVN-2011-12-28 (snap)
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
I confirmed fix. thank you.
Previous Comments:
[2011-12-28 09:59:14] dmi...@php.net
Automatic comment from SVN on behalf of dmitry
Revision: http://svn.php.net/viewvc/?view=revision&revision=321463
Log: Fixed bug #60613 (Segmentation fault with $cls->{expr}() syntax)
[2011-12-28 06:46:59] larue...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
hmm, I will trigger a E_COMPILER_ERROR while in this situation, since it
doesn't
make sense for a no-string method name.
Dmitry, you maybe want to review this fix. thanks :)
[2011-12-28 06:45:47] larue...@php.net
Automatic comment from SVN on behalf of laruence
Revision: http://svn.php.net/viewvc/?view=revision&revision=321458
Log: Fix #60613 (Segmentation fault with $cls->{expr}() syntax)
#now the behavior is like 5.3, a COMPILER_ERROR will be triggered
[2011-12-28 06:14:39] larue...@php.net
dmitry, I have a quick look at this, since due to cache mechanism, I have not
gat familiar with this area.
it is better if you can have a look at this. I will keep troubleshooting anyway
:).
backtrace:
#0 0x00998aa5 in ZEND_INIT_METHOD_CALL_SPEC_CV_CONST_HANDLER
(execute_data=0x2a95dac0e8) at /home/huixc/opensource/php-
src/trunk/Zend/zend_vm_execute.h:28982
28982 if (IS_CONST != IS_CONST ||
(gdb) bt
#0 0x00998aa5 in ZEND_INIT_METHOD_CALL_SPEC_CV_CONST_HANDLER
(execute_data=0x2a95dac0e8) at /home/huixc/opensource/php-
src/trunk/Zend/zend_vm_execute.h:28982
#1 0x008dbc57 in execute (op_array=0x2a95de3708) at
/home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:410
#2 0x008a3f0b in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/huixc/opensource/php-src/trunk/Zend/zend.c:1272
#3 0x008235c3 in php_execute_script (primary_file=0x7fb280) at
/home/huixc/opensource/php-src/trunk/main/main.c:2476
#4 0x009c5981 in do_cli (argc=2, argv=0x7fb568) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:983
#5 0x009c6822 in main (argc=2, argv=0x7fb568) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:1356
[2011-12-28 04:22:48] do dot hiroaki at gmail dot com
Description:
I reported Bug #60611 and this bug was fixed.
Bat segmentation fault occurred yet when using $cls->{expr}() syntax only.
Test script:
---
class Cls {
function __call($name, $arg) {
}
}
$cls = new Cls();
$cls->{0}();
$cls->{1.0}();
$cls->{true}();
$cls->{false}();
$cls->{null}();
echo 'done';
Expected result:
done
Actual result:
--
Segmentation fault
--
Edit this bug report at https://bugs.php.net/bug.php?id=60613&edit=1
Bug #60636 [Opn]: Dots in folders results in a open_basedir restriction warning
Edit report at https://bugs.php.net/bug.php?id=60636&edit=1 ID: 60636 Updated by: larue...@php.net Reported by:fernando at consultorpc dot com Summary:Dots in folders results in a open_basedir restriction warning Status: Open Type: Bug Package:Safe Mode/open_basedir Operating System: Linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: hmm, I can't no reproduce this if you are sure that "/home/example" exists. Previous Comments: [2012-01-03 17:13:40] fernando at consultorpc dot com Yes, /home/example exists. If i rename myfolder.example to myfolderexample ( no dots ), them it works as expected. Meaning that it will return false without any warnings. [2012-01-03 17:06:24] larue...@php.net does that /home/example exists? I think this might has nothing to do with the *dot*, but a mis-understand warning. [2012-01-02 13:56:27] fernando at consultorpc dot com Description: If you try to access a file within a folder that has a dot, an open_basedir restriction warning will show up even if the folder is in the allowed paths list. Test script: --- function.file- exists]: open_basedir restriction in effect. File(/home/example/public_html/myfolder.example/file.php) is not within the allowed path(s): (/home/example:/usr/lib/php:/tmp) in /home/example/public_html/test.php on line 3 -- Edit this bug report at https://bugs.php.net/bug.php?id=60636&edit=1
Bug #60640 [Asn->]: Invalid return values
Edit report at https://bugs.php.net/bug.php?id=60640&edit=1 ID: 60640 Updated by: ar...@php.net Reported by:drak at zikula dot org Summary:Invalid return values -Status: Assigned +Status: To be documented Type: Bug Package:Session related PHP Version:5.4.0RC4 Assigned To:arpad 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. Previous Comments: [2012-01-04 01:31:04] ar...@php.net Automatic comment from SVN on behalf of arpad Revision: http://svn.php.net/viewvc/?view=revision&revision=321741 Log: fix return values of inherited session handler to match user handlers - #60640 [2012-01-03 10:01:57] drak at zikula dot org Description: According to the documentation at http://www.php.net/manual/en/class.sessionhandler.php the various methods return 0 for success and 1 for failure which is kind of backwards since 0 would normally be evaluated as false and 1 as true. This is in direct contradiction with the current expected behaviour of session_set_save_handler() http://www.php.net/manual/en/function.session-set-save-handler.php which expects true or false return values except for the read handler which should always return a string. What's the deal here? I think the return values really should be true and false for this class, as expected by session_set_save_handler() Expected result: I would expect the methods of SessionHandler class to return back true or false for all methods except read() which should return a string, as expected by the session_set_save_handler() -- Edit this bug report at https://bugs.php.net/bug.php?id=60640&edit=1
Req #60551 [Dup->]: session_set_save_handler should support a core's session handler interface
Edit report at https://bugs.php.net/bug.php?id=60551&edit=1 ID: 60551 Updated by: ar...@php.net Reported by:wiltave at gmail dot com Summary:session_set_save_handler should support a core's session handler interface -Status: Duplicate +Status: To be documented Type: Feature/Change Request Package:Session related Operating System: Any PHP Version:Irrelevant 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. session_set_save_handler() now takes a SessionHandlerInterface, which SessionHandler implements. Previous Comments: [2012-01-04 01:16:18] ar...@php.net Automatic comment from SVN on behalf of arpad Revision: http://svn.php.net/viewvc/?view=revision&revision=321738 Log: add SessionHandlerInterface for session_set_save_handler() - #60551 [2011-12-17 18:15:13] cataphr...@php.net Already implemented in PHP 5.4. [2011-12-17 12:16:43] wiltave at gmail dot com Description: session_set_save_handler expects callbacks to session handler's operations (open, close, etc). It would be great if this function accepts a core's session handler interface. Something like: https://bugs.php.net/bug.php?id=60551&edit=1
Req #14285 [Com]: Forcing variable declaration
Edit report at https://bugs.php.net/bug.php?id=14285&edit=1
ID: 14285
Comment by: matt at mattandwell dot net
Reported by:pnh102 at psu dot edu
Summary:Forcing variable declaration
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *
PHP Version:*
Block user comment: N
Private report: N
New Comment:
This would be a great option to add in error_reporting, consider the following
script.
ini_set("error_reporting", E_ALL|E_STRICT);
class test1
{
private $m1 = "initial value in t1";
public function setVarsTest()
{
$this->m1 = "in t1";
}
public function showValues()
{
echo(")".$this->m1."(");
}
}
class test2 extends test1
{
public function setVarsTest()
{
$this->m1 = "in t2";
}
}
$t1 = new test1();
$t1->setVarsTest();
$t1->showValues();
$t2 = new test2();
$t2->setVarsTest();
$t2->showValues();
the output is:
)in t1(
)initial value in t1(
changing $m1 to protected solves the issue, but tracking down issues like this
after a refactoring session could be easier if PHP had this feature.
"$t2->setVarsTest();" would generate a notice in the above code.
Previous Comments:
[2008-06-13 11:27:34] gvdefence-ncr at yahoo dot it
This feature is necessary in PHP.
Try this simple example:
error_reporting(E_ALL | E_NOTICE | E_STRICT); //E_STRICT for PHP5
class Test
{
var $mispelled_var;
function Test($test)
{
$this->$mispeled_var = $test;
/*
ERROR: we think to instantiate $this->mispelled_var, but
we forgot an 'l' and we are instantiating a new var.
PHP does not raise any error or warning or notice.
*/
}
};
All other languages would raise an error or at least a warning.
I love PHP and I want it to grow, this is a neccesary feature.
It is necessary to add a sort of gobal option that when activated makes PHP
sensible to these type of errors.
[2004-07-22 09:49:24] jeffrparsons at optushome dot com dot au
I agree this is a very major issue, and it scares people I know away from using
PHP. It would be extremely convenient to have warnings on assignment as well -
instead of just upon reading a non-existent variable - and instead of creating
a variable when a value is first assigned to it, require a separate declaration
using a "var" keyword or such. Obviously not as standard, but as an option...
[2003-08-13 14:35:52] lsemel at yahoo dot com
This is an important issue. E_ALL doesn't catch everything. It makes PHP
harder to program compared to other languages where you can declare variables
(Perl, Java, etc.)
[2003-07-16 15:36:44] andrew_nefsky at hotmail dot com
This is definitely an important issue. Not being able to declare variables
creates a debugging nightmare!
[2002-11-19 08:06:07] z95kahe at mtek dot chalmers dot se
I realy think this is good idea. I've been looking for some tool to do this
kind of checks and found none.
For small scripts there is no need to have variable declaring but there are for
longer multi file, multi developer projects. By making the checks an option we
can have both modes available.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=14285
--
Edit this bug report at https://bugs.php.net/bug.php?id=14285&edit=1
Bug #45282 [Com]: SoapClient has namespace issues when WSDL is distributed
Edit report at https://bugs.php.net/bug.php?id=45282&edit=1
ID: 45282
Comment by: pumuckel at metropolis dot de
Reported by:Martin dot Bosslet at googlemail dot com
Summary:SoapClient has namespace issues when WSDL is
distributed
Status: Verified
Type: Bug
Package:SOAP related
Operating System: *
PHP Version:5.*, 6CVS (2009-04-28)
Block user comment: N
Private report: N
New Comment:
Any progress on this issue?
Previous Comments:
[2008-12-12 18:13:38] clwells at nocworx dot com
This WSDL exhibits this behavior:
http://www.swsoft.com/webservices/vza/4.0.0/VZA.wsdl
[2008-06-16 15:54:52] Martin dot Bosslet at googlemail dot com
Description:
I have tried to access a web service whose WSDL is distributed among several
files each of which contains references to several further XSDs. Now the WSDL
itself is valid, as .NET or Java clients have accessed the services without any
problems. But when creating a new instance of SoapClient it fails because I'm
told that a certain element has already been defined. The problem is, that
there are elements with the same name, but they DO differ in
namespaces.
Reproduce code:
---
$client = new SoapClient('someURI');
/* Please email me to get a copy of the WSDLs producing the error. They're too
large to be posted here (although I tried to keep them small already) and I
have no facility to make them available online. */
Expected result:
No error when parsing the WSDL.
Actual result:
--
SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: '' already
defined in
--
Edit this bug report at https://bugs.php.net/bug.php?id=45282&edit=1
Bug #60629 [Fbk->Csd]: memory corruption when web server closed the fcgi fd(?)
Edit report at https://bugs.php.net/bug.php?id=60629&edit=1 ID: 60629 Updated by: f...@php.net Reported by:phpbugs at oops dot mooo dot com Summary:memory corruption when web server closed the fcgi fd(?) -Status: Feedback +Status: Closed Type: Bug Package:FPM related Operating System: Debian Squeeze PHP Version:5.3.9RC4 Assigned To:fat Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-01-03 22:25:44] f...@php.net Automatic comment from SVN on behalf of fat Revision: http://svn.php.net/viewvc/?view=revision&revision=321734 Log: - Fixed bug #60629 (memory corruption when web server closed the fcgi fd) [2012-01-03 19:44:15] phpbugs at oops dot mooo dot com Looks good to me, I don't understand a) Why was fcgi_write's return value changed to ssize_t b) Why the explicit (size_t) casts was added but I can't see any problem with them either :) (I only did this part.) - size_t ret; + ssize_t ret [2012-01-03 18:03:28] f...@php.net Can you please test and validate the attached patch please ? thx ++ jerome [2012-01-03 18:02:55] f...@php.net The following patch has been added/updated: Patch Name: fpm-bugs-60629.patch Revision: 1325613774 URL: https://bugs.php.net/patch-display.php?bug=60629&patch=fpm-bugs-60629.patch&revision=1325613774 [2012-01-03 12:13:34] f...@php.net it's on my todo list. I'll try to take time to look at this bugs this week. ++ jerome The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60629 -- Edit this bug report at https://bugs.php.net/bug.php?id=60629&edit=1
Bug #60634 [Ver]: Segmentation fault when trying to die() in SessionHandler::write()
Edit report at https://bugs.php.net/bug.php?id=60634&edit=1 ID: 60634 Updated by: ar...@php.net Reported by:bobwei9 at hotmail dot com Summary:Segmentation fault when trying to die() in SessionHandler::write() Status: Verified Type: Bug Package:Reproducible crash Operating System: Mac OS X 10.7 PHP Version:trunk-SVN-2012-01-01 (SVN) -Assigned To:arpad +Assigned To: Block user comment: N Private report: N New Comment: This is present in 5.3 too using the old style session_set_save_handler(). Seems to be related to the zend_try in php_session_flush(). Previous Comments: [2012-01-03 21:46:51] ar...@php.net Automatic comment from SVN on behalf of arpad Revision: http://svn.php.net/viewvc/?view=revision&revision=321733 Log: add test for #60634 [2012-01-01 19:32:18] bobwei9 at hotmail dot com Description: The apache or the CLI reports an segmentation fault while trying to die() or to exit() a script in the write method of a class which extends the SessionHandler class. Test script: --- https://bugs.php.net/bug.php?id=60634&edit=1
Bug #60157 [Com]: OPENSSL_CONF environment variable ignored
Edit report at https://bugs.php.net/bug.php?id=60157&edit=1
ID: 60157
Comment by: dfroe at gmx dot de
Reported by:zeusgerde at arcor dot de
Summary:OPENSSL_CONF environment variable ignored
Status: Open
Type: Bug
Package:OpenSSL related
Operating System: Windows XP and Windows 7
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
I am able to reproduce this bug under FreeBSD, too. So it does not seem to be a
Windows specific issue. I am using PHP 5.3.8 compiled via the latest FreeBSD
ports tree. The putenv() hint does not work, either. Passing the config value
within the config array directly to the openssl function works - but can of
course only be a quick and dirty workaround.
Previous Comments:
[2011-10-31 07:51:05] zeusgerde at arcor dot de
> Where do you set it? System wild? manually in your script?
In httpd.conf in a global scope:
| SetEnv OPENSSL_CONF D:\sandbox\openssl.cnf
You can see that it is set in the actual result:
| var_dump(getenv('OPENSSL_CONF'));
| // string(42) "D:\sandbox\openssl.cnf"
(hint: don't look at the string length, I scrambled the path in this bug report)
> putenv("OPENSSL_CONF=whereyouwanit");
No change in the actual result. Even if I do this:
| putenv("OPENSSL_CONF=", getenv('OPENSSL_CONF'));
It only works if I use the $configargs parameter directly (see my first comment
at 2011-10-28 11:48 UTC)
[2011-10-28 12:45:52] paj...@php.net
Where do you set it? System wild? manually in your script?
try:
putenv("OPENSSL_CONF=whereyouwanit");
.. rest of your code..
Only to verify a possible cause.
[2011-10-28 11:50:18] zeusgerde at arcor dot de
BTW, this is the work-around
var_dump(openssl_pkey_new(array(
'config' => getenv('OPENSSL_CONF'),
)));
[2011-10-28 11:48:36] zeusgerde at arcor dot de
Description:
setting OPENSSL_CONF is ignored in openssl* functions despite the documentation
lists it as the first location where the configuration file is searched
http://de2.php.net/manual/en/openssl.installation.php
Test script:
---
https://bugs.php.net/bug.php?id=60157&edit=1
Bug #60629 [Com]: memory corruption when web server closed the fcgi fd(?)
Edit report at https://bugs.php.net/bug.php?id=60629&edit=1 ID: 60629 Comment by: phpbugs at oops dot mooo dot com Reported by:phpbugs at oops dot mooo dot com Summary:memory corruption when web server closed the fcgi fd(?) Status: Feedback Type: Bug Package:FPM related Operating System: Debian Squeeze PHP Version:5.3.9RC4 Assigned To:fat Block user comment: N Private report: N New Comment: Looks good to me, I don't understand a) Why was fcgi_write's return value changed to ssize_t b) Why the explicit (size_t) casts was added but I can't see any problem with them either :) (I only did this part.) - size_t ret; + ssize_t ret Previous Comments: [2012-01-03 18:03:28] f...@php.net Can you please test and validate the attached patch please ? thx ++ jerome [2012-01-03 18:02:55] f...@php.net The following patch has been added/updated: Patch Name: fpm-bugs-60629.patch Revision: 1325613774 URL: https://bugs.php.net/patch-display.php?bug=60629&patch=fpm-bugs-60629.patch&revision=1325613774 [2012-01-03 12:13:34] f...@php.net it's on my todo list. I'll try to take time to look at this bugs this week. ++ jerome [2012-01-03 12:12:09] larue...@php.net fat, could you plz look at this? thanks [2011-12-30 23:40:43] phpbugs at oops dot mooo dot com I think it might've been introduced in this commit (~line 270). http://svn.php.net/viewvc/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c?r1=317894&r2=317897 It looks like write() might have the same problem, since it returns a ssize_t that's casted to size_t. Fix might be to use ssize_t instead? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60629 -- Edit this bug report at https://bugs.php.net/bug.php?id=60629&edit=1
Bug #60517 [Opn]: SimpleXML doesn't like empty elements with attributes
Edit report at https://bugs.php.net/bug.php?id=60517&edit=1
ID: 60517
User updated by:raj at rajsingh dot org
Reported by:raj at rajsingh dot org
Summary:SimpleXML doesn't like empty elements with
attributes
Status: Open
Type: Bug
Package:SimpleXML related
Operating System: Mac OS X 10.7.2
PHP Version:5.4.0RC3
Block user comment: N
Private report: N
New Comment:
Thanks Will. That works.
However, I'm still a little confused. Example #4 from
http://www.php.net/manual/en/simplexml.examples-basic.php made me think that
I'd get back an iterable object from the $xml->relationship access method, but
example #2 on that same page makes it seem like you get back the value of the
element if there's only a single element with that name?
So thanks for your solution because it works, but if I'm understanding
correctly those examples, then the interface is sending a mixed message.
Previous Comments:
[2011-12-24 09:37:41] will dot fitch at gmail dot com
I believe the issue is in your code. When you check for:
if (!empty($xml->relationship))
You are checking the first element. In your XML, the first element of
is empty. There is no value in the element. However, in your
example, the first element is not empty. It contains a new line
character. That is why !empty($xml->link) passes.
What you should be checking is this:
if (count($xml->relationship) > 0)
When you're verifying with empty(), you're checking the element - not the
number
of elements with that name within the node leaf.
[2011-12-14 03:01:33] raj at rajsingh dot org
Description:
If the first XML element is an empty tag, e.g. , then no
elements by that name will get recognized. However, if you have many, e.g.
elements, and you write at least the first one as a non-empty tag, e.g.
SimpleXML will recognize all the elements (even those
with empty tags. A test program that uses a test file on my web site shows this
problem.
Test script:
---
$fn = "http://www.rajsingh.org/poiwg/c_error.xml";;
$xml = simplexml_load_file($fn);
if ( !empty($xml->link) ) {
echo "number of links: " . sizeof($xml->link) . "\n";
foreach ($xml->link as $link) {
echo "link href: " . $link['href'] . "\n";
}
}
if ( !empty($xml->relationship) ) {
echo "number of relationships: " . sizeof($xml->location->relationship) .
"\n";
foreach ($xml->location->relationship as $rel) {
echo "relationship term: " . $rel['term'] . "\n";
}
}
Expected result:
number of links: 3
link href: http://www.rajsingh.org/pois/45343489.xml
link href: http://en.wikipedia.org/wiki/Boston
link href: http://www.geonames.org/maps/google_42.358_-71.06.html
number of relationships: 3
relationship term: contains
relationship term: within
relationship term: contains
Actual result:
--
number of links: 3
link href: http://www.rajsingh.org/pois/45343489.xml
link href: http://en.wikipedia.org/wiki/Boston
link href: http://www.geonames.org/maps/google_42.358_-71.06.html
--
Edit this bug report at https://bugs.php.net/bug.php?id=60517&edit=1
[PHP-BUG] Bug #60646 [NEW]: Recursive request with same session fails
From: Operating system: Centos 5.4 PHP version: 5.3.8 Package: Session related Bug Type: Bug Bug description:Recursive request with same session fails Description: Hi, When a request issues another request to same domain sending the same cookie (e.g. Cookie: PHPSESSID=f2e6bd70963b37243d6be566a6d3adc1). The inner request timeouts throwing a "Warning: Unknown: Error occured while closing statement in Unknown on line 0" occurs. I suspect this has to do with the fact that the session file is being locked. If the documentation says it somewhere, at least the error thrown should be more specific. Expected result: Dont'know, but if error, a detailed one. Actual result: -- Warning: Unknown: Error occured while closing statement in Unknown on line 0 -- Edit bug report at https://bugs.php.net/bug.php?id=60646&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60646&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60646&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60646&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60646&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60646&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60646&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60646&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60646&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60646&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60646&r=support Expected behavior: https://bugs.php.net/fix.php?id=60646&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60646&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60646&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60646&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60646&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60646&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60646&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60646&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60646&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60646&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60646&r=mysqlcfg
Bug #60629 [Asn->Fbk]: memory corruption when web server closed the fcgi fd(?)
Edit report at https://bugs.php.net/bug.php?id=60629&edit=1
ID: 60629
Updated by: f...@php.net
Reported by:phpbugs at oops dot mooo dot com
Summary:memory corruption when web server closed the fcgi
fd(?)
-Status: Assigned
+Status: Feedback
Type: Bug
Package:FPM related
Operating System: Debian Squeeze
PHP Version:5.3.9RC4
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
Can you please test and validate the attached patch please ?
thx
++ jerome
Previous Comments:
[2012-01-03 18:02:55] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-bugs-60629.patch
Revision: 1325613774
URL:
https://bugs.php.net/patch-display.php?bug=60629&patch=fpm-bugs-60629.patch&revision=1325613774
[2012-01-03 12:13:34] f...@php.net
it's on my todo list. I'll try to take time to look at this bugs this week.
++ jerome
[2012-01-03 12:12:09] larue...@php.net
fat, could you plz look at this? thanks
[2011-12-30 23:40:43] phpbugs at oops dot mooo dot com
I think it might've been introduced in this commit (~line 270).
http://svn.php.net/viewvc/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c?r1=317894&r2=317897
It looks like write() might have the same problem, since it returns a ssize_t
that's casted to size_t.
Fix might be to use ssize_t instead?
[2011-12-30 23:12:00] phpbugs at oops dot mooo dot com
Description:
I tried php5.3.9RC4 today and got a few core dumps.
I think b)fcgi_flush() returns false, making fcgi_write return -1. Then
sapi_cgibin_single_write will make it positive because ret is unsigned in c).
As a result, the comparison in d) will fail.
In debugger it looks like PHP is looping over open_packet() in an infinite
loop. Each time out_pos gets increased a little. Finally, after overwriting the
whole stack, it will SIGSEGV.
===
https://svn.php.net/repository/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fastcgi.c
===
int fcgi_write(fcgi_request *req, fcgi_request_type type, const char *str, int
len)
{
int limit, rest;
if (len <= 0) {
return 0;
}
if (req->out_hdr && req->out_hdr->type != type) {
close_packet(req);
}
/* Optimized version */
limit = sizeof(req->out_buf) - (req->out_pos - req->out_buf);
if (!req->out_hdr) {
limit -= sizeof(fcgi_header);
if (limit < 0) limit = 0;
}
if (len < limit) {
if (!req->out_hdr) {
open_packet(req, type);
}
memcpy(req->out_pos, str, len);
req->out_pos += len;
} else if (len - limit < sizeof(req->out_buf) - sizeof(fcgi_header)) {
if (!req->out_hdr) {
a) open_packet(req, type);
}
if (limit > 0) {
memcpy(req->out_pos, str, limit);
req->out_pos += limit;
}
if (!fcgi_flush(req, 0)) {
b) return -1;
}
===
https://svn.php.net/repository/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c
===
static inline size_t sapi_cgibin_single_write(const char *str, uint str_length
TSRMLS_DC)
{
c) size_t ret;
/* sapi has started which means everyhting must be send through fcgi */
if (fpm_is_running) {
fcgi_request *request = (fcgi_request*) SG(server_context);
ret = fcgi_write(request, FCGI_STDOUT, str, str_length);
d) if (ret <= 0) {
return 0;
}
return ret;
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60629&edit=1
Bug #60629 [PATCH]: memory corruption when web server closed the fcgi fd(?)
Edit report at https://bugs.php.net/bug.php?id=60629&edit=1
ID: 60629
Patch added by: f...@php.net
Reported by:phpbugs at oops dot mooo dot com
Summary:memory corruption when web server closed the fcgi
fd(?)
Status: Assigned
Type: Bug
Package:FPM related
Operating System: Debian Squeeze
PHP Version:5.3.9RC4
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: fpm-bugs-60629.patch
Revision: 1325613774
URL:
https://bugs.php.net/patch-display.php?bug=60629&patch=fpm-bugs-60629.patch&revision=1325613774
Previous Comments:
[2012-01-03 12:13:34] f...@php.net
it's on my todo list. I'll try to take time to look at this bugs this week.
++ jerome
[2012-01-03 12:12:09] larue...@php.net
fat, could you plz look at this? thanks
[2011-12-30 23:40:43] phpbugs at oops dot mooo dot com
I think it might've been introduced in this commit (~line 270).
http://svn.php.net/viewvc/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c?r1=317894&r2=317897
It looks like write() might have the same problem, since it returns a ssize_t
that's casted to size_t.
Fix might be to use ssize_t instead?
[2011-12-30 23:12:00] phpbugs at oops dot mooo dot com
Description:
I tried php5.3.9RC4 today and got a few core dumps.
I think b)fcgi_flush() returns false, making fcgi_write return -1. Then
sapi_cgibin_single_write will make it positive because ret is unsigned in c).
As a result, the comparison in d) will fail.
In debugger it looks like PHP is looping over open_packet() in an infinite
loop. Each time out_pos gets increased a little. Finally, after overwriting the
whole stack, it will SIGSEGV.
===
https://svn.php.net/repository/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fastcgi.c
===
int fcgi_write(fcgi_request *req, fcgi_request_type type, const char *str, int
len)
{
int limit, rest;
if (len <= 0) {
return 0;
}
if (req->out_hdr && req->out_hdr->type != type) {
close_packet(req);
}
/* Optimized version */
limit = sizeof(req->out_buf) - (req->out_pos - req->out_buf);
if (!req->out_hdr) {
limit -= sizeof(fcgi_header);
if (limit < 0) limit = 0;
}
if (len < limit) {
if (!req->out_hdr) {
open_packet(req, type);
}
memcpy(req->out_pos, str, len);
req->out_pos += len;
} else if (len - limit < sizeof(req->out_buf) - sizeof(fcgi_header)) {
if (!req->out_hdr) {
a) open_packet(req, type);
}
if (limit > 0) {
memcpy(req->out_pos, str, limit);
req->out_pos += limit;
}
if (!fcgi_flush(req, 0)) {
b) return -1;
}
===
https://svn.php.net/repository/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c
===
static inline size_t sapi_cgibin_single_write(const char *str, uint str_length
TSRMLS_DC)
{
c) size_t ret;
/* sapi has started which means everyhting must be send through fcgi */
if (fpm_is_running) {
fcgi_request *request = (fcgi_request*) SG(server_context);
ret = fcgi_write(request, FCGI_STDOUT, str, str_length);
d) if (ret <= 0) {
return 0;
}
return ret;
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60629&edit=1
Bug #60642 [Com]: Missing constant PHP_QUERY_RFC1738 and PHP_QUERY_RFC3986
Edit report at https://bugs.php.net/bug.php?id=60642&edit=1 ID: 60642 Comment by: michiel at thalent dot nl Reported by:michiel at thalent dot nl Summary:Missing constant PHP_QUERY_RFC1738 and PHP_QUERY_RFC3986 Status: Bogus Type: Bug Package:URL related Operating System: Windows and Linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Well the documentation says: The following constants are meant to be used with parse_url() and are available since PHP 5.1.2. (...) PHP_QUERY_RFC1738 (integer) PHP_QUERY_RFC3986 (integer) And i'm not sure how long the doc already is saying that. I noticed this problem when using a library that was last updated January 2011. So those constants must have been know by then already. But when its in php5.4 right now, I think only the documentation should be changed then. Previous Comments: [2012-01-03 17:36:43] m...@php.net Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Those constants were added along with the enc_type parameter in PHP 5.4.0 - check the changelog on http://php.net/http_build_query. [2012-01-03 12:50:00] michiel at thalent dot nl Description: I'm missing the contansts PHP_QUERY_RFC1738 and PHP_QUERY_RFC3986. I believe their value should be resp 1 and 2. Test script: --- Expected result: 1 2 Actual result: -- You will get a notice error. -- Edit this bug report at https://bugs.php.net/bug.php?id=60642&edit=1
Bug #60642 [Opn->Bgs]: Missing constant PHP_QUERY_RFC1738 and PHP_QUERY_RFC3986
Edit report at https://bugs.php.net/bug.php?id=60642&edit=1 ID: 60642 Updated by: m...@php.net Reported by:michiel at thalent dot nl Summary:Missing constant PHP_QUERY_RFC1738 and PHP_QUERY_RFC3986 -Status: Open +Status: Bogus Type: Bug Package:URL related Operating System: Windows and Linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Those constants were added along with the enc_type parameter in PHP 5.4.0 - check the changelog on http://php.net/http_build_query. Previous Comments: [2012-01-03 12:50:00] michiel at thalent dot nl Description: I'm missing the contansts PHP_QUERY_RFC1738 and PHP_QUERY_RFC3986. I believe their value should be resp 1 and 2. Test script: --- Expected result: 1 2 Actual result: -- You will get a notice error. -- Edit this bug report at https://bugs.php.net/bug.php?id=60642&edit=1
Bug #60636 [Fbk->Opn]: Dots in folders results in a open_basedir restriction warning
Edit report at https://bugs.php.net/bug.php?id=60636&edit=1 ID: 60636 User updated by:fernando at consultorpc dot com Reported by:fernando at consultorpc dot com Summary:Dots in folders results in a open_basedir restriction warning -Status: Feedback +Status: Open Type: Bug Package:Safe Mode/open_basedir Operating System: Linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Yes, /home/example exists. If i rename myfolder.example to myfolderexample ( no dots ), them it works as expected. Meaning that it will return false without any warnings. Previous Comments: [2012-01-03 17:06:24] larue...@php.net does that /home/example exists? I think this might has nothing to do with the *dot*, but a mis-understand warning. [2012-01-02 13:56:27] fernando at consultorpc dot com Description: If you try to access a file within a folder that has a dot, an open_basedir restriction warning will show up even if the folder is in the allowed paths list. Test script: --- function.file- exists]: open_basedir restriction in effect. File(/home/example/public_html/myfolder.example/file.php) is not within the allowed path(s): (/home/example:/usr/lib/php:/tmp) in /home/example/public_html/test.php on line 3 -- Edit this bug report at https://bugs.php.net/bug.php?id=60636&edit=1
Bug #60636 [Opn->Fbk]: Dots in folders results in a open_basedir restriction warning
Edit report at https://bugs.php.net/bug.php?id=60636&edit=1 ID: 60636 Updated by: larue...@php.net Reported by:fernando at consultorpc dot com Summary:Dots in folders results in a open_basedir restriction warning -Status: Open +Status: Feedback Type: Bug Package:Safe Mode/open_basedir Operating System: Linux PHP Version:5.3.8 Block user comment: N Private report: N Previous Comments: [2012-01-03 17:06:24] larue...@php.net does that /home/example exists? I think this might has nothing to do with the *dot*, but a mis-understand warning. [2012-01-02 13:56:27] fernando at consultorpc dot com Description: If you try to access a file within a folder that has a dot, an open_basedir restriction warning will show up even if the folder is in the allowed paths list. Test script: --- function.file- exists]: open_basedir restriction in effect. File(/home/example/public_html/myfolder.example/file.php) is not within the allowed path(s): (/home/example:/usr/lib/php:/tmp) in /home/example/public_html/test.php on line 3 -- Edit this bug report at https://bugs.php.net/bug.php?id=60636&edit=1
Bug #60636 [Opn]: Dots in folders results in a open_basedir restriction warning
Edit report at https://bugs.php.net/bug.php?id=60636&edit=1 ID: 60636 Updated by: larue...@php.net Reported by:fernando at consultorpc dot com Summary:Dots in folders results in a open_basedir restriction warning Status: Open Type: Bug Package:Safe Mode/open_basedir Operating System: Linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: does that /home/example exists? I think this might has nothing to do with the *dot*, but a mis-understand warning. Previous Comments: [2012-01-02 13:56:27] fernando at consultorpc dot com Description: If you try to access a file within a folder that has a dot, an open_basedir restriction warning will show up even if the folder is in the allowed paths list. Test script: --- function.file- exists]: open_basedir restriction in effect. File(/home/example/public_html/myfolder.example/file.php) is not within the allowed path(s): (/home/example:/usr/lib/php:/tmp) in /home/example/public_html/test.php on line 3 -- Edit this bug report at https://bugs.php.net/bug.php?id=60636&edit=1
Req #48352 [Com]: Method registerNodeClass does not work with DOMNodeList
Edit report at https://bugs.php.net/bug.php?id=48352&edit=1
ID: 48352
Comment by: kroccamen at gmail dot com
Reported by:php at xxlwebdesign dot de
Summary:Method registerNodeClass does not work with
DOMNodeList
Status: Assigned
Type: Feature/Change Request
Package:DOM XML related
Operating System: Gentoo
PHP Version:5.3CVS-2009-05-21 (snap)
Assigned To:rrichards
Block user comment: N
Private report: N
New Comment:
Iâd like to provide a valid use-case for this bug.
I have created an extended DOMDocument that upon __construct also creates an
XPath object, that way I can add methods to DOMElement to allow for
DOMElement->xpath ('...') instead of using DOMXPath->query ('...', DOMNode).
This makes the DOM more chainable and simpler to use without so many temporary
variables.
What I want to do is extend DOMNodeList so that one function call can apply to
all nodes returned from an XPath query, e.g.
DOMNode->xpath ('a')->addClass ('link');
Is anybody aware of any other work around that can be used to achieve this same
effect?
Previous Comments:
[2011-01-08 05:17:47] mat at homedvd dot ca
Any movement on this? The method should probably be called registerNodeListClass
[2010-02-15 02:45:10] mail at r-site dot net
very helpfull, extending DOMNode's almost implies it, pls hurry, ty
[2009-09-20 21:17:12] goetas at lignano dot it
this would be really helpful!
[2009-05-22 12:53:55] php at xxlwebdesign dot de
This would be very nice!
[2009-05-22 10:49:41] rricha...@php.net
This method was designed specifically for DOMNode based classes only.
changing to feature request and I will consider and evaluate expanding
its functionality.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=48352
--
Edit this bug report at https://bugs.php.net/bug.php?id=48352&edit=1
[PHP-BUG] Bug #60642 [NEW]: Missing constant PHP_QUERY_RFC1738 and PHP_QUERY_RFC3986
From: Operating system: Windows and Linux PHP version: 5.3.8 Package: URL related Bug Type: Bug Bug description:Missing constant PHP_QUERY_RFC1738 and PHP_QUERY_RFC3986 Description: I'm missing the contansts PHP_QUERY_RFC1738 and PHP_QUERY_RFC3986. I believe their value should be resp 1 and 2. Test script: --- Expected result: 1 2 Actual result: -- You will get a notice error. -- Edit bug report at https://bugs.php.net/bug.php?id=60642&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60642&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60642&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60642&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60642&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60642&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60642&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60642&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60642&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60642&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60642&r=support Expected behavior: https://bugs.php.net/fix.php?id=60642&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60642&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60642&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60642&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60642&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60642&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60642&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60642&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60642&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60642&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60642&r=mysqlcfg
Bug #60557 [Opn->Bgs]: ceil function bug
Edit report at https://bugs.php.net/bug.php?id=60557&edit=1 ID: 60557 Updated by: m...@php.net Reported by:vividy163 at hotmail dot com Summary:ceil function bug -Status: Open +Status: Bogus Type: Bug Package:Math related Operating System: Linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is, read this: http://www.floating-point-gui.de/ Thank you for your interest in PHP. Previous Comments: [2011-12-20 01:01:49] anon at anon dot anon (And if you need a solution for the more general case, consider subtracting a tiny value just before calling ceil:) echo ceil((12000*(7/100)) - 1e-8); // outputs: 840 [2011-12-20 00:55:27] anon at anon dot anon Ceil is correct. Due to the underlying limitations of the floating point math, 7/100 is not a fraction which can be exactly represented, so the CPU chooses the closest possible value, and after multiplying the result is: 840.1136868377216160297393798828125 All programming languages implementing IEEE 754 (see: https://en.wikipedia.org/wiki/IEEE_754-1985 ) (which is most of them) will give 841 for this computation. In this specific case, just do the multiplication first (remove the extra brackets): echo ceil(12000*7/100); // outputs: 840 [2011-12-19 03:38:37] vividy163 at hotmail dot com Description: it give me result 841. Test script: --- it give me result 841. Expected result: 840 Actual result: -- 841 -- Edit this bug report at https://bugs.php.net/bug.php?id=60557&edit=1
Bug #60629 [Com]: memory corruption when web server closed the fcgi fd(?)
Edit report at https://bugs.php.net/bug.php?id=60629&edit=1
ID: 60629
Comment by: f...@php.net
Reported by:phpbugs at oops dot mooo dot com
Summary:memory corruption when web server closed the fcgi
fd(?)
Status: Assigned
Type: Bug
Package:FPM related
Operating System: Debian Squeeze
PHP Version:5.3.9RC4
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
it's on my todo list. I'll try to take time to look at this bugs this week.
++ jerome
Previous Comments:
[2012-01-03 12:12:09] larue...@php.net
fat, could you plz look at this? thanks
[2011-12-30 23:40:43] phpbugs at oops dot mooo dot com
I think it might've been introduced in this commit (~line 270).
http://svn.php.net/viewvc/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c?r1=317894&r2=317897
It looks like write() might have the same problem, since it returns a ssize_t
that's casted to size_t.
Fix might be to use ssize_t instead?
[2011-12-30 23:12:00] phpbugs at oops dot mooo dot com
Description:
I tried php5.3.9RC4 today and got a few core dumps.
I think b)fcgi_flush() returns false, making fcgi_write return -1. Then
sapi_cgibin_single_write will make it positive because ret is unsigned in c).
As a result, the comparison in d) will fail.
In debugger it looks like PHP is looping over open_packet() in an infinite
loop. Each time out_pos gets increased a little. Finally, after overwriting the
whole stack, it will SIGSEGV.
===
https://svn.php.net/repository/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fastcgi.c
===
int fcgi_write(fcgi_request *req, fcgi_request_type type, const char *str, int
len)
{
int limit, rest;
if (len <= 0) {
return 0;
}
if (req->out_hdr && req->out_hdr->type != type) {
close_packet(req);
}
/* Optimized version */
limit = sizeof(req->out_buf) - (req->out_pos - req->out_buf);
if (!req->out_hdr) {
limit -= sizeof(fcgi_header);
if (limit < 0) limit = 0;
}
if (len < limit) {
if (!req->out_hdr) {
open_packet(req, type);
}
memcpy(req->out_pos, str, len);
req->out_pos += len;
} else if (len - limit < sizeof(req->out_buf) - sizeof(fcgi_header)) {
if (!req->out_hdr) {
a) open_packet(req, type);
}
if (limit > 0) {
memcpy(req->out_pos, str, limit);
req->out_pos += limit;
}
if (!fcgi_flush(req, 0)) {
b) return -1;
}
===
https://svn.php.net/repository/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c
===
static inline size_t sapi_cgibin_single_write(const char *str, uint str_length
TSRMLS_DC)
{
c) size_t ret;
/* sapi has started which means everyhting must be send through fcgi */
if (fpm_is_running) {
fcgi_request *request = (fcgi_request*) SG(server_context);
ret = fcgi_write(request, FCGI_STDOUT, str, str_length);
d) if (ret <= 0) {
return 0;
}
return ret;
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60629&edit=1
Bug #60629 [Opn]: memory corruption when web server closed the fcgi fd(?)
Edit report at https://bugs.php.net/bug.php?id=60629&edit=1
ID: 60629
Updated by: larue...@php.net
Reported by:phpbugs at oops dot mooo dot com
Summary:memory corruption when web server closed the fcgi
fd(?)
Status: Open
Type: Bug
Package:FPM related
Operating System: Debian Squeeze
PHP Version:5.3.9RC4
-Assigned To:
+Assigned To:fat
Block user comment: N
Private report: N
New Comment:
fat, could you plz look at this? thanks
Previous Comments:
[2011-12-30 23:40:43] phpbugs at oops dot mooo dot com
I think it might've been introduced in this commit (~line 270).
http://svn.php.net/viewvc/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c?r1=317894&r2=317897
It looks like write() might have the same problem, since it returns a ssize_t
that's casted to size_t.
Fix might be to use ssize_t instead?
[2011-12-30 23:12:00] phpbugs at oops dot mooo dot com
Description:
I tried php5.3.9RC4 today and got a few core dumps.
I think b)fcgi_flush() returns false, making fcgi_write return -1. Then
sapi_cgibin_single_write will make it positive because ret is unsigned in c).
As a result, the comparison in d) will fail.
In debugger it looks like PHP is looping over open_packet() in an infinite
loop. Each time out_pos gets increased a little. Finally, after overwriting the
whole stack, it will SIGSEGV.
===
https://svn.php.net/repository/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fastcgi.c
===
int fcgi_write(fcgi_request *req, fcgi_request_type type, const char *str, int
len)
{
int limit, rest;
if (len <= 0) {
return 0;
}
if (req->out_hdr && req->out_hdr->type != type) {
close_packet(req);
}
/* Optimized version */
limit = sizeof(req->out_buf) - (req->out_pos - req->out_buf);
if (!req->out_hdr) {
limit -= sizeof(fcgi_header);
if (limit < 0) limit = 0;
}
if (len < limit) {
if (!req->out_hdr) {
open_packet(req, type);
}
memcpy(req->out_pos, str, len);
req->out_pos += len;
} else if (len - limit < sizeof(req->out_buf) - sizeof(fcgi_header)) {
if (!req->out_hdr) {
a) open_packet(req, type);
}
if (limit > 0) {
memcpy(req->out_pos, str, limit);
req->out_pos += limit;
}
if (!fcgi_flush(req, 0)) {
b) return -1;
}
===
https://svn.php.net/repository/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c
===
static inline size_t sapi_cgibin_single_write(const char *str, uint str_length
TSRMLS_DC)
{
c) size_t ret;
/* sapi has started which means everyhting must be send through fcgi */
if (fpm_is_running) {
fcgi_request *request = (fcgi_request*) SG(server_context);
ret = fcgi_write(request, FCGI_STDOUT, str, str_length);
d) if (ret <= 0) {
return 0;
}
return ret;
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60629&edit=1
[PHP-BUG] Bug #60640 [NEW]: Invalid return values
From: Operating system: PHP version: 5.4.0RC4 Package: Session related Bug Type: Bug Bug description:Invalid return values Description: According to the documentation at http://www.php.net/manual/en/class.sessionhandler.php the various methods return 0 for success and 1 for failure which is kind of backwards since 0 would normally be evaluated as false and 1 as true. This is in direct contradiction with the current expected behaviour of session_set_save_handler() http://www.php.net/manual/en/function.session-set-save-handler.php which expects true or false return values except for the read handler which should always return a string. What's the deal here? I think the return values really should be true and false for this class, as expected by session_set_save_handler() Expected result: I would expect the methods of SessionHandler class to return back true or false for all methods except read() which should return a string, as expected by the session_set_save_handler() -- Edit bug report at https://bugs.php.net/bug.php?id=60640&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60640&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60640&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60640&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60640&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60640&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60640&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60640&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60640&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60640&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60640&r=support Expected behavior: https://bugs.php.net/fix.php?id=60640&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60640&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60640&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60640&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60640&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60640&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60640&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60640&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60640&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60640&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60640&r=mysqlcfg
