#47857 [NEW]: Deprecated set_magic_quotes_runtime

2009-03-31 Thread david at grudl dot com
From: david at grudl dot com
Operating system: 
PHP version:  5.3CVS-2009-04-01 (CVS)
PHP Bug Type: Feature/Change Request
Bug description:  Deprecated set_magic_quotes_runtime 

Description:

In PHP 5.3 this code throws E_DEPRECATED warning:

   set_magic_quotes_runtime(FALSE);

I think if is directive magic_quotes_runtime (finally!) marked as
deprecated, a code used to disable it should not throws warning.
E_DEPRECATED should throws only this code:

   set_magic_quotes_runtime(TRUE);

Or is there any way to disable magic_quotes_runtime without any warning?


-- 
Edit bug report at http://bugs.php.net/?id=47857&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47857&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47857&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47857&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47857&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47857&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47857&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47857&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47857&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47857&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47857&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47857&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47857&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47857&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47857&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47857&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47857&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47857&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47857&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47857&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47857&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47857&r=mysqlcfg



#47856 [NEW]: stristr converts needle to lower-case

2009-03-31 Thread hk at truebridge dot com
From: hk at truebridge dot com
Operating system: XP SP3
PHP version:  5.3.0RC1
PHP Bug Type: Strings related
Bug description:  stristr converts needle to lower-case

Description:

stristr converts needle to lower-case

Problem occurs on XP SP3

This does not happen on PHP 5.2.8 on FreeBSD 7.1





Reproduce code:
---
$haystack = "HAYSTACK";
$needle = "NEEDLE";
stristr( $haystack,$needle);
echo $haystack; // --> HAYSTACK
echo $needle;   // --> needle

Expected result:

HAYSTACK
NEEDLE

Actual result:
--
HAYSTACK
needle

-- 
Edit bug report at http://bugs.php.net/?id=47856&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47856&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47856&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47856&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47856&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47856&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47856&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47856&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47856&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47856&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47856&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47856&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47856&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47856&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47856&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47856&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47856&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47856&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47856&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47856&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47856&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47856&r=mysqlcfg



#47818 [Opn]: Segfault due to bound callback param

2009-03-31 Thread galaxy dot mipt at gmail dot com
 ID:   47818
 User updated by:  galaxy dot mipt at gmail dot com
 Reported By:  galaxy dot mipt at gmail dot com
 Status:   Open
 Bug Type: XMLRPC-EPI related
 Operating System: Linux 2.6.18 x86
 PHP Version:  5.2.9
 New Comment:

xmlrpc-epi-php.c, line 1115 (xmlrpc_server_call_method):

/* cleanup after ourselves.  what a sty! */
zval_dtor(data.xmlrpc_method);
FREE_ZVAL(data.xmlrpc_method);
zval_dtor(data.return_data);
FREE_ZVAL(data.return_data);

If I get it right data.xmlrpc_method is completely destructed after
method call. What if it has more than 1 reference like in reproduce
code?


Previous Comments:


[2009-04-01 02:04:44] galaxy dot mipt at gmail dot com

Okay, here's the backtrace from my app (not sure if this is helpful as
it does not contain references to XML-RPC extension):

#0  0x0078c0ec in memcpy () from /lib/tls/libc.so.6
#1  0x012a4fc2 in php_var_serialize_intern (buf=0xbfa05560,
struc=Variable "struc" is not available.
) at /home/local/php-5.2.9/ext/standard/var.c:536
#2  0x012a4b12 in php_var_serialize_intern (buf=0xbfa05560,
struc=0x914d4f8, var_hash=0xbfa05570) at
/home/local/php-5.2.9/ext/standard/var.c:824
#3  0x012a4b12 in php_var_serialize_intern (buf=0xbfa05560,
struc=0xb7f3b114, var_hash=0xbfa05570) at
/home/local/php-5.2.9/ext/standard/var.c:824
#4  0x012a4b12 in php_var_serialize_intern (buf=0xbfa05560,
struc=0xb7f3b2ec, var_hash=0xbfa05570) at
/home/local/php-5.2.9/ext/standard/var.c:824
#5  0x012a7ae5 in php_var_serialize (buf=0xbfa05560, struc=0x9216500,
var_hash=0xbfa05570) at /home/local/php-5.2.9/ext/standard/var.c:842
#6  0x012a7b71 in zif_serialize (ht=1, return_value=0xb7f3e694,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at
/home/local/php-5.2.9/ext/standard/var.c:865
#7  0x0132c009 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfa05b90) at
/home/local/php-5.2.9/Zend/zend_vm_execute.h:200
#8  0x0132b7b5 in execute (op_array=0x8fa87e0) at
/home/local/php-5.2.9/Zend/zend_vm_execute.h:92
#9  0x0132ba01 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfa05fd0) at
/home/local/php-5.2.9/Zend/zend_vm_execute.h:234
#10 0x0132b7b5 in execute (op_array=0x8f9a988) at
/home/local/php-5.2.9/Zend/zend_vm_execute.h:92
#11 0x0132ba01 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfa06280) at
/home/local/php-5.2.9/Zend/zend_vm_execute.h:234
#12 0x0132b7b5 in execute (op_array=0x8f8342c) at
/home/local/php-5.2.9/Zend/zend_vm_execute.h:92
#13 0x01312029 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/local/php-5.2.9/Zend/zend.c:1134
#14 0x012d96dd in php_execute_script (primary_file=0xbfa08560) at
/home/local/php-5.2.9/main/main.c:2023
#15 0x0138d2b6 in apache_php_module_main (r=0x8f71984,
display_source_mode=0) at
/home/local/php-5.2.9/sapi/apache/sapi_apache.c:53
#16 0x0138dc48 in send_php (r=0x8f71984, display_source_mode=0,
filename=0x0) at /home/local/php-5.2.9/sapi/apache/mod_php5.c:664
#17 0x0138de3e in send_parsed_php (r=0x8f71984) at
/home/local/php-5.2.9/sapi/apache/mod_php5.c:679
#18 0x0809e808 in ap_invoke_handler ()
#19 0x080b3eca in process_request_internal ()
#20 0x080b4323 in ap_internal_redirect ()
#21 0x0806d3c7 in handler_redirect ()
#22 0x0809e808 in ap_invoke_handler ()
#23 0x080b3eca in process_request_internal ()
#24 0x080b3f29 in ap_process_request ()
#25 0x080aad2b in child_main ()
#26 0x080ab014 in make_child ()
#27 0x080ab34d in perform_idle_server_maintenance ()
#28 0x080ab95a in standalone_main ()
#29 0x080abf7d in main ()


As I mentioned earlier the crash is not very stable, I caught this on
PHP compiled without --enable-debug because I could not make it crash
otherwise after reasonable effort. With debug enabled though it reports
memory leaks:

[Wed Apr  1 01:31:18 2009]  Script: 
'/home/local/public_html/site/index.php'
/home/local/php-5.2.9/Zend/zend_variables.h(45) :  Freeing 0xB7E9DC64
(1 bytes), script=/home/local/public_html/site/index.php
/home/local/php-5.2.9/Zend/zend_variables.c(120) : Actual location
(location was relayed)
[Wed Apr  1 01:31:18 2009]  Script: 
'/home/local/public_html/site/index.php'
/home/local/php-5.2.9/ext/xmlrpc/xmlrpc-epi-php.c(362) :  Freeing
0x0939CEA8 (21 bytes), script=/home/local/public_html/site/index.php
=== Total 2 memory leaks detected ===


Up in backtrace it crashed at serialize step but it tends to
occasinally crash at any access attempts to the variable that stores the
unfortunate XML-RPC method name.



[2009-03-31 07:12:12] j...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace

#47818 [Fbk->Opn]: Segfault due to bound callback param

2009-03-31 Thread galaxy dot mipt at gmail dot com
 ID:   47818
 User updated by:  galaxy dot mipt at gmail dot com
 Reported By:  galaxy dot mipt at gmail dot com
-Status:   Feedback
+Status:   Open
 Bug Type: XMLRPC-EPI related
 Operating System: Linux 2.6.18 x86
 PHP Version:  5.2.9
 New Comment:

Okay, here's the backtrace from my app (not sure if this is helpful as
it does not contain references to XML-RPC extension):

#0  0x0078c0ec in memcpy () from /lib/tls/libc.so.6
#1  0x012a4fc2 in php_var_serialize_intern (buf=0xbfa05560,
struc=Variable "struc" is not available.
) at /home/local/php-5.2.9/ext/standard/var.c:536
#2  0x012a4b12 in php_var_serialize_intern (buf=0xbfa05560,
struc=0x914d4f8, var_hash=0xbfa05570) at
/home/local/php-5.2.9/ext/standard/var.c:824
#3  0x012a4b12 in php_var_serialize_intern (buf=0xbfa05560,
struc=0xb7f3b114, var_hash=0xbfa05570) at
/home/local/php-5.2.9/ext/standard/var.c:824
#4  0x012a4b12 in php_var_serialize_intern (buf=0xbfa05560,
struc=0xb7f3b2ec, var_hash=0xbfa05570) at
/home/local/php-5.2.9/ext/standard/var.c:824
#5  0x012a7ae5 in php_var_serialize (buf=0xbfa05560, struc=0x9216500,
var_hash=0xbfa05570) at /home/local/php-5.2.9/ext/standard/var.c:842
#6  0x012a7b71 in zif_serialize (ht=1, return_value=0xb7f3e694,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at
/home/local/php-5.2.9/ext/standard/var.c:865
#7  0x0132c009 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfa05b90) at
/home/local/php-5.2.9/Zend/zend_vm_execute.h:200
#8  0x0132b7b5 in execute (op_array=0x8fa87e0) at
/home/local/php-5.2.9/Zend/zend_vm_execute.h:92
#9  0x0132ba01 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfa05fd0) at
/home/local/php-5.2.9/Zend/zend_vm_execute.h:234
#10 0x0132b7b5 in execute (op_array=0x8f9a988) at
/home/local/php-5.2.9/Zend/zend_vm_execute.h:92
#11 0x0132ba01 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfa06280) at
/home/local/php-5.2.9/Zend/zend_vm_execute.h:234
#12 0x0132b7b5 in execute (op_array=0x8f8342c) at
/home/local/php-5.2.9/Zend/zend_vm_execute.h:92
#13 0x01312029 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/local/php-5.2.9/Zend/zend.c:1134
#14 0x012d96dd in php_execute_script (primary_file=0xbfa08560) at
/home/local/php-5.2.9/main/main.c:2023
#15 0x0138d2b6 in apache_php_module_main (r=0x8f71984,
display_source_mode=0) at
/home/local/php-5.2.9/sapi/apache/sapi_apache.c:53
#16 0x0138dc48 in send_php (r=0x8f71984, display_source_mode=0,
filename=0x0) at /home/local/php-5.2.9/sapi/apache/mod_php5.c:664
#17 0x0138de3e in send_parsed_php (r=0x8f71984) at
/home/local/php-5.2.9/sapi/apache/mod_php5.c:679
#18 0x0809e808 in ap_invoke_handler ()
#19 0x080b3eca in process_request_internal ()
#20 0x080b4323 in ap_internal_redirect ()
#21 0x0806d3c7 in handler_redirect ()
#22 0x0809e808 in ap_invoke_handler ()
#23 0x080b3eca in process_request_internal ()
#24 0x080b3f29 in ap_process_request ()
#25 0x080aad2b in child_main ()
#26 0x080ab014 in make_child ()
#27 0x080ab34d in perform_idle_server_maintenance ()
#28 0x080ab95a in standalone_main ()
#29 0x080abf7d in main ()


As I mentioned earlier the crash is not very stable, I caught this on
PHP compiled without --enable-debug because I could not make it crash
otherwise after reasonable effort. With debug enabled though it reports
memory leaks:

[Wed Apr  1 01:31:18 2009]  Script: 
'/home/local/public_html/site/index.php'
/home/local/php-5.2.9/Zend/zend_variables.h(45) :  Freeing 0xB7E9DC64
(1 bytes), script=/home/local/public_html/site/index.php
/home/local/php-5.2.9/Zend/zend_variables.c(120) : Actual location
(location was relayed)
[Wed Apr  1 01:31:18 2009]  Script: 
'/home/local/public_html/site/index.php'
/home/local/php-5.2.9/ext/xmlrpc/xmlrpc-epi-php.c(362) :  Freeing
0x0939CEA8 (21 bytes), script=/home/local/public_html/site/index.php
=== Total 2 memory leaks detected ===


Up in backtrace it crashed at serialize step but it tends to
occasinally crash at any access attempts to the variable that stores the
unfortunate XML-RPC method name.


Previous Comments:


[2009-03-31 07:12:12] j...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.





[2009-03-28 04:04:16] galaxy dot mipt at gmail dot com

Description:

In my particular case when the callback for
xmlrpc_server_register_method() is a class method attempt to save some
of the parameters passed to that callback during
xmlrpc_server_call_method() ca

#47786 [Com]: ldap_list get "Decoding error" on some specific searching attribute

2009-03-31 Thread tedc21thc at hotmail dot com
 ID:   47786
 Comment by:   tedc21thc at hotmail dot com
 Reported By:  tedc21thc at hotmail dot com
 Status:   Feedback
 Bug Type: LDAP related
 Operating System: FreeBSD 7.1
 PHP Version:  5.2.9
 New Comment:

the problem is when I change the searching attribute from 
("cn","mail","proxyaddresses","ou")
to any other
like... ("mail","cn","proxyaddresses","ou") <- only switching sorting
or... ("cn","mail","proxyaddresses","ou","something") <- add something
or remove something
or whatever

the result of ""LDAP_ERROR($ds)"" become success,
and I can get values from
$info = ldap_get_entries($ds, $sr);
and following steps.


Previous Comments:


[2009-03-31 07:37:09] j...@php.net

What makes you think it's not expected result?

>From manual about ldap_list():

"LDAP_SCOPE_ONELEVEL means that the search should only return 
information that is at the level immediately below the base_dn given 
in the call. (Equivalent to typing "ls" and getting a list of files 
and folders in the current working directory.)"




[2009-03-26 09:46:53] tedc21thc at hotmail dot com

Description:

target ldap server : notes
PHP version : 5.2.9(CLI)
OS: FreeBSD ( tested on 5.4 and 7.1)
When using "ldap_list" on specific basedn and specific attribute
combination will get "Decoding error" (-4) error.

look seems like bug #5433
But "Decoding error" only happens on searching for 
("cn","mail","proxyaddresses","ou") attributes,
and will NOT get error if changing these attirbute's sorting or
add/remove some other attributes.

ps: using ldap_search wont get error.

Reproduce code:
---
$ldp_svrip ='192.168.100.150';   // IP
$ldp_acc = '';
$ldp_pwd = '';
$ldp_svrport ='';   // Port
$ldp_dn = 'OU=tw,O=iei2';   // DN
$ldp_filter = '(objectclass=*)';   // FILTER
$ldp_jth = array("cn","mail","proxyaddresses","ou");   // Attribute
$ds = ldap_connect($ldp_svrip, $ldp_svrport) ;
$rbind = ldap_bind($ds, $ldp_acc, $ldp_pwd);
$sr = @ldap_list($ds, $ldp_dn, $ldp_filter, $ldp_jth);
echo LDAP_ERROR($ds);
$info = ldap_get_entries($ds, $sr);

Expected result:

"Success"

Actual result:
--
"Decoding error"





-- 
Edit this bug report at http://bugs.php.net/?id=47786&edit=1



#47855 [Opn->Asn]: VC6 Thread Safe MSI install fails

2009-03-31 Thread pajoye
 ID:   47855
 Updated by:   paj...@php.net
 Reported By:  mfaust at usinternet dot com
-Status:   Open
+Status:   Assigned
 Bug Type: *General Issues
 Operating System: Windows XP SP3
 PHP Version:  5.3CVS-2009-03-31 (snap)
-Assigned To:  
+Assigned To:  jmertic


Previous Comments:


[2009-03-31 23:27:50] mfaust at usinternet dot com

Description:

Towards the end of the install process the installer prompts with
"There is a problem with this Windows installer package. A script
required for this install to complete could not be run. Contact your
support personnel or package vendor." Clicking on "OK" takes you to once
last install screen stating PHP 5.3.0 Setup Wizard ended prematurely. As
far as I can tell the steps that are missed are modifying httpd.conf and
mime.types for the Apache 2.2 install. This happens on two separately
configured Windows XP SP3 machines. This happens in PHP 5.3.0 RC1 as
well as 2009-03-31 SNAP






-- 
Edit this bug report at http://bugs.php.net/?id=47855&edit=1



#47855 [NEW]: VC6 Thread Safe MSI install fails

2009-03-31 Thread mfaust at usinternet dot com
From: mfaust at usinternet dot com
Operating system: Windows XP SP3
PHP version:  5.3CVS-2009-03-31 (snap)
PHP Bug Type: *General Issues
Bug description:  VC6 Thread Safe MSI install fails

Description:

Towards the end of the install process the installer prompts with "There
is a problem with this Windows installer package. A script required for
this install to complete could not be run. Contact your support personnel
or package vendor." Clicking on "OK" takes you to once last install screen
stating PHP 5.3.0 Setup Wizard ended prematurely. As far as I can tell the
steps that are missed are modifying httpd.conf and mime.types for the
Apache 2.2 install. This happens on two separately configured Windows XP
SP3 machines. This happens in PHP 5.3.0 RC1 as well as 2009-03-31 SNAP


-- 
Edit bug report at http://bugs.php.net/?id=47855&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47855&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47855&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47855&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47855&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47855&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47855&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47855&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47855&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47855&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47855&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47855&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47855&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47855&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47855&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47855&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47855&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47855&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47855&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47855&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47855&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47855&r=mysqlcfg



#47801 [Opn]: __call() accessed via parent:: operator is provided incorrect method name

2009-03-31 Thread kkauper at yahoo-inc dot com
 ID:   47801
 User updated by:  kkauper at yahoo-inc dot com
 Reported By:  kkauper at yahoo-inc dot com
 Status:   Open
 Bug Type: Class/Object related
 Operating System: FreeBSD 4
 PHP Version:  5.2.9
 New Comment:

jani@ -- I'm not sure I understand your comment. I've already mentioned
bug 42937 in my problem description. This problem may be related, but is
not identical.


Previous Comments:


[2009-03-31 07:23:29] j...@php.net

See also bug #42937



[2009-03-27 03:29:40] kkauper at yahoo-inc dot com

Description:

If parent:: (NOTE: this is *not* a static invocation) is
called in a child class, and  does not exist in the parent,
the parent's __call() magic method is provided the method name (the
$name argument) in lower case.

See the code provided to reproduce the problem. The $b->getFoo(); call
should output the method name as "getFoo", including the upercase "F"
character. Instead, the method name is converted to all lower case. To
be consistent with the results of $a->getFoo();, the method name should
not be converted to lower case.

This issue is probably related to the recently resolved bug # 42937.

Reproduce code:
---
class A
{
  function __call($name, $args)
  {
echo("magic method called: $name\n");
  }
}

class B extends A
{
  function getFoo()
  {
parent::getFoo();
  }
}

$a = new A();
$a->getFoo();

$b = new B();
$b->getFoo();

Expected result:

magic method called: getFoo
magic method called: getFoo 

Actual result:
--
magic method called: getFoo
magic method called: getfoo 





-- 
Edit this bug report at http://bugs.php.net/?id=47801&edit=1



#47660 [Asn]: open/close can be reduced for require_once in ZEND_INCLUDE_OR_EVAL handlers

2009-03-31 Thread rasmus
 ID:   47660
 Updated by:   ras...@php.net
 Reported By:  basant dot kukreja at gmail dot com
 Status:   Assigned
 Bug Type: Performance problem
 Operating System: *
 PHP Version:  5.2.9
 Assigned To:  dmitry
 New Comment:

How does this handle the case where:

/some/path/to/file.php
/other/full/path/to/file.php

where /other is a symlink to /some ?


Previous Comments:


[2009-03-31 21:44:27] basant dot kukreja at gmail dot com

Here is the performance data collected :
For 30 minute 8 core measurement :
Before this patch :
__open 285.019 sec (Inclusive system time):

After this patch :
__open 124.747 sec (Inclusive system time):

So with submitted patch, specweb ecommerce benchmark spent 160 second
less
time.



[2009-03-15 04:03:06] basant dot kukreja at gmail dot com

Why do php does so? Reason is obvious. For included_once files, php
engine has
to make sure that files are included only once. A script can include a
file
e.g
include_once "file1.php"
include_once "file2.php"

If file2.php is just a symlink to file1.php, it should not be included
more
than once. So to assure that php engine calles zend_stream_open which
will
eventually find the real path of the file and open the file.

However, if file is an absolute file then virtual_file_ex already finds
the
real path so we can have a performance optimization for absolute
paths.

Here is my suggested patch :

--
diff -r f55e0053325c php-5.2.9RC3/Zend/zend_vm_def.h
--- a/php-5.2.9RC3/Zend/zend_vm_def.h   Wed Mar 11 12:43:20 2009 -0700
+++ b/php-5.2.9RC3/Zend/zend_vm_def.h   Sat Mar 14 20:26:27 2009 -0700
@@ -2851,22 +2851,49 @@
case ZEND_INCLUDE_ONCE:
case ZEND_REQUIRE_ONCE: {
zend_file_handle file_handle;
+   char* realfilepath = NULL;
 
if (IS_ABSOLUTE_PATH(Z_STRVAL_P(inc_filename),
Z_STRLEN_P(inc_filename))) {
cwd_state state;
+   int virtfile_res = 0;

state.cwd_length = 0;
state.cwd = malloc(1);
state.cwd[0] = 0;
 
-   failure_retval = 
(!virtual_file_ex(&state,
Z_STRVAL_P(inc_filename), NULL, 1) &&
+   virtfile_res = !virtual_file_ex(&state, 
Z_STRVAL_P(inc_filename),
NULL, 1);
+   failure_retval = (virtfile_res &&

zend_hash_exists(&EG(included_files), state.cwd,
state.cwd_length+1));
+
+   if (virtfile_res && !failure_retval && 
(state.cwd[0] != 0)) {
+   realfilepath = 
estrdup(state.cwd);
+   }
 
free(state.cwd);
}
 
if (failure_retval) {
/* do nothing */
+   } else if (realfilepath) {
+   /* file is a absolute file name and 
virtual_file_ex succeeded */
+   int type =
(Z_LVAL(opline->op2.u.constant)==ZEND_INCLUDE_ONCE?ZEND_INCLUDE:ZEND_REQUIRE);
+   file_handle.filename = realfilepath;
+   file_handle.free_filename = 0;
+   file_handle.type = ZEND_HANDLE_FILENAME;
+   file_handle.opened_path = NULL;
+   file_handle.handle.fp = NULL;
+
+   new_op_array = 
zend_compile_file(&file_handle, type TSRMLS_CC);
+   if (!file_handle.opened_path) {
+   file_handle.opened_path = 
estrndup(realfilepath,
strlen(realfilepath));
+   }
+   if 
(zend_hash_add_empty_element(&EG(included_files),
file_handle.opened_path, strlen(file_handle.opened_path)+1)==SUCCESS) {
+   
zend_destroy_file_handle(&file_handle TSRMLS_CC);
+   } else {
+   
zend_file_handle_dtor(&file_handle);
+   failure_retval=1;
+   }
+   efree(realfilepath);
} else if (SUCCESS == 
zend_stream_open(Z_STRVAL_P(i

#47660 [Asn]: open/close can be reduced for require_once in ZEND_INCLUDE_OR_EVAL handlers

2009-03-31 Thread basant dot kukreja at gmail dot com
 ID:   47660
 User updated by:  basant dot kukreja at gmail dot com
 Reported By:  basant dot kukreja at gmail dot com
 Status:   Assigned
 Bug Type: Performance problem
 Operating System: *
 PHP Version:  5.2.9
 Assigned To:  dmitry
 New Comment:

Here is the performance data collected :
For 30 minute 8 core measurement :
Before this patch :
__open 285.019 sec (Inclusive system time):

After this patch :
__open 124.747 sec (Inclusive system time):

So with submitted patch, specweb ecommerce benchmark spent 160 second
less
time.


Previous Comments:


[2009-03-15 04:03:06] basant dot kukreja at gmail dot com

Why do php does so? Reason is obvious. For included_once files, php
engine has
to make sure that files are included only once. A script can include a
file
e.g
include_once "file1.php"
include_once "file2.php"

If file2.php is just a symlink to file1.php, it should not be included
more
than once. So to assure that php engine calles zend_stream_open which
will
eventually find the real path of the file and open the file.

However, if file is an absolute file then virtual_file_ex already finds
the
real path so we can have a performance optimization for absolute
paths.

Here is my suggested patch :

--
diff -r f55e0053325c php-5.2.9RC3/Zend/zend_vm_def.h
--- a/php-5.2.9RC3/Zend/zend_vm_def.h   Wed Mar 11 12:43:20 2009 -0700
+++ b/php-5.2.9RC3/Zend/zend_vm_def.h   Sat Mar 14 20:26:27 2009 -0700
@@ -2851,22 +2851,49 @@
case ZEND_INCLUDE_ONCE:
case ZEND_REQUIRE_ONCE: {
zend_file_handle file_handle;
+   char* realfilepath = NULL;
 
if (IS_ABSOLUTE_PATH(Z_STRVAL_P(inc_filename),
Z_STRLEN_P(inc_filename))) {
cwd_state state;
+   int virtfile_res = 0;

state.cwd_length = 0;
state.cwd = malloc(1);
state.cwd[0] = 0;
 
-   failure_retval = 
(!virtual_file_ex(&state,
Z_STRVAL_P(inc_filename), NULL, 1) &&
+   virtfile_res = !virtual_file_ex(&state, 
Z_STRVAL_P(inc_filename),
NULL, 1);
+   failure_retval = (virtfile_res &&

zend_hash_exists(&EG(included_files), state.cwd,
state.cwd_length+1));
+
+   if (virtfile_res && !failure_retval && 
(state.cwd[0] != 0)) {
+   realfilepath = 
estrdup(state.cwd);
+   }
 
free(state.cwd);
}
 
if (failure_retval) {
/* do nothing */
+   } else if (realfilepath) {
+   /* file is a absolute file name and 
virtual_file_ex succeeded */
+   int type =
(Z_LVAL(opline->op2.u.constant)==ZEND_INCLUDE_ONCE?ZEND_INCLUDE:ZEND_REQUIRE);
+   file_handle.filename = realfilepath;
+   file_handle.free_filename = 0;
+   file_handle.type = ZEND_HANDLE_FILENAME;
+   file_handle.opened_path = NULL;
+   file_handle.handle.fp = NULL;
+
+   new_op_array = 
zend_compile_file(&file_handle, type TSRMLS_CC);
+   if (!file_handle.opened_path) {
+   file_handle.opened_path = 
estrndup(realfilepath,
strlen(realfilepath));
+   }
+   if 
(zend_hash_add_empty_element(&EG(included_files),
file_handle.opened_path, strlen(file_handle.opened_path)+1)==SUCCESS) {
+   
zend_destroy_file_handle(&file_handle TSRMLS_CC);
+   } else {
+   
zend_file_handle_dtor(&file_handle);
+   failure_retval=1;
+   }
+   efree(realfilepath);
} else if (SUCCESS == 
zend_stream_open(Z_STRVAL_P(inc_filename),
&file_handle TSRMLS_CC)) {
 
if (!file_handle.opened_path) {
--

As I submitted the test case, it works fine for include_once of
multiple f

#47462 [Com]: [chm] bug on function.pspell-check.html

2009-03-31 Thread todd at magnifisites dot com
 ID:   47462
 Comment by:   todd at magnifisites dot com
 Reported By:  esigners_daily at yahoo dot com
 Status:   No Feedback
 Bug Type: *General Issues
 Operating System: windows
 PHP Version:  5.3.0beta1
 New Comment:

This bug is set to a "No Feedback" status right now which doesn't seem
to mean it is not open ... a pre-cursor to my comments :)

I am quite certain it the issue here is the aspell binary running on
the Windows platform.  The latest version of the bundled aspell dll in
the PHP Windows distribution fails with the following Application error
code when executing a script via the Apache http server:

Faulting application httpd.exe, version 2.2.8.0, faulting module
aspell-15.dll, version 0.0.0.0, fault address 0x0008cef6.

I tested this on Apache 2.2.10.0 and PHP 5.2.8 for Windows with the
same results.

Running a script from the command line:
php -f pspell.php
returns a similar error:

Faulting application php.exe, version 5.2.9.9, faulting module
aspell-15.dll, version 0.0.0.0, fault address 0x0008cef2.

Here we attempted to use the latest Windows 5.2.9.9 download
unsuccessfully.


Previous Comments:


[2009-02-28 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2009-02-20 11:15:31] der...@php.net

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.




[2009-02-20 11:12:05] esigners_daily at yahoo dot com

Description:


http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml";>


Untitled Document





click












-- 
Edit this bug report at http://bugs.php.net/?id=47462&edit=1



#19022 [Com]: PHP Warning: Failed to write session data (files)

2009-03-31 Thread prikid at gmail dot com
 ID:   19022
 Comment by:   prikid at gmail dot com
 Reported By:  phpbugs at mx4k dot com
 Status:   No Feedback
 Bug Type: Session related
 Operating System: linux (rh7.3), apache 1.3.26
 PHP Version:  4.2.2
 New Comment:

We are currently getting the same error on 2 different enviroments.
This does not happen all the time, but often enough to be an annoyance
during testing.

Environment as follows:
1. FreeBSD 6.2-RELEASE 
[r...@crossbow /]# cat /usr/local/etc/php.ini | grep "session"

session.save_handler = files
session.save_path = "/var/tmp"
session.use_cookies = 1

[r...@crossbow /]# php -v
PHP 5.2.9 with Suhosin-Patch 0.9.7 (cli) (built: Mar 31 2009 12:24:17)

Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
[r...@crossbow /var/www/branches]# apachectl -v
Server version: Apache/2.0.63
Server built:   Apr 16 2008 16:52:47

---
2. Red Hat Enterprise Linux ES 4

[r...@131080-stagingdb /]# cat /etc/php.ini |grep "session"
session.save_handler = files
session.save_path = "/var/lib/php/session"
session.use_cookies = 1

[r...@131080-stagingdb /]# php -v
PHP 5.2.9 (cli) (built: Feb 27 2009 14:38:59) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
[r...@131080-stagingdb logs]# apachectl -v
Server version: Apache/2.0.52
Server built:   Jun 29 2007 05:07:13


Previous Comments:


[2008-02-28 17:50:49] ras...@php.net

session.save_path = "0;\tmp"

??  What is 0;\tmp supposed to mean?



[2008-02-28 12:04:47] m1ckx at hotmail dot com

I too am getting similar messages - essentially where the session file
is failing to create.  Unfortunately I am getting it all the time, which
is a problem as I am trying to teach myself PHP at home.

What is different for me is that I am running a Windows 2K server,
using IIS, and PHP 5.2.2.

The initial error I get at the first session_start() call is:
The description for Event ID ( 2 ) in Source ( PHP-5.2.2 ) cannot be
found. The local computer may not have the necessary registry
information or message DLL files to display messages from a remote
computer. The following information is part of the event: php[352], PHP
Warning:  session_start() [function.session-start]:
open(\tmp\sess_8t6afg6omu4au9ofqnru80l6r5, O_RDWR) failed: No such file
or directory (2) in F:\MixWeb\mdroot\php_sandpit\ch10\login.php on line
60.

The extract of my php.ini is:
[Session]

session.save_handler = files

session.save_path = "0;\tmp"

session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /

Having been trying to search down answers for this but so far no luck.



[2008-01-19 22:07:24] ozdemir_e at yahoo dot com

I have been getting the same error...

in php.ini file i have set the session.save_path to
public_html/cgi-bin/session

And the chmod of the session folder is 777

Everything looks fine technically but even if that... i get this
error.

I really need help to figure out this issue and fix it. And the hosting
company that i work with they insist on saying that it is not a server
error. But I do not understand that even if the chomod of the
session.save_path pointing to the correct folder and chmod 777, I am
getting this error.

PHP Warning:  session_start() [function.session-staPHP Warning: 
session_start() [function.session-start]:
open(/home/users/web/b469/as.x/sess_164a72ebe9813cc1b0341ad6f6edbc8a,
O_RDWR) failed: Read-only file system (30) in
/hermes/web03/b469/as./public_html/admin/index.php on line 31
PHP Warning:  Unknown(): Failed to write session data (files). Please
verify that the current setting of session.save_path is correct
(/home/users/web/b469/as.yuvamemlak/public_html/cgi-bin/session) in
Unknown on line 0


thank you in advance



[2007-12-28 23:45:50] allan at emeraldforest dot com

I have been experiencing the same (or very similar) problem. One
interesting thing that I found is that sometimes I can reload page A and
see the session data happily sitting there, but on page B the data is
not there. I have both pages open in tabs in Firefox and I can go back
and forth reloading the pages. Page A always has the data, page B never
does. Both pages require the same init.php script to start the session.



[2007-01-03 21:49:22] stranger at teuton dot org

I just started encountering this problem today, after having upgraded
to PHP5 from a PHP4 app. As with some of the other reports I have some
users reporting constant problems, while others have no problems at
all.

I using Linux, with session files written to /t

#47854 [NEW]: Bug on explode limit.

2009-03-31 Thread disas at mail dot ru
From: disas at mail dot ru
Operating system: Windows Vista SP1
PHP version:  5.2.9
PHP Bug Type: Strings related
Bug description:  Bug on explode limit.

Description:

Bug on result where negative or positive number of limit is very high.

Reproduce code:
---
#Code:

var_export(
explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ", -1e99)
);

#Result:
array (
  0 => ' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ',
);

#Code:

var_export(
explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ", -1e9)
);

#Result:
array (
)

Expected result:

array (
  0 => ' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ',
);

Actual result:
--
I think that in both cases the result should be:
array(
)

-- 
Edit bug report at http://bugs.php.net/?id=47854&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47854&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47854&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47854&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47854&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47854&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47854&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47854&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47854&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47854&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47854&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47854&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47854&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47854&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47854&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47854&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47854&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47854&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47854&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47854&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47854&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47854&r=mysqlcfg



#47660 [Opn->Asn]: open/close can be reduced for require_once in ZEND_INCLUDE_OR_EVAL handlers

2009-03-31 Thread johannes
 ID:   47660
 Updated by:   johan...@php.net
 Reported By:  basant dot kukreja at gmail dot com
-Status:   Open
+Status:   Assigned
 Bug Type: Performance problem
 Operating System: *
 PHP Version:  5.2.9
-Assigned To:  
+Assigned To:  dmitry


Previous Comments:


[2009-03-15 04:03:06] basant dot kukreja at gmail dot com

Why do php does so? Reason is obvious. For included_once files, php
engine has
to make sure that files are included only once. A script can include a
file
e.g
include_once "file1.php"
include_once "file2.php"

If file2.php is just a symlink to file1.php, it should not be included
more
than once. So to assure that php engine calles zend_stream_open which
will
eventually find the real path of the file and open the file.

However, if file is an absolute file then virtual_file_ex already finds
the
real path so we can have a performance optimization for absolute
paths.

Here is my suggested patch :

--
diff -r f55e0053325c php-5.2.9RC3/Zend/zend_vm_def.h
--- a/php-5.2.9RC3/Zend/zend_vm_def.h   Wed Mar 11 12:43:20 2009 -0700
+++ b/php-5.2.9RC3/Zend/zend_vm_def.h   Sat Mar 14 20:26:27 2009 -0700
@@ -2851,22 +2851,49 @@
case ZEND_INCLUDE_ONCE:
case ZEND_REQUIRE_ONCE: {
zend_file_handle file_handle;
+   char* realfilepath = NULL;
 
if (IS_ABSOLUTE_PATH(Z_STRVAL_P(inc_filename),
Z_STRLEN_P(inc_filename))) {
cwd_state state;
+   int virtfile_res = 0;

state.cwd_length = 0;
state.cwd = malloc(1);
state.cwd[0] = 0;
 
-   failure_retval = 
(!virtual_file_ex(&state,
Z_STRVAL_P(inc_filename), NULL, 1) &&
+   virtfile_res = !virtual_file_ex(&state, 
Z_STRVAL_P(inc_filename),
NULL, 1);
+   failure_retval = (virtfile_res &&

zend_hash_exists(&EG(included_files), state.cwd,
state.cwd_length+1));
+
+   if (virtfile_res && !failure_retval && 
(state.cwd[0] != 0)) {
+   realfilepath = 
estrdup(state.cwd);
+   }
 
free(state.cwd);
}
 
if (failure_retval) {
/* do nothing */
+   } else if (realfilepath) {
+   /* file is a absolute file name and 
virtual_file_ex succeeded */
+   int type =
(Z_LVAL(opline->op2.u.constant)==ZEND_INCLUDE_ONCE?ZEND_INCLUDE:ZEND_REQUIRE);
+   file_handle.filename = realfilepath;
+   file_handle.free_filename = 0;
+   file_handle.type = ZEND_HANDLE_FILENAME;
+   file_handle.opened_path = NULL;
+   file_handle.handle.fp = NULL;
+
+   new_op_array = 
zend_compile_file(&file_handle, type TSRMLS_CC);
+   if (!file_handle.opened_path) {
+   file_handle.opened_path = 
estrndup(realfilepath,
strlen(realfilepath));
+   }
+   if 
(zend_hash_add_empty_element(&EG(included_files),
file_handle.opened_path, strlen(file_handle.opened_path)+1)==SUCCESS) {
+   
zend_destroy_file_handle(&file_handle TSRMLS_CC);
+   } else {
+   
zend_file_handle_dtor(&file_handle);
+   failure_retval=1;
+   }
+   efree(realfilepath);
} else if (SUCCESS == 
zend_stream_open(Z_STRVAL_P(inc_filename),
&file_handle TSRMLS_CC)) {
 
if (!file_handle.opened_path) {
--

As I submitted the test case, it works fine for include_once of
multiple files
whose names are different but their real paths are actually same.



[2009-03-15 03:53:56] basant dot kukreja at gmail dot com

Description:

There are few ways to include a file. include

#47809 [Fbk->Opn]: PHP doesn't parse the php.ini file

2009-03-31 Thread privat at timohummel dot com
 ID:   47809
 User updated by:  privat at timohummel dot com
 Reported By:  privat at timohummel dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PHP options/info functions
 Operating System: Gentoo
 PHP Version:  5.3.0RC1
 Assigned To:  pajoye
 New Comment:

Okay, the issue seems to be resolved - but in the meanwhile I
downgraded my whole system to 4.1.2; maybe there was some problem caused
by the compiler? I was running gcc-4.3.3 previously.

By the way, my configure line looks odd since it is a gentoo ebuild -
it needs to disable virtually everything in order to enable the user to
add features by the USE flag.

I think we can close this bug now; but maybe someone can re-test with
gcc-4.3.3 again?


Previous Comments:


[2009-03-31 07:18:36] j...@php.net

To make this a bit simpler, delete that file and create one with only 
this:

include_path = "foo/bar"

Then check what phpinfo() says in apache about the include_path.
Note: this works fine for me..

Also, your configure line is kinda odd. Using --disable-all and only 
enabling what you really need would make the line quite more 
readable..





[2009-03-30 18:53:47] privat at timohummel dot com

It is the stock php.ini-development file, where I tried to set the
default timezone to "Europe/Berlin". As it didn't work, I reverted my
change of the timezone and tried modifying other values, for example,
the error reporting and also simple values like "precision". None of my
changes were shown after a restart of apache using the phpinfo()-call.

As I said before, changes are accepted when using the cli sapi.



[2009-03-30 18:07:19] j...@php.net

What exactly is in that file?



[2009-03-27 19:02:25] privat at timohummel dot com

I just ran apache with strace to make sure that the php.ini file is
actually opened. It is opened, but I'm not sure how to debug if the
values are getting parsed and probably overwritten later or if the
values in the php.ini file are silently ignored.



[2009-03-27 16:11:27] privat at timohummel dot com

I rebuilt PHP from the CVS, snapshot
http://snaps.php.net/php5.3-200903271530.tar.bz2 (latest snapshot
currently available). The issue remains, all php.ini-entries are ignored
silently when using the apache2 SAPI.

Oddly enough, the CLI SAPI works fine and reads the config file as
expected.

Here's my configure line:
'./configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu'
'--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info'
'--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64'
'--disable-cli' '--with-apxs2=/usr/sbin/apxs2' '--disable-cgi'
'--with-config-file-path=/etc/php/apache2-php5'
'--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active'
'--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar'
'--with-curl' '--without-curlwrappers' '--disable-dbase'
'--disable-exif' '--without-fbsql' '--disable-fileinfo' '--enable-ftp'
'--with-gettext' '--with-gmp' '--disable-hash' '--without-kerberos'
'--enable-mbstring' '--with-mcrypt' '--without-mhash' '--without-msql'
'--without-mssql' '--with-openssl' '--with-openssl-dir=/usr'
'--disable-pcntl' '--with-pgsql' '--disable-posix' '--with-pspell'
'--without-recode' '--disable-simplexml' '--disable-shmop' '--with-snmp'
'--enable-soap' '--disable-sockets' '--without-sybase-ct'
'--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm'
'--with-tidy' '--enable-wddx' '--disable-xmlreader'
'--disable-xmlwriter' '--with-xmlrpc' '--with-xsl' '--enable-zip'
'--with-zlib' '--disable-debug' '--enable-dba' '--without-cdb'
'--with-db4' '--disable-flatfile' '--with-gdbm' '--disable-inifile'
'--without-qdbm' '--with-freetype-dir=/usr' '--with-t1lib=/usr'
'--disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr'
'--with-xpm-dir=/usr' '--with-gd' '--with-imap' '--with-imap-ssl'
'--with-mysql=/usr' '--with-mysql-sock=/var/run/mysqld/mysqld.sock'
'--with-mysqli=/usr/bin/mysql_config' '--without-pdo-dblib'
'--with-pdo-mysql=/usr' '--without-pdo-odbc' '--with-pdo-pgsql'
'--with-pdo-sqlite=/usr' '--with-readline' '--without-libedit'
'--without-mm' '--with-sqlite=/usr' '--enable-sqlite-utf8'
'--with-sqlite3'



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/47809

-- 
Edit this bug report at http://bugs.php.net/?id=47809&edit=1



#47730 [Fbk->Ana]: PHP crashes when errorHandler throws Exception

2009-03-31 Thread scottmac
 ID:   47730
 Updated by:   scott...@php.net
 Reported By:  berblinger at krumedia dot de
-Status:   Feedback
+Status:   Analyzed
 Bug Type: Reproducible crash
 Operating System: Linux
 PHP Version:  5.2.9
 New Comment:

This is a bug in the GCC 4.3 optimizer, A -O1 build works fine but a
-O2 fails.

Gentoo have an open bug for this http://bugs.gentoo.org/234177

The test that fails is Zend/tests/bug31177.phpt

Maybe someone else with a better understanding of the optimizer can
look at this.


Previous Comments:


[2009-03-31 16:19:15] mk at krumedia dot de

Scott, do you have any results or patches, already?



[2009-03-26 16:17:01] scott...@php.net

You can just drop me an email with the details.

My public key is at http://whisky.macvicar.net/scott-public-key.txt



[2009-03-26 16:04:25] berblinger at krumedia dot de

I could manage to get you an account on a newly set up server,
configured with nothing else that debian 5.0, PHP 5.2.9 and no other
third party php extention for a maximum of 2 days on the upcoming
friday.

We just got two new servers at our computer center. Please tell me if
you can take a look at the weekend (friday till sunday maximum) and how
i should provide the account informations to you. Thanks in advance.



[2009-03-25 14:03:05] tombt081981 at hotmail dot com

This information might help:

I got the bug with php 5.2.9 and(!) php 5.2.6 after(!) an upgrade to
Bebian lenny 5.0. Before (debian 4) it worked fine, so this got to do
something with Debian 5 and not especially with php 5.2.9.



[2009-03-25 11:41:15] scott...@php.net

Can you do

./configure --disable-all --enable-debug

And run the script through valgrind as well as through gdb.

If that fails then getting access to an account on the server might be
the easiest solution.



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/47730

-- 
Edit this bug report at http://bugs.php.net/?id=47730&edit=1



#47730 [Com]: PHP crashes when errorHandler throws Exception

2009-03-31 Thread mk at krumedia dot de
 ID:   47730
 Comment by:   mk at krumedia dot de
 Reported By:  berblinger at krumedia dot de
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Linux
 PHP Version:  5.2.9
 New Comment:

Scott, do you have any results or patches, already?


Previous Comments:


[2009-03-26 16:17:01] scott...@php.net

You can just drop me an email with the details.

My public key is at http://whisky.macvicar.net/scott-public-key.txt



[2009-03-26 16:04:25] berblinger at krumedia dot de

I could manage to get you an account on a newly set up server,
configured with nothing else that debian 5.0, PHP 5.2.9 and no other
third party php extention for a maximum of 2 days on the upcoming
friday.

We just got two new servers at our computer center. Please tell me if
you can take a look at the weekend (friday till sunday maximum) and how
i should provide the account informations to you. Thanks in advance.



[2009-03-25 14:03:05] tombt081981 at hotmail dot com

This information might help:

I got the bug with php 5.2.9 and(!) php 5.2.6 after(!) an upgrade to
Bebian lenny 5.0. Before (debian 4) it worked fine, so this got to do
something with Debian 5 and not especially with php 5.2.9.



[2009-03-25 11:41:15] scott...@php.net

Can you do

./configure --disable-all --enable-debug

And run the script through valgrind as well as through gdb.

If that fails then getting access to an account on the server might be
the easiest solution.



[2009-03-25 11:32:49] berblinger at krumedia dot de

This segfault is also caused when any 3rd party modules are disabled.
As already said, we got several servers with very similar hardware and
OS ( including configuration ) and each of them makes PHP crash with
this snippet.

We recently upgraded from PHP 5.2.6 to PHP 5.2.9 and since this upgrade
we noticed this segfault.

Can i provide any other informations for you to help you fixing this
bug?



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/47730

-- 
Edit this bug report at http://bugs.php.net/?id=47730&edit=1



#47852 [NEW]: Compilation failure in zend_alloc.c

2009-03-31 Thread mbecc...@php.net
From: mbecc...@php.net
Operating system: NetBSD 5
PHP version:  5.3CVS-2009-03-31 (CVS)
PHP Bug Type: Compile Failure
Bug description:  Compilation failure in zend_alloc.c

Description:

NetBSD 5 introduced mremap() but the signature is different from what we
expect.

>From man remap:

COMPATIBILITY
 The semantics of mremap() differ from the one provided by glibc on
Linux
 in that the newp argument was added and a different set of flags are
 implemented.


A patch is available here:
http://www.beccati.com/misc/php/zend_alloc_netbsd.diff

NetBSD 4 compiles without any problem because mremap is not available.


-- 
Edit bug report at http://bugs.php.net/?id=47852&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47852&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47852&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47852&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47852&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47852&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47852&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47852&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47852&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47852&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47852&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47852&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47852&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47852&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47852&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47852&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47852&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47852&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47852&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47852&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47852&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47852&r=mysqlcfg



#43313 [Opn]: getopt() doesn't handle unknown parameters

2009-03-31 Thread hradtke
 ID:   43313
 Updated by:   hrad...@php.net
 Reported By:  RQuadling at GMail dot com
 Status:   Open
 Bug Type: CGI related
 Operating System: *
 PHP Version:  5CVS-2008-11-11
 New Comment:

I have a patch for this bug.  Actually, I am not sure this is even a
bug.  POSIX says that getopt should break on the first non-option. 
Also, the php_getopt() function needs to break on the first non-option. 
Consider the following: php -n test.php -a 1 -b 2

That being said, the getopt() userspace function can be made to work
both ways.  I have a patch to allow php_getopt() to ignore unknown
parameters.  

One question: Should getopt() have its prototype changed to: array
getopt  ( string $options  [, array $longopts, bool posix ] ) ? It would
default to true if not specified (for BC).  Setting it to false would
make it ignore non-options.




Previous Comments:


[2009-01-22 01:14:01] j...@php.net

Deassigning since Hannes apparently has no idea how to fix this.



[2008-11-11 11:08:09] j...@php.net

Still fails after a year without response from Hannes.



[2008-11-02 13:13:49] j...@php.net

Hannes, are you doing something about this?



[2007-11-16 15:18:00] RQuadling at GMail dot com

Description:

getopt() stops processing at the first unknown parameter.

I'm not sure if this is ...

a php bug - getopt should return them as is

or ...

a doc bug - getopt() will cease operation at the first hurdle.



My preference is to return them as is. Maybe a third param to the
function to collect unknown parameters. This would provide backward
compatibility if the function didn't die when an unknown parameter was
reached.




The code is a simple test to examine the command line.

Run this with this parameter

-a 1

and then with these

broken -a 1


Reproduce code:
---


Expected result:

array(3) {
  [0]=>
  string(17) "C:\phpargtest.php"
  [1]=>
  string(2) "-a"
  [2]=>
  string(1) "1"
}
array(1) {
  ["a"]=>
  string(1) "1"
}

array(4) {
  [0]=>
  string(17) "C:\phpargtest.php"
  [1]=>
  string(6) "broken"
  [2]=>
  string(2) "-a"
  [3]=>
  string(1) "1"
}
array(1) {
  [0]=>
  string(6) "broken"
  ["a"]=>
  string(1) "1"
}


Actual result:
--
array(3) {
  [0]=>
  string(17) "C:\phpargtest.php"
  [1]=>
  string(2) "-a"
  [2]=>
  string(1) "1"
}
array(1) {
  ["a"]=>
  string(1) "1"
}

array(4) {
  [0]=>
  string(17) "C:\phpargtest.php"
  [1]=>
  string(6) "broken"
  [2]=>
  string(2) "-a"
  [3]=>
  string(1) "1"
}
array(0) {
}





-- 
Edit this bug report at http://bugs.php.net/?id=43313&edit=1



#47851 [NEW]: is_callable throws fatal error

2009-03-31 Thread mbecc...@php.net
From: mbecc...@php.net
Operating system: Irrelevant
PHP version:  5.3CVS-2009-03-31 (CVS)
PHP Bug Type: Class/Object related
Bug description:  is_callable throws fatal error

Description:

Under some circumstances is_callable() throws a fatal error when testing
if the PHP4-style constructor of the class (e.g. is_callable(array('test1',
'test1')).

Unfortunately I wasn't able to create a self-contained example, but the
issue seems to happen often when using Simpletest Mocks in the OpenX test
suite.

It's ok if is_callable returns false if the method cannot be called
statically, but definitely a fatal error isn't expected.

Reproduce code:
---
echo "Test";
is_callable(array('OX_Dal_Maintenance_Statistics',
'OX_Dal_Maintenance_Statistics'));

Expected result:

Test

Actual result:
--
Test
Fatal error: Non-static method
OX_Dal_Maintenance_Statistics::OX_Dal_Maintenance_Statistics() cannot be
called statically in ...

-- 
Edit bug report at http://bugs.php.net/?id=47851&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47851&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47851&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47851&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47851&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47851&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47851&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47851&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47851&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47851&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47851&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47851&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47851&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47851&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47851&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47851&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47851&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47851&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47851&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47851&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47851&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47851&r=mysqlcfg



#31323 [Com]: session file permissions differ randomly

2009-03-31 Thread prikid at gmail dot com
 ID:   31323
 Comment by:   prikid at gmail dot com
 Reported By:  julien dot mathieu at gmail dot com
 Status:   No Feedback
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  5.1.2, 4.3.9
 New Comment:

We are experiencing similar problem with php 5.2.6 on freebsd and red
hat linux


Previous Comments:


[2008-08-12 16:21:03] linus dot norton at assertis dot co dot uk

I have also encountered this twice on redhat running apache 2.2.6 and
php 5.2.6.

Why has this been closed, no feedback was requested then the ticket is
just closed saying no feedback has been given.



[2006-11-09 14:44:35] mg at iceni dot pl

I can confirm this bug happening on php 4.4.2 build as apache 2 (with
prefork) module. It's extremaly difficult to reproduce, but with little
research it seems to be somehow umask related. 

The following is from strace running on a apache process that creates
the files with wrong permissions 

open("/tmp/sess_5b2929b94cf141335d0b2d1e5a38fc29", O_RDWR|O_CREAT,
0600) = 186
fstat64(186, {st_mode=S_IFREG|0400, st_size=0, ...}) = 0

So php creates file with 600 permissions but it has only 400 in final.
Note that's happening very rarely, normally file is created with 600. 

I didn't have luck tracing how and when umask is changing during
request processing (probably something is changing it prior to the
request, so possibly it's not even php related), but I tried to make the
following very dirty workaround in ext/session/mod_files.c:


@@ -138,6 +138,7 @@
 static void ps_files_open(ps_files *data, const char *key TSRMLS_DC)
 {
char buf[MAXPATHLEN];
+   mode_t orig_mask;

if (data->fd < 0 || !data->lastkey || strcmp(key,
data->lastkey)) {
if (data->lastkey) {
@@ -156,8 +157,10 @@

data->lastkey = estrdup(key);

+   orig_mask = umask(0);
data->fd = VCWD_OPEN_MODE(buf, O_CREAT | O_RDWR |
O_BINARY, 0600);
-
+   umask(orig_mask);
+

No matter how ugly it is - it seems to do the job and session files
with wrong permissions are no longer created (this workaround is
probably bad idea on threaded severs though).



[2006-11-05 00:16:32] bclaydon at volved dot com

To provide further details, I am also using Debian (Sarge) with the
latest 4.3.10-16 PHP4 package.

My /var/liv/php4 looks exactly as 'pieter at q-go dot com' mentioned:

drwx-wx-wt   2 root root 4.0K 2006-11-04 18:58 ./
drwxr-xr-x  35 root root 4.0K 2006-09-08 19:11 ../
-rw---   1 www-data www-data   77 2006-11-04 18:58
sess_7b8da94a2febce75775d9082cd20d58d
-rw---   1 www-data www-data  116 2006-11-04 19:05
sess_856401c969cc1d4e68b6ffd75457c743
-rw---   1 www-data www-data  116 2006-11-04 18:58
sess_b5419618a3586b7e3b940a0eaf137fb9
-rw---   1 www-data www-data  116 2006-11-04 19:09
sess_f7d957b726ff923b4b1f6178f8db489f


I am seeing this issue fairly frequently during usage of CakePHP
framework which has fairly detailed usage of session functions.

I hope this is resolved at some point, especially if it is still open
as of 5.2.0



[2006-05-22 09:20:29] pieter at q-go dot com

We have similar problems on Debian with PHP 5.1.2 and 5.1.4.

Sessions are all created with correct permissions, but we get the same
permission denied error in 5% of the cases.

drwx-wx-wt   2 root root 4096 May 22 11:03 .
drwxr-xr-x  27 root root 4096 May 18 13:44 ..
-rw---   1 www-data www-data0 May 22 11:03
sess_11f06ca5b4701f4be8be30b275e4e51e
-rw---   1 www-data www-data 1569 May 22 11:00
sess_1856e3c4630f074a1b0490c4792c3e53
-rw---   1 www-data www-data0 May 22 10:21
sess_d110fb48e440d1ec4ac610243e897c69
-rw---   1 www-data www-data 1717 May 22 11:05
sess_f9668179e8a92714f4d9553504bdcd93

Changing the default Debian permissions on /var/lib/php5 from
drwx-wx-wt to drwxrwxrwt seems to help.

I am putting this here because if the two cases are related, the
problem might be more general.



[2006-03-28 13:15:10] m...@php.net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





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
 

#47365 [Asn->Opn]: ip2long: 32bis vs. 64bit!

2009-03-31 Thread jani
 ID:   47365
 Updated by:   j...@php.net
-Summary:  ip2long: 32bit vs. 64bit
 Reported By:  flobee at gmail dot com
-Status:   Assigned
+Status:   Open
-Bug Type: Network related
+Bug Type: *Network Functions
 Operating System: SunOS
-PHP Version:  5.2.9RC1
+PHP Version:  5.2.9
 Assigned To:  dsp


Previous Comments:


[2009-03-26 01:22:34] pada at hrz dot tu-chemnitz dot de

Hi,

I can confirm the bug on Solaris (not OpenSolaris) Version 10 x86_64

# isainfo -b
64
# uname -srvmpi
SunOS 5.10 Generic_118855-33 i86pc i386 i86pc

# Results with unpatched 64 Bit PHP 5.2.8:

# php5 -r "var_dump(ip2long('example.com'));"
int(4294967295) # WRONG, should be bool(false), this is not a valid IP
# php5 -r "var_dump(ip2long(\"1\x00x\"));"
int(1) # correct?
# php5 -r "var_dump(ip2long('0.1'));"
int(1) # correct?
# php5 -r "var_dump(ip2long(''));"
bool(false) # correct
# php5 -r "var_dump(ip2long('0.0.0.0'));"
int(0) # correct
# php5 -r "var_dump(ip2long('0.0.0.1'));"
int(1) # correct
# php5 -r "var_dump(ip2long('1.2.3.4'));"
int(16909060) # correct
# php5 -r "var_dump(ip2long('4.3.2.1'));"
int(67305985) # correct
# php5 -r "var_dump(ip2long('255.255.255.254'));"
int(4294967294) # correct
# php5 -r "var_dump(ip2long('255.255.255.255'));"
int(4294967295) # correct

There is a problem in PHP function ip2long() with the comparison with
INADDR_NONE on 64 bit Solaris systems, since the return value of
function inet_addr is stored in an "unsigned long int" variable while
struct inet_addr is only 32 bit wide.  The "RETURN_FALSE" branch will
never be reached when a string like "example.com" is supplied, since the
comparison of ip and INADDR_NONE evaluates to false (it should be true
in case of error).

# Patch worked as expected on Debian GNU/Linux squeeze x86_64 with PHP
5.2.6:

# php5 -r "var_dump(ip2long('example.com'));"
bool(false) # correct
# php5 -r "var_dump(ip2long(\"1\x00x\"));"
int(1) # correct?
# php5 -r "var_dump(ip2long('0.1'));"
int(1) # correct?
# php5 -r "var_dump(ip2long(''));"
bool(false) # correct
# php5 -r "var_dump(ip2long('0.0.0.0'));"
int(0) # correct
# php5 -r "var_dump(ip2long('0.0.0.1'));"
int(1) # correct
# php5 -r "var_dump(ip2long('1.2.3.4'));"
int(16909060) # correct
# php5 -r "var_dump(ip2long('4.3.2.1'));"
int(67305985) # correct
# php5 -r "var_dump(ip2long('255.255.255.254'));"
int(4294967294) # correct
# php5 -r "var_dump(ip2long('255.255.255.255'));"
int(4294967295) # correct

I propose the following patch to simplify the code and fix the problem
at the same time.  Will this code work on all platforms (Linux, Solaris,
BSD, Windows, etc.)?  Your hints and suggestions are welcome.

 start of patch 
diff -ru php-5.2.9.orig/ext/standard/basic_functions.c
php-5.2.9/ext/standard/basic_functions.c
--- php-5.2.9.orig/ext/standard/basic_functions.c 2008-12-31
12:17:44.0 +0100
+++ php-5.2.9/ext/standard/basic_functions.c  2009-03-25
19:00:15.0 +0100
@@ -97,10 +97,6 @@
 # include "win32/unistd.h"
 #endif

-#ifndef INADDR_NONE
-#define INADDR_NONE ((unsigned long int) -1)
-#endif
-
 #include "zend_globals.h"
 #include "php_globals.h"
 #include "SAPI.h"
@@ -4336,7 +4332,7 @@
 PHP_FUNCTION(ip2long)
 {
  zval **str;
- unsigned long int ip;
+ struct in_addr addr;

  if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &str) ==
FAILURE) {
WRONG_PARAM_COUNT;
@@ -4344,20 +4340,11 @@

  convert_to_string_ex(str);

- if (Z_STRLEN_PP(str) == 0 || (ip = inet_addr(Z_STRVAL_PP(str))) ==
INADDR_NONE) {
-   /* the only special case when we should return -1 ourselves,
-* because inet_addr() considers it wrong. We return 0x
and
-* not -1 or ~0 because of 32/64bit issues.
-*/
-   if (Z_STRLEN_PP(str) == sizeof("255.255.255.255") - 1 &&
- !memcmp(Z_STRVAL_PP(str), "255.255.255.255",
sizeof("255.255.255.255") - 1)) {
- RETURN_LONG(0x);
-   }
-
-   RETURN_FALSE;
- }
+  if (Z_STRLEN_PP(str) == 0 || inet_pton(AF_INET, Z_STRVAL_PP(str),
&addr) != 1) {
+RETURN_FALSE;
+  }

- RETURN_LONG(ntohl(ip));
+ RETURN_LONG(ntohl(addr.s_addr));
 }
 /* }}} */

 end of patch 

Kind regards,
Daniel



[2009-02-12 13:09:49] d...@php.net

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


Which Solaris Version. Solaris 10. On Sparc or on x86?

On OpenSolaris x86 64 bit it returns false as expected:

~/> php -r "var_dump(ip2long('web.de'));"  
   
bool(false)
~/> isainfo -b  

#47365 [Opn->Asn]: ip2long: 32bis vs. 64bit!

2009-03-31 Thread jani
 ID:   47365
 Updated by:   j...@php.net
 Reported By:  flobee at gmail dot com
-Status:   Open
+Status:   Assigned
-Bug Type: *Network Functions
+Bug Type: Network related
 Operating System: SunOS
 PHP Version:  5.2.9RC1
-Assigned To:  
+Assigned To:  dsp


Previous Comments:


[2009-03-26 01:22:34] pada at hrz dot tu-chemnitz dot de

Hi,

I can confirm the bug on Solaris (not OpenSolaris) Version 10 x86_64

# isainfo -b
64
# uname -srvmpi
SunOS 5.10 Generic_118855-33 i86pc i386 i86pc

# Results with unpatched 64 Bit PHP 5.2.8:

# php5 -r "var_dump(ip2long('example.com'));"
int(4294967295) # WRONG, should be bool(false), this is not a valid IP
# php5 -r "var_dump(ip2long(\"1\x00x\"));"
int(1) # correct?
# php5 -r "var_dump(ip2long('0.1'));"
int(1) # correct?
# php5 -r "var_dump(ip2long(''));"
bool(false) # correct
# php5 -r "var_dump(ip2long('0.0.0.0'));"
int(0) # correct
# php5 -r "var_dump(ip2long('0.0.0.1'));"
int(1) # correct
# php5 -r "var_dump(ip2long('1.2.3.4'));"
int(16909060) # correct
# php5 -r "var_dump(ip2long('4.3.2.1'));"
int(67305985) # correct
# php5 -r "var_dump(ip2long('255.255.255.254'));"
int(4294967294) # correct
# php5 -r "var_dump(ip2long('255.255.255.255'));"
int(4294967295) # correct

There is a problem in PHP function ip2long() with the comparison with
INADDR_NONE on 64 bit Solaris systems, since the return value of
function inet_addr is stored in an "unsigned long int" variable while
struct inet_addr is only 32 bit wide.  The "RETURN_FALSE" branch will
never be reached when a string like "example.com" is supplied, since the
comparison of ip and INADDR_NONE evaluates to false (it should be true
in case of error).

# Patch worked as expected on Debian GNU/Linux squeeze x86_64 with PHP
5.2.6:

# php5 -r "var_dump(ip2long('example.com'));"
bool(false) # correct
# php5 -r "var_dump(ip2long(\"1\x00x\"));"
int(1) # correct?
# php5 -r "var_dump(ip2long('0.1'));"
int(1) # correct?
# php5 -r "var_dump(ip2long(''));"
bool(false) # correct
# php5 -r "var_dump(ip2long('0.0.0.0'));"
int(0) # correct
# php5 -r "var_dump(ip2long('0.0.0.1'));"
int(1) # correct
# php5 -r "var_dump(ip2long('1.2.3.4'));"
int(16909060) # correct
# php5 -r "var_dump(ip2long('4.3.2.1'));"
int(67305985) # correct
# php5 -r "var_dump(ip2long('255.255.255.254'));"
int(4294967294) # correct
# php5 -r "var_dump(ip2long('255.255.255.255'));"
int(4294967295) # correct

I propose the following patch to simplify the code and fix the problem
at the same time.  Will this code work on all platforms (Linux, Solaris,
BSD, Windows, etc.)?  Your hints and suggestions are welcome.

 start of patch 
diff -ru php-5.2.9.orig/ext/standard/basic_functions.c
php-5.2.9/ext/standard/basic_functions.c
--- php-5.2.9.orig/ext/standard/basic_functions.c 2008-12-31
12:17:44.0 +0100
+++ php-5.2.9/ext/standard/basic_functions.c  2009-03-25
19:00:15.0 +0100
@@ -97,10 +97,6 @@
 # include "win32/unistd.h"
 #endif

-#ifndef INADDR_NONE
-#define INADDR_NONE ((unsigned long int) -1)
-#endif
-
 #include "zend_globals.h"
 #include "php_globals.h"
 #include "SAPI.h"
@@ -4336,7 +4332,7 @@
 PHP_FUNCTION(ip2long)
 {
  zval **str;
- unsigned long int ip;
+ struct in_addr addr;

  if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &str) ==
FAILURE) {
WRONG_PARAM_COUNT;
@@ -4344,20 +4340,11 @@

  convert_to_string_ex(str);

- if (Z_STRLEN_PP(str) == 0 || (ip = inet_addr(Z_STRVAL_PP(str))) ==
INADDR_NONE) {
-   /* the only special case when we should return -1 ourselves,
-* because inet_addr() considers it wrong. We return 0x
and
-* not -1 or ~0 because of 32/64bit issues.
-*/
-   if (Z_STRLEN_PP(str) == sizeof("255.255.255.255") - 1 &&
- !memcmp(Z_STRVAL_PP(str), "255.255.255.255",
sizeof("255.255.255.255") - 1)) {
- RETURN_LONG(0x);
-   }
-
-   RETURN_FALSE;
- }
+  if (Z_STRLEN_PP(str) == 0 || inet_pton(AF_INET, Z_STRVAL_PP(str),
&addr) != 1) {
+RETURN_FALSE;
+  }

- RETURN_LONG(ntohl(ip));
+ RETURN_LONG(ntohl(addr.s_addr));
 }
 /* }}} */

 end of patch 

Kind regards,
Daniel



[2009-02-12 13:09:49] d...@php.net

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


Which Solaris Version. Solaris 10. On Sparc or on x86?

On OpenSolaris x86 64 bit it returns false as expected:

~/> php -r "var_dump(ip2long('web.de'));"  
   
bool(false)
~/> isainfo -b 
   
64
~/> uname -a  

#47687 [Asn->Bgs]: header("Location:") changing HTTP status in FCGI mode.

2009-03-31 Thread jani
 ID:   47687
 Updated by:   j...@php.net
 Reported By:  make dot fire at gmail dot com
-Status:   Assigned
+Status:   Bogus
 Bug Type: HTTP related
 Operating System: windows vista
 PHP Version:  5.3CVS-2009-03-17 (snap)
 Assigned To:  pajoye
 New Comment:

Bugs in MS crap aren't bugs in PHP -> BOGUS.


Previous Comments:


[2009-03-26 23:11:37] paj...@php.net

Confirmed, it is a bug in the FastCGI. I will notice you as soon as an
update is available.



[2009-03-23 08:41:48] make dot fire at gmail dot com

yep, I think that you're right.
wait for M$ to fix it..



[2009-03-18 14:38:24] dmi...@php.net

The issue is probably caused by fastcgi module of web server. The PHP
sends proper headers, but it looks like fastcgi module sets status to
302 in case it finds "Location" header.



[2009-03-18 02:16:40] make dot fire at gmail dot com

I have tried using PHP 5.2 (5.2.10-dev), both VC6 x86 Non Thread Safe
(2009-Mar-18 00:00:00) and VC6 x86 Thread Safe (2009-Mar-18 00:00:00).
And have tried on windows vista and windows server 2008, got the same
results:

test code:

code1:
http://www.php.net/";);
exit;
?>

code2:


code3:
http://www.php.net/";);
exit;
?>

the problem only occurs when run php in fastCGI mode(using
php-cgi.exe). 
code1 produce status line:
HTTP/1.1 302 Redirect  (expected: HTTP/1.1 303 See Other)
code2 porduct status line:
HTTP/1.1 303 See Other (expected: HTTP/1.1 303 See Other)
code3 product status line:
HTTP/1.1 302 Redirect  (expected: HTTP/1.1 302 Moved Temporarily)


when run php in ISAPI mode(using php5isapi.dll) or run php-cgi.exe
under commend line, both test codes will produce expected result.

it seems that something wrong with header("Location: ") with CGI
mode...



[2009-03-17 14:30:46] make dot fire at gmail dot com

If change to ISAPI mode(use php5isapi.dll), the result is expected.

http://www.php.net/";);
exit;
?>

will got status line:

HTTP/1.1 303 See Other



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/47687

-- 
Edit this bug report at http://bugs.php.net/?id=47687&edit=1



#47687 [Ana->Asn]: header("Location:") changing HTTP status in FCGI mode.

2009-03-31 Thread jani
 ID:   47687
 Updated by:   j...@php.net
 Reported By:  make dot fire at gmail dot com
-Status:   Analyzed
+Status:   Assigned
 Bug Type: HTTP related
 Operating System: windows vista
 PHP Version:  5.3CVS-2009-03-17 (snap)
 Assigned To:  pajoye


Previous Comments:


[2009-03-26 23:11:37] paj...@php.net

Confirmed, it is a bug in the FastCGI. I will notice you as soon as an
update is available.



[2009-03-23 08:41:48] make dot fire at gmail dot com

yep, I think that you're right.
wait for M$ to fix it..



[2009-03-18 14:38:24] dmi...@php.net

The issue is probably caused by fastcgi module of web server. The PHP
sends proper headers, but it looks like fastcgi module sets status to
302 in case it finds "Location" header.



[2009-03-18 02:16:40] make dot fire at gmail dot com

I have tried using PHP 5.2 (5.2.10-dev), both VC6 x86 Non Thread Safe
(2009-Mar-18 00:00:00) and VC6 x86 Thread Safe (2009-Mar-18 00:00:00).
And have tried on windows vista and windows server 2008, got the same
results:

test code:

code1:
http://www.php.net/";);
exit;
?>

code2:


code3:
http://www.php.net/";);
exit;
?>

the problem only occurs when run php in fastCGI mode(using
php-cgi.exe). 
code1 produce status line:
HTTP/1.1 302 Redirect  (expected: HTTP/1.1 303 See Other)
code2 porduct status line:
HTTP/1.1 303 See Other (expected: HTTP/1.1 303 See Other)
code3 product status line:
HTTP/1.1 302 Redirect  (expected: HTTP/1.1 302 Moved Temporarily)


when run php in ISAPI mode(using php5isapi.dll) or run php-cgi.exe
under commend line, both test codes will produce expected result.

it seems that something wrong with header("Location: ") with CGI
mode...



[2009-03-17 14:30:46] make dot fire at gmail dot com

If change to ISAPI mode(use php5isapi.dll), the result is expected.

http://www.php.net/";);
exit;
?>

will got status line:

HTTP/1.1 303 See Other



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/47687

-- 
Edit this bug report at http://bugs.php.net/?id=47687&edit=1



#47819 [Opn->Csd]: Getting pdo_mysql.so: undefined symbol: mysqlnd_debug_init at startup

2009-03-31 Thread johannes
 ID:   47819
 Updated by:   johan...@php.net
 Reported By:  shahar dot e at zend dot com
-Status:   Open
+Status:   Closed
 Bug Type: PDO related
 Operating System: Linux i386
 PHP Version:  5.3.0RC1
 Assigned To:  mysql
 New Comment:

This bug has been fixed in CVS.

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.

Ok, so you were too fast and the snapshot you tried yesterday didn't
have the fix, yet. Closing the report.


Previous Comments:


[2009-03-31 10:40:01] shahar dot e at zend dot com

I just tried again with today's snapshot (php5.3-200903310830) and
looks like it is fixed. I no longer get the message, and pdo_mysql is
indeed loaded. 

Thanks!



[2009-03-30 14:48:56] shahar dot e at zend dot com

This still happens with the latest snapshot you linked to. 
Here are the relevant parts from sapi/cli/php -i:

PHP Version => 5.3.0RC2-dev
System => Linux wintergreen 2.6.28-gentoo-r2 #1 PREEMPT Sun Mar 8
17:10:56 IST 2009 i686
Build Date => Mar 30 2009 17:42:20
Configure Command =>  './configure'  '--disable-all' '--enable-pdo'
'--with-pdo-mysql=shared,mysqlnd' '--enable-debug'
Server API => Command Line Interface
Debug Build => yes
Thread Safety => disabled

mysqlnd

mysqlnd => enabled
Version => mysqlnd 5.0.5-dev - 081106 - $Revision: 1.3.2.22 $
Command buffer size => 2048
Read buffer size => 32768
Collecting statistics => Yes
Collecting memory statistics => No

PDO

PDO support => enabled



[2009-03-30 14:06:49] johan...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

I still didn't reproduce it but applied a patch with some guessing.
Please try the snapshot and see whether it helps.



[2009-03-30 13:15:58] johan...@php.net

Ah, the debug piece is important, investigating ...



[2009-03-30 11:59:05] shahar dot e at zend dot com

Yes, I'm building PHP from scratch with the above mentioned configure
command.

I think that in order to reproduce this you need to add --enable-debug
to your ./configure, as so (I just tried this):

$ ./configure --disable-all --enable-pdo
--with-pdo-mysql=shared,mysqlnd --enable-debug
$ make
$ sapi/cli/php -d extension_dir=modules/ -d extension=pdo_mysql.so -m
PHP Warning:  PHP Startup: Unable to load dynamic library
'modules/pdo_mysql.so' - modules/pdo_mysql.so: undefined symbol:
mysqlnd_debug_init in Unknown on line 0

I assume that ext/mysqlnd/mysqlnd_debug.c needs to be added as a build
dependency of pdo_mysql if --enable-debug is set, but I am not
experienced enough with autoconf et al to figure this out exactly. 

Thanks,
Shahar.



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/47819

-- 
Edit this bug report at http://bugs.php.net/?id=47819&edit=1



#47724 [Com]: Reproducable segmenation fault using symfony and doctrine

2009-03-31 Thread peter at f-is dot eu
 ID:   47724
 Comment by:   peter at f-is dot eu
 Reported By:  scott at danielfamily dot com
 Status:   No Feedback
 Bug Type: Reproducible crash
 Operating System: Centos 5.2
 PHP Version:  5.2.9
 New Comment:

Scott, thanks for your work at the VMWARE image, and Scott MacVicar for
looking into it.

I really hope this annoying bug finally get's fixed.

I've been playing with Duma, Valgrind and GDB for a few days, but my
knowledge about these tools, c programming, or the internals of PHP seem
insufficient.

>From what i can tell, this is a reference counting problem. Some object
has 3 references, and than some time later the some memory location
contains a String, with 1 reference, which gets dereferenced and
de-allocated. During php shutdown, the original object is being read,
and because the memory is 'gone' it segfaults.

The String that seems to overwrite the object is being provided by the
__toString function of the original object. So i guess something goes
wrong there.

I can't stress enough that my experience with C is extremely limited,
so the above may be completely wrong :P. There is also no way for me to
be sure that this is the same bug that Scott has, but the symptoms are
the same.

This is the information valgrind spits out about the crash is the
following. Note that this only happens in crashing pages, or pages that
sometimes crash, depending on input:
==29860== Invalid read of size 4
==29860==at 0x63EBB7: _zval_ptr_dtor (zend_execute_API.c:410)
==29860==by 0x64F079: _zval_ptr_dtor_wrapper
(zend_variables.c:177)
==29860==by 0x65F9C8: zend_hash_destroy (zend_hash.c:526)
==29860==by 0x64EC8A: _zval_dtor_func (zend_variables.c:45)
==29860==by 0x63E978: _zval_dtor (zend_variables.h:35)
==29860==by 0x63EC31: _zval_ptr_dtor (zend_execute_API.c:414)
==29860==by 0x64F079: _zval_ptr_dtor_wrapper
(zend_variables.c:177)
==29860==by 0x65F9C8: zend_hash_destroy (zend_hash.c:526)
==29860==by 0x675161: zend_object_std_dtor (zend_objects.c:45)
==29860==by 0x675600: zend_objects_free_object_storage
(zend_objects.c:122)
==29860==by 0x679E67: zend_objects_store_del_ref_by_handle
(zend_objects_API.c:211)
==29860==by 0x679C45: zend_objects_store_del_ref
(zend_objects_API.c:169)
==29860==  Address 0xBF348B8 is 16 bytes inside a block of size 24
free'd
==29860==at 0x4A0541E: free (vg_replace_malloc.c:233)
==29860==by 0x62E4EB: _efree (zend_alloc.c:2303)
==29860==by 0x63ECD9: safe_free_zval_ptr_rel (zend_execute.h:70)
==29860==by 0x63EC51: _zval_ptr_dtor (zend_execute_API.c:415)
==29860==by 0x67D57C: zend_ptr_stack_clear_multiple
(zend_execute.h:155)
==29860==by 0x67CE1E: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:307)
==29860==by 0x683160: ZEND_DO_FCALL_SPEC_CONST_HANDLER
(zend_vm_execute.h:1729)
==29860==by 0x67C11B: execute (zend_vm_execute.h:92)
==29860==by 0x6951FA: ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER
(zend_vm_execute.h:7811)
==29860==by 0x67C11B: execute (zend_vm_execute.h:92)
==29860==by 0x6517CC: zend_execute_scripts (zend.c:1134)
==29860==by 0x5F108F: php_execute_script (main.c:2023)

This is the output of php that I got by enabling debugging options.
They concern the same memory region as the above:
Reducing refcount for bf348a8 (feff5738) type 5:  16->15
Reducing refcount for bf348a8 (feff5ba8) type 5:  15->14
Reducing refcount for bf348a8 (feff5cf0) type 5:  14->13
Reducing refcount for bf348a8 (bf45c08) type 5:  13->12
Reducing refcount for bf348a8 (bf45cc0) type 5:  12->11
Reducing refcount for bf348a8 (bf351a8) type 5:  11->10
Reducing refcount for bf348a8 (a0a518) type 5:  10->9
Reducing refcount for bf348a8 (feff84a8) type 5:  10->9
Reducing refcount for bf348a8 (bf350a8) type 5:  9->8
Reducing refcount for bf348a8 (a0a518) type 5:  8->7
Reducing refcount for bf348a8 (feff8d28) type 5:  7->6
Reducing refcount for bf348a8 (bf34b70) type 5:  6->5
Reducing refcount for bf348a8 (a0a518) type 5:  5->4
Reducing refcount for bf348a8 (a0a518) type 5:  4->3
Reducing refcount for bf348a8 (feffa048) type 6:  1->0
Destroying bf348a8 of type 6
Reducing refcount for bf348a8 (bf44e38) type 6:  0->-1
Reducing refcount for bf348a8 (bf35f70) type 6:  -1->-2


Previous Comments:


[2009-03-31 03:21:39] scott at danielfamily dot com

Scott MacVicar from the PHP team send me a note saying he would look at
the bug. I uploaded the VMWARE appliance and send him the information,
but have not heard back after some days. Still hoping for some love.



[2009-03-31 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

--

#47736 [Ver]: imap_headerinfo() segfaults with large address lists

2009-03-31 Thread etremblay at kronostechnologies dot com
 ID:   47736
 User updated by:  etremblay at kronostechnologies dot com
 Reported By:  etremblay at kronostechnologies dot com
 Status:   Verified
 Bug Type: IMAP related
 Operating System: *
 PHP Version:  5.*, 6CVS (2009-03-31)
 New Comment:

If you look closely at http://markmail.org/message/ypvowfyqcijit4f5, it
say that the fixed api functions begin with rfc822_output_*.  

In the core dump, we see that the problem is in the function 
rfc822_output_address () from /usr/lib/libc-client.so.2007b.

So, the actual problem is not the same.


Previous Comments:


[2009-03-31 07:55:38] j...@php.net

This explains the bug:

http://markmail.org/message/ypvowfyqcijit4f5





[2009-03-23 12:22:38] etremblay at kronostechnologies dot com

libc-client2007b (ubuntu intrepid)
I try the current snapshot of php.  Post back in 2 minutes.



[2009-03-23 12:16:27] paj...@php.net

Which imap version do you use?



[2009-03-23 12:14:50] etremblay at kronostechnologies dot com

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb757e700 (LWP 21722)]
0xb7e7fbb6 in memcpy () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0xb7e7fbb6 in memcpy () from /lib/tls/i686/cmov/libc.so.6
#1  0xbf877e84 in ?? ()
#2  0xb6c72d42 in ?? () from /usr/lib/libc-client.so.2007b
#3  0xb6c738b3 in rfc822_output_address () from
/usr/lib/libc-client.so.2007b
#4  0xb6c73abd in rfc822_output_address_list () from
/usr/lib/libc-client.so.2007b
#5  0xb6f9a0ea in _php_rfc822_write_address (addresslist=0xb8ccc6f8) at
/opt/php-5.2.9/ext/imap/php_imap.c:3947
#6  0x0061632e in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)



[2009-03-20 19:24:37] etremblay at kronostechnologies dot com

Description:

This is a duplicate of bug #19280 which is closed.

I can reproduced it php 5.2.9.  
With 5.2.6, it worked well.

I see that imap address related code have been touched by bug #46918
(shown in 5.2.9 releasenotes)

Look like someone broke it when fixing some other issue.

Reproduce code:
---
Look in bug #19280

Expected result:

No segfault

Actual result:
--
Segfault





-- 
Edit this bug report at http://bugs.php.net/?id=47736&edit=1



#47849 [NEW]: Non-deep import loses the namespace

2009-03-31 Thread robin2008 at altruists dot org
From: robin2008 at altruists dot org
Operating system: Ubuntu
PHP version:  5.2.9
PHP Bug Type: DOM XML related
Bug description:  Non-deep import loses the namespace

Description:

I was expecting importNode to respect namespace

Reproduce code:
---
appendChild($aDOM->createElementNS(' http://friend2friend.net/
','f2f:a'));
echo 'DOM to add into is '.$aDOM->saveXML().chr(13);

$fromdom= DOMDocument::loadXML('http://altruists.org "/>');
echo 'Dom to import from is'.$fromdom->saveXML().chr(13);

$data= $fromdom->firstChild;

$aDOM->documentElement->appendChild($aDOM->importNode($data));
echo 'Result is '.$aDOM->saveXML();

?>

Expected result:

The manual says "This function returns a copy of the node to import and
associates it with the current document. " so I was expecting it to
preserve the namespace

Actual result:
--
The namespace gets lost.

-- 
Edit bug report at http://bugs.php.net/?id=47849&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47849&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47849&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47849&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47849&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47849&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47849&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47849&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47849&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47849&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47849&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47849&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47849&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47849&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47849&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47849&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47849&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47849&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47849&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47849&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47849&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47849&r=mysqlcfg



#47848 [NEW]: importNode doesn't preserve attribute namespaces

2009-03-31 Thread robin2008 at altruists dot org
From: robin2008 at altruists dot org
Operating system: Ubuntu
PHP version:  5.2.9
PHP Bug Type: DOM XML related
Bug description:  importNode doesn't preserve attribute namespaces

Description:

I was expecting importNode to preserve attribute namespaces.
It doesn't

Reproduce code:
---
appendChild($aDOM->createElementNS('http://friend2friend.net/','f2f:a'));
echo 'DOM to add into is '.$aDOM->saveXML().chr(13);

$fromdom= DOMDocument::loadXML('http://altruists.org "
ai:attr="namespaced" />');
echo 'Dom to import from is'.$fromdom->saveXML().chr(13);

$attr= $fromdom->firstChild->attributes->item(0);

$aDOM->documentElement->appendChild($aDOM->importNode($attr));
echo 'Result is '.$aDOM->saveXML();

// The following script gets round this bug

function importAttrNS($targetNode, $attr)
{ // Last modified 2009-01-26   Imports an attribute without losing the 
NS,
if present
if ($attr->prefix=='')
$targetNode->appendChild($targetNode->ownerDocument->importNode($attr));
else
$targetNode->setAttributeNS($attr->lookupNamespaceURI($attr->prefix),
$attr->prefix.':'.$attr->name, $attr->value);
}
?>

Expected result:

The imported attribute should keep its namespace.

Actual result:
--
The imported attribute becomes unnamespaced.

-- 
Edit bug report at http://bugs.php.net/?id=47848&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47848&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47848&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47848&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47848&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47848&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47848&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47848&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47848&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47848&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47848&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47848&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47848&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47848&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47848&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47848&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47848&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47848&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47848&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47848&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47848&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47848&r=mysqlcfg



#47765 [Opn]: __invoke lacks if object is a static property or return

2009-03-31 Thread biohazard999 at gmx dot at
 ID:   47765
 User updated by:  biohazard999 at gmx dot at
 Reported By:  biohazard999 at gmx dot at
 Status:   Open
-Bug Type: Documentation problem
+Bug Type: Scripting Engine problem
 Operating System: Windows XP SP3
-PHP Version:  Irrelevant
+PHP Version:  5.3.0RC1
 New Comment:

Think it's a script engine problem or a documentation problem


Previous Comments:


[2009-03-24 19:10:07] biohazard999 at gmx dot at

Description:

If the object to invoke is stored in a static property or is returned
by a static function __invoke will not be called.
Especially for singletons is this extremly missleading.

Either it is an documentation problem or something other is wrong.

Actual documentation:
The __invoke method is called when a script tries to call an object as
a function. 

Reproduce code:
---
class foo
{
  public static $instance = null; //only public for this example

  public static function get()
  {
if(is_null(self::$instance))
  self::$instance = new self;

return self::$instance;
  }

  public function __invoke($name)
  {
echo 'Hello '.$name;
  }
}

//1)
foo::get()('World');

//2)
foo::get();
foo::$instance('World');

//3)
$bar = foo::get();
$bar('World');

Expected result:

1) //Here is the parsing-error partial expected
Hello World

2)
Hello World

3)
Hello World

Actual result:
--
1)
Parse error: parse error in test.php on line 23

2)
Notice: Undefined variable: instance in test.php on line 27
Fatal error: Function name must be a string in test.php on line 27

3)
Hello World //Behavior as expected





-- 
Edit this bug report at http://bugs.php.net/?id=47765&edit=1



#47847 [NEW]: importNode loses the namespace of an XML element.

2009-03-31 Thread robin2008 at altruists dot org
From: robin2008 at altruists dot org
Operating system: Ubuntu
PHP version:  5.2.9
PHP Bug Type: DOM XML related
Bug description:  importNode loses the namespace of an XML element.

Description:

ImportNode don't treat namespace properly

Reproduce code:
---
appendChild($aDOM->createElementNS(' http://friend2friend.net
','f2f:a'));
echo 'DOM to add into is '.$aDOM->saveXML().chr(13);

$fromdom= DOMDocument::loadXML('http://friend2friend.net ">http://friend2friend.net
">

');
echo 'Dom to import from is'.$fromdom->saveXML().chr(13);

$imported= $aDOM->importNode($fromdom->firstChild->firstChild, 1);
$aDOM->appendChild($imported);
echo 'Result is '.$aDOM->saveXML();
?>

Expected result:

Namespace should be preserved

Actual result:
--
Namespace gets lost

-- 
Edit bug report at http://bugs.php.net/?id=47847&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47847&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47847&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47847&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47847&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47847&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47847&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47847&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47847&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47847&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47847&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47847&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47847&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47847&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47847&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47847&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47847&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47847&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47847&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47847&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47847&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47847&r=mysqlcfg



#47819 [Fbk->Opn]: Getting pdo_mysql.so: undefined symbol: mysqlnd_debug_init at startup

2009-03-31 Thread shahar dot e at zend dot com
 ID:   47819
 User updated by:  shahar dot e at zend dot com
 Reported By:  shahar dot e at zend dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: Linux i386
 PHP Version:  5.3.0RC1
 Assigned To:  mysql
 New Comment:

I just tried again with today's snapshot (php5.3-200903310830) and
looks like it is fixed. I no longer get the message, and pdo_mysql is
indeed loaded. 

Thanks!


Previous Comments:


[2009-03-30 14:48:56] shahar dot e at zend dot com

This still happens with the latest snapshot you linked to. 
Here are the relevant parts from sapi/cli/php -i:

PHP Version => 5.3.0RC2-dev
System => Linux wintergreen 2.6.28-gentoo-r2 #1 PREEMPT Sun Mar 8
17:10:56 IST 2009 i686
Build Date => Mar 30 2009 17:42:20
Configure Command =>  './configure'  '--disable-all' '--enable-pdo'
'--with-pdo-mysql=shared,mysqlnd' '--enable-debug'
Server API => Command Line Interface
Debug Build => yes
Thread Safety => disabled

mysqlnd

mysqlnd => enabled
Version => mysqlnd 5.0.5-dev - 081106 - $Revision: 1.3.2.22 $
Command buffer size => 2048
Read buffer size => 32768
Collecting statistics => Yes
Collecting memory statistics => No

PDO

PDO support => enabled



[2009-03-30 14:06:49] johan...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

I still didn't reproduce it but applied a patch with some guessing.
Please try the snapshot and see whether it helps.



[2009-03-30 13:15:58] johan...@php.net

Ah, the debug piece is important, investigating ...



[2009-03-30 11:59:05] shahar dot e at zend dot com

Yes, I'm building PHP from scratch with the above mentioned configure
command.

I think that in order to reproduce this you need to add --enable-debug
to your ./configure, as so (I just tried this):

$ ./configure --disable-all --enable-pdo
--with-pdo-mysql=shared,mysqlnd --enable-debug
$ make
$ sapi/cli/php -d extension_dir=modules/ -d extension=pdo_mysql.so -m
PHP Warning:  PHP Startup: Unable to load dynamic library
'modules/pdo_mysql.so' - modules/pdo_mysql.so: undefined symbol:
mysqlnd_debug_init in Unknown on line 0

I assume that ext/mysqlnd/mysqlnd_debug.c needs to be added as a build
dependency of pdo_mysql if --enable-debug is set, but I am not
experienced enough with autoconf et al to figure this out exactly. 

Thanks,
Shahar.



[2009-03-30 11:14:13] johan...@php.net

Are you loading the module into a PHP which has mysqlnd enabled?
Usually mysqlnd is automatically activated once another extension using
mysqlnd is being activated.

I tried the following which worked:

$ ./configure --disable-all --enable-pdo
--with-pdo-mysql=shared,mysqlnd
$ make
$ sapi/cli/php -d extension_dir=modules/ -d extension=pdo_mysql.so -m




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/47819

-- 
Edit this bug report at http://bugs.php.net/?id=47819&edit=1



#47745 [Asn->Csd]: FILTER_VALIDATE_INT doesn't allow minimum integer

2009-03-31 Thread dmitry
 ID:   47745
 Updated by:   dmi...@php.net
 Reported By:  for-bugs at hnw dot jp
-Status:   Assigned
+Status:   Closed
 Bug Type: Filter related
 Operating System: *
 PHP Version:  5.2.9
 Assigned To:  dmitry
 New Comment:

This bug has been fixed in CVS.

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:


[2009-03-31 09:27:50] for-bugs at hnw dot jp

Result on 64bit environment:


$ php -r 'var_dump(intval((string)~PHP_INT_MAX));'
int(-9223372036854775808)
$ php -r 'var_dump(filter_var((string)~PHP_INT_MAX,
FILTER_VALIDATE_INT));'
bool(false)


There is same problem on 64bit environment, I think.



[2009-03-30 19:47:42] il...@php.net

The multiplication is done by the standard ZEND macro, so if there is a

limit issue it needs to be handled inside the Zend Engine.

That said on my 64bit machine, I cannot reproduce the issue via -
PHP_INT_MAX



[2009-03-29 21:38:18] scott...@php.net

Must have been sleep deprived when I looked at this last.



[2009-03-29 16:47:47] paj...@php.net

The only problem is the value we use for the max unsigned range. It
should be changed to allow - 2^31, but I did not check the code more in
details, but Ilia is on it so :)



[2009-03-29 16:43:23] il...@php.net

We don't eat a 0. When parsing #s we follow this logic:

Let's say X is our temp var containing the 1st digit and the number to

be parsed is 435.

X = X * 10;
X += 3; (X = 43)

X = X * 10;
X += 5; (X = 435)

There is no 0 eating etc...



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/47745

-- 
Edit this bug report at http://bugs.php.net/?id=47745&edit=1



#47825 [Bgs]: POST Data being ignored

2009-03-31 Thread tiposchi at tiscali dot it
 ID:   47825
 User updated by:  tiposchi at tiscali dot it
 Reported By:  tiposchi at tiscali dot it
 Status:   Bogus
 Bug Type: CGI related
 Operating System: GNU/Linux
 PHP Version:  5.2.9
 New Comment:

The bug is about the incorrect handling of data from pipe. I guess you
do a simple read, when you should do multiple reads until you've all the
data the webserver says the client sent (using the envvar
CONTENT_LENGTH) or until the read returns 0.

This is not a support request. The bug is about poor cgi
implementation.


Previous Comments:


[2009-03-31 07:10:45] j...@php.net

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.





[2009-03-29 09:32:38] tiposchi at tiscali dot it

Description:

CGI protocol says that POST data must be passed to the script using
its standard input.

So what i have to do is something like (see the attached code).

Anyway, the php knows how long the input will be because it has an
environmental variable called content length that says it.

So php should wait to read the entire post data before going on.
Since i don't have any information about how the scheduler works, i
can't assure the father process to fill the pipe before the child is
scheduled.

But php ignores the data if the pipe isn't full already. So what i
did was filling the pipe BEFORE the fork, and doing this it works.
But there is another problem. With large POST data, the buffer is
filled and the OS puts my process on wait until the pipe is empty by
another process. But i didn't start the php yet because it wants all
the post data already present, so the webserver just hangs.

I think you should review the way php-cgi reads post data.

Thanks

Reproduce code:
---
p=pipe()

if (fork()==0) {
close(STDIN)
dup(p)
exec ("php")
} else {
write(p,str_post)
wait()
}

I HAVE MADE THE CODE SIMPLE. I KNOW THIS CAN'T WORK.






-- 
Edit this bug report at http://bugs.php.net/?id=47825&edit=1



#47745 [Asn]: FILTER_VALIDATE_INT doesn't allow minimum integer

2009-03-31 Thread for-bugs at hnw dot jp
 ID:   47745
 User updated by:  for-bugs at hnw dot jp
 Reported By:  for-bugs at hnw dot jp
 Status:   Assigned
 Bug Type: Filter related
 Operating System: *
 PHP Version:  5.2.9
 Assigned To:  dmitry
 New Comment:

Result on 64bit environment:


$ php -r 'var_dump(intval((string)~PHP_INT_MAX));'
int(-9223372036854775808)
$ php -r 'var_dump(filter_var((string)~PHP_INT_MAX,
FILTER_VALIDATE_INT));'
bool(false)


There is same problem on 64bit environment, I think.


Previous Comments:


[2009-03-30 19:47:42] il...@php.net

The multiplication is done by the standard ZEND macro, so if there is a

limit issue it needs to be handled inside the Zend Engine.

That said on my 64bit machine, I cannot reproduce the issue via -
PHP_INT_MAX



[2009-03-29 21:38:18] scott...@php.net

Must have been sleep deprived when I looked at this last.



[2009-03-29 16:47:47] paj...@php.net

The only problem is the value we use for the max unsigned range. It
should be changed to allow - 2^31, but I did not check the code more in
details, but Ilia is on it so :)



[2009-03-29 16:43:23] il...@php.net

We don't eat a 0. When parsing #s we follow this logic:

Let's say X is our temp var containing the 1st digit and the number to

be parsed is 435.

X = X * 10;
X += 3; (X = 43)

X = X * 10;
X += 5; (X = 435)

There is no 0 eating etc...



[2009-03-26 22:44:17] scott...@php.net

For some reason php_filter_parse_int multiplies the integer by ten then
attempts to eat a 0? This is causing overflow and resulting in an
error.

I have no idea why its doing this though. ilia?



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/47745

-- 
Edit this bug report at http://bugs.php.net/?id=47745&edit=1



#47846 [Fbk]: Error in DateTime class when initialising with '2009-02'

2009-03-31 Thread rasmus
 ID:   47846
 Updated by:   ras...@php.net
 Reported By:  brooksie155 at yahoo dot com
 Status:   Feedback
 Bug Type: Date/time related
 Operating System: CentOS
 PHP Version:  5.2CVS-2009-03-31 (snap)
 New Comment:

The output from your script on my box:

America/Los_Angeles
array(12) {
  ["year"]=>
  int(2009)
  ["month"]=>
  int(2)
  ["day"]=>
  bool(false)
  ["hour"]=>
  bool(false)
  ["minute"]=>
  bool(false)
  ["second"]=>
  bool(false)
  ["fraction"]=>
  bool(false)
  ["warning_count"]=>
  int(0)
  ["warnings"]=>
  array(0) {
  }
  ["error_count"]=>
  int(0)
  ["errors"]=>
  array(0) {
  }
  ["is_localtime"]=>
  bool(false)
}
2009-03-03T00:00:00-0800

That 'false' there on the date will make it default to today's date. 
Seeing it on both 5.2 and 5.3 on Freebsd.  


Previous Comments:


[2009-03-31 09:01:28] der...@php.net

Just as a comment to Rasmus, that's not true. The format "2009-02"
implicitly sets the day nr as 1.



[2009-03-31 08:56:25] der...@php.net

I can not reproduce this, what does the following output:

format( DateTime::ISO8601 ), "\n";
?>



[2009-03-31 08:56:02] ras...@php.net

Not a bug.  As documented, this defaults to now and you can override
individual components in the constructor.  In your case you have chosen
Feb. 2009, but didn't specify a day of the month.  PHP picks todays day,
which is the 31st day of the month.  The 31st day of Feb will fall in
March since Feb doesn't have 31 days.



[2009-03-31 08:44:45] brooksie155 at yahoo dot com

Description:

There is a bug in the constructor of this object if you are only
specifying the month and the year when dealing with the month of
February.





Reproduce code:
---
$date = new DateTime('2009-02');
echo $date->format('Y-m');

Expected result:

2009-02

Actual result:
--
2009-03





-- 
Edit this bug report at http://bugs.php.net/?id=47846&edit=1



#47846 [Fbk]: Error in DateTime class when initialising with '2009-02'

2009-03-31 Thread derick
 ID:   47846
 Updated by:   der...@php.net
 Reported By:  brooksie155 at yahoo dot com
 Status:   Feedback
 Bug Type: Date/time related
 Operating System: CentOS
 PHP Version:  5.2CVS-2009-03-31 (snap)
 New Comment:

Just as a comment to Rasmus, that's not true. The format "2009-02"
implicitly sets the day nr as 1.


Previous Comments:


[2009-03-31 08:56:25] der...@php.net

I can not reproduce this, what does the following output:

format( DateTime::ISO8601 ), "\n";
?>



[2009-03-31 08:56:02] ras...@php.net

Not a bug.  As documented, this defaults to now and you can override
individual components in the constructor.  In your case you have chosen
Feb. 2009, but didn't specify a day of the month.  PHP picks todays day,
which is the 31st day of the month.  The 31st day of Feb will fall in
March since Feb doesn't have 31 days.



[2009-03-31 08:44:45] brooksie155 at yahoo dot com

Description:

There is a bug in the constructor of this object if you are only
specifying the month and the year when dealing with the month of
February.





Reproduce code:
---
$date = new DateTime('2009-02');
echo $date->format('Y-m');

Expected result:

2009-02

Actual result:
--
2009-03





-- 
Edit this bug report at http://bugs.php.net/?id=47846&edit=1



#47846 [Bgs->Fbk]: Error in DateTime class when initialising with '2009-02'

2009-03-31 Thread derick
 ID:   47846
 Updated by:   der...@php.net
 Reported By:  brooksie155 at yahoo dot com
-Status:   Bogus
+Status:   Feedback
-Bug Type: Feature/Change Request
+Bug Type: Date/time related
 Operating System: CentOS
 PHP Version:  5.2CVS-2009-03-31 (snap)
 New Comment:

I can not reproduce this, what does the following output:

format( DateTime::ISO8601 ), "\n";
?>


Previous Comments:


[2009-03-31 08:56:02] ras...@php.net

Not a bug.  As documented, this defaults to now and you can override
individual components in the constructor.  In your case you have chosen
Feb. 2009, but didn't specify a day of the month.  PHP picks todays day,
which is the 31st day of the month.  The 31st day of Feb will fall in
March since Feb doesn't have 31 days.



[2009-03-31 08:44:45] brooksie155 at yahoo dot com

Description:

There is a bug in the constructor of this object if you are only
specifying the month and the year when dealing with the month of
February.





Reproduce code:
---
$date = new DateTime('2009-02');
echo $date->format('Y-m');

Expected result:

2009-02

Actual result:
--
2009-03





-- 
Edit this bug report at http://bugs.php.net/?id=47846&edit=1



#47846 [Opn->Bgs]: Error in DateTime class when initialising with '2009-02'

2009-03-31 Thread rasmus
 ID:   47846
 Updated by:   ras...@php.net
 Reported By:  brooksie155 at yahoo dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: CentOS
 PHP Version:  5.2CVS-2009-03-31 (snap)
 New Comment:

Not a bug.  As documented, this defaults to now and you can override
individual components in the constructor.  In your case you have chosen
Feb. 2009, but didn't specify a day of the month.  PHP picks todays day,
which is the 31st day of the month.  The 31st day of Feb will fall in
March since Feb doesn't have 31 days.


Previous Comments:


[2009-03-31 08:44:45] brooksie155 at yahoo dot com

Description:

There is a bug in the constructor of this object if you are only
specifying the month and the year when dealing with the month of
February.





Reproduce code:
---
$date = new DateTime('2009-02');
echo $date->format('Y-m');

Expected result:

2009-02

Actual result:
--
2009-03





-- 
Edit this bug report at http://bugs.php.net/?id=47846&edit=1



#47846 [NEW]: Error in DateTime class when initialising with '2009-02'

2009-03-31 Thread brooksie155 at yahoo dot com
From: brooksie155 at yahoo dot com
Operating system: CentOS
PHP version:  5.2CVS-2009-03-31 (snap)
PHP Bug Type: Feature/Change Request
Bug description:  Error in DateTime class when initialising with '2009-02'

Description:

There is a bug in the constructor of this object if you are only
specifying the month and the year when dealing with the month of February.





Reproduce code:
---
$date = new DateTime('2009-02');
echo $date->format('Y-m');

Expected result:

2009-02

Actual result:
--
2009-03

-- 
Edit bug report at http://bugs.php.net/?id=47846&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47846&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47846&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47846&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47846&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47846&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47846&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47846&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47846&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47846&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47846&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47846&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47846&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47846&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47846&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47846&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47846&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47846&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47846&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47846&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47846&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47846&r=mysqlcfg



#43991 [Com]: Content-Length in HTTP header from PHP SOAP wrong

2009-03-31 Thread zkroecher at gingco dot net
 ID:   43991
 Comment by:   zkroecher at gingco dot net
 Reported By:  s dot slater at cabletime dot com
 Status:   Open
 Bug Type: SOAP related
 Operating System: Windows Vista + IIS7.0
 PHP Version:  5.2.5
 New Comment:

We have the same problem on Windows 2008 Server with IIS7, using
php5ispai.dll.
No solution yet?


Previous Comments:


[2008-01-31 12:13:12] s dot slater at cabletime dot com

Description:

PHP SOAP seems to return an incorrect Content-Length in the HTTP header
(8 bytes too small) which causes a problem with IIS7 on Windows Vista. 


Note that the incorrect value is present but does not cause a problem
with IIS5.1 on XP or with Apache on Vista, XP or Linux.  You don't see
any symptoms unless using IIS7.

Reproduce code:
---
The problem seems to occur on any response I get from PHP SOAP.

Used 5.2.5 installed with Windows installer with SOAP + PDO SQLite
modules and running as CGI

Expected result:

Looking at a specific example with Wireshark on various servers, the
full body of the SOAP response consists of 578 bytes:

SP CR LF
569 bytes of XML
LF SP CR LF CR LF

I would expect the HTTP header to include Content-Length: 578

Actual result:
--
The HTTP header contains Content-Length: 570

What I actually receive in the client is:

With IIS7: 570 bytes of body, so the last two bytes of the XML are
truncated and my Java applet client software won't parse it

With IIS5.1: 570 bytes of body followed by a second HTTP packet
containing the last 8 bytes, which works

With Apache: The whole response in one HTTP packet with no truncation,
which works

So the SOAP communication still works OK on the older IIS and Apache
even with the incorrect content length, but on each message sent by
vista the response ends with "" and
terminating bytes are missing.





-- 
Edit this bug report at http://bugs.php.net/?id=43991&edit=1



#45244 [Bgs]: serialize() inserts NUL chars when serializing objects

2009-03-31 Thread yunosh
 ID:   45244
 Updated by:   yun...@php.net
 Reported By:  bukaj at bukaj dot net
 Status:   Bogus
 Bug Type: Strings related
 Operating System: OS X, FreeBSD
 PHP Version:  5.2.6
 New Comment:

It also says "Returns a string containing a byte-stream representation
of value  that can be stored anywhere."
You can't store it everywhere, because there are a lot of storage
systems that truncate data a NUL chars, e.g. databases.


Previous Comments:


[2008-06-12 11:10:03] johan...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

>From the documentation: \"serialize - Generates a storable
representation of a value\" - storable, not \"displayable\" ot something
like that.



[2008-06-12 09:47:41] bukaj at bukaj dot net

Description:

This issue has been marked as closed in bug 
#29865 but THE PROBLEM IS STILL PRESENT IN 5.2.6.

Serialize inserts NUL (ASCII 0) characters into output when serializing

objects. Serialize CAN'T produce output with unprintable chars - that's

the idea of serialize! This issue has been marked as resolved in bug 
#29865 but IT IS NOT.






Reproduce code:
---
$ php -r 'class Foo { protected $bar = 1; } $v = new Foo; echo
serialize($v);' | hexdump



Expected result:

No unprintable chars in result of serialize!!!

Actual result:
--
000 4f 3a 33 3a 22 46 6f 6f 22 3a 31 3a 7b 73 3a 36
010 3a 22 00 2a 00 62 61 72 22 3b 69 3a 31 3b 7d   
01f

mark the two 00's at 0x12 and 0x14










-- 
Edit this bug report at http://bugs.php.net/?id=45244&edit=1



#46395 [Com]: Inconsistent behaviour of require_once

2009-03-31 Thread befroozfar at yahoo dot com
 ID:   46395
 Comment by:   befroozfar at yahoo dot com
 Reported By:  ebosman at gmail dot com
 Status:   No Feedback
 Bug Type: Directory function related
 Operating System: Linux
 PHP Version:  5.2.6
 New Comment:

Warning: require_once(Mail.php) [function.require-once]: failed to open
stream: No such file or directory in


Previous Comments:


[2009-01-29 01:00:15] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2009-01-21 19:47:57] j...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





[2008-12-09 20:30:36] tomas at matfyz dot cz

Note that my bug #46801 was marked as a duplicate of this one. My
testcase could be found here:
http://tomas.matfyz.cz/obs/pok_require_dirs3/report/www/use.php



[2008-11-24 17:33:18] ebosman at gmail dot com

And then I forgot that I put the original include_path back, apologies

/var/www/bug/top.php /var/www/bug
/var/www/bug/subdir/sub.inc /var/www/bug
(and htmlized:)
Warning: require_once(../top1.inc) [function.require-once]: failed to
open stream: No such file or directory in /var/www/bug/subdir/sub.inc on
line 1

Fatal error: require_once() [function.require]: Failed opening required
'../top1.inc' (include_path='/usr/share/php:/usr/share/pear') in
/var/www/bug/subdir/sub.inc on line 1



[2008-11-24 17:30:28] ebosman at gmail dot com

correction, for top.php it should be (still no difference):

/var/www/bug/top.php /var/www/bug
/var/www/bug/subdir/sub.inc /var/www/bug
(and htmlized)
Warning: require_once(../top1.inc) [function.require-once]: failed to
open stream: No such file or directory in /var/www/bug/subdir/sub.inc on
line 1

Fatal error: require_once() [function.require]: Failed opening required
'../top1.inc' (include_path='.:/usr/share/php:/usr/share/pear') in
/var/www/bug/subdir/sub.inc on line 1

(line difference in the previous comment was because of copy-pasting)



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/46395

-- 
Edit this bug report at http://bugs.php.net/?id=46395&edit=1



#47800 [Bgs]: Sessions won't be loaded when Cookies are disabled

2009-03-31 Thread whistl0r+phpbug at googlemail dot com
 ID:   47800
 User updated by:  whistl0r+phpbug at googlemail dot com
 Reported By:  whistl0r+phpbug at googlemail dot com
 Status:   Bogus
 Bug Type: Session related
 Operating System: Windows
 PHP Version:  5.3.0RC1
 New Comment:

Please could you say at least why this is bogus?

The example code is identical to your documentation, isn't it?
http://www.php.net/manual/en/session.idpassing.php

Did I miss a new behavior in PHP 5.3?


Previous Comments:


[2009-03-31 07:20:32] j...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php





[2009-03-27 02:36:36] whistl0r+phpbug at googlemail dot com

Description:

When forcing PHP to not use cookies for sessions, PHP isn't able to
load an existing session. Instead it will create a new one.

Tested with the default php.ini (php.ini-production) coming with the
php-5.3.0RC1-nts-Win32-VC6-x86.zip package.

I just fixed line 428 and set the session.save_path value.

Session files will be created as expected.

With PHP <5.3, the script is working as expected.

I can confirm, that this problem is still present in the latest
snapshot (VC6 x86 Thread Safe (2009-Mar-26 19:00:00)).

Reproduce code:
---
' . PHP_EOL, $_SESSION['counter']);

// Print Next link
printf('Next',
$_SERVER['PHP_SELF'],
SID
);


Expected result:

When you first run this code, a session with a variable "counter" with
the value "1" (int) should be created and a link pointing to the same
script with this SESSION-ID should be displayed.

When you click this link, you run this code again and the previous
created session should be loaded and the "counter" variable should be
incremented by 1.

Actual result:
--
On every run, PHP creates a new session.





-- 
Edit this bug report at http://bugs.php.net/?id=47800&edit=1



#47845 [NEW]: PDO_Firebird omits first row from query

2009-03-31 Thread piotrt at itisit dot pl
From: piotrt at itisit dot pl
Operating system: Windows XP
PHP version:  5.2.9
PHP Bug Type: PDO related
Bug description:  PDO_Firebird omits first row from query

Description:

PDO_Firebird omits first row from query.

Reproduce code:
---
First create sample table:
CREATE TABLE PDO_BUG(
  ID Integer NOT NULL,
  TEXTFIELD Varchar(20),
  NUMFIELD Numeric(18,2),
  PRIMARY KEY (ID)
);
INSERT INTO PDO_BUG (ID, TEXTFIELD, NUMFIELD) VALUES ('1', 'val1',
'992831.00');
INSERT INTO PDO_BUG (ID, TEXTFIELD, NUMFIELD) VALUES ('2', 'val2',
'488111.00');
INSERT INTO PDO_BUG (ID, TEXTFIELD, NUMFIELD) VALUES ('3', 'val3',
'1109911.00');

 $dbh = new
PDO('firebird:dbname=localhost:database','SYSDBA','masterkey');
 $sql = "select * from PDO_BUG order by ID" ;
 $stm = $dbh->prepare($sql);
 $stm->execute();
 $result = $stm->fetchAll(PDO::FETCH_ASSOC);
 print_r($result);

Expected result:

$result should containt 3 rows from query.

Actual result:
--
First row is omitted. I already tried different methods (with or without
prepare, fetching single rows etc.). I didn't find a way to make PDO return
all rows from query including first one.

-- 
Edit bug report at http://bugs.php.net/?id=47845&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47845&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47845&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47845&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47845&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47845&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47845&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47845&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47845&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47845&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47845&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47845&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47845&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47845&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47845&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47845&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47845&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47845&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47845&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47845&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47845&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47845&r=mysqlcfg



#47692 [Opn->Bgs]: Segmentation fault: using Calendar Application http://www.k5n.us/webcalendar.php

2009-03-31 Thread jani
 ID:   47692
 Updated by:   j...@php.net
 Reported By:  wolf at isp dot uni-luebeck dot de
-Status:   Open
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: opensuse 11.1
 PHP Version:  5.2.9
 New Comment:

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


.


Previous Comments:


[2009-03-23 12:28:56] wolf at isp dot uni-luebeck dot de

Unfortunately php is crashing using a calendar application. it can be
found at http://www.k5n.us/webcalendar.php .
This application is more or less used as black box.

I can provide access to our system or do some basic debugging if you
have an idea what I can do to track down the problem.



[2009-03-22 08:04:16] j...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





[2009-03-17 15:15:54] wolf at isp dot uni-luebeck dot de

Description:

Webserver Segmentation fault using Calendar Application form
http://www.k5n.us/webcalendar.php

User with large calendar data is not able to log in anymore. Calendars
with less data works fine

This error occurs with PHP version 5.2.9 PHP version 5.2.6 works fine

Both version are compiled on the same machine with following compile
options
/configure --with-mysql=/usr/local/mysql --with-openssl 
--enable-discard-path --prefix=/usr/local/php5_modul
--with-config-file-path=/usr/local/php5_modul/lib
--with-apxs2=/usr/local/apache2/bin/apxs --enable-exif --with-iconv
--enable-mbstring=all --enable-mbregex --with-zlib --enable-soap
--with-gd --with-gettext
 

Actual result:
--
gdb ./httpd
GNU gdb (GDB; openSUSE 11.1) 6.8.50.20081120-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i586-suse-linux".
For bug reporting instructions, please see:
...
(gdb)  run -X -d /usr/local/apache2
Starting program: /usr/local/apache2/bin/httpd -X -d
/usr/local/apache2
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0xb77f3354 in _zend_hash_quick_add_or_update (ht=0x970958c,
arKey=0x8351360 "item", nKeyLength=5, h=262956212, pData=0xbf6520b0,
nDataSize=4, pDest=0xbf6520f0, flag=1)
at /usr/local/src/php-5.2.9/Zend/zend_hash.c:312
312 p = (Bucket *) pemalloc(sizeof(Bucket) - 1 +
nKeyLength, ht->persistent);
(gdb) bt
#0  0xb77f3354 in _zend_hash_quick_add_or_update (ht=0x970958c,
arKey=0x8351360 "item", nKeyLength=5, h=262956212, pData=0xbf6520b0,
nDataSize=4, pDest=0xbf6520f0, flag=1)
at /usr/local/src/php-5.2.9/Zend/zend_hash.c:312
#1  0xb784cd1e in ZEND_RECV_SPEC_HANDLER (execute_data=0xbf652720) at
/usr/local/src/php-5.2.9/Zend/zend_execute.c:160
#2  0xb7808ad0 in execute (op_array=0x8539100) at
/usr/local/src/php-5.2.9/Zend/zend_vm_execute.h:92
#3  0xb781a856 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbf652e60) at
/usr/local/src/php-5.2.9/Zend/zend_vm_execute.h:234
#4  0xb7808ad0 in execute (op_array=0x8539100) at
/usr/local/src/php-5.2.9/Zend/zend_vm_execute.h:92
#5  0xb781a856 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbf6535a0) at
/usr/local/src/php-5.2.9/Zend/zend_vm_execute.h:234
#6  0xb7808ad0 in execute (op_array=0x8539100) at
/usr/local/src/php-5.2.9/Zend/zend_vm_execute.h:92
#7  0xb781a856 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbf653ce0) at
/usr/local/src/php-5.2.9/Zend/zend_vm_execute.h:234
#8  0xb7808ad0 in execute (op_array=0x8539100) at
/usr/local/src/php-5.2.9/Zend/zend_vm_execute.h:92
#9  0xb781a856 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbf654420) at
/usr/local/src/php-5.2.9/Zend/zend_vm_execute.h:234
#10 0xb7808ad0 in execute (op_array=0x8539100) at
/usr/local/src/php-5.2.9/Zend/zend_vm_execute.h:92
#11 0xb781a856 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbf654b60) at
/usr/local/src/php-5.2.9/Zend/zend_vm_execute.h:234
#12 0xb7808ad0 in exe

#47736 [Opn->Ver]: imap_headerinfo() segfaults with large address lists

2009-03-31 Thread jani
 ID:   47736
 Updated by:   j...@php.net
-Summary:  imap_headerinfo Segfault  with large To:
 Reported By:  etremblay at kronostechnologies dot com
-Status:   Open
+Status:   Verified
 Bug Type: IMAP related
-Operating System: linux
+Operating System: *
-PHP Version:  5.2.9
+PHP Version:  5.*, 6CVS (2009-03-31)
 New Comment:

This explains the bug:

http://markmail.org/message/ypvowfyqcijit4f5




Previous Comments:


[2009-03-23 12:22:38] etremblay at kronostechnologies dot com

libc-client2007b (ubuntu intrepid)
I try the current snapshot of php.  Post back in 2 minutes.



[2009-03-23 12:16:27] paj...@php.net

Which imap version do you use?



[2009-03-23 12:14:50] etremblay at kronostechnologies dot com

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb757e700 (LWP 21722)]
0xb7e7fbb6 in memcpy () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0xb7e7fbb6 in memcpy () from /lib/tls/i686/cmov/libc.so.6
#1  0xbf877e84 in ?? ()
#2  0xb6c72d42 in ?? () from /usr/lib/libc-client.so.2007b
#3  0xb6c738b3 in rfc822_output_address () from
/usr/lib/libc-client.so.2007b
#4  0xb6c73abd in rfc822_output_address_list () from
/usr/lib/libc-client.so.2007b
#5  0xb6f9a0ea in _php_rfc822_write_address (addresslist=0xb8ccc6f8) at
/opt/php-5.2.9/ext/imap/php_imap.c:3947
#6  0x0061632e in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)



[2009-03-20 19:24:37] etremblay at kronostechnologies dot com

Description:

This is a duplicate of bug #19280 which is closed.

I can reproduced it php 5.2.9.  
With 5.2.6, it worked well.

I see that imap address related code have been touched by bug #46918
(shown in 5.2.9 releasenotes)

Look like someone broke it when fixing some other issue.

Reproduce code:
---
Look in bug #19280

Expected result:

No segfault

Actual result:
--
Segfault





-- 
Edit this bug report at http://bugs.php.net/?id=47736&edit=1



#47768 [Opn->Fbk]: httpd ( Apache 2.2 ) crashes of abort() in signal handler

2009-03-31 Thread jani
 ID:   47768
 Updated by:   j...@php.net
 Reported By:  hossy421 at yahoo dot co dot jp
-Status:   Open
+Status:   Feedback
 Bug Type: Apache2 related
 Operating System: FreeBSD 6.3-RELEASE-p9
 PHP Version:  5.2.9
 New Comment:

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.





Previous Comments:


[2009-03-24 22:58:38] hossy421 at yahoo dot co dot jp

Description:

httpd ( Apache 2.2 ) crashes below messages.

> httpd in free(): error: recursive call
> [notice] child pid X exit signal Abort trap (6)

X is process id of a httpd child process.

Reproduce code:
---
sorry, I could't repro this bug in another environment.

Actual result:
--
this is backtrace.

Program received signal SIGABRT, Aborted.
0x2836b56f in kill () from /lib/libc.so.6
(gdb) bt
#0  0x2836b56f in kill () from /lib/libc.so.6
#1  0x2828d27b in raise () from /usr/lib/libpthread.so.2
#2  0x2836a2ab in abort () from /lib/libc.so.6
 :
#6  0x2830662c in free () from /lib/libc.so.6
#7  0x28617828 in php_error_cb (type=1,
error_filename=0x86b1e38 "/usr/home/hossy/public_html/test.php",
error_lineno=391,
format=0x2874febc "Maximum execution time of %d second%s exceeded",
args=0xbfbf7898 "\n")
at /usr/ports/lang/php5/work/php-5.2.9/main/main.c:824
 :
#10 0x282920d3 in sigaction () from /usr/lib/libpthread.so.2
#11 
 :
#15 0x2830662c in free () from /lib/libc.so.6
#16 0x28644cb5 in zend_mm_mem_malloc_free (storage=0x80a1690,
ptr=0xa81c000)
at /usr/ports/lang/php5/work/php-5.2.9/Zend/zend_alloc.c:276
 :

1. httpd cought SIGPROF in free() because of `max_execution_time'
parameter.
2. php_error_cb() called free()
3. free() detected as `recursive call.'

in zend_mm_mem_malloc_free(), signal is blocked from
HANDLE_BLOCK_INTERRUPTIONS macro.
but, apache2handler does't have the function for it.

(gdb) p zend_block_interruptions
$1 = (void (*)(void)) 0
(gdb) p sapi_module
$2 = {name = 0x28759d5d "apache2handler", pretty_name = 0x28759d6c
"Apache 2.0 Handler",
 :
  block_interruptions = 0, unblock_interruptions = 0,
 :
(gdb) p apache2_sapi_module
$3 = {name = 0x28759d5d "apache2handler", pretty_name = 0x28759d6c
"Apache 2.0 Handler",
 :
  block_interruptions = 0, unblock_interruptions = 0,
 :

in japanese mailing list, I got a patch for this problem.
http://ml.php.gr.jp/pipermail/php-dev/2009-March/001453.html






-- 
Edit this bug report at http://bugs.php.net/?id=47768&edit=1



#47775 [Opn->Bgs]: Not loading MSSQL DLL

2009-03-31 Thread jani
 ID:   47775
 Updated by:   j...@php.net
 Reported By:  itamarc at rogers dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Dynamic loading
 Operating System: Windows 2003 Ent SP2
 PHP Version:  5.2.9
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:


[2009-03-25 15:30:42] itamarc at rogers dot com

Description:

Trying to make PHP work with MSSQL DLL I tried to load it in my
installation but when I use "print_r(get_loaded_extensions());" to check
what is loaded it wasn't.

I doubled checked the php.ini to confirm and it was also listed in
there.

Reproduce code:
---
I am able to reproduce this every time I try on this installation.

Expected result:

I would expect it to list MSSQL.

Actual result:
--
It lists the following:

 [0] => bcmath [1] => calendar [2] => com_dotnet [3] => ctype [4] =>
session [5] => filter [6] => ftp [7] => hash [8] => iconv [9] => json
[10] => odbc [11] => pcre [12] => Reflection [13] => date [14] => libxml
[15] => standard [16] => tokenizer [17] => zlib [18] => SimpleXML [19]
=> dom [20] => SPL [21] => wddx [22] => xml [23] => xmlreader [24] =>
xmlwriter [25] => ISAPI 





-- 
Edit this bug report at http://bugs.php.net/?id=47775&edit=1



#47753 [Opn->Bgs]: PHP crashes when in class method argument throw Exception

2009-03-31 Thread jani
 ID:   47753
 Updated by:   j...@php.net
 Reported By:  work at setor dot net
-Status:   Open
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: Linux
 PHP Version:  5.2.9
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.




Previous Comments:


[2009-03-25 11:25:51] berblinger at krumedia dot de

Guess this is - as you already mentioned - the same problem like the
bug #47730. 
If you rewrite the execute() function to something like this:
---

public function execute()
{
$tmp = $this->makeThrow();
$this->test( $tmp );
}

---

everything works fine. This segfault is only caused, when one of the
arguments of a valid function call throws an exception.



[2009-03-23 13:44:23] work at setor dot net

Description:

Looks like this bug #47730

php chashes (Segmentation fault). See reproduce code and comments
inside for further details.


Reproduce code:
---
test( $this->makeThrow() );
}

private function test( $test )
{
}

private function makeThrow()
{
throw new Exception( 'test' );
}
}

$Test = new ExceptionBug();
$Test->execute();

Expected result:

Fatal error: Uncaught exception 'Exception' with message 'test' in
/data2/www/test.php:18 Stack trace: #0 /data2/www/test.php(9):
ExceptionBug->makeThrow() #1 /data2/www/test.php(23):
ExceptionBug->execute() #2 {main} thrown in /data2/www/test.php on line
18

Actual result:
--
nothing. php crashes.

Segmentation fault in cli





-- 
Edit this bug report at http://bugs.php.net/?id=47753&edit=1



#47743 [Opn->Fbk]: crash upon communication with mysql through unix socket

2009-03-31 Thread jani
 ID:   47743
 Updated by:   j...@php.net
 Reported By:  electro at vgr dot pl
-Status:   Open
+Status:   Feedback
-Bug Type: Reproducible crash
+Bug Type: MySQL related
 Operating System: Mandriva 2009 x64 cooker
 PHP Version:  5.3CVS-2009-03-21 (snap)
 New Comment:

So what exactly are you using to connect to mysql now, mysql PDO 
driver or what? We need a reproduce script. And can you reproduce 
this crash with PHP 5.2.9 ?


Previous Comments:


[2009-03-24 08:21:24] electro at vgr dot pl

I compiled the newest php snapshot without --enable-memory-limit and
--enable-embedded-mysqli. Segmentation fault still occured. Then I
recompiled with --enable-debug. Curiously, segmentation fault did NOT
happen this time. So I can't submit a backtrace. would a core file
without --enable-debug be of any help?
I also tested my php code on similar Mandriva cooker system, but 32-bit
instead of 64. Segmentation fault does not occur.



[2009-03-22 00:16:37] johan...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

A backtrace would be nice and please add the code. Additionally: Do you
really need --enable-embedded-mysqli which links in a MySQL Server into
PHP?



[2009-03-21 18:30:01] electro at vgr dot pl

Description:

apache 2.2.11 with php compiled as module crashes upon reading from
unix socket while communicating with mysql (5.1.32, pdo driver). It
happens only in some specific circumstances but I haven't been able to
trace it so far. What is important is that php crashes always in the
same point in my application which I confirmed by stracing apache.
Configure Command'./configure' '--prefix=/usr/local/php5'
'--with-libdir=lib64' '--with-apxs2=/usr/sbin/apxs' '--with-curl'
'--with-iconv' '--with-libxml-dir' '--with-mysql' '--with-openssl'
'--with-pdo-mysql' '--with-pear' '--with-pcre-regex' '--with-zlib'
'--disable-all' '--disable-cgi' '--disable-ipv6' '--enable-dom'
'--enable-embedded-mysqli' '--enable-libxml' '--enable-memory-limit 

Reproduce code:
---
haven't been able to trace the bug to some specific code yet, but
watching strace output I can see that php crashes always in the same
moment. I will try to extract specific code that makes php crash.

Actual result:
--
socket(PF_FILE, SOCK_STREAM, 0) = 34
fcntl(34, F_SETFL, O_RDONLY)= 0
fcntl(34, F_GETFL)  = 0x2 (flags O_RDWR)
fcntl(34, F_GETFL)  = 0x2 (flags O_RDWR)
fcntl(34, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
connect(34, {sa_family=AF_FILE, path="/var/lib/mysql/mysql.sock"...},
110) = 0
fcntl(34, F_SETFL, O_RDWR)  = 0
setsockopt(34, SOL_SOCKET, SO_RCVTIMEO,
"\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0"..., 16) = 0
setsockopt(34, SOL_SOCKET, SO_SNDTIMEO,
"\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0"..., 16) = 0
setsockopt(34, SOL_IP, IP_TOS, [8], 4)  = -1 EOPNOTSUPP (Operation not
supported)
setsockopt(34, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
poll([{fd=34, events=POLLIN}], 1, 3) = 1 ([{fd=34,
revents=POLLIN}])
read(34,
"4\0\0\0\n5.1.32\0\231)\0\0t7U&ZsT-\0\377\367\300\2\0\0\0\0"..., 16384)
= 56
stat("/usr/share/mysql/charsets/Index.xml", {st_mode=S_IFREG|0644,
st_size=18261, ...}) = 0
open("/usr/share/mysql/charsets/Index.xml", O_RDONLY) = 35
read(35, "http://bugs.php.net/?id=47743&edit=1



#47773 [Opn->Asn]: cURL multi crashes

2009-03-31 Thread jani
 ID:   47773
 Updated by:   j...@php.net
 Reported By:  entpman at gmail dot com
-Status:   Open
+Status:   Assigned
 Bug Type: cURL related
-Operating System: WIN XP SP2
+Operating System: win32 only - WIN XP SP2
 PHP Version:  5.2.9
 Assigned To:  pajoye


Previous Comments:


[2009-03-25 15:29:52] entpman at gmail dot com

I tried version 5.3.0RC2-dev same results.



[2009-03-25 14:08:06] entpman at gmail dot com

Description:

The program will work fine for hundreds of downloads then suddenly
crashes.

Reproduce code:
---
 'http://www.google.com'
),
array(
'url' => 'http://www.yahoo.com'
)
)
);

// of course more urls are needs

function downloadurls($downloads,$cookie = null){   
$timeout = 30;  
$mcurl = curl_multi_init();
$agent = "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12)
Gecko/2009201 Firefox/3.0.0.1";

foreach($downloads as $key=>$download){ 
$url = $download['url'];
$ch = curl_init();   
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($ch, CURLOPT_TIMEOUT, $timeout);
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER,0);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 15);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST,0);
curl_setopt($ch, CURLOPT_USERAGENT, $agent);
if(!empty($download['postdata'])){
curl_setopt($ch, CURLOPT_POST, 1); 
curl_setopt($ch, CURLOPT_POSTFIELDS,$download['postdata']); 
}   
if(!empty($cookie)){
@unlink($cookie);
//echo "added cookie\n";
curl_setopt($ch, CURLOPT_COOKIEFILE, $cookie);
curl_setopt($ch, CURLOPT_COOKIEJAR, $cookie);
}
if(!empty($download['proxy'])){
curl_setopt($ch, CURLOPT_PROXY, $download['proxy']);
}
curl_multi_add_handle($mcurl, $ch);
$downloads[$key]['handle'] = $ch;   
}

do {
$n=curl_multi_exec($mcurl,$active);
usleep(100);
}   
while ($active);

foreach($downloads as $key=>$download){ 
$ch = $download['handle'];
$done_content = curl_multi_getcontent($ch);
if(curl_errno($ch) == 0) {
$downloads[$key]['picture'] = $done_content;
} else {
exit('error');  
}
curl_multi_remove_handle($mcurl, $ch);
curl_close($ch);   
}

curl_multi_close($mcurl);
return $downloads;
}
?>

Actual result:
--
backtrace:

php_curl.dll!_Curl_llist_insert_next()  + 0x48 bytes
php_curl.dll!_Curl_hash_add()  + 0x74 bytes 
php_curl.dll!_Curl_cache_addr()  + 0x6d bytes   
php_curl.dll!_Curl_addrinfo4_callback()  + 0x82 bytes   
php_curl.dll!_Curl_addrinfo4_callback()  + 0x14 bytes   
php_curl.dll!_Curl_getaddrinfo()  + 0x317 bytes 
msvcrt.dll!77c3a3b0()   
[Frames below may be incorrect and/or missing, no symbols loaded for
msvcrt.dll] 
kernel32.dll!7c80b683() 





-- 
Edit this bug report at http://bugs.php.net/?id=47773&edit=1



#47776 [Opn->Bgs]: -without-ldap-sasl option is ignored

2009-03-31 Thread jani
 ID:   47776
 Updated by:   j...@php.net
 Reported By:  tprohaska2 at honeywell dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: AIX 5.3
 PHP Version:  5.2.9
 New Comment:

Your ldap lib is compiled with sasl, hence you're REQUIRED to use 
this. (no, this is not a bug)


Previous Comments:


[2009-03-25 16:05:37] tprohaska2 at honeywell dot com

Description:

configure fails while looking for sasl symbols
--without-ldap-sasl as chosen 


Reproduce code:
---
./configure \
--with-ldap=/webapp/DSRSK/lib/ldapcsdk \
--with-oci8=instantclient,/webapp/instantclient10_1 \
--with-apxs2=/webapp/apache/2.2.11/bin/apxs \
--with-config-file-path=/webapp/apache/2.2.11/conf/httpd.conf \
--with-zlib-dir=/webapp/local/lib \
--without-ldap-sasl \
--enable-shared  \
--disable-static \
--without-zlib-dir \
--without-bz2 \
--without-sqlite \


Expected result:

expect it not to fail - expect it to not look for sasl related symbols

Actual result:
--
configure:53481: checking for ldap_parse_result
configure:53509: gcc -o conftest -I/usr/include -DHAVE_LONG_LONG 
-I/webapp/DSRS
K/lib/ldapcsdk/include -L/usr/lib  -L/opt/freeware/lib
-L/opt/freeware/lib -L/we
bapp/DSRSK/lib/ldapcsdk/lib -L/webapp/DSRSK/lib/ldapcsdk/lib conftest.c
-lssl3 -
lprldap50 -lldap50 -lssldap50 -llber50 -lplds4 -lplc4 -lnspr4 -lm 
-lxml2 -licon
v -lm -lxml2 -liconv -lm  1>&5
ld: 0711-317 ERROR: Undefined symbol: .pthread_getspecific
ld: 0711-317 ERROR: Undefined symbol: .pthread_setspecific
ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_destroy
ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_init
ld: 0711-317 ERROR: Undefined symbol: .sasl_setprop
ld: 0711-317 ERROR: Undefined symbol: .sasl_client_start
ld: 0711-317 ERROR: Undefined symbol: .sasl_client_step
ld: 0711-317 ERROR: Undefined symbol: .sasl_getprop
ld: 0711-317 ERROR: Undefined symbol: .sasl_client_new
ld: 0711-317 ERROR: Undefined symbol: .sasl_dispose
ld: 0711-317 ERROR: Undefined symbol: .sasl_encode
ld: 0711-317 ERROR: Undefined symbol: .sasl_decode
ld: 0711-317 ERROR: Undefined symbol: .sasl_set_alloc
ld: 0711-317 ERROR: Undefined symbol: .sasl_client_init
ld: 0711-317 ERROR: Undefined symbol: .pthread_key_create
ld: 0711-317 ERROR: Undefined symbol: pthread_mutex_lock
...
...
...





-- 
Edit this bug report at http://bugs.php.net/?id=47776&edit=1



#47844 [Opn->Bgs]: Why Global varible $HTTP_REFERER work firfox but it not work in IE 7..????

2009-03-31 Thread jani
 ID:   47844
 Updated by:   j...@php.net
 Reported By:  reachtobrijeshm4013 at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: MS XP
 PHP Version:  5.2.9
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:


[2009-03-31 07:30:34] reachtobrijeshm4013 at gmail dot com

Description:

Why Global varible $HTTP_REFERER work firfox but it not work in IE
7.. 






-- 
Edit this bug report at http://bugs.php.net/?id=47844&edit=1



#47786 [Opn->Fbk]: ldap_list get "Decoding error" on some specific searching attribute

2009-03-31 Thread jani
 ID:   47786
 Updated by:   j...@php.net
 Reported By:  tedc21thc at hotmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: LDAP related
 Operating System: FreeBSD 7.1
 PHP Version:  5.2.9
 New Comment:

What makes you think it's not expected result?

>From manual about ldap_list():

"LDAP_SCOPE_ONELEVEL means that the search should only return 
information that is at the level immediately below the base_dn given 
in the call. (Equivalent to typing "ls" and getting a list of files 
and folders in the current working directory.)"



Previous Comments:


[2009-03-26 09:46:53] tedc21thc at hotmail dot com

Description:

target ldap server : notes
PHP version : 5.2.9(CLI)
OS: FreeBSD ( tested on 5.4 and 7.1)
When using "ldap_list" on specific basedn and specific attribute
combination will get "Decoding error" (-4) error.

look seems like bug #5433
But "Decoding error" only happens on searching for 
("cn","mail","proxyaddresses","ou") attributes,
and will NOT get error if changing these attirbute's sorting or
add/remove some other attributes.

ps: using ldap_search wont get error.

Reproduce code:
---
$ldp_svrip ='192.168.100.150';   // IP
$ldp_acc = '';
$ldp_pwd = '';
$ldp_svrport ='';   // Port
$ldp_dn = 'OU=tw,O=iei2';   // DN
$ldp_filter = '(objectclass=*)';   // FILTER
$ldp_jth = array("cn","mail","proxyaddresses","ou");   // Attribute
$ds = ldap_connect($ldp_svrip, $ldp_svrport) ;
$rbind = ldap_bind($ds, $ldp_acc, $ldp_pwd);
$sr = @ldap_list($ds, $ldp_dn, $ldp_filter, $ldp_jth);
echo LDAP_ERROR($ds);
$info = ldap_get_entries($ds, $sr);

Expected result:

"Success"

Actual result:
--
"Decoding error"





-- 
Edit this bug report at http://bugs.php.net/?id=47786&edit=1



#47789 [Bgs]: Opera file upload - multiple files from one input cannot be handled

2009-03-31 Thread michal dot aichinger at gmail dot com
 ID:   47789
 User updated by:  michal dot aichinger at gmail dot com
 Reported By:  michal dot aichinger at gmail dot com
 Status:   Bogus
 Bug Type: *General Issues
 Operating System: Windows / Linux
 PHP Version:  5.2.9
 New Comment:

I am pretty shure that this is bug. PHP does not respect
multipart/mixed  part in POST request and it is clearly a bug. This part
is valid and is made only by Opera in this example.


Previous Comments:


[2009-03-31 07:20:07] j...@php.net

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.





[2009-03-26 14:33:55] michal dot aichinger at gmail dot com

Description:

Code below makes form with one file input. In Opera and Safari 4 it is
possible select more than one file in this input. If you send this form
in Safari it is in PHP normaly handled like multi file upload (multiple
inputs). Upload from Opera caused empty $_FILES array. 

The diference between this browsers is that Opera use multipart/mixed
for packing files from this input when posting data.

Reproduce code:
---
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml"; xml:lang="cs" lang="cs">
  
  
  Multiupload
  
  
Multiupload








  



Expected result:

full $_FILES array after sending more files selected in files[] input 
from Opera

Actual result:
--
array is empty





-- 
Edit this bug report at http://bugs.php.net/?id=47789&edit=1



#47844 [NEW]: Why Global varible $HTTP_REFERER work firfox but it not work in IE 7..????

2009-03-31 Thread reachtobrijeshm4013 at gmail dot com
From: reachtobrijeshm4013 at gmail dot com
Operating system: MS XP
PHP version:  5.2.9
PHP Bug Type: PHP options/info functions
Bug description:  Why Global varible $HTTP_REFERER work firfox but it not work 
in IE 7.. 

Description:

Why Global varible $HTTP_REFERER work firfox but it not work in IE 7..



-- 
Edit bug report at http://bugs.php.net/?id=47844&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47844&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47844&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47844&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47844&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47844&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47844&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47844&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47844&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47844&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47844&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47844&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47844&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47844&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47844&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47844&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47844&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47844&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47844&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47844&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47844&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47844&r=mysqlcfg



#47787 [Bgs]: VC++ 2005 build error

2009-03-31 Thread dpage at pgadmin dot org
 ID:   47787
 User updated by:  dpage at pgadmin dot org
 Reported By:  dpage at pgadmin dot org
 Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Windows XP
 PHP Version:  5.2.9
 New Comment:

It obviously was a bug in PHP, given that a fix was committed to CVS
which resolves precisely the problem I reported.


Previous Comments:


[2009-03-31 07:22:02] j...@php.net

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.





[2009-03-26 16:26:18] dpage at pgadmin dot org

I get the same bison error building the source tarball from
http://windows.php.net/snapshots/



[2009-03-26 14:59:18] paj...@php.net

I don't think using the mac to checkout the code is a good idea (or
tgz). You can simply fetch the snaps source from http://windows.php.net,
the new lines will be correct (and bison will not cry).



[2009-03-26 14:46:10] dpage at pgadmin dot org

I built the tarball from CVS on the mac (using a tweaked version of the
makedist script) and then transferred it to the Windows build server.

Glad to see it's fixed anyway - thanks.



[2009-03-26 14:34:17] paj...@php.net

on your mac?

The HAVE_STRNLEN  issue is already fixed in CVS.



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/47787

-- 
Edit this bug report at http://bugs.php.net/?id=47787&edit=1



#47801 [Opn]: __call() accessed via parent:: operator is provided incorrect method name

2009-03-31 Thread jani
 ID:   47801
 Updated by:   j...@php.net
 Reported By:  kkauper at yahoo-inc dot com
 Status:   Open
 Bug Type: Class/Object related
 Operating System: FreeBSD 4
 PHP Version:  5.2.9
 New Comment:

See also bug #42937


Previous Comments:


[2009-03-27 03:29:40] kkauper at yahoo-inc dot com

Description:

If parent:: (NOTE: this is *not* a static invocation) is
called in a child class, and  does not exist in the parent,
the parent's __call() magic method is provided the method name (the
$name argument) in lower case.

See the code provided to reproduce the problem. The $b->getFoo(); call
should output the method name as "getFoo", including the upercase "F"
character. Instead, the method name is converted to all lower case. To
be consistent with the results of $a->getFoo();, the method name should
not be converted to lower case.

This issue is probably related to the recently resolved bug # 42937.

Reproduce code:
---
class A
{
  function __call($name, $args)
  {
echo("magic method called: $name\n");
  }
}

class B extends A
{
  function getFoo()
  {
parent::getFoo();
  }
}

$a = new A();
$a->getFoo();

$b = new B();
$b->getFoo();

Expected result:

magic method called: getFoo
magic method called: getFoo 

Actual result:
--
magic method called: getFoo
magic method called: getfoo 





-- 
Edit this bug report at http://bugs.php.net/?id=47801&edit=1



#47787 [Opn->Bgs]: VC++ 2005 build error

2009-03-31 Thread jani
 ID:   47787
 Updated by:   j...@php.net
 Reported By:  dpage at pgadmin dot org
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Windows XP
 PHP Version:  5.2.9
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:


[2009-03-26 16:26:18] dpage at pgadmin dot org

I get the same bison error building the source tarball from
http://windows.php.net/snapshots/



[2009-03-26 14:59:18] paj...@php.net

I don't think using the mac to checkout the code is a good idea (or
tgz). You can simply fetch the snaps source from http://windows.php.net,
the new lines will be correct (and bison will not cry).



[2009-03-26 14:46:10] dpage at pgadmin dot org

I built the tarball from CVS on the mac (using a tweaked version of the
makedist script) and then transferred it to the Windows build server.

Glad to see it's fixed anyway - thanks.



[2009-03-26 14:34:17] paj...@php.net

on your mac?

The HAVE_STRNLEN  issue is already fixed in CVS.



[2009-03-26 13:34:49] dpage at pgadmin dot org

HEAD of the 5.2 branch fails at the beginning with:

bison.exe --output=Zend/zend_ini_parser.c -v -d -p ini_
Zend/zend_ini_parser.y
NMAKE : fatal error U1077: 'bison.exe' : return code '0xc135'

I get that from a straight CVS checkout and from a tarball from a
modified version of makedist (modified to use the head of the 5.2
branch) on on my mac.

Unfortunately my windows box is a part of a bigger buildfarm, on which
I can't do much in the way of debugging and testing other than to feed
it new tarballs and see if they build or not.



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/47787

-- 
Edit this bug report at http://bugs.php.net/?id=47787&edit=1



#47800 [Opn->Bgs]: Sessions won't be loaded when Cookies are disabled

2009-03-31 Thread jani
 ID:   47800
 Updated by:   j...@php.net
 Reported By:  whistl0r+phpbug at googlemail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Session related
 Operating System: Windows
 PHP Version:  5.3.0RC1
 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php




Previous Comments:


[2009-03-27 02:36:36] whistl0r+phpbug at googlemail dot com

Description:

When forcing PHP to not use cookies for sessions, PHP isn't able to
load an existing session. Instead it will create a new one.

Tested with the default php.ini (php.ini-production) coming with the
php-5.3.0RC1-nts-Win32-VC6-x86.zip package.

I just fixed line 428 and set the session.save_path value.

Session files will be created as expected.

With PHP <5.3, the script is working as expected.

I can confirm, that this problem is still present in the latest
snapshot (VC6 x86 Thread Safe (2009-Mar-26 19:00:00)).

Reproduce code:
---
' . PHP_EOL, $_SESSION['counter']);

// Print Next link
printf('Next',
$_SERVER['PHP_SELF'],
SID
);


Expected result:

When you first run this code, a session with a variable "counter" with
the value "1" (int) should be created and a link pointing to the same
script with this SESSION-ID should be displayed.

When you click this link, you run this code again and the previous
created session should be loaded and the "counter" variable should be
incremented by 1.

Actual result:
--
On every run, PHP creates a new session.





-- 
Edit this bug report at http://bugs.php.net/?id=47800&edit=1



#47817 [Opn->Bgs]: PHP hangs when running proc_open()

2009-03-31 Thread jani
 ID:   47817
 Updated by:   j...@php.net
 Reported By:  steven dot abarnett at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: Windows XP
 PHP Version:  5.2.9
 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php




Previous Comments:


[2009-03-29 11:49:35] steven dot abarnett at gmail dot com

I have found a fix for now, although I would like to know if better
options exist. The fault seems to lie in Windows. Both XP and Vista
refuse to allow file descriptors over 2. When I changed the code like so
it worked just fine:

$descriptors = array(
0 => array("pipe", "r"), // STDIN. Used to feed input
1 => array("pipe", "r"), // STDOUT. We are writing to it,
though
2 => array("pipe", "w"), // STDERR. Used to read errors
);
// Build the command line and start the process
$cmd = '"C:/program files/gnu/gnupg/gpg.exe" --batch
--no-verbose --passphrase-fd 1 --output decrypted.zip --decrypt
encrypted.zip.gpg';
$gpg = proc_open( $cmd, $descriptors, $pipes);
if(is_resource($gpg)) {
// Push passphrase to custom pipe
fwrite($pipes[1], $passphrase);
fclose($pipes[1]);
proc_close($gpg);
}


Is there a solution to be able to create more pipes in Windows? It's
very inconvenient having to write to STDOUT just to make my program work
properly, as it prevents me from reading any output thrown out by the
code (other than errors)



[2009-03-28 02:48:21] steven dot abarnett at gmail dot com

Description:

Unfortunately as far as I can tell, I am the only person having this
problem- which leads me to wonder if it's an issue with my PHP
configuration. Although I keep using default configuration, so I am at a
loss. I have tried installing PHP and Apache, I have tried in xampp, and
I have tried in WAMP. Every time after running the proc_open() command
the PHP script will wait for the process to close before reading the
next line- making reading or writing to any pipes impossible.

$fileDesc = array(
0 => array("pipe", "r"), // STDIN
1 => array("pipe", "w"), // STDOUT
2 => array("pipe", "w") // STDERR
);
die("Got this far");
$handle = proc_open("C:/wherever/program.exe", $fileDesc, $pipes);
fwrite($pipes[0], "input");
fclose($pipes[0]);
proc_close($handle);

Displays "Got this far" and dies, as expected. However:

$fileDesc = array(
0 => array("pipe", "r"), // STDIN
1 => array("pipe", "w"), // STDOUT
2 => array("pipe", "w") // STDERR
);
$handle = proc_open("C:/wherever/program.exe", $fileDesc, $pipes);
die("Got this far");
fwrite($pipes[0], "input");
fclose($pipes[0]);
proc_close($handle);

Will simply hang and seem to cease all function. The moment that I
close program.exe through task manager the script continues as if
nothing were wrong, dying with the output "Got this far". The input is
never passed to the program, although no errors are raised when I hit
the proc_close() line.

Reproduce code:
---
$descriptors = array(
0 => array("pipe", "r"), // STDIN. Used to feed input
1 => array("pipe", "w"), // STDOUT. Used to read output
2 => array("pipe", "w"), // STDERR. Used to read errors
3 => array("pipe", "r") // We can feed the passphrase here
);
// Build the command line and start the process
$cmd = '"C:/program files/gnu/gnupg/gpg.exe" --batch
--no-verbose --passphrase-fd 3 --output decrypted.zip --decrypt
encrypted.zip.gpg';
$gpg = proc_open( $cmd, $descriptors, $pipes);
if(is_resource($gpg)) {
// Push passphrase to custom pipe
fwrite($pipes[3], $passphrase);
fclose($pipes[3]);
proc_close($gpg);
}

Expected result:

Expected to find decrypted.zip in the same directory as the PHP script
(a decrypted version of encrypted.zip.gpg, which is located in the same
directory as the PHP script)

Actual result:
--
When localhost/test.php was run the webpage continued to load
indefinitely. I waited as long as 20 minutes. The PHP.ini file should
stop execution after 30 seconds. When gpg.exe was killed with task
manager the page loaded but the .zip file was never created.





-- 
Edit this bug report at http://bugs.php.net/?id=47817&edit=1



#47789 [Opn->Bgs]: Opera file upload - multiple files from one input cannot be handled

2009-03-31 Thread jani
 ID:   47789
 Updated by:   j...@php.net
 Reported By:  michal dot aichinger at gmail dot com
-Status:   Open
+Status:   Bogus
-Bug Type: Unknown/Other Function
+Bug Type: *General Issues
 Operating System: Windows / Linux
 PHP Version:  5.2.9
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:


[2009-03-26 14:33:55] michal dot aichinger at gmail dot com

Description:

Code below makes form with one file input. In Opera and Safari 4 it is
possible select more than one file in this input. If you send this form
in Safari it is in PHP normaly handled like multi file upload (multiple
inputs). Upload from Opera caused empty $_FILES array. 

The diference between this browsers is that Opera use multipart/mixed
for packing files from this input when posting data.

Reproduce code:
---
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml"; xml:lang="cs" lang="cs">
  
  
  Multiupload
  
  
Multiupload








  



Expected result:

full $_FILES array after sending more files selected in files[] input 
from Opera

Actual result:
--
array is empty





-- 
Edit this bug report at http://bugs.php.net/?id=47789&edit=1



#47809 [Opn->Fbk]: PHP doesn't parse the php.ini file

2009-03-31 Thread jani
 ID:   47809
 Updated by:   j...@php.net
 Reported By:  privat at timohummel dot com
-Status:   Open
+Status:   Feedback
 Bug Type: PHP options/info functions
 Operating System: Gentoo
 PHP Version:  5.3.0RC1
 Assigned To:  pajoye
 New Comment:

To make this a bit simpler, delete that file and create one with only 
this:

include_path = "foo/bar"

Then check what phpinfo() says in apache about the include_path.
Note: this works fine for me..

Also, your configure line is kinda odd. Using --disable-all and only 
enabling what you really need would make the line quite more 
readable..




Previous Comments:


[2009-03-30 18:53:47] privat at timohummel dot com

It is the stock php.ini-development file, where I tried to set the
default timezone to "Europe/Berlin". As it didn't work, I reverted my
change of the timezone and tried modifying other values, for example,
the error reporting and also simple values like "precision". None of my
changes were shown after a restart of apache using the phpinfo()-call.

As I said before, changes are accepted when using the cli sapi.



[2009-03-30 18:07:19] j...@php.net

What exactly is in that file?



[2009-03-27 19:02:25] privat at timohummel dot com

I just ran apache with strace to make sure that the php.ini file is
actually opened. It is opened, but I'm not sure how to debug if the
values are getting parsed and probably overwritten later or if the
values in the php.ini file are silently ignored.



[2009-03-27 16:11:27] privat at timohummel dot com

I rebuilt PHP from the CVS, snapshot
http://snaps.php.net/php5.3-200903271530.tar.bz2 (latest snapshot
currently available). The issue remains, all php.ini-entries are ignored
silently when using the apache2 SAPI.

Oddly enough, the CLI SAPI works fine and reads the config file as
expected.

Here's my configure line:
'./configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu'
'--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info'
'--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64'
'--disable-cli' '--with-apxs2=/usr/sbin/apxs2' '--disable-cgi'
'--with-config-file-path=/etc/php/apache2-php5'
'--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active'
'--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar'
'--with-curl' '--without-curlwrappers' '--disable-dbase'
'--disable-exif' '--without-fbsql' '--disable-fileinfo' '--enable-ftp'
'--with-gettext' '--with-gmp' '--disable-hash' '--without-kerberos'
'--enable-mbstring' '--with-mcrypt' '--without-mhash' '--without-msql'
'--without-mssql' '--with-openssl' '--with-openssl-dir=/usr'
'--disable-pcntl' '--with-pgsql' '--disable-posix' '--with-pspell'
'--without-recode' '--disable-simplexml' '--disable-shmop' '--with-snmp'
'--enable-soap' '--disable-sockets' '--without-sybase-ct'
'--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm'
'--with-tidy' '--enable-wddx' '--disable-xmlreader'
'--disable-xmlwriter' '--with-xmlrpc' '--with-xsl' '--enable-zip'
'--with-zlib' '--disable-debug' '--enable-dba' '--without-cdb'
'--with-db4' '--disable-flatfile' '--with-gdbm' '--disable-inifile'
'--without-qdbm' '--with-freetype-dir=/usr' '--with-t1lib=/usr'
'--disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr'
'--with-xpm-dir=/usr' '--with-gd' '--with-imap' '--with-imap-ssl'
'--with-mysql=/usr' '--with-mysql-sock=/var/run/mysqld/mysqld.sock'
'--with-mysqli=/usr/bin/mysql_config' '--without-pdo-dblib'
'--with-pdo-mysql=/usr' '--without-pdo-odbc' '--with-pdo-pgsql'
'--with-pdo-sqlite=/usr' '--with-readline' '--without-libedit'
'--without-mm' '--with-sqlite=/usr' '--enable-sqlite-utf8'
'--with-sqlite3'



[2009-03-27 15:06:54] paj...@php.net

This bug has been fixed in CVS.

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.





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/47809

-- 
Edit this bug report at http://bugs.php.net/?id=47809&edit=1



#47818 [Opn->Fbk]: Segfault due to bound callback param

2009-03-31 Thread jani
 ID:   47818
 Updated by:   j...@php.net
 Reported By:  galaxy dot mipt at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: XMLRPC-EPI related
 Operating System: Linux 2.6.18 x86
 PHP Version:  5.2.9
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.




Previous Comments:


[2009-03-28 04:04:16] galaxy dot mipt at gmail dot com

Description:

In my particular case when the callback for
xmlrpc_server_register_method() is a class method attempt to save some
of the parameters passed to that callback during
xmlrpc_server_call_method() call results in segfault.

Well, I cannot provide short code that would reproduce the segfault I
get in my application - it's sort of unstable. But the code below at
least show that something is really wrong here.

I believe that $method_name just gets garbage-collected no matter that
it is bound with $this->method. Decoupling them, for example like this,
helps:
$this->method = (string)$method_name;


Reproduce code:
---
class MyXmlRpc {

private $s;

private $method;

function impl($method_name, $params, $user_data){
$this->method = $method_name;
print "Inside impl(): {$this->method}\n";
return array_sum($params);
}

function __construct() {
$this->s = xmlrpc_server_create();
xmlrpc_server_register_method($this->s,'add', array($this,
'impl'));
}

function call($req) {
return xmlrpc_server_call_method($this->s, $req, null);
}

function getMethod() {return $this->method;}

}

$x = new MyXmlRpc;
$resp = $x->call(xmlrpc_encode_request('add',array(1,2,3)));

$method = $x->getMethod();

print "Global scope: $method\n";



Expected result:

Inside impl(): add
Global scope: add

Actual result:
--
Inside impl(): add
Global scope:





-- 
Edit this bug report at http://bugs.php.net/?id=47818&edit=1



#47825 [Opn->Bgs]: POST Data being ignored

2009-03-31 Thread jani
 ID:   47825
 Updated by:   j...@php.net
 Reported By:  tiposchi at tiscali dot it
-Status:   Open
+Status:   Bogus
 Bug Type: CGI related
 Operating System: GNU/Linux
 PHP Version:  5.2.9
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:


[2009-03-29 09:32:38] tiposchi at tiscali dot it

Description:

CGI protocol says that POST data must be passed to the script using
its standard input.

So what i have to do is something like (see the attached code).

Anyway, the php knows how long the input will be because it has an
environmental variable called content length that says it.

So php should wait to read the entire post data before going on.
Since i don't have any information about how the scheduler works, i
can't assure the father process to fill the pipe before the child is
scheduled.

But php ignores the data if the pipe isn't full already. So what i
did was filling the pipe BEFORE the fork, and doing this it works.
But there is another problem. With large POST data, the buffer is
filled and the OS puts my process on wait until the pipe is empty by
another process. But i didn't start the php yet because it wants all
the post data already present, so the webserver just hangs.

I think you should review the way php-cgi reads post data.

Thanks

Reproduce code:
---
p=pipe()

if (fork()==0) {
close(STDIN)
dup(p)
exec ("php")
} else {
write(p,str_post)
wait()
}

I HAVE MADE THE CODE SIMPLE. I KNOW THIS CAN'T WORK.






-- 
Edit this bug report at http://bugs.php.net/?id=47825&edit=1



#47824 [Opn->Fbk]: 64-bit build make check segmentation fault

2009-03-31 Thread jani
 ID:   47824
 Updated by:   j...@php.net
 Reported By:  jr at e-integration dot net
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Solaris 10 SPARC u6
 PHP Version:  5.2.9
 New Comment:

Can you provide the backtrace of the crash..?


Previous Comments:


[2009-03-29 03:34:58] jr at e-integration dot net

Used the following build tools:

gcc 4.2.4
gmake 3.81
re2c 0.13.5
bison 2.4.1



[2009-03-29 03:31:52] jr at e-integration dot net

Description:

# make

The make completes without error.

# ./sapi/cli/php --version
PHP 5.2.9 (cli) (built: Mar 26 2009 23:43:41)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

# make test

Build complete.
Don't forget to run 'make test'.

Segmentation Fault - core dumped
make: [test] Error 139 (ignored)

Build environment:  Solaris 10 SPARC u6; 64-bit used gcc 4.2.4 and GNU
make 3.81

Expected result:

make test creates two core files if you have coreadm set like so:

# coreadm
 global core file pattern:
 global core file content: default
   init core file pattern: /var/core/init_core.%n.%z.%u.%f.%p
   init core file content: default
global core dumps: disabled
   per-process core dumps: enabled
  global setid core dumps: disabled
 per-process setid core dumps: enabled
 global core dump logging: enabled

# ls -lt /var/core/
total 106272
-rw--- 1 root root 27865628 Mar 27 10:38
init_core.halo.global.0.php.7926
-rw--- 1 root root 26489372 Mar 27 10:38
init_core.halo.global.0.php.7924
-rw--- 1 root root 27865628 Mar 27 10:30
init_core.halo.global.0.php.7757
-rw--- 1 root root 26489372 Mar 27 10:30
init_core.halo.global.0.php.7751







-- 
Edit this bug report at http://bugs.php.net/?id=47824&edit=1