#47492 [Com]: SOAP_SINGLE_ELEMENT_ARRAYS has no effect
ID: 47492
Comment by: niek at signet dot nl
Reported By: florian dot eberle at gmail dot com
Status: Open
Bug Type: SOAP related
Operating System: Debian Lenny
PHP Version: 5.2CVS-2009-02-24 (CVS)
New Comment:
I've the same problem; but I use WSDL with my SOAP.
Previous Comments:
[2009-02-24 13:33:47] florian dot eberle at gmail dot com
Description:
The Feature SOAP_SINGLE_ELEMENT_ARRAYS has no effect when I try to get
a resultset that sometimes contains only one Object. It always removes
the array and returns the Object without the array.
See Example Code for additional information and feel free to contact me
for additional information.
Reproduce code:
---
?php
$options = array(
'location' = 'http://u8020.intx.ch.netstream.com/dnssoap/soap.cgi'
,
'uri' = 'http://dnstool.netstream.com/DnsAPI' ,
'exceptions' = false ,
'trace' = false ,
'soap_version' = SOAP_1_1 ,
'user_agent' = 'PHP DNS Client' ,
'features' = SOAP_SINGLE_ELEMENT_ARRAYS
);
$soapserver = new SoapClient(null, $options);
//Watch Param type = A here -- array 2 results expected here
$result = $soapserver-__soapCall('GetResourceRecords',
array(new SoapParam('wtf.com', 'zone') , new SoapParam('A',
'type')
));
var_dump($result);
//Watch Param type = MX here -- array with 1 result expected here
$result = $soapserver-__soapCall('GetResourceRecords',
array(new SoapParam('wtf.com', 'zone') , new SoapParam('MX',
'type')
));
var_dump($result);
?
Expected result:
array(2) {
[total]=
string(1) 2
[records]=
array(2) {
[0]=
object(stdClass)#4 (7) {
[name]=
string(4) test
[class]=
string(2) IN
[data]=
string(9) 127.0.0.1
[id]=
string(6) 160441
[parameter]=
string(0)
[ttl]=
string(0)
[type]=
string(1) A
}
[1]=
object(stdClass)#5 (7) {
[name]=
string(4) test
[class]=
string(2) IN
[data]=
string(9) 127.0.0.1
[id]=
string(6) 160442
[parameter]=
string(0)
[ttl]=
string(0)
[type]=
string(1) A
}
}
}
array(2) {
[total]=
string(1) 2
[records]=
array(1) {
[0]=
object(stdClass)#4 (7) {
[name]=
string(4) stop.bugging.me
[class]=
string(2) IN
[data]=
string(9) 32
[id]=
string(6) 160443
[parameter]=
string(0) 50
[ttl]=
string(0) 1337
[type]=
string(1) MX
}
}
}
Actual result:
--
array(2) {
[total]=
string(1) 2
[records]=
array(2) {
[0]=
object(stdClass)#4 (7) {
[name]=
string(4) test
[class]=
string(2) IN
[data]=
string(9) 127.0.0.1
[id]=
string(6) 160441
[parameter]=
string(0)
[ttl]=
string(0)
[type]=
string(1) A
}
[1]=
object(stdClass)#5 (7) {
[name]=
string(4) test
[class]=
string(2) IN
[data]=
string(9) 127.0.0.1
[id]=
string(6) 160442
[parameter]=
string(0)
[ttl]=
string(0)
[type]=
string(1) A
}
}
}
array(2) {
[total]=
string(1) 1
[records]=
object(stdClass)#6 (7) {
[name]=
string(15) stop.bugging.me
[class]=
string(2) IN
[data]=
string(2) 32
[id]=
string(6) 160443
[parameter]=
string(2) 50
[ttl]=
string(4) 1337
[type]=
string(2) MX
}
}
--
Edit this bug report at http://bugs.php.net/?id=47492edit=1
#50299 [Com]: method is called in context of another object
ID: 50299
Comment by: shepik at yandex dot ru
Reported By: shepik at yandex dot ru
Status: Open
Bug Type: SPL related
Operating System: *
PHP Version: 5.3SVN-2009-11-25 (snap)
New Comment:
it seems that rewind and valid are called on $P variable and not on
the contents of $P variable at the moment foreach was called.
#3 0x08397fe1 in zend_call_function (fci=0xbfdeeaf4,
fci_cache=0xbfdeeac4)
at /home/shepik/php-5.3-200911260930/Zend/zend_execute_API.c:942
#4 0x083bef94 in zend_call_method (object_pp=0xbfdeeb60,
obj_ce=0x8f20038, fn_proxy=0x8f20180,
function_name=0x871959d rewind, function_name_len=6,
retval_ptr_ptr=0x0, param_count=0, arg1=0x0, arg2=0x0)
at /home/shepik/php-5.3-200911260930/Zend/zend_interfaces.c:97
#5 0x083bf735 in zend_user_it_rewind (_iter=0x8f23754)
at /home/shepik/php-5.3-200911260930/Zend/zend_interfaces.c:261
*(zval*)iter-it.data = {value = {lval = 1, dval =
5.6472996106671002e-268, str = {val = 0x1 Address 0x1 out of bounds,
len = 141731200}, ht = 0x1, obj = {handle = 1, handlers = 0x872a580}},
refcount__gc = 3, type = 5 '\005',
is_ref__gc = 1 '\001'}
now callind valid:
#1 0x083bef20 in zend_call_method (object_pp=0xbfdeeb5c,
obj_ce=0x8f20038, fn_proxy=0x8f20170,
function_name=0x87194c5 valid, function_name_len=5,
retval_ptr_ptr=0xbfdeeb58, param_count=0, arg1=0x0,
arg2=0x0) at
/home/shepik/php-5.3-200911260930/Zend/zend_interfaces.c:88
#2 0x083bf1d9 in zend_user_it_valid (_iter=0x8f23754)
at /home/shepik/php-5.3-200911260930/Zend/zend_interfaces.c:163
*(zval*)iter-it.data = {value = {lval = 0, dval =
8.4879831638610893e-314, str = {val = 0x0, len = 4}, ht = 0x0, obj =
{handle = 0,
handlers = 0x4}}, refcount__gc = 2, type = 0 '\0', is_ref__gc = 1
'\001'}
(i don't know if this information is useful at all, but hope it is)
Previous Comments:
[2009-11-26 11:05:29] shepik at yandex dot ru
she...@samoval ~/php-5.3-200911260930 $ gdb sapi/cli/php
GNU gdb 6.8 [..]
This GDB was configured as i686-pc-linux-gnu...
(gdb) run test_variant2.php
Starting program: /home/shepik/php-5.3-200911260930/sapi/cli/php
test_variant2.php
rewind on Foo
Program received signal SIGSEGV, Segmentation fault.
0x083a67d7 in zend_get_class_entry (zobject=0x8e536c0) at
/home/shepik/php-5.3-200911260930/Zend/zend_API.c:230
230 if (Z_OBJ_HT_P(zobject)-get_class_entry) {
(gdb) bt
#0 0x083a67d7 in zend_get_class_entry (zobject=0x8e536c0) at
/home/shepik/php-5.3-200911260930/Zend/zend_API.c:230
#1 0x083bef20 in zend_call_method (object_pp=0xbfc6b3cc,
obj_ce=0x8e50038, fn_proxy=0x8e50170,
function_name=0x87194c5 valid, function_name_len=5,
retval_ptr_ptr=0xbfc6b3c8, param_count=0, arg1=0x0,
arg2=0x0) at
/home/shepik/php-5.3-200911260930/Zend/zend_interfaces.c:88
#2 0x083bf1d9 in zend_user_it_valid (_iter=0x8e53754)
at /home/shepik/php-5.3-200911260930/Zend/zend_interfaces.c:163
#3 0x08446999 in ZEND_FE_RESET_SPEC_CV_HANDLER
(execute_data=0x8e7dba0)
at /home/shepik/php-5.3-200911260930/Zend/zend_vm_execute.h:22653
#4 0x083d0b7e in execute (op_array=0x8e51a84) at
/home/shepik/php-5.3-200911260930/Zend/zend_vm_execute.h:104
#5 0x083a605e in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/shepik/php-5.3-200911260930/Zend/zend.c:1194
#6 0x0833df90 in php_execute_script (primary_file=0xbfc6d8cc)
at /home/shepik/php-5.3-200911260930/main/main.c:2231
#7 0x0846b874 in main (argc=2, argv=0xbfc6da24) at
/home/shepik/php-5.3-200911260930/sapi/cli/php_cli.c:1190
[2009-11-26 10:18:32] ka...@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-11-25 21:56:09] shepik at yandex dot ru
(and i don't know if i should select SPL related or reproducible
crash category, so if i'm wrong with selecting SPL, please correct
me)
[2009-11-25 21:17:57] shepik at yandex dot ru
And if change code to
$P = new lazyNew(function() use ($P) {
$v = new ArrayIterator(array(1,2,3,4,5));
$P = null;
return $v;
});
instead of fatal error, or 12345, or something else, i get
segmentation fault.
[2009-11-25 21:10:53] shepik at yandex dot ru
Description:
I tried this in php 5.3.2-dev (snapshot from 2009-11-19,
#50270 [Com]: ldap_start_tls problem
ID: 50270 Comment by: jcarlos at dsi dot uclm dot es Reported By: jcarlos at dsi dot uclm dot es Status: To be documented Bug Type: LDAP related Operating System: windows PHP Version: 5.3.1 New Comment: In Step 1, I have downloaded the certificate the the url https://www.myDomain.com Previous Comments: [2009-11-26 11:05:18] paj...@php.net Moving to the to be documented state, it could be very usefull to have this info in the ldap documentation. [2009-11-26 10:54:10] jcarlos at dsi dot uclm dot es A little manual, for a easy configuration INTEGRATING ACTIVE DIRECTORY WITH PHP-LDAP AND TLS == My configuration: Apache/2.2.14 (Win32) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11 NOTE 1: At the momment, the versión 5.3.1 fail with tls NOTE 2: This example works on windows, but in linux is similar 1) Download the Certificate X.509 (PEM format) from a web browser, I used Firefox. I put the name webcert.crt 2) Create the folder c:\openldap\sysconf 3) Copy the file webcert.crt to c:\openldap\sysconf 4) With notepad you must create the file c:\openldap\sysconf\ldap.conf file. The file contents: TLS_REQCERT never TLS_CACERT c:\openldap\sysconf\webcert.crt 5) The code: ?php $ldap=ldap.myDomain.com; $usr=u...@mydomain.com; $pwd=mypassword; $ds=ldap_connect($ldap); $ldapbind=false; if(ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3)) if(ldap_set_option($ds, LDAP_OPT_REFERRALS, 0)) if(ldap_start_tls($ds)) $ldapbind = @ldap_bind($ds, $usr, $pwd); ldap_close($ds); if(!$ldapbind) echo ERROR; else echo OK; ? [2009-11-24 10:44:19] jcarlos at dsi dot uclm dot es I have tested with: Apache/2.2.14 (Win32) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11 (works fine) Apache/2.2.14 (Win32) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.3.1 (same error) [2009-11-24 09:11:21] jcarlos at dsi dot uclm dot es Also, if I'm going back to php-5.2.11 works fine, but if I change the php-5.3.1 not working sorry for my english [2009-11-24 09:02:50] jcarlos at dsi dot uclm dot es In the past, I always updated the php version and I have never had problems. I have in c:\openldap\sysconf\ the file ldap.conf TLS_REQCERT never TLS_CACERT C:\OpenLdap\sysconf\certs\cert_dom_uclm.pem I have compiled Filezilla Server with support for ldap and It works perfect now. http://forum.filezilla-project.org/viewtopic.php?f=6t=11146 It run with AD. 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/50270 -- Edit this bug report at http://bugs.php.net/?id=50270edit=1
#50309 [NEW]: Add plain-text sanitizing to filter
From: marcus at synchromedia dot co dot uk Operating system: PHP version: 5.3.1 PHP Bug Type: Feature/Change Request Bug description: Add plain-text sanitizing to filter Description: While the FILTER_FLAG_STRIP_LOW and FILTER_FLAG_STRIP_HIGH flags used with FILTER_SANITIZE_STRING work fine, They are just a bit blunt to be useful in practice. A more normal application would be to remove any 'funny' characters from plain text, so for example to allow chars 9, 10, 13, 32-126. This could be called FILTER_FLAG_PLAIN_TEXT. While this could be done using regex, it's probably the most common use case, so deserves a dedicated filter flag. This could be flipped around and be called FILTER_FLAG_ALLOW_WHITESPACE, overriding STRIP_LOW to allow chars 9, 10, 13 through. Similarly, a very common need is to normalize line breaks to \n, \r\n or \r. -- Edit bug report at http://bugs.php.net/?id=50309edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50309r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50309r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50309r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50309r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50309r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50309r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50309r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50309r=needscript Try newer version: http://bugs.php.net/fix.php?id=50309r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50309r=support Expected behavior: http://bugs.php.net/fix.php?id=50309r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50309r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50309r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50309r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50309r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50309r=dst IIS Stability: http://bugs.php.net/fix.php?id=50309r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50309r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50309r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50309r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50309r=mysqlcfg
#50265 [Opn-Fbk]: endless loop waiting for child process
ID: 50265 Updated by: j...@php.net Reported By: mg at fork dot pl -Status: Open +Status: Feedback Bug Type: CGI related Operating System: Linux PHP Version: 5.2.11 New Comment: Please let us know when you figure out how to reliably reproduce this. Until that, do not change the status. Thank you. Previous Comments: [2009-11-25 23:04:00] mg at fork dot pl The problem happens where there's NO child process (wait4 returns -1 with errno set to ECHILD). It looks like child mysteriously vanished between fork() and wait(). Unfortunately I cannot easily reproduce the problem so we're still waiting for this to happen. I think it may be important that called php script uses exec() to call some utilities. [2009-11-25 13:17:12] j...@php.net Well, that means the child is running and this process is the main process waiting it to terminate. So is that child in endless loop or what? And if it is, why? That's the real problem here.. [2009-11-24 22:00:17] mg at fork dot pl My previous comment shows state BEFORE the problem hits. Many forking messages are because of low MAX_REQUEST limit. When I attached to the process running inside the endless loop (it was before recompilation with DEBUG_FASTCGI) I got following bt #0 0xe424 in __kernel_vsyscall () #1 0xb712fc6d in __libc_wait (stat_loc=0xbff2d2a4) at ../sysdeps/unix/sysv/linux/wait.c:32 #2 0x0845e720 in main (argc=0, argv=Cannot access memory at address 0x4 ) at /usr/src/debug/dev-lang/php-5.2.11/php-5.2.11/sapi/cgi/cgi_main.c:1632 [2009-11-24 20:20:27] j...@php.net 1 child is in endless loop or what? Try attach to such process with gdb and see what the backtrace says. [2009-11-24 03:02:09] mg at fork dot pl I rebuilt php and started up, but as I don't know what exactly causes the problem we'll have to wait until it happens... I started it like % PHP_FCGI_CHILDREN=2 PHP_FCGI_MAX_REQUESTS=100 php-cgi -e -b 127.0.0.1:30004 -c /.../php.ini Process group 2720 Forking, 0 running Forking, 1 running Wait for kids, pid 2720 Forking, 1 running Wait for kids, pid 2720 Forking, 1 running Wait for kids, pid 2720 Forking, 1 running Wait for kids, pid 2720 pstree -uap shows `-php-cgi,2720 -e -b 127.0.0.1:30004 -c /.../php.ini |-php-cgi,13821 -e -b 127.0.0.1:30004 -c /.../php.ini `-php-cgi,13822 -e -b 127.0.0.1:30004 -c /.../php.ini 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/50265 -- Edit this bug report at http://bugs.php.net/?id=50265edit=1
#47397 [Com]: php://stdout gives odd behavior under CGI/Apache
ID: 47397
Comment by: ruj dot sabya at gmail dot com
Reported By: shaunspiller at gmail dot com
Status: No Feedback
Bug Type: Output Control
Operating System: Any?
PHP Version: 5.2.9RC2
New Comment:
I am also facing this problem.
Version: 5.2.9-2
Previous Comments:
[2009-02-23 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-16 16:12:56] shaunspiller at gmail dot com
I'm using php-5.2.9RC2-Win32-VC6-x86.zip (last modified:
2009-Feb-12).
The STDOUT constant is only defined for CLI. The documentation isn't
clear on what the correct behavior of the stdout stream should be under
other interfaces.
[2009-02-15 23:15:53] j...@php.net
1. Exactly what PHP version are you using here?
2. What if you don't open another stdout stream but use the STDOUT
constant, does it work better..?
For more info: http://www.php.net/wrappers.php
[2009-02-15 19:16:22] shaunspiller at gmail dot com
Description:
Hi!
I think this might be a bug. I was writing some code that used output
buffering, but which also bypassed it by writing directly to stdout.
I've done before it under CLI but the results I got under CGI and as an
Apache module were a bit strange:
Example 1:
--
?php
echo 1. echo, before output bufferingbr\n;
ob_start();
echo 2. echo, during output bufferingbr\n;
flush();
/* in theory, this line will be output immediately while 2 4 will be
held back until ob_end_flush() */
$stdout = fopen('php://stdout', 'w');
fwrite($stdout, 3. fwrite to stdout, during output bufferingbr\n);
echo 4. echo, during output bufferingbr\n;
ob_end_flush();
echo 5. echo, after output bufferingbr\n;
?
Result:
---
I'm not expert on how PHP communicates with its various output
mechanisms. These are just my observations from testing this code:
* Under CLI, this example works, and the displayed order is 1, 3, 2, 4,
5.
* As an Apache module, no. 3 is never output, no matter how much I try
to flush it through. (Maybe that is the intended behavior, since the
STDOUT constant is not defined.)
* Under CGI, no. 3 is never output **unless** at least 1 previous
byte has been flushed (provided by the echo()s and flush() call, above).
In that case, the displayed order is 1, 3, 2, 4, 5 again. I'm not sure
if it's supposed to work or not, but the inconsistency seems wrong.
* (In all cases, the fopen call returns a valid stream.)
Example 2:
--
?php
header('Cache-Control: no-cache');
$stdout = fopen('php://stdout', 'w');
fwrite($stdout, Location: http://www.php.net/\r\n;);
?
Result:
---
This is even stranger. Under CGI, if at least one call to header() has
been made and no other data has yet been flushed, writing to stdout puts
data directly into the HTTP response. In this case I've used a complete
valid header so it can be tested from a browser.
It's also possible to write complete garbage into the headers,
bypassing the header() function's restrictions (this is best observed
via telnet), and this is what was unintentionally happening when I first
encountered this.
Expected result:
It would be nice if stdout would always work, and always bypass output
buffering. Otherwise, it should at least be consistent within each
interface.
--
Edit this bug report at http://bugs.php.net/?id=47397edit=1
#50290 [Com]: 5.3.1 iis fast cgi module time out on accessing mysql
ID: 50290 Comment by: avivahl at gmail dot com Reported By: praveen at aexea dot net Status: Feedback Bug Type: MySQL related Operating System: vista business PHP Version: 5.3.1 Assigned To: mysql New Comment: Probably related to: http://bugs.php.net/bug.php?id=50172 Previous Comments: [2009-11-25 06:44:57] paj...@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 ?php and ends 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-11-24 23:22:18] praveen at aexea dot net Description: When upgraded php from 5.3.0 to latest 5.3.1 on IIS7 - Fast-CGI (vista business) edition. IIS7-fast cgi times out when any page is accessed which have mysql functions. All other things are working fine, problem is only with pages which use mysql. -- Edit this bug report at http://bugs.php.net/?id=50290edit=1
#50190 [Csd]: need libtool =1.5.26
ID: 50190 User updated by: ralphdoncaster at gmail dot com Reported By: ralphdoncaster at gmail dot com Status: Closed Bug Type: Feature/Change Request Operating System: AIX 5.3 PHP Version: 5.2.11 New Comment: The build instructions might need to be updated about the required version of libtool. http://php.net/svn.php Previous Comments: [2009-11-23 21:53:58] j...@php.net Fixed in SVN. [2009-11-20 20:06:38] ralphdoncaster at gmail dot com I guess you missed the part where I said I don't have gnu diff. [2009-11-20 19:48:10] j...@php.net I should have been more verbose I guess: I need diff -u (unified diff) and do NOT paste it here but in http://pastebin.com/ and provide the URL to the paste in this bug report. DO NOT EMAIL anything to me! [2009-11-20 14:01:01] j...@php.net Yes, I know all this. I really need the diff between the libtool that gets generated with stock PHP (which didn't work for you) and the libtool your replaced it with. Can you do this or not? If you can, put it to pastebin.com and submit the url here.. [2009-11-20 13:10:54] ralphdoncaster at gmail dot com I tried it again with need_version=1.5.26 and it makes no difference. 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/50190 -- Edit this bug report at http://bugs.php.net/?id=50190edit=1
#37865 [Com]: The SNMP extension does not support setting multiple OIDs
ID: 37865 Comment by: ch at lathspell dot de Reported By: lee dot duncan at intel dot com Status: Open Bug Type: Feature/Change Request Operating System: SUSE, Kernel 2.6.8-24.21-smp PHP Version: 5.1.4 New Comment: The above patch URL is no longer available. Does anybody still have the patch? I could put it on my web page until somebody adds it to the PHP upstream. Previous Comments: [2009-05-13 12:25:42] yanirj at orckit dot com Hi, On behalf of Lee Duncan's good will and Murali Sundar's kindess I've uploaded the patch for everyone to download. I truly hope this will get merged into the CVS tree for everyone to enjoy. URL: http://sphinx.not.nu/php_snmp_patch.zip Regards, Yanir. [2009-03-17 11:59:59] yanirj at orckit dot com It would be great if you post the patch. Thanks! [2008-05-21 12:21:57] daniel dot buschke at nextiraone dot de Lee, would you please add an attachment with your patch? TIA [2007-03-16 15:11:19] eqguy2002 at yahoo dot com Version: 5.2.1 OS: Windows 2003 PHP's snmpset extension does not support setting multiple OIDs at once. Doing so from the command line using snmpset from Net-SNMP works fine. I need to set multiple OIDs at once in order to manage switches [2006-06-21 00:09:05] lee dot duncan at intel dot com Description: In order to add an entry to many SNMP tables, you need to be able to set multiple OIDs (values) at the same time. The net-snmp snmpset command allows this, as do the libnetsnmp APIs, but the SNMP extension to PHP does not support this. I added a new function to ext/snmp.c to support setting multiple values at once, and I'd like to see it added to the PHP SNMP extension for all to use. Reproduce code: --- Just try to set multiple SNMP OIDs (object IDs) with the current API, which is: proto int snmp2_set(string host, string community, string object_id, string type, mixed value [, int timeout [, int retries]]) I added: proto int snmp2_set_arr(string host, string community, array oids, array types, array values [, int timeout [, int retries]]) This way, no current programs break and new programs can use this functionality. Expected result: I'd like to be able to manage things like Marvell switches, which only allow adding a Table entry (e.g. for a new VLAN) if you can set multiple values (OIDs) at the same time. Actual result: -- Right now I can't do this without hacking the PHP SNMP extension. -- Edit this bug report at http://bugs.php.net/?id=37865edit=1
#50312 [NEW]: Opening an https using fopen consumes all cpu time
From: kvr at centrum dot cz
Operating system: Linux, Debian
PHP version: 5.3SVN-2009-11-27 (snap)
PHP Bug Type: HTTP related
Bug description: Opening an https using fopen consumes all cpu time
Description:
When connecting to https server using fopen(https://...;), php
consumes all cpu time until the connection is established. When there
is problem with the remote https server, the cpu is occupied until
the script runs out of time.
Full version information: PHP 5.3.0-0.dotdeb.8 with Suhosin-Patch
0.9.7 (cli) (built: Aug 12 2009 18:11:27)
Reproduce code:
---
The following code can be used to reproduce:
$fd = fopen(https://whatever.com/index.html;, r)
Expected result:
The code should open the connection without busy waits.
Actual result:
--
The code keeps trying reading on non-blocked socket until some data
is received, see the strace:
25832 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 38
25832 fcntl64(38, F_GETFL) = 0x2 (flags O_RDWR)
25832 fcntl64(38, F_SETFL, O_RDWR|O_NONBLOCK) = 0
25832 connect(38, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr(w.x.y.z)}, 16) = -1 EINPROGRESS (Operation now
in progress)
25832 poll([{fd=38, events=POLLIN|POLLOUT|POLLERR|POLLHUP}], 1, 6
unfinished ...
25832 ... poll resumed ) = 1 ([{fd=38,
revents=POLLOUT}])
25832 getsockopt(38, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
25832 fcntl64(38, F_SETFL, O_RDWR) = 0
25832 fcntl64(38, F_GETFL) = 0x2 (flags O_RDWR)
25832 fcntl64(38, F_SETFL, O_RDWR|O_NONBLOCK) = 0
25832 gettimeofday({1259327624, 794801}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 time(NULL)= 1259327624
25832 write(38,
\200d\1\3\1\0K\0\0\0\20\0\0009\0\0008\0\0005\0\0\26\0\0\23\0\0\n\7\0
0\200\0\0\25\0\0\22\0\0\t\...@\0\0\24\0\0\21\0\0\10\0\0\6\4\0\200\0\0
25832 read(38, 0x8e62f78, 7)= -1 EAGAIN (Resource
temporarily unavailable)
25832 gettimeofday({1259327624, 795389}, {4294967176, 0}) = 0
25832 gettimeofday({1259327624, 795463}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 read(38, 0x8e62f78, 7)= -1 EAGAIN (Resource
temporarily unavailable)
... read repeats many times / or forever instead of polling socket
for POLLIN.
25832 read(38, 0x8e62f78, 5)= -1 EAGAIN (Resource
temporarily unavailable)
25832 gettimeofday({1259327624, 893179}, {4294967176, 0}) = 0
25832 gettimeofday({1259327624, 893222}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 read(38, \24\3\1\0\1, 5)= 5
When / if the data is received, the communication continues
correctly.
--
Edit bug report at http://bugs.php.net/?id=50312edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50312r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50312r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50312r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50312r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50312r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50312r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50312r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50312r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50312r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50312r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50312r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50312r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50312r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50312r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50312r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50312r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50312r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50312r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50312r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50312r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50312r=mysqlcfg
#47492 [Com]: SOAP_SINGLE_ELEMENT_ARRAYS has no effect
ID: 47492
Comment by: niek at signet dot nl
Reported By: florian dot eberle at gmail dot com
Status: Open
Bug Type: SOAP related
Operating System: Debian Lenny
PHP Version: 5.2CVS-2009-02-24 (CVS)
New Comment:
This bug was filed a long time ago, still no replies. Is there going to
be some kind of fix for this?
Previous Comments:
[2009-11-27 08:35:52] niek at signet dot nl
I've the same problem; but I use WSDL with my SOAP.
[2009-02-24 13:33:47] florian dot eberle at gmail dot com
Description:
The Feature SOAP_SINGLE_ELEMENT_ARRAYS has no effect when I try to get
a resultset that sometimes contains only one Object. It always removes
the array and returns the Object without the array.
See Example Code for additional information and feel free to contact me
for additional information.
Reproduce code:
---
?php
$options = array(
'location' = 'http://u8020.intx.ch.netstream.com/dnssoap/soap.cgi'
,
'uri' = 'http://dnstool.netstream.com/DnsAPI' ,
'exceptions' = false ,
'trace' = false ,
'soap_version' = SOAP_1_1 ,
'user_agent' = 'PHP DNS Client' ,
'features' = SOAP_SINGLE_ELEMENT_ARRAYS
);
$soapserver = new SoapClient(null, $options);
//Watch Param type = A here -- array 2 results expected here
$result = $soapserver-__soapCall('GetResourceRecords',
array(new SoapParam('wtf.com', 'zone') , new SoapParam('A',
'type')
));
var_dump($result);
//Watch Param type = MX here -- array with 1 result expected here
$result = $soapserver-__soapCall('GetResourceRecords',
array(new SoapParam('wtf.com', 'zone') , new SoapParam('MX',
'type')
));
var_dump($result);
?
Expected result:
array(2) {
[total]=
string(1) 2
[records]=
array(2) {
[0]=
object(stdClass)#4 (7) {
[name]=
string(4) test
[class]=
string(2) IN
[data]=
string(9) 127.0.0.1
[id]=
string(6) 160441
[parameter]=
string(0)
[ttl]=
string(0)
[type]=
string(1) A
}
[1]=
object(stdClass)#5 (7) {
[name]=
string(4) test
[class]=
string(2) IN
[data]=
string(9) 127.0.0.1
[id]=
string(6) 160442
[parameter]=
string(0)
[ttl]=
string(0)
[type]=
string(1) A
}
}
}
array(2) {
[total]=
string(1) 2
[records]=
array(1) {
[0]=
object(stdClass)#4 (7) {
[name]=
string(4) stop.bugging.me
[class]=
string(2) IN
[data]=
string(9) 32
[id]=
string(6) 160443
[parameter]=
string(0) 50
[ttl]=
string(0) 1337
[type]=
string(1) MX
}
}
}
Actual result:
--
array(2) {
[total]=
string(1) 2
[records]=
array(2) {
[0]=
object(stdClass)#4 (7) {
[name]=
string(4) test
[class]=
string(2) IN
[data]=
string(9) 127.0.0.1
[id]=
string(6) 160441
[parameter]=
string(0)
[ttl]=
string(0)
[type]=
string(1) A
}
[1]=
object(stdClass)#5 (7) {
[name]=
string(4) test
[class]=
string(2) IN
[data]=
string(9) 127.0.0.1
[id]=
string(6) 160442
[parameter]=
string(0)
[ttl]=
string(0)
[type]=
string(1) A
}
}
}
array(2) {
[total]=
string(1) 1
[records]=
object(stdClass)#6 (7) {
[name]=
string(15) stop.bugging.me
[class]=
string(2) IN
[data]=
string(2) 32
[id]=
string(6) 160443
[parameter]=
string(2) 50
[ttl]=
string(4) 1337
[type]=
string(2) MX
}
}
--
Edit this bug report at http://bugs.php.net/?id=47492edit=1
#50314 [NEW]: File upload problem
From: jj07020 at lanet dot lv
Operating system: Windows XP Pro SP3
PHP version: 5.3.1
PHP Bug Type: Apache2 related
Bug description: File upload problem
Description:
It is possible to supply a filename which will be incorrectly parsed by
PHP. The problem occurs when uploading a file from an HTML form with
attributes name=file[ (lacking the closing bracket) and type=file. I'm
using Apache 2.2.14 PHP 5.3.1, but I was able to reproduce the bug with
Apache 2.2.10 PHP 5.3.0.
Reproduce code:
---
HTML form - form.html:
form method=post enctype=multipart/form-data action=upload.php
input type=file name=file[ /
input type=submit value=OK /
/form
PHP code - upload.php:
?php
var_dump($_FILES);
?
The body of the HTTP request:
3PL7QzumhbsotvnG6nZnmR
Content-Disposition: form-data; name=file[; filename=code.gif
Content-Type: image/gif
binary gif data
3PL7QzumhbsotvnG6nZnmR--
Expected result:
The array $_FILES should contain valid keys as specified in
http://www.php.net/manual/en/features.file-upload.post-method.php. Hovever,
the following assertion fails:
if (isset($_FILES[file])) {
assert(is_string($_FILES[name])); // actual key is [name
}
Since the filename (file[) lacks the closing bracket, it probably should
be interpreted as a single file named file[:
array(1) { [file[]= array(5) { [name]= string(8) code.gif
[type]= string(9) image/gif [tmp_name]= string(17)
C:\Temp\php3A.tmp [error]= int(0) [size]= int(3342) } }
Actual result:
--
The array $_FILES:
array(1) { [file]= array(5) { [[name]= string(8) code.gif
[[type]= string(9) image/gif [[tmp_name]= string(17)
C:\Temp\php3A.tmp [[error]= int(0) [[size]= int(3342) } }
--
Edit bug report at http://bugs.php.net/?id=50314edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50314r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50314r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50314r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50314r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50314r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50314r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50314r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50314r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50314r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50314r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50314r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50314r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50314r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50314r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50314r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50314r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50314r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50314r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50314r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50314r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50314r=mysqlcfg
#50314 [Opn-Fbk]: File upload problem
ID: 50314
Updated by: j...@php.net
Reported By: jj07020 at lanet dot lv
-Status: Open
+Status: Feedback
Bug Type: Apache2 related
Operating System: Windows XP Pro SP3
PHP Version: 5.3.1
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2009-11-27 14:20:01] jj07020 at lanet dot lv
Description:
It is possible to supply a filename which will be incorrectly parsed by
PHP. The problem occurs when uploading a file from an HTML form with
attributes name=file[ (lacking the closing bracket) and type=file.
I'm using Apache 2.2.14 PHP 5.3.1, but I was able to reproduce the bug
with Apache 2.2.10 PHP 5.3.0.
Reproduce code:
---
HTML form - form.html:
form method=post enctype=multipart/form-data action=upload.php
input type=file name=file[ /
input type=submit value=OK /
/form
PHP code - upload.php:
?php
var_dump($_FILES);
?
The body of the HTTP request:
3PL7QzumhbsotvnG6nZnmR
Content-Disposition: form-data; name=file[; filename=code.gif
Content-Type: image/gif
binary gif data
3PL7QzumhbsotvnG6nZnmR--
Expected result:
The array $_FILES should contain valid keys as specified in
http://www.php.net/manual/en/features.file-upload.post-method.php.
Hovever, the following assertion fails:
if (isset($_FILES[file])) {
assert(is_string($_FILES[name])); // actual key is [name
}
Since the filename (file[) lacks the closing bracket, it probably
should be interpreted as a single file named file[:
array(1) { [file[]= array(5) { [name]= string(8) code.gif
[type]= string(9) image/gif [tmp_name]= string(17)
C:\Temp\php3A.tmp [error]= int(0) [size]= int(3342) } }
Actual result:
--
The array $_FILES:
array(1) { [file]= array(5) { [[name]= string(8) code.gif
[[type]= string(9) image/gif [[tmp_name]= string(17)
C:\Temp\php3A.tmp [[error]= int(0) [[size]= int(3342) } }
--
Edit this bug report at http://bugs.php.net/?id=50314edit=1
#50312 [Opn-Fbk]: Opening an https using fopen consumes all cpu time
ID: 50312
Updated by: j...@php.net
Reported By: kvr at centrum dot cz
-Status: Open
+Status: Feedback
Bug Type: HTTP related
Operating System: Linux, Debian
PHP Version: 5.3SVN-2009-11-27 (snap)
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works fine for me. Try without any 3rd party patches.
Previous Comments:
[2009-11-27 13:37:07] kvr at centrum dot cz
Description:
When connecting to https server using fopen(https://...;), php
consumes all cpu time until the connection is established. When there
is problem with the remote https server, the cpu is occupied until
the script runs out of time.
Full version information: PHP 5.3.0-0.dotdeb.8 with Suhosin-Patch
0.9.7 (cli) (built: Aug 12 2009 18:11:27)
Reproduce code:
---
The following code can be used to reproduce:
$fd = fopen(https://whatever.com/index.html;, r)
Expected result:
The code should open the connection without busy waits.
Actual result:
--
The code keeps trying reading on non-blocked socket until some data
is received, see the strace:
25832 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 38
25832 fcntl64(38, F_GETFL) = 0x2 (flags O_RDWR)
25832 fcntl64(38, F_SETFL, O_RDWR|O_NONBLOCK) = 0
25832 connect(38, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr(w.x.y.z)}, 16) = -1 EINPROGRESS (Operation now
in progress)
25832 poll([{fd=38, events=POLLIN|POLLOUT|POLLERR|POLLHUP}], 1, 6
unfinished ...
25832 ... poll resumed ) = 1 ([{fd=38,
revents=POLLOUT}])
25832 getsockopt(38, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
25832 fcntl64(38, F_SETFL, O_RDWR) = 0
25832 fcntl64(38, F_GETFL) = 0x2 (flags O_RDWR)
25832 fcntl64(38, F_SETFL, O_RDWR|O_NONBLOCK) = 0
25832 gettimeofday({1259327624, 794801}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 time(NULL)= 1259327624
25832 write(38,
\200d\1\3\1\0K\0\0\0\20\0\0009\0\0008\0\0005\0\0\26\0\0\23\0\0\n\7\0
0\200\0\0\25\0\0\22\0\0\t\...@\0\0\24\0\0\21\0\0\10\0\0\6\4\0\200\0\0
25832 read(38, 0x8e62f78, 7)= -1 EAGAIN (Resource
temporarily unavailable)
25832 gettimeofday({1259327624, 795389}, {4294967176, 0}) = 0
25832 gettimeofday({1259327624, 795463}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 read(38, 0x8e62f78, 7)= -1 EAGAIN (Resource
temporarily unavailable)
... read repeats many times / or forever instead of polling socket
for POLLIN.
25832 read(38, 0x8e62f78, 5)= -1 EAGAIN (Resource
temporarily unavailable)
25832 gettimeofday({1259327624, 893179}, {4294967176, 0}) = 0
25832 gettimeofday({1259327624, 893222}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 read(38, \24\3\1\0\1, 5)= 5
When / if the data is received, the communication continues
correctly.
--
Edit this bug report at http://bugs.php.net/?id=50312edit=1
#50312 [Fbk]: Opening an https using fopen consumes all cpu time
ID: 50312
Updated by: j...@php.net
Reported By: kvr at centrum dot cz
Status: Feedback
Bug Type: HTTP related
Operating System: Linux, Debian
PHP Version: 5.3SVN-2009-11-27 (snap)
New Comment:
Unless of course your provided code is supposed to work at all?
This works too:
# php -r '$fd = fopen(https://master.php.net/manage/users.php;, r);'
Previous Comments:
[2009-11-27 14:28:31] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works fine for me. Try without any 3rd party patches.
[2009-11-27 13:37:07] kvr at centrum dot cz
Description:
When connecting to https server using fopen(https://...;), php
consumes all cpu time until the connection is established. When there
is problem with the remote https server, the cpu is occupied until
the script runs out of time.
Full version information: PHP 5.3.0-0.dotdeb.8 with Suhosin-Patch
0.9.7 (cli) (built: Aug 12 2009 18:11:27)
Reproduce code:
---
The following code can be used to reproduce:
$fd = fopen(https://whatever.com/index.html;, r)
Expected result:
The code should open the connection without busy waits.
Actual result:
--
The code keeps trying reading on non-blocked socket until some data
is received, see the strace:
25832 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 38
25832 fcntl64(38, F_GETFL) = 0x2 (flags O_RDWR)
25832 fcntl64(38, F_SETFL, O_RDWR|O_NONBLOCK) = 0
25832 connect(38, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr(w.x.y.z)}, 16) = -1 EINPROGRESS (Operation now
in progress)
25832 poll([{fd=38, events=POLLIN|POLLOUT|POLLERR|POLLHUP}], 1, 6
unfinished ...
25832 ... poll resumed ) = 1 ([{fd=38,
revents=POLLOUT}])
25832 getsockopt(38, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
25832 fcntl64(38, F_SETFL, O_RDWR) = 0
25832 fcntl64(38, F_GETFL) = 0x2 (flags O_RDWR)
25832 fcntl64(38, F_SETFL, O_RDWR|O_NONBLOCK) = 0
25832 gettimeofday({1259327624, 794801}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 time(NULL)= 1259327624
25832 write(38,
\200d\1\3\1\0K\0\0\0\20\0\0009\0\0008\0\0005\0\0\26\0\0\23\0\0\n\7\0
0\200\0\0\25\0\0\22\0\0\t\...@\0\0\24\0\0\21\0\0\10\0\0\6\4\0\200\0\0
25832 read(38, 0x8e62f78, 7)= -1 EAGAIN (Resource
temporarily unavailable)
25832 gettimeofday({1259327624, 795389}, {4294967176, 0}) = 0
25832 gettimeofday({1259327624, 795463}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 read(38, 0x8e62f78, 7)= -1 EAGAIN (Resource
temporarily unavailable)
... read repeats many times / or forever instead of polling socket
for POLLIN.
25832 read(38, 0x8e62f78, 5)= -1 EAGAIN (Resource
temporarily unavailable)
25832 gettimeofday({1259327624, 893179}, {4294967176, 0}) = 0
25832 gettimeofday({1259327624, 893222}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 read(38, \24\3\1\0\1, 5)= 5
When / if the data is received, the communication continues
correctly.
--
Edit this bug report at http://bugs.php.net/?id=50312edit=1
#50297 [Fbk-Opn]: MessageFormatter::formatMessage don't support string with accent in it
ID: 50297 User updated by: pby_fr at yahoo dot fr Reported By: pby_fr at yahoo dot fr -Status: Feedback +Status: Open Bug Type: I18N and L10N related Operating System: Windows Vista 64 PHP Version: 5.3.1 New Comment: formatMessage being a static method, it is not possible to use getErrorMessage! I tested with a full object code: $fmt = new MessageFormatter(fr_FR, with accent à é); $fmt isn't an object, but FALSE Whit $fmt = new MessageFormatter(fr_FR, with accent a e); $fmt is an object, and everything works fine. Anyway, I must switch back to PHP 5.2, therefore I will recode a very simple formatter instead of use this class. Previous Comments: [2009-11-26 10:08:22] j...@php.net Try this: http://www.php.net/manual/en/messageformatter.geterrormessage.php You might have something like wrong locale there or something.. [2009-11-25 20:37:49] pby_fr at yahoo dot fr Description: Using accent character in the pattern of MessageFormatter::formatMessage return an empty string. Reproduce code: --- echo (MessageFormatter::formatMessage(fr_FR, with accent à é, array())); Expected result: to display: with accent à é Actual result: -- display nothing -- Edit this bug report at http://bugs.php.net/?id=50297edit=1
#50312 [Fbk-Opn]: Opening an https using fopen consumes all cpu time
ID: 50312
User updated by: kvr at centrum dot cz
Reported By: kvr at centrum dot cz
-Status: Feedback
+Status: Open
Bug Type: HTTP related
Operating System: Linux, Debian
PHP Version: 5.3SVN-2009-11-27 (snap)
New Comment:
Well, sorry, the URL address was supposed to be replaced with
anything real but preferably slow.
I compiled the php5.3-latest as proposed and the problem is there as
well.
Previous Comments:
[2009-11-27 14:31:01] j...@php.net
Unless of course your provided code is supposed to work at all?
This works too:
# php -r '$fd = fopen(https://master.php.net/manage/users.php;, r);'
[2009-11-27 14:28:31] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works fine for me. Try without any 3rd party patches.
[2009-11-27 13:37:07] kvr at centrum dot cz
Description:
When connecting to https server using fopen(https://...;), php
consumes all cpu time until the connection is established. When there
is problem with the remote https server, the cpu is occupied until
the script runs out of time.
Full version information: PHP 5.3.0-0.dotdeb.8 with Suhosin-Patch
0.9.7 (cli) (built: Aug 12 2009 18:11:27)
Reproduce code:
---
The following code can be used to reproduce:
$fd = fopen(https://whatever.com/index.html;, r)
Expected result:
The code should open the connection without busy waits.
Actual result:
--
The code keeps trying reading on non-blocked socket until some data
is received, see the strace:
25832 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 38
25832 fcntl64(38, F_GETFL) = 0x2 (flags O_RDWR)
25832 fcntl64(38, F_SETFL, O_RDWR|O_NONBLOCK) = 0
25832 connect(38, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr(w.x.y.z)}, 16) = -1 EINPROGRESS (Operation now
in progress)
25832 poll([{fd=38, events=POLLIN|POLLOUT|POLLERR|POLLHUP}], 1, 6
unfinished ...
25832 ... poll resumed ) = 1 ([{fd=38,
revents=POLLOUT}])
25832 getsockopt(38, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
25832 fcntl64(38, F_SETFL, O_RDWR) = 0
25832 fcntl64(38, F_GETFL) = 0x2 (flags O_RDWR)
25832 fcntl64(38, F_SETFL, O_RDWR|O_NONBLOCK) = 0
25832 gettimeofday({1259327624, 794801}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 time(NULL)= 1259327624
25832 write(38,
\200d\1\3\1\0K\0\0\0\20\0\0009\0\0008\0\0005\0\0\26\0\0\23\0\0\n\7\0
0\200\0\0\25\0\0\22\0\0\t\...@\0\0\24\0\0\21\0\0\10\0\0\6\4\0\200\0\0
25832 read(38, 0x8e62f78, 7)= -1 EAGAIN (Resource
temporarily unavailable)
25832 gettimeofday({1259327624, 795389}, {4294967176, 0}) = 0
25832 gettimeofday({1259327624, 795463}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 read(38, 0x8e62f78, 7)= -1 EAGAIN (Resource
temporarily unavailable)
... read repeats many times / or forever instead of polling socket
for POLLIN.
25832 read(38, 0x8e62f78, 5)= -1 EAGAIN (Resource
temporarily unavailable)
25832 gettimeofday({1259327624, 893179}, {4294967176, 0}) = 0
25832 gettimeofday({1259327624, 893222}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 read(38, \24\3\1\0\1, 5)= 5
When / if the data is received, the communication continues
correctly.
--
Edit this bug report at http://bugs.php.net/?id=50312edit=1
#42096 [NoF-Opn]: is_dir() truncates dirs when using UNC paths
ID: 42096 User updated by: michael202 at gmx dot de Reported By: michael202 at gmx dot de -Status: No Feedback +Status: Open Bug Type: Streams related Operating System: Windows only PHP Version: 5.2CVS-2007-07-24 New Comment: First I gave up on this issue and switched to drive letters. Now I tested php 5.3.1 and this bug is fixed ! It must have been an issue with php, because: I have two parallel installations of php (5.2.6 and 5.3.1) on the same computer. If I switch between these I can produce the bug with 5.2.6 and I don't have it with 5.3.1. Again: for each access to a file with a UNC path, something truncates the last character of the share name (here import - impor) resulting in hundreds of these error messages (/var/log/samba/log.smbd): [2009/11/27 18:07:44, 0] smbd/service.c:make_connection(794) pro (1.2.7.1) couldn't find service impor AND resulting in a very high load and a server hard reset. Thanks ! Previous Comments: [2007-09-08 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. [2007-08-31 10:04:20] j...@php.net As is_dir() uses stat to check whether passed path is directory or not I doubt this can really be any PHP bug, just another limitiation of Windows. Try doing the same using something else than PHP and I bet the result is the same. And this is totally bogus: echo(is_dir($p) . \n); Proto for the function http://php.net/is_dir is: bool is_dir ( string $filename ) Returns TRUE if the filename exists and is a directory, FALSE otherwise. [2007-08-08 09:09:04] michael202 at gmx dot de running a script that makes a few thousand accesses to a samba server (that is used by approx. 30 other hosts) causes this server to crash and dismount the samba share. [2007-07-25 14:43:22] michael202 at gmx dot de tested with php5.2-win32-latest.zip from today morning 2007-07-25 08h08 error is still in there [2007-07-25 08:48:13] michael202 at gmx dot de Description: calling is_dir() with an UNC path truncates each part of the path. The last character is missing. This results in unnecessary errors (on the host side) and slowdowns (on client side). Reproduce code: --- windows only (php 5.2.3, Windows XP with cmd.exe) and linux host. ?php $p = '\\hostA\volumeB\dirC'; echo(is_dir($p) . \n); and then trace network IO for service/port SMB. Beware of posssible side effects though caching of SMB connections Expected result: no error messages in /var/log/messages on 'hostA' Actual result: -- I traced these SMB Commands sent over the network: Connect AndX Request \\hostA\IPC$ Connect AndX Request \\hostA\volume - STATUS_BAD_NETWORK_NAME FindFirst2, Pattern: \dir these are in /var/log/messages in 'hostA' ... smbd/service.c:make_connection(252) ... couldn't find service volume I think this is another problem with tsrm_virtual_cwd.c where around line 500 state_cwd_length is set to 2 if a slash is found at the beginning. Perhaps the existence of UNC paths is not checked for. -- Edit this bug report at http://bugs.php.net/?id=42096edit=1
#42096 [Opn-Asn]: is_dir() truncates dirs when using UNC paths
ID: 42096 Updated by: paj...@php.net Reported By: michael202 at gmx dot de -Status: Open +Status: Assigned Bug Type: Streams related -Operating System: Windows only +Operating System: Windows -PHP Version: 5.2CVS-2007-07-24 +PHP Version: 5.2* -Assigned To: +Assigned To: pajoye New Comment: I have to verify with UNC path and 5.2. Previous Comments: [2009-11-27 17:18:56] michael202 at gmx dot de First I gave up on this issue and switched to drive letters. Now I tested php 5.3.1 and this bug is fixed ! It must have been an issue with php, because: I have two parallel installations of php (5.2.6 and 5.3.1) on the same computer. If I switch between these I can produce the bug with 5.2.6 and I don't have it with 5.3.1. Again: for each access to a file with a UNC path, something truncates the last character of the share name (here import - impor) resulting in hundreds of these error messages (/var/log/samba/log.smbd): [2009/11/27 18:07:44, 0] smbd/service.c:make_connection(794) pro (1.2.7.1) couldn't find service impor AND resulting in a very high load and a server hard reset. Thanks ! [2007-09-08 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. [2007-08-31 10:04:20] j...@php.net As is_dir() uses stat to check whether passed path is directory or not I doubt this can really be any PHP bug, just another limitiation of Windows. Try doing the same using something else than PHP and I bet the result is the same. And this is totally bogus: echo(is_dir($p) . \n); Proto for the function http://php.net/is_dir is: bool is_dir ( string $filename ) Returns TRUE if the filename exists and is a directory, FALSE otherwise. [2007-08-08 09:09:04] michael202 at gmx dot de running a script that makes a few thousand accesses to a samba server (that is used by approx. 30 other hosts) causes this server to crash and dismount the samba share. [2007-07-25 14:43:22] michael202 at gmx dot de tested with php5.2-win32-latest.zip from today morning 2007-07-25 08h08 error is still in there 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/42096 -- Edit this bug report at http://bugs.php.net/?id=42096edit=1
#50312 [Opn-Fbk]: Opening an https using fopen consumes all cpu time
ID: 50312
Updated by: j...@php.net
Reported By: kvr at centrum dot cz
-Status: Open
+Status: Feedback
Bug Type: HTTP related
Operating System: Linux, Debian
PHP Version: 5.3SVN-2009-11-27 (snap)
New Comment:
Well, did you try the short example I provided? That site isn't
exactly slow but since you're not providing anything to work with
that's what I tested and that works..
Previous Comments:
[2009-11-27 16:57:04] kvr at centrum dot cz
Well, sorry, the URL address was supposed to be replaced with
anything real but preferably slow.
I compiled the php5.3-latest as proposed and the problem is there as
well.
[2009-11-27 14:31:01] j...@php.net
Unless of course your provided code is supposed to work at all?
This works too:
# php -r '$fd = fopen(https://master.php.net/manage/users.php;, r);'
[2009-11-27 14:28:31] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works fine for me. Try without any 3rd party patches.
[2009-11-27 13:37:07] kvr at centrum dot cz
Description:
When connecting to https server using fopen(https://...;), php
consumes all cpu time until the connection is established. When there
is problem with the remote https server, the cpu is occupied until
the script runs out of time.
Full version information: PHP 5.3.0-0.dotdeb.8 with Suhosin-Patch
0.9.7 (cli) (built: Aug 12 2009 18:11:27)
Reproduce code:
---
The following code can be used to reproduce:
$fd = fopen(https://whatever.com/index.html;, r)
Expected result:
The code should open the connection without busy waits.
Actual result:
--
The code keeps trying reading on non-blocked socket until some data
is received, see the strace:
25832 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 38
25832 fcntl64(38, F_GETFL) = 0x2 (flags O_RDWR)
25832 fcntl64(38, F_SETFL, O_RDWR|O_NONBLOCK) = 0
25832 connect(38, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr(w.x.y.z)}, 16) = -1 EINPROGRESS (Operation now
in progress)
25832 poll([{fd=38, events=POLLIN|POLLOUT|POLLERR|POLLHUP}], 1, 6
unfinished ...
25832 ... poll resumed ) = 1 ([{fd=38,
revents=POLLOUT}])
25832 getsockopt(38, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
25832 fcntl64(38, F_SETFL, O_RDWR) = 0
25832 fcntl64(38, F_GETFL) = 0x2 (flags O_RDWR)
25832 fcntl64(38, F_SETFL, O_RDWR|O_NONBLOCK) = 0
25832 gettimeofday({1259327624, 794801}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 time(NULL)= 1259327624
25832 write(38,
\200d\1\3\1\0K\0\0\0\20\0\0009\0\0008\0\0005\0\0\26\0\0\23\0\0\n\7\0
0\200\0\0\25\0\0\22\0\0\t\...@\0\0\24\0\0\21\0\0\10\0\0\6\4\0\200\0\0
25832 read(38, 0x8e62f78, 7)= -1 EAGAIN (Resource
temporarily unavailable)
25832 gettimeofday({1259327624, 795389}, {4294967176, 0}) = 0
25832 gettimeofday({1259327624, 795463}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 read(38, 0x8e62f78, 7)= -1 EAGAIN (Resource
temporarily unavailable)
... read repeats many times / or forever instead of polling socket
for POLLIN.
25832 read(38, 0x8e62f78, 5)= -1 EAGAIN (Resource
temporarily unavailable)
25832 gettimeofday({1259327624, 893179}, {4294967176, 0}) = 0
25832 gettimeofday({1259327624, 893222}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 read(38, \24\3\1\0\1, 5)= 5
When / if the data is received, the communication continues
correctly.
--
Edit this bug report at http://bugs.php.net/?id=50312edit=1
#50312 [Fbk-Opn]: Opening an https using fopen consumes all cpu time
ID: 50312
User updated by: kvr at centrum dot cz
Reported By: kvr at centrum dot cz
-Status: Feedback
+Status: Open
Bug Type: HTTP related
Operating System: Linux, Debian
PHP Version: 5.3SVN-2009-11-27 (snap)
New Comment:
Yes, I tried it exactly as written in your example.
The php version was the latest: ~/iphp/bin/php -v
PHP 5.3.2-dev (cli) (built: Nov 27 2009 17:39:57)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
Did you check the strace output (or whatever tool your system
provides to trace program syscalls) ? Could you please attach it?
Previous Comments:
[2009-11-27 17:48:47] j...@php.net
Well, did you try the short example I provided? That site isn't
exactly slow but since you're not providing anything to work with
that's what I tested and that works..
[2009-11-27 16:57:04] kvr at centrum dot cz
Well, sorry, the URL address was supposed to be replaced with
anything real but preferably slow.
I compiled the php5.3-latest as proposed and the problem is there as
well.
[2009-11-27 14:31:01] j...@php.net
Unless of course your provided code is supposed to work at all?
This works too:
# php -r '$fd = fopen(https://master.php.net/manage/users.php;, r);'
[2009-11-27 14:28:31] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works fine for me. Try without any 3rd party patches.
[2009-11-27 13:37:07] kvr at centrum dot cz
Description:
When connecting to https server using fopen(https://...;), php
consumes all cpu time until the connection is established. When there
is problem with the remote https server, the cpu is occupied until
the script runs out of time.
Full version information: PHP 5.3.0-0.dotdeb.8 with Suhosin-Patch
0.9.7 (cli) (built: Aug 12 2009 18:11:27)
Reproduce code:
---
The following code can be used to reproduce:
$fd = fopen(https://whatever.com/index.html;, r)
Expected result:
The code should open the connection without busy waits.
Actual result:
--
The code keeps trying reading on non-blocked socket until some data
is received, see the strace:
25832 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 38
25832 fcntl64(38, F_GETFL) = 0x2 (flags O_RDWR)
25832 fcntl64(38, F_SETFL, O_RDWR|O_NONBLOCK) = 0
25832 connect(38, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr(w.x.y.z)}, 16) = -1 EINPROGRESS (Operation now
in progress)
25832 poll([{fd=38, events=POLLIN|POLLOUT|POLLERR|POLLHUP}], 1, 6
unfinished ...
25832 ... poll resumed ) = 1 ([{fd=38,
revents=POLLOUT}])
25832 getsockopt(38, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
25832 fcntl64(38, F_SETFL, O_RDWR) = 0
25832 fcntl64(38, F_GETFL) = 0x2 (flags O_RDWR)
25832 fcntl64(38, F_SETFL, O_RDWR|O_NONBLOCK) = 0
25832 gettimeofday({1259327624, 794801}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 time(NULL)= 1259327624
25832 write(38,
\200d\1\3\1\0K\0\0\0\20\0\0009\0\0008\0\0005\0\0\26\0\0\23\0\0\n\7\0
0\200\0\0\25\0\0\22\0\0\t\...@\0\0\24\0\0\21\0\0\10\0\0\6\4\0\200\0\0
25832 read(38, 0x8e62f78, 7)= -1 EAGAIN (Resource
temporarily unavailable)
25832 gettimeofday({1259327624, 795389}, {4294967176, 0}) = 0
25832 gettimeofday({1259327624, 795463}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 read(38, 0x8e62f78, 7)= -1 EAGAIN (Resource
temporarily unavailable)
... read repeats many times / or forever instead of polling socket
for POLLIN.
25832 read(38, 0x8e62f78, 5)= -1 EAGAIN (Resource
temporarily unavailable)
25832 gettimeofday({1259327624, 893179}, {4294967176, 0}) = 0
25832 gettimeofday({1259327624, 893222}, {4294967176, 0}) = 0
25832 time(NULL)= 1259327624
25832 read(38, \24\3\1\0\1, 5)= 5
When / if the data is received, the communication continues
correctly.
--
Edit this bug report at http://bugs.php.net/?id=50312edit=1
#50264 [Opn-Bgs]: Possible pcre memory leak
ID: 50264
Updated by: j...@php.net
Reported By: laszlo dot janszky at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: PCRE related
Operating System: Windows XP
PHP Version: 5.3.1
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-11-23 19:38:35] laszlo dot janszky at gmail dot com
If it is not clear, by the test:
the 8 tokens withBlock (M1) test string is:
$test='
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{/display}
{/display}
{/display}
{/display}
{/display}
{/display}
{/display}
{/display}
';
and the 8 tokens withoutBlock (M2) test string is:
$test='
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{display}
';
[2009-11-23 19:21:02] laszlo dot janszky at gmail dot com
The leak is in relation with this
http://bugs.php.net/bug.php?id=49333
Here is a simplyfied example with eight withoutBlock tokens:
?php
ini_set('pcre.backtrack_limit', 4);
ini_set('pcre.recursion_limit', 1000);
$pattern=
'%
{(\w+)(?:}
(.*?(?:(?0).*?)*?)
{/\1)?}
%usDx';
$test='
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{display}
';
preg_match_all($pattern,$test,$matches,PREG_SET_ORDER);
var_dump($matches);
?
The basic syntax is:
{withBlock}block{/withBlock}
or
{withoutBlock}
As the {withBlock} opener part is of the same structure like the
{withoutBlock}, it starts to collect the string after the {withoutBlock}
to the backtrace. But for some kind of reason the {withoutBlock}
backtrace eats up the memory superexponential, not linear like in the
case of {withBlock}.
A measured the memory usage with the simplyfied example. It was not
superexponential, just exponential. I think cause I have in this example
two capturing groups only, not a lot like in the original code.
tokens M1[b] M2[b] LN(M2)
1 19 22 3,0910
2 53 115 4,7449
3 87 405 6,0039
4 121 12867,1593
5 155 39408,2789
6 189 11913 9,3854
7 223 35843 10,4869
8 257 107644 11,6204
M1 = 34 * N - 15
R^2 = 1
M2 = exp ( 1,1192 * N + 2,6669 )
R^2 = 0, for the 3-8 part
Btw. it's funny memory usage.
[2009-11-22 18:53:14] laszlo dot janszky at gmail dot com
If I remove the recursive part
(?:\\}(?block.*?(?:(?0).*?)*?)\\{/(?P=function))?
from the end of the regex, then it works fine...
[2009-11-22 18:47:14] laszlo dot janszky at gmail dot com
Description:
I have a huge recursive regex (about 500bytes), which needs a lot of
memory for backtrace.
The regex matches on templates like
{command1 arg1=$arg1 arg2=$arg2|modifier2
arg3=text|modifier3:modarg31:modarg32}
etc
If I use the regex with preg_match_all, then the backtrace memory usage
depends on the count of the commands superexponential.
So:
R^2 = 0,9977 (R^2 for trendline)
ln ln M = 0,0787 * N + 1,9304
[M] = used backtrack memory in bytes
[N] = number of command calls
It don't think that more than 1Mb memory usage is normal for a 0.0002Mb
string.
The recursion memory usage is normal(under 1kb). I'm pretty
disappointed because I can't use my template engine because of a badly
written pcre engine.
Reproduce code:
---
$template1='
{display var=$link}
{display var=$link}
{display var=$link}
{display var=$link}
{display var=$link}
{display var=$link}
{display var=$link}
{display var=$link}
{display var=$link}
{display var=$link}
';
$template2='
{display var=$link}
{display var=$link}
{display var=$link}
{display var=$link}
test test test test test
test test test test test
test test test test test
test test test test test
test test test test test
test test test test test
test test test test test
test test test test test
test test test test test
test test test test test
';
#50312 [Opn-Fbk]: Opening an https using fopen consumes all cpu time
ID: 50312 Updated by: j...@php.net Reported By: kvr at centrum dot cz -Status: Open +Status: Feedback Bug Type: HTTP related Operating System: Linux, Debian PHP Version: 5.3SVN-2009-11-27 (snap) New Comment: Yes, it's the OpenSSL lib doing the read, what's the bug here? Previous Comments: [2009-11-27 17:56:41] kvr at centrum dot cz Yes, I tried it exactly as written in your example. The php version was the latest: ~/iphp/bin/php -v PHP 5.3.2-dev (cli) (built: Nov 27 2009 17:39:57) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies Did you check the strace output (or whatever tool your system provides to trace program syscalls) ? Could you please attach it? [2009-11-27 17:48:47] j...@php.net Well, did you try the short example I provided? That site isn't exactly slow but since you're not providing anything to work with that's what I tested and that works.. [2009-11-27 16:57:04] kvr at centrum dot cz Well, sorry, the URL address was supposed to be replaced with anything real but preferably slow. I compiled the php5.3-latest as proposed and the problem is there as well. [2009-11-27 14:31:01] j...@php.net Unless of course your provided code is supposed to work at all? This works too: # php -r '$fd = fopen(https://master.php.net/manage/users.php;, r);' [2009-11-27 14:28:31] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Works fine for me. Try without any 3rd party patches. 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/50312 -- Edit this bug report at http://bugs.php.net/?id=50312edit=1
#49700 [Opn-Fbk]: memory leaks in php_date.c if garbage collector is enabled
ID: 49700
Updated by: j...@php.net
Reported By: indey...@php.net
-Status: Open
+Status: Feedback
Bug Type: Date/time related
Operating System: Mac OS X 10.6.1
PHP Version: 5.3SVN-2009-09-28 (SVN)
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2009-10-07 05:48:38] ahar...@php.net
I can reproduce this with the current PHP_5_3 and with a custom-built
vanilla 5.3.0 on OS X 10.6.1, so long as the new garbage collector is
enabled via zend.enable_gc or gc_enable(). Linux is unaffected, as is
the php 5.3.0 build provided with OS X 10.6. The build I'm using is an
x86_64 compile, as the reporter's also appears to be. Most of the leaks
appear to be in time zone handling routines.
Interestingly, I can actually get this to segfault for certain numbers
of loop iterations with the current PHP_5_3 head, but not with 5.3.0.
This works fine up to and including 9993 iterations of the loop,
segfaults between 9994-9996 iterations, and then generates the memory
leak output in the report from 9997 iterations onwards.
Relevant gdb output (using PHP_5_3):
(gdb) r /tmp/test.php 9995
Starting program: /Users/adam/Trees/php5.3-200910070430/sapi/cli/php
/tmp/test.php 9995
Reading symbols for shared libraries .+. done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
0x7fff872b5c00 in strlen ()
(gdb) bt
#0 0x7fff872b5c00 in strlen ()
#1 0x000165b2 in date_object_get_properties
(object=0x7fff5fbff280) at
/Users/adam/Trees/php5.3-200910070430/ext/date/php_date.c:2101
#2 0x0001003da593 in zobj_mark_grey (obj=0x1020dc328,
pz=0x7fff5fbff280) at
/Users/adam/Trees/php5.3-200910070430/Zend/zend_gc.c:383
#3 0x0001003da6a9 in gc_mark_roots () at
/Users/adam/Trees/php5.3-200910070430/Zend/zend_gc.c:410
#4 0x0001003daff1 in gc_collect_cycles () at
/Users/adam/Trees/php5.3-200910070430/Zend/zend_gc.c:628
#5 0x0001003d9c2c in gc_zval_possible_root (zv=0x1009be148) at
/Users/adam/Trees/php5.3-200910070430/Zend/zend_gc.c:166
#6 0x00010039f0a7 in _zval_ptr_dtor (zval_ptr=0x1007fdff8,
__zend_filename=0x1004ea278
/Users/adam/Trees/php5.3-200910070430/main/main.c, __zend_lineno=1585)
at zend_gc.h:183
#7 0x000100331de8 in php_request_shutdown (dummy=0x0) at
/Users/adam/Trees/php5.3-200910070430/main/main.c:1585
#8 0x00010049e057 in main (argc=3, argv=0x7fff5fbff820) at
/Users/adam/Trees/php5.3-200910070430/sapi/cli/php_cli.c:1371
(gdb) frame 1
#1 0x000165b2 in date_object_get_properties
(object=0x7fff5fbff280) at
/Users/adam/Trees/php5.3-200910070430/ext/date/php_date.c:2101
2101ZVAL_STRING(zv,
dateobj-time-tz_info-name, 1);
(gdb) print *dateobj-time-tz_info
$1 = {
name = 0x6 Address 0x6 out of bounds,
ttisgmtcnt = 6,
ttisstdcnt = 0,
leapcnt = 12,
timecnt = 18,
typecnt = 4,
charcnt = 4,
trans = 0x0,
trans_idx = 0x0,
type = 0x0,
timezone_abbr = 0x0,
leap_times = 0x0,
bc = 1 '\001',
location = {
country_code = AU,
latitude = -31.953,
longitude = 115.850002,
comments = 0x0
}
}
The value of dateobj-time-tz_info-name is not consistent between
runs, even with the same number of iterations, but it's always an
invalid pointer value between 0 and 15, inclusive.
For completeness, the test script I'm using:
?php
gc_enable();
$a = array();
foreach (range(1, $_SERVER['argv'][1]) as $i) {
$a[] = new DateTime;
}
?
And the entire contents of the php.ini being used:
date.timezone = Australia/Perth
Let me know if there's anything I can do to help debug.
tl;dr: OS X specific; only occurs with the new garbage collector
enabled; possibly related to or at least triggered by something in the
time zone code.
[2009-10-02 22:44:55] f...@php.net
Probably Mac OS only...
Couldn't reproduce with latest snap (php5.3-200910022030) on Linux x86
without running into a memory_limit of 512 MB with CLI
[2009-09-28 17:25:28] indey...@php.net
Description:
If garbage-collector is enabled and large quantity of DateTime objects
is created, php reports memory leaks
Reproduce code:
---
?php
gc_enable();
$objs = array();
foreach (range(1,2) as $i) {
$objs[$i] = new DateTime();
}
Expected result:
DONE
Actual result:
--
DONE
[Mon Sep 28 21:23:24 2009] Script: '_mem_test.php'
/Users/indy/Documents/Sources/_mine/php5/ext/date/php_date.c(1137) :
Freeing 0x106340068 (79 bytes), script=_mem_test.php
Last leak repeated 39993 times
[Mon Sep 28 21:23:24 2009]
#50312 [Fbk-Opn]: Opening an https using fopen consumes all cpu time
ID: 50312 User updated by: kvr at centrum dot cz Reported By: kvr at centrum dot cz -Status: Feedback +Status: Open Bug Type: HTTP related Operating System: Linux, Debian PHP Version: 5.3SVN-2009-11-27 (snap) New Comment: php (or OpenSSL library) doesn't handle the error code EAGAIN and instead of waiting for data using select() or poll(), it calls read() again and again, taking all the cpu time. Previous Comments: [2009-11-27 18:04:20] j...@php.net Yes, it's the OpenSSL lib doing the read, what's the bug here? [2009-11-27 17:56:41] kvr at centrum dot cz Yes, I tried it exactly as written in your example. The php version was the latest: ~/iphp/bin/php -v PHP 5.3.2-dev (cli) (built: Nov 27 2009 17:39:57) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies Did you check the strace output (or whatever tool your system provides to trace program syscalls) ? Could you please attach it? [2009-11-27 17:48:47] j...@php.net Well, did you try the short example I provided? That site isn't exactly slow but since you're not providing anything to work with that's what I tested and that works.. [2009-11-27 16:57:04] kvr at centrum dot cz Well, sorry, the URL address was supposed to be replaced with anything real but preferably slow. I compiled the php5.3-latest as proposed and the problem is there as well. [2009-11-27 14:31:01] j...@php.net Unless of course your provided code is supposed to work at all? This works too: # php -r '$fd = fopen(https://master.php.net/manage/users.php;, r);' 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/50312 -- Edit this bug report at http://bugs.php.net/?id=50312edit=1
#50312 [Opn]: Opening an https using fopen consumes all cpu time
ID: 50312 Updated by: ras...@php.net Reported By: kvr at centrum dot cz Status: Open Bug Type: HTTP related Operating System: Linux, Debian PHP Version: 5.3SVN-2009-11-27 (snap) New Comment: This was reported before and a patch supplied but Pierre blew it off. See bug #46685 The patch there looks sane. I'll try to get some time this weekend to play with it. Previous Comments: [2009-11-27 18:14:41] kvr at centrum dot cz php (or OpenSSL library) doesn't handle the error code EAGAIN and instead of waiting for data using select() or poll(), it calls read() again and again, taking all the cpu time. [2009-11-27 18:04:20] j...@php.net Yes, it's the OpenSSL lib doing the read, what's the bug here? [2009-11-27 17:56:41] kvr at centrum dot cz Yes, I tried it exactly as written in your example. The php version was the latest: ~/iphp/bin/php -v PHP 5.3.2-dev (cli) (built: Nov 27 2009 17:39:57) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies Did you check the strace output (or whatever tool your system provides to trace program syscalls) ? Could you please attach it? [2009-11-27 17:48:47] j...@php.net Well, did you try the short example I provided? That site isn't exactly slow but since you're not providing anything to work with that's what I tested and that works.. [2009-11-27 16:57:04] kvr at centrum dot cz Well, sorry, the URL address was supposed to be replaced with anything real but preferably slow. I compiled the php5.3-latest as proposed and the problem is there as well. 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/50312 -- Edit this bug report at http://bugs.php.net/?id=50312edit=1
#50312 [Opn]: Opening an https using fopen consumes all cpu time
ID: 50312 User updated by: kvr at centrum dot cz Reported By: kvr at centrum dot cz Status: Open Bug Type: HTTP related Operating System: Linux, Debian PHP Version: 5.3SVN-2009-11-27 (snap) New Comment: Yes, it looks related. The patch looks quite logical but I'm not sure if it would work with stream_select() functions. Anyway, thank you and sorry the bug report was not clear from the first description. Previous Comments: [2009-11-27 18:24:29] ras...@php.net This was reported before and a patch supplied but Pierre blew it off. See bug #46685 The patch there looks sane. I'll try to get some time this weekend to play with it. [2009-11-27 18:14:41] kvr at centrum dot cz php (or OpenSSL library) doesn't handle the error code EAGAIN and instead of waiting for data using select() or poll(), it calls read() again and again, taking all the cpu time. [2009-11-27 18:04:20] j...@php.net Yes, it's the OpenSSL lib doing the read, what's the bug here? [2009-11-27 17:56:41] kvr at centrum dot cz Yes, I tried it exactly as written in your example. The php version was the latest: ~/iphp/bin/php -v PHP 5.3.2-dev (cli) (built: Nov 27 2009 17:39:57) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies Did you check the strace output (or whatever tool your system provides to trace program syscalls) ? Could you please attach it? [2009-11-27 17:48:47] j...@php.net Well, did you try the short example I provided? That site isn't exactly slow but since you're not providing anything to work with that's what I tested and that works.. 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/50312 -- Edit this bug report at http://bugs.php.net/?id=50312edit=1
#50312 [Opn]: Opening an https using fopen consumes all cpu time
ID: 50312 Updated by: paj...@php.net Reported By: kvr at centrum dot cz Status: Open Bug Type: HTTP related Operating System: Linux, Debian PHP Version: 5.3SVN-2009-11-27 (snap) New Comment: IIRC I did not blew it, I was simply not able to reproduce this problem, same as here. I did not blindly apply the patch as every attempt to fix smtg that was not reproducable always had bad side effect. I'm still not able to reproduce, Rasmus, feel free to take the hand on both bugs if you can reproduce these problems and can fix them. Previous Comments: [2009-11-27 18:37:23] kvr at centrum dot cz Yes, it looks related. The patch looks quite logical but I'm not sure if it would work with stream_select() functions. Anyway, thank you and sorry the bug report was not clear from the first description. [2009-11-27 18:24:29] ras...@php.net This was reported before and a patch supplied but Pierre blew it off. See bug #46685 The patch there looks sane. I'll try to get some time this weekend to play with it. [2009-11-27 18:14:41] kvr at centrum dot cz php (or OpenSSL library) doesn't handle the error code EAGAIN and instead of waiting for data using select() or poll(), it calls read() again and again, taking all the cpu time. [2009-11-27 18:04:20] j...@php.net Yes, it's the OpenSSL lib doing the read, what's the bug here? [2009-11-27 17:56:41] kvr at centrum dot cz Yes, I tried it exactly as written in your example. The php version was the latest: ~/iphp/bin/php -v PHP 5.3.2-dev (cli) (built: Nov 27 2009 17:39:57) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies Did you check the strace output (or whatever tool your system provides to trace program syscalls) ? Could you please attach it? 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/50312 -- Edit this bug report at http://bugs.php.net/?id=50312edit=1
#46685 [NoF-Asn]: SSL code should use select.
ID: 46685 Updated by: paj...@php.net Reported By: scott dot php at scottrix dot co dot uk -Status: No Feedback +Status: Assigned Bug Type: Performance problem Operating System: Linux PHP Version: 5.2.6 -Assigned To: +Assigned To: rasmus New Comment: assigned to Rasmus, looks like he is willing to figure out the cause and improve this patch. Previous Comments: [2008-11-26 13:36:31] scott dot php at scottrix dot co dot uk Seems to me you don't understand, I could easily have found this with a code walk and would not have any test case. The way you are using the SSL libraries is (IMO and the openssl examples) wrong. Doesn't matter if it has any effects on running scripts, it is still wrong. I DO understand that you will want a test to show it has been fixed, but this isn't possible with all coding problems as I'm sure you know, the main thing from a change like this is that it doesn't break any of the existing tests and regression tests that you already have. (or anybody else code that is out there) The only test I have that shows the problem is an strace on a running script. I don't have permission to release that script and you don't have the server pages and software that the script runs against, so would be useless anyway. I would try to create one, but I personally don't know PHP so can't. Given the problem I would imagine that any PHP script that is talking SSL and having to wait for data to come back would have the same problem (viewable by strace output). Anyway, if you NEED more to be able to apply a patch and test it, then I guess you can close this bug. The important thing for me is that I have tried to get someone upstream interested in writing better code, and that it is searchable so that others that experience the problem can find it and try my fix. [2008-11-26 13:19:34] paj...@php.net You get it wrong. A patch can and will be applied when tests are provided as well. The goal is not only to be able to reproduce a possible issue, but also to be sure about the patch is trying to fix. You do not want to provide them and I'm not sure your patch is the right to do it (as already said, that does not mean it is wrong). So this bug has now in a no feedback status, until you have figured out that what I asked is relevent. That's a relatively simple process, isn't it? [2008-11-26 13:13:58] scott dot php at scottrix dot co dot uk I didn't submit the patch to help me, I already have the fix for the problem. If you aren't interested then that is fine. Just thought I'd try and give something back to you guys. Next time I won't bother. [2008-11-26 13:07:36] paj...@php.net your choice no feedback. [2008-11-26 12:22:53] scott dot php at scottrix dot co dot uk I don't see how the script is relevant. You should never sit in a busy loop like this no matter what the php script is doing. 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/46685 -- Edit this bug report at http://bugs.php.net/?id=46685edit=1
#50312 [Opn]: Opening an https using fopen consumes all cpu time
ID: 50312 Updated by: ras...@php.net Reported By: kvr at centrum dot cz Status: Open Bug Type: HTTP related Operating System: Linux, Debian PHP Version: 5.3SVN-2009-11-27 (snap) New Comment: It's not so much a matter of reproducing it as it is reading the openssl docs and looking at our code. If you read about SSL_read and SSL_get_error it seems pretty clear that we are not handling errors efficiently here. We are simply busy-looping on an SSL_ERROR_WANT_READ which is something you are going to have a hard time reproducing consistently, but when it happens it sucks. Previous Comments: [2009-11-27 18:42:36] paj...@php.net IIRC I did not blew it, I was simply not able to reproduce this problem, same as here. I did not blindly apply the patch as every attempt to fix smtg that was not reproducable always had bad side effect. I'm still not able to reproduce, Rasmus, feel free to take the hand on both bugs if you can reproduce these problems and can fix them. [2009-11-27 18:37:23] kvr at centrum dot cz Yes, it looks related. The patch looks quite logical but I'm not sure if it would work with stream_select() functions. Anyway, thank you and sorry the bug report was not clear from the first description. [2009-11-27 18:24:29] ras...@php.net This was reported before and a patch supplied but Pierre blew it off. See bug #46685 The patch there looks sane. I'll try to get some time this weekend to play with it. [2009-11-27 18:14:41] kvr at centrum dot cz php (or OpenSSL library) doesn't handle the error code EAGAIN and instead of waiting for data using select() or poll(), it calls read() again and again, taking all the cpu time. [2009-11-27 18:04:20] j...@php.net Yes, it's the OpenSSL lib doing the read, what's the bug here? 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/50312 -- Edit this bug report at http://bugs.php.net/?id=50312edit=1
#50312 [Opn-Asn]: Opening an https using fopen consumes all cpu time
ID: 50312 Updated by: paj...@php.net Reported By: kvr at centrum dot cz -Status: Open +Status: Assigned Bug Type: HTTP related Operating System: Linux, Debian PHP Version: 5.3SVN-2009-11-27 (snap) -Assigned To: +Assigned To: rasmus New Comment: btw, if it happens to be the same issue, can you bogus (duplicate) this one pls? Previous Comments: [2009-11-27 18:54:58] ras...@php.net It's not so much a matter of reproducing it as it is reading the openssl docs and looking at our code. If you read about SSL_read and SSL_get_error it seems pretty clear that we are not handling errors efficiently here. We are simply busy-looping on an SSL_ERROR_WANT_READ which is something you are going to have a hard time reproducing consistently, but when it happens it sucks. [2009-11-27 18:42:36] paj...@php.net IIRC I did not blew it, I was simply not able to reproduce this problem, same as here. I did not blindly apply the patch as every attempt to fix smtg that was not reproducable always had bad side effect. I'm still not able to reproduce, Rasmus, feel free to take the hand on both bugs if you can reproduce these problems and can fix them. [2009-11-27 18:37:23] kvr at centrum dot cz Yes, it looks related. The patch looks quite logical but I'm not sure if it would work with stream_select() functions. Anyway, thank you and sorry the bug report was not clear from the first description. [2009-11-27 18:24:29] ras...@php.net This was reported before and a patch supplied but Pierre blew it off. See bug #46685 The patch there looks sane. I'll try to get some time this weekend to play with it. [2009-11-27 18:14:41] kvr at centrum dot cz php (or OpenSSL library) doesn't handle the error code EAGAIN and instead of waiting for data using select() or poll(), it calls read() again and again, taking all the cpu time. 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/50312 -- Edit this bug report at http://bugs.php.net/?id=50312edit=1
#50312 [Asn-Opn]: Opening an https using fopen consumes all cpu time
ID: 50312 Updated by: ras...@php.net Reported By: kvr at centrum dot cz -Status: Assigned +Status: Open Bug Type: HTTP related Operating System: Linux, Debian PHP Version: 5.3SVN-2009-11-27 (snap) Assigned To: rasmus New Comment: kvr, you mean you are worried about nested selects if you are doing a stream_select() in userspace and internally the SSL reading is selecting as well? Previous Comments: [2009-11-27 18:56:49] paj...@php.net btw, if it happens to be the same issue, can you bogus (duplicate) this one pls? [2009-11-27 18:54:58] ras...@php.net It's not so much a matter of reproducing it as it is reading the openssl docs and looking at our code. If you read about SSL_read and SSL_get_error it seems pretty clear that we are not handling errors efficiently here. We are simply busy-looping on an SSL_ERROR_WANT_READ which is something you are going to have a hard time reproducing consistently, but when it happens it sucks. [2009-11-27 18:42:36] paj...@php.net IIRC I did not blew it, I was simply not able to reproduce this problem, same as here. I did not blindly apply the patch as every attempt to fix smtg that was not reproducable always had bad side effect. I'm still not able to reproduce, Rasmus, feel free to take the hand on both bugs if you can reproduce these problems and can fix them. [2009-11-27 18:37:23] kvr at centrum dot cz Yes, it looks related. The patch looks quite logical but I'm not sure if it would work with stream_select() functions. Anyway, thank you and sorry the bug report was not clear from the first description. [2009-11-27 18:24:29] ras...@php.net This was reported before and a patch supplied but Pierre blew it off. See bug #46685 The patch there looks sane. I'll try to get some time this weekend to play with it. 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/50312 -- Edit this bug report at http://bugs.php.net/?id=50312edit=1
#50312 [Opn-Fbk]: Opening an https using fopen consumes all cpu time
ID: 50312 Updated by: j...@php.net Reported By: kvr at centrum dot cz -Status: Open +Status: Feedback Bug Type: HTTP related Operating System: Linux, Debian PHP Version: 5.3SVN-2009-11-27 (snap) Previous Comments: [2009-11-27 19:13:28] ras...@php.net kvr, you mean you are worried about nested selects if you are doing a stream_select() in userspace and internally the SSL reading is selecting as well? [2009-11-27 18:56:49] paj...@php.net btw, if it happens to be the same issue, can you bogus (duplicate) this one pls? [2009-11-27 18:54:58] ras...@php.net It's not so much a matter of reproducing it as it is reading the openssl docs and looking at our code. If you read about SSL_read and SSL_get_error it seems pretty clear that we are not handling errors efficiently here. We are simply busy-looping on an SSL_ERROR_WANT_READ which is something you are going to have a hard time reproducing consistently, but when it happens it sucks. [2009-11-27 18:42:36] paj...@php.net IIRC I did not blew it, I was simply not able to reproduce this problem, same as here. I did not blindly apply the patch as every attempt to fix smtg that was not reproducable always had bad side effect. I'm still not able to reproduce, Rasmus, feel free to take the hand on both bugs if you can reproduce these problems and can fix them. [2009-11-27 18:37:23] kvr at centrum dot cz Yes, it looks related. The patch looks quite logical but I'm not sure if it would work with stream_select() functions. Anyway, thank you and sorry the bug report was not clear from the first description. 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/50312 -- Edit this bug report at http://bugs.php.net/?id=50312edit=1
#50312 [Fbk-Opn]: Opening an https using fopen consumes all cpu time
ID: 50312 User updated by: kvr at centrum dot cz Reported By: kvr at centrum dot cz -Status: Feedback +Status: Open Bug Type: HTTP related Operating System: Linux, Debian PHP Version: 5.3SVN-2009-11-27 (snap) New Comment: Not personally as it's not my case :) But yes, I mean to take care when stream_select is called, not to perform system select/poll on one ssl socket. Previous Comments: [2009-11-27 19:13:28] ras...@php.net kvr, you mean you are worried about nested selects if you are doing a stream_select() in userspace and internally the SSL reading is selecting as well? [2009-11-27 18:56:49] paj...@php.net btw, if it happens to be the same issue, can you bogus (duplicate) this one pls? [2009-11-27 18:54:58] ras...@php.net It's not so much a matter of reproducing it as it is reading the openssl docs and looking at our code. If you read about SSL_read and SSL_get_error it seems pretty clear that we are not handling errors efficiently here. We are simply busy-looping on an SSL_ERROR_WANT_READ which is something you are going to have a hard time reproducing consistently, but when it happens it sucks. [2009-11-27 18:42:36] paj...@php.net IIRC I did not blew it, I was simply not able to reproduce this problem, same as here. I did not blindly apply the patch as every attempt to fix smtg that was not reproducable always had bad side effect. I'm still not able to reproduce, Rasmus, feel free to take the hand on both bugs if you can reproduce these problems and can fix them. [2009-11-27 18:37:23] kvr at centrum dot cz Yes, it looks related. The patch looks quite logical but I'm not sure if it would work with stream_select() functions. Anyway, thank you and sorry the bug report was not clear from the first description. 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/50312 -- Edit this bug report at http://bugs.php.net/?id=50312edit=1
#50312 [Opn-Asn]: Opening an https using fopen consumes all cpu time
ID: 50312 Updated by: j...@php.net Reported By: kvr at centrum dot cz -Status: Open +Status: Assigned Bug Type: HTTP related Operating System: Linux, Debian PHP Version: 5.3SVN-2009-11-27 (snap) -Assigned To: +Assigned To: rasmus Previous Comments: [2009-11-27 20:12:07] kvr at centrum dot cz Not personally as it's not my case :) But yes, I mean to take care when stream_select is called, not to perform system select/poll on one ssl socket. [2009-11-27 19:13:28] ras...@php.net kvr, you mean you are worried about nested selects if you are doing a stream_select() in userspace and internally the SSL reading is selecting as well? [2009-11-27 18:56:49] paj...@php.net btw, if it happens to be the same issue, can you bogus (duplicate) this one pls? [2009-11-27 18:54:58] ras...@php.net It's not so much a matter of reproducing it as it is reading the openssl docs and looking at our code. If you read about SSL_read and SSL_get_error it seems pretty clear that we are not handling errors efficiently here. We are simply busy-looping on an SSL_ERROR_WANT_READ which is something you are going to have a hard time reproducing consistently, but when it happens it sucks. [2009-11-27 18:42:36] paj...@php.net IIRC I did not blew it, I was simply not able to reproduce this problem, same as here. I did not blindly apply the patch as every attempt to fix smtg that was not reproducable always had bad side effect. I'm still not able to reproduce, Rasmus, feel free to take the hand on both bugs if you can reproduce these problems and can fix them. 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/50312 -- Edit this bug report at http://bugs.php.net/?id=50312edit=1
#48930 [Ana-Asn]: __COMPILER_HALT_OFFSET__ incorrect in PHP=5.3
ID: 48930 Updated by: j...@php.net Reported By: adam-phpbugs at adam dot gs -Status: Analyzed +Status: Assigned Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.3.0 Assigned To: scottmac Previous Comments: [2009-09-09 20:02:00] j...@php.net Nevermind, of course it's still borked since the check is NOT done in scanner. :) [2009-09-09 19:56:40] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Since the shebang check was removed from scanner, isn't this issue solved then? (please try :) [2009-08-30 22:56:02] adam-phpbugs at adam dot gs Understandably this might be a bit hackish to have use a global variable here, but perhaps thats preferable to what i'd consider a major regression? I attempted to patch this so I could just submit a patch here, but unfortunately my c-fu and my understanding of PHP internals is lacking. [2009-08-03 03:06:47] scott...@php.net The sapi/cli/php_cli.c code will read forward when it see's a shebang to the next line. The file is already seeked by the time the scanner gets a change to look at it. The zend_get_scanned_file_offset() doesn't know about this because by the time the scanner is started the bytes are already long gone. Short of a global variable I'm not seeing a clean way to fix this. [2009-07-16 00:23:45] ka...@php.net Scott, you worked on the re2c switch, any chance you can clarrify this one? 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/48930 -- Edit this bug report at http://bugs.php.net/?id=48930edit=1
#49935 [Csd-Opn]: All tests failing due to warning message
ID: 49935 User updated by: shopping at jth dot net Reported By: shopping at jth dot net -Status: Closed +Status: Open Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.3.0 New Comment: This bug has been fixed in SVN. So why is it still in 5.3.1 ? Shouldn't a serious thing like this be tested before a new release ? Previous Comments: [2009-10-21 06:50:21] j...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-10-20 14:58:36] shopping at jth dot net Description: It does not seem very clever to issue a warning which makes all tests (make test) fail (register_globals deprecated). And what else will it break in production ?! -- Edit this bug report at http://bugs.php.net/?id=49935edit=1
#49935 [Opn]: All tests failing due to warning message
ID: 49935 User updated by: shopping at jth dot net Reported By: shopping at jth dot net Status: Open Bug Type: Scripting Engine problem Operating System: Linux -PHP Version: 5.3.0 +PHP Version: 5.3.1 New Comment: I see the reputation of PHP at stake here. If testing is not done properly we cannot rely on using a new release in a production environment. Previous Comments: [2009-11-27 22:24:46] shopping at jth dot net This bug has been fixed in SVN. So why is it still in 5.3.1 ? Shouldn't a serious thing like this be tested before a new release ? [2009-10-21 06:50:21] j...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-10-20 14:58:36] shopping at jth dot net Description: It does not seem very clever to issue a warning which makes all tests (make test) fail (register_globals deprecated). And what else will it break in production ?! -- Edit this bug report at http://bugs.php.net/?id=49935edit=1
#42096 [Asn-Fbk]: is_dir() truncates dirs when using UNC paths
ID: 42096 Updated by: paj...@php.net Reported By: michael202 at gmx dot de -Status: Assigned +Status: Feedback Bug Type: Streams related Operating System: win32 only - Windows PHP Version: 5.2* Assigned To: pajoye New Comment: Can't reproduce it here. Please provide a script to reproduce this problem, like the UNC path you use as well as which Windows version. Previous Comments: [2009-11-27 17:21:59] paj...@php.net I have to verify with UNC path and 5.2. [2009-11-27 17:18:56] michael202 at gmx dot de First I gave up on this issue and switched to drive letters. Now I tested php 5.3.1 and this bug is fixed ! It must have been an issue with php, because: I have two parallel installations of php (5.2.6 and 5.3.1) on the same computer. If I switch between these I can produce the bug with 5.2.6 and I don't have it with 5.3.1. Again: for each access to a file with a UNC path, something truncates the last character of the share name (here import - impor) resulting in hundreds of these error messages (/var/log/samba/log.smbd): [2009/11/27 18:07:44, 0] smbd/service.c:make_connection(794) pro (1.2.7.1) couldn't find service impor AND resulting in a very high load and a server hard reset. Thanks ! [2007-08-31 10:04:20] j...@php.net As is_dir() uses stat to check whether passed path is directory or not I doubt this can really be any PHP bug, just another limitiation of Windows. Try doing the same using something else than PHP and I bet the result is the same. And this is totally bogus: echo(is_dir($p) . \n); Proto for the function http://php.net/is_dir is: bool is_dir ( string $filename ) Returns TRUE if the filename exists and is a directory, FALSE otherwise. [2007-08-08 09:09:04] michael202 at gmx dot de running a script that makes a few thousand accesses to a samba server (that is used by approx. 30 other hosts) causes this server to crash and dismount the samba share. [2007-07-25 14:43:22] michael202 at gmx dot de tested with php5.2-win32-latest.zip from today morning 2007-07-25 08h08 error is still in there 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/42096 -- Edit this bug report at http://bugs.php.net/?id=42096edit=1
#50264 [Bgs]: Possible pcre memory leak
ID: 50264
User updated by: laszlo dot janszky at gmail dot com
Reported By: laszlo dot janszky at gmail dot com
Status: Bogus
Bug Type: PCRE related
Operating System: Windows XP
PHP Version: 5.3.1
New Comment:
OK.
If it's not a bug, then what is it?
Previous Comments:
[2009-11-27 17:57:16] 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-11-23 19:38:35] laszlo dot janszky at gmail dot com
If it is not clear, by the test:
the 8 tokens withBlock (M1) test string is:
$test='
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{/display}
{/display}
{/display}
{/display}
{/display}
{/display}
{/display}
{/display}
';
and the 8 tokens withoutBlock (M2) test string is:
$test='
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{display}
';
[2009-11-23 19:21:02] laszlo dot janszky at gmail dot com
The leak is in relation with this
http://bugs.php.net/bug.php?id=49333
Here is a simplyfied example with eight withoutBlock tokens:
?php
ini_set('pcre.backtrack_limit', 4);
ini_set('pcre.recursion_limit', 1000);
$pattern=
'%
{(\w+)(?:}
(.*?(?:(?0).*?)*?)
{/\1)?}
%usDx';
$test='
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{display}
';
preg_match_all($pattern,$test,$matches,PREG_SET_ORDER);
var_dump($matches);
?
The basic syntax is:
{withBlock}block{/withBlock}
or
{withoutBlock}
As the {withBlock} opener part is of the same structure like the
{withoutBlock}, it starts to collect the string after the {withoutBlock}
to the backtrace. But for some kind of reason the {withoutBlock}
backtrace eats up the memory superexponential, not linear like in the
case of {withBlock}.
A measured the memory usage with the simplyfied example. It was not
superexponential, just exponential. I think cause I have in this example
two capturing groups only, not a lot like in the original code.
tokens M1[b] M2[b] LN(M2)
1 19 22 3,0910
2 53 115 4,7449
3 87 405 6,0039
4 121 12867,1593
5 155 39408,2789
6 189 11913 9,3854
7 223 35843 10,4869
8 257 107644 11,6204
M1 = 34 * N - 15
R^2 = 1
M2 = exp ( 1,1192 * N + 2,6669 )
R^2 = 0, for the 3-8 part
Btw. it's funny memory usage.
[2009-11-22 18:53:14] laszlo dot janszky at gmail dot com
If I remove the recursive part
(?:\\}(?block.*?(?:(?0).*?)*?)\\{/(?P=function))?
from the end of the regex, then it works fine...
[2009-11-22 18:47:14] laszlo dot janszky at gmail dot com
Description:
I have a huge recursive regex (about 500bytes), which needs a lot of
memory for backtrace.
The regex matches on templates like
{command1 arg1=$arg1 arg2=$arg2|modifier2
arg3=text|modifier3:modarg31:modarg32}
etc
If I use the regex with preg_match_all, then the backtrace memory usage
depends on the count of the commands superexponential.
So:
R^2 = 0,9977 (R^2 for trendline)
ln ln M = 0,0787 * N + 1,9304
[M] = used backtrack memory in bytes
[N] = number of command calls
It don't think that more than 1Mb memory usage is normal for a 0.0002Mb
string.
The recursion memory usage is normal(under 1kb). I'm pretty
disappointed because I can't use my template engine because of a badly
written pcre engine.
Reproduce code:
---
$template1='
{display var=$link}
{display var=$link}
{display var=$link}
{display var=$link}
{display var=$link}
{display var=$link}
{display var=$link}
{display var=$link}
{display var=$link}
{display var=$link}
';
$template2='
{display var=$link}
{display var=$link}
{display var=$link}
{display var=$link}
test test test test test
test test test test test
test test test test test
test test test test test
test test test test test
test test test test test
test test test test test
test test test test test
test test test test test
test test test test test
';
#49935 [Opn-Asn]: All tests failing due to warning message
ID: 49935 Updated by: j...@php.net Reported By: shopping at jth dot net -Status: Open +Status: Assigned Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.3.1 -Assigned To: +Assigned To: jani New Comment: You really have bigger problems if you have to have register_globals=On anyway, so please, don't overreact. Previous Comments: [2009-11-27 22:30:22] shopping at jth dot net I see the reputation of PHP at stake here. If testing is not done properly we cannot rely on using a new release in a production environment. [2009-11-27 22:24:46] shopping at jth dot net This bug has been fixed in SVN. So why is it still in 5.3.1 ? Shouldn't a serious thing like this be tested before a new release ? [2009-10-21 06:50:21] j...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-10-20 14:58:36] shopping at jth dot net Description: It does not seem very clever to issue a warning which makes all tests (make test) fail (register_globals deprecated). And what else will it break in production ?! -- Edit this bug report at http://bugs.php.net/?id=49935edit=1
#50315 [NEW]: Use of config.cache causes missing HAVE_FORK define
From: jd at cpanel dot net Operating system: Centos 5 AMD64 PHP version: 5.2.12RC3 PHP Bug Type: *Compile Issues Bug description: Use of config.cache causes missing HAVE_FORK define Description: The bug fix in revision 291318 exposes additional problems with ext/standard/config.m4 When php_cv_can_support_proc_open is loaded from config.cache the function tests that come after are not executed. As a result, the existence of fork() is not tested and HAVE_FORK is not defined. ext/standard/proc_open.c has a chain of preprocessor if blocks that expects one of PHP_WIN32, NETWARE or HAVE_FORK to be set whenever PHP_CAN_SUPPORT_PROC_OPEN is set. Reproduce code: --- Remove config.cache then run configure twice without --enable-pcntl (which also tests for fork()). Diff the two generated php_config.h files. -- Edit bug report at http://bugs.php.net/?id=50315edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50315r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50315r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50315r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50315r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50315r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50315r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50315r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50315r=needscript Try newer version: http://bugs.php.net/fix.php?id=50315r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50315r=support Expected behavior: http://bugs.php.net/fix.php?id=50315r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50315r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50315r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50315r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50315r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50315r=dst IIS Stability: http://bugs.php.net/fix.php?id=50315r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50315r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50315r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50315r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50315r=mysqlcfg
#50264 [Bgs]: Possible pcre memory leak
ID: 50264
Updated by: ras...@php.net
Reported By: laszlo dot janszky at gmail dot com
Status: Bogus
Bug Type: PCRE related
Operating System: Windows XP
PHP Version: 5.3.1
New Comment:
Did you test it with the command line pcre test tool? This is unlikely
to have anything to do with php-specific code.
Previous Comments:
[2009-11-27 23:07:01] laszlo dot janszky at gmail dot com
OK.
If it's not a bug, then what is it?
[2009-11-27 17:57:16] 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-11-23 19:38:35] laszlo dot janszky at gmail dot com
If it is not clear, by the test:
the 8 tokens withBlock (M1) test string is:
$test='
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{/display}
{/display}
{/display}
{/display}
{/display}
{/display}
{/display}
{/display}
';
and the 8 tokens withoutBlock (M2) test string is:
$test='
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{display}
';
[2009-11-23 19:21:02] laszlo dot janszky at gmail dot com
The leak is in relation with this
http://bugs.php.net/bug.php?id=49333
Here is a simplyfied example with eight withoutBlock tokens:
?php
ini_set('pcre.backtrack_limit', 4);
ini_set('pcre.recursion_limit', 1000);
$pattern=
'%
{(\w+)(?:}
(.*?(?:(?0).*?)*?)
{/\1)?}
%usDx';
$test='
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{display}
';
preg_match_all($pattern,$test,$matches,PREG_SET_ORDER);
var_dump($matches);
?
The basic syntax is:
{withBlock}block{/withBlock}
or
{withoutBlock}
As the {withBlock} opener part is of the same structure like the
{withoutBlock}, it starts to collect the string after the {withoutBlock}
to the backtrace. But for some kind of reason the {withoutBlock}
backtrace eats up the memory superexponential, not linear like in the
case of {withBlock}.
A measured the memory usage with the simplyfied example. It was not
superexponential, just exponential. I think cause I have in this example
two capturing groups only, not a lot like in the original code.
tokens M1[b] M2[b] LN(M2)
1 19 22 3,0910
2 53 115 4,7449
3 87 405 6,0039
4 121 12867,1593
5 155 39408,2789
6 189 11913 9,3854
7 223 35843 10,4869
8 257 107644 11,6204
M1 = 34 * N - 15
R^2 = 1
M2 = exp ( 1,1192 * N + 2,6669 )
R^2 = 0, for the 3-8 part
Btw. it's funny memory usage.
[2009-11-22 18:53:14] laszlo dot janszky at gmail dot com
If I remove the recursive part
(?:\\}(?block.*?(?:(?0).*?)*?)\\{/(?P=function))?
from the end of the regex, then it works fine...
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/50264
--
Edit this bug report at http://bugs.php.net/?id=50264edit=1
#49935 [Asn-Csd]: Deprecated warnings make make test to fail
ID: 49935 Updated by: j...@php.net -Summary: All tests failing due to warning message Reported By: shopping at jth dot net -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.3.1 Assigned To: jani New Comment: Fixed now. Oh, and thanks for testing the PHP 5.3.1 RCs too. Great work there, mate. Previous Comments: [2009-11-27 23:34:36] s...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revisionrevision=291363 Log: - Fixed bug #49935 (Deprecated warnings make make test to fail) [2009-11-27 23:07:20] j...@php.net You really have bigger problems if you have to have register_globals=On anyway, so please, don't overreact. [2009-11-27 22:30:22] shopping at jth dot net I see the reputation of PHP at stake here. If testing is not done properly we cannot rely on using a new release in a production environment. [2009-11-27 22:24:46] shopping at jth dot net This bug has been fixed in SVN. So why is it still in 5.3.1 ? Shouldn't a serious thing like this be tested before a new release ? [2009-10-21 06:50:21] j...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. 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/49935 -- Edit this bug report at http://bugs.php.net/?id=49935edit=1
#50315 [Opn-Csd]: Use of config.cache causes missing HAVE_FORK define
ID: 50315 Updated by: j...@php.net Reported By: jd at cpanel dot net -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Centos 5 AMD64 PHP Version: 5.2.12RC3 Previous Comments: [2009-11-27 23:41:13] s...@php.net Automatic comment from SVN on behalf of rasmus Revision: http://svn.php.net/viewvc/?view=revisionrevision=291364 Log: Fix bug #50315 [2009-11-27 23:11:33] jd at cpanel dot net Description: The bug fix in revision 291318 exposes additional problems with ext/standard/config.m4 When php_cv_can_support_proc_open is loaded from config.cache the function tests that come after are not executed. As a result, the existence of fork() is not tested and HAVE_FORK is not defined. ext/standard/proc_open.c has a chain of preprocessor if blocks that expects one of PHP_WIN32, NETWARE or HAVE_FORK to be set whenever PHP_CAN_SUPPORT_PROC_OPEN is set. Reproduce code: --- Remove config.cache then run configure twice without --enable-pcntl (which also tests for fork()). Diff the two generated php_config.h files. -- Edit this bug report at http://bugs.php.net/?id=50315edit=1
#50315 [Csd]: Use of config.cache causes missing HAVE_FORK define
ID: 50315 Updated by: ras...@php.net Reported By: jd at cpanel dot net Status: Closed Bug Type: Compile Failure Operating System: Centos 5 AMD64 PHP Version: 5.2.12RC3 New Comment: Fixed by simply not caching this check. Previous Comments: [2009-11-27 23:41:13] s...@php.net Automatic comment from SVN on behalf of rasmus Revision: http://svn.php.net/viewvc/?view=revisionrevision=291364 Log: Fix bug #50315 [2009-11-27 23:11:33] jd at cpanel dot net Description: The bug fix in revision 291318 exposes additional problems with ext/standard/config.m4 When php_cv_can_support_proc_open is loaded from config.cache the function tests that come after are not executed. As a result, the existence of fork() is not tested and HAVE_FORK is not defined. ext/standard/proc_open.c has a chain of preprocessor if blocks that expects one of PHP_WIN32, NETWARE or HAVE_FORK to be set whenever PHP_CAN_SUPPORT_PROC_OPEN is set. Reproduce code: --- Remove config.cache then run configure twice without --enable-pcntl (which also tests for fork()). Diff the two generated php_config.h files. -- Edit this bug report at http://bugs.php.net/?id=50315edit=1
#50266 [Asn-Csd]: conflicting types for llabs
ID: 50266
Updated by: j...@php.net
Reported By: selsky at columbia dot edu
-Status: Assigned
+Status: Closed
Bug Type: Date/time related
Operating System: Solaris 9
PHP Version: 5.2SVN-2009-11-23 (snap)
Assigned To: derick
Previous Comments:
[2009-11-28 00:38:06] s...@php.net
Automatic comment from SVN on behalf of jani
Revision: http://svn.php.net/viewvc/?view=revisionrevision=291371
Log: - Fixed bug #50266 (conflicting types for llabs)
[2009-11-23 02:55:44] selsky at columbia dot edu
Description:
llabs() is defined in both /usr/include/stdlib.h and
ext/date/php_date.c
#if defined(__GNUC__) __GNUC__ 3
static __inline __int64_t llabs( __int64_t i ) { return i = 0 ? i :
-i;
}
#endif
I'm using gcc 2 so this inline function is defined, but it's also
defined by the system. Perhaps it would be better to test for the
function in configure and set something in php_config.h?
Reproduce code:
---
$ uname -a
SunOS cumin 5.9 Generic_122300-45 sun4u sparc SUNW,UltraAX-i2 Solaris
$ gcc --version
2.95.3
$ ./configure
$ make
/bin/sh /tmp/php5.2-200911230130/libtool --silent --preserve-dup-deps
--mode=compile gcc -Iext/date/lib -Iext/date/
-I/tmp/php5.2-200911230130/ext/date/ -DPHP_ATOM_INC
-I/tmp/php5.2-200911230130/include -I/tmp/php5.2-200911230130/main
-I/tmp/php5.2-200911230130 -I/tmp/php5.2-200911230130/ext/date/lib
-I/opt/libxml2-2.6.32/include/libxml2 -I/tmp/php5.2-200911230130/TSRM
-I/tmp/php5.2-200911230130/Zend -D_POSIX_PTHREAD_SEMANTICS
-I/usr/include -g -O2 -c /tmp/php5.2-200911230130/ext/date/php_date.c
-o ext/date/php_date.lo
/tmp/php5.2-200911230130/ext/date/php_date.c:38: parse error before
`llabs'
/tmp/php5.2-200911230130/ext/date/php_date.c:38: parse error before
`i'
/tmp/php5.2-200911230130/ext/date/php_date.c:38: conflicting types for
`llabs'
/usr/include/stdlib.h:203: previous declaration of `llabs'
/tmp/php5.2-200911230130/ext/date/php_date.c: In function `llabs':
/tmp/php5.2-200911230130/ext/date/php_date.c:38: `i' undeclared (first
use in this function)
/tmp/php5.2-200911230130/ext/date/php_date.c:38: (Each undeclared
identifier is reported only once
/tmp/php5.2-200911230130/ext/date/php_date.c:38: for each function it
appears in.)
--
Edit this bug report at http://bugs.php.net/?id=50266edit=1
#37111 [Asn-Opn]: Apache crashes when strftime is called inside user defined session write func
ID: 37111 Updated by: j...@php.net Reported By: haakonsk at gmail dot com -Status: Assigned +Status: Open Bug Type: Date/time related Operating System: * PHP Version: 5.*, 6CVS (2008-11-11) Assigned To: derick Previous Comments: [2008-11-02 12:35:26] j...@php.net Derick, would you mind responding to my comment above? [2008-02-15 00:11:11] j...@php.net Why can't this be fixed by making ext/date the last extension to be unloaded? ie. simply rename config.m4 to config9.m4 :) (dunno how to do it for the windows build..does it have the same method of simple rename?) [2006-07-27 09:27:06] der...@php.net But as we can't just run it at the end... I would say there is a more fundamental problem here... [2006-07-27 06:32:34] tony2...@php.net AFAIK I told Derick what should be the reason: ext/date shutdowns and frees all resources before ext/session, so strftime() will access already freed timezonedb and other ext/date resources. I'd say this is more ext/date related, as I suppose it's mshutdown handler should be run at the very end. [2006-07-27 01:57:25] sni...@php.net And I can not reproduce this with latest of everything on Linux. Bate: Provide the backtrace please. 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/37111 -- Edit this bug report at http://bugs.php.net/?id=37111edit=1
#37111 [Opn-Asn]: Apache crashes when strftime is called inside user defined session write func
ID: 37111 Updated by: j...@php.net Reported By: haakonsk at gmail dot com -Status: Open +Status: Assigned Bug Type: Date/time related Operating System: * PHP Version: 5.*, 6CVS (2008-11-11) -Assigned To: derick +Assigned To: tony2001 New Comment: Antony, since you could reproduce this (?), can you try this patch: http://pecl.php.net/~jani/patches/bug37111.patch Previous Comments: [2008-11-02 12:35:26] j...@php.net Derick, would you mind responding to my comment above? [2008-02-15 00:11:11] j...@php.net Why can't this be fixed by making ext/date the last extension to be unloaded? ie. simply rename config.m4 to config9.m4 :) (dunno how to do it for the windows build..does it have the same method of simple rename?) [2006-07-27 09:27:06] der...@php.net But as we can't just run it at the end... I would say there is a more fundamental problem here... [2006-07-27 06:32:34] tony2...@php.net AFAIK I told Derick what should be the reason: ext/date shutdowns and frees all resources before ext/session, so strftime() will access already freed timezonedb and other ext/date resources. I'd say this is more ext/date related, as I suppose it's mshutdown handler should be run at the very end. [2006-07-27 01:57:25] sni...@php.net And I can not reproduce this with latest of everything on Linux. Bate: Provide the backtrace please. 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/37111 -- Edit this bug report at http://bugs.php.net/?id=37111edit=1
#50264 [Bgs]: Possible pcre memory leak
ID: 50264
User updated by: laszlo dot janszky at gmail dot com
Reported By: laszlo dot janszky at gmail dot com
Status: Bogus
Bug Type: PCRE related
Operating System: Windows XP
PHP Version: 5.3.1
New Comment:
Ahm, so you mean, this is a pcre memory handling problem, not a php
bug? Okay, then where can I report this issue?
(Sorry for the bad English, I'm just med- ...)
Previous Comments:
[2009-11-27 23:26:10] ras...@php.net
Did you test it with the command line pcre test tool? This is unlikely
to have anything to do with php-specific code.
[2009-11-27 23:07:01] laszlo dot janszky at gmail dot com
OK.
If it's not a bug, then what is it?
[2009-11-27 17:57:16] 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-11-23 19:38:35] laszlo dot janszky at gmail dot com
If it is not clear, by the test:
the 8 tokens withBlock (M1) test string is:
$test='
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{/display}
{/display}
{/display}
{/display}
{/display}
{/display}
{/display}
{/display}
';
and the 8 tokens withoutBlock (M2) test string is:
$test='
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{display}
';
[2009-11-23 19:21:02] laszlo dot janszky at gmail dot com
The leak is in relation with this
http://bugs.php.net/bug.php?id=49333
Here is a simplyfied example with eight withoutBlock tokens:
?php
ini_set('pcre.backtrack_limit', 4);
ini_set('pcre.recursion_limit', 1000);
$pattern=
'%
{(\w+)(?:}
(.*?(?:(?0).*?)*?)
{/\1)?}
%usDx';
$test='
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{display}
';
preg_match_all($pattern,$test,$matches,PREG_SET_ORDER);
var_dump($matches);
?
The basic syntax is:
{withBlock}block{/withBlock}
or
{withoutBlock}
As the {withBlock} opener part is of the same structure like the
{withoutBlock}, it starts to collect the string after the {withoutBlock}
to the backtrace. But for some kind of reason the {withoutBlock}
backtrace eats up the memory superexponential, not linear like in the
case of {withBlock}.
A measured the memory usage with the simplyfied example. It was not
superexponential, just exponential. I think cause I have in this example
two capturing groups only, not a lot like in the original code.
tokens M1[b] M2[b] LN(M2)
1 19 22 3,0910
2 53 115 4,7449
3 87 405 6,0039
4 121 12867,1593
5 155 39408,2789
6 189 11913 9,3854
7 223 35843 10,4869
8 257 107644 11,6204
M1 = 34 * N - 15
R^2 = 1
M2 = exp ( 1,1192 * N + 2,6669 )
R^2 = 0, for the 3-8 part
Btw. it's funny memory usage.
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/50264
--
Edit this bug report at http://bugs.php.net/?id=50264edit=1
#50264 [Bgs]: Possible pcre memory leak
ID: 50264
User updated by: laszlo dot janszky at gmail dot com
Reported By: laszlo dot janszky at gmail dot com
Status: Bogus
Bug Type: PCRE related
Operating System: Windows XP
PHP Version: 5.3.1
New Comment:
Did you test it with the command line pcre test tool?
I did not test it.
Previous Comments:
[2009-11-28 02:37:58] laszlo dot janszky at gmail dot com
Ahm, so you mean, this is a pcre memory handling problem, not a php
bug? Okay, then where can I report this issue?
(Sorry for the bad English, I'm just med- ...)
[2009-11-27 23:26:10] ras...@php.net
Did you test it with the command line pcre test tool? This is unlikely
to have anything to do with php-specific code.
[2009-11-27 23:07:01] laszlo dot janszky at gmail dot com
OK.
If it's not a bug, then what is it?
[2009-11-27 17:57:16] 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-11-23 19:38:35] laszlo dot janszky at gmail dot com
If it is not clear, by the test:
the 8 tokens withBlock (M1) test string is:
$test='
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{/display}
{/display}
{/display}
{/display}
{/display}
{/display}
{/display}
{/display}
';
and the 8 tokens withoutBlock (M2) test string is:
$test='
{display}
{display}
{display}
{display}
{display}
{display}
{display}
{display}
';
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/50264
--
Edit this bug report at http://bugs.php.net/?id=50264edit=1
#50297 [Opn-Bgs]: MessageFormatter::formatMessage don't support string with accent in it
ID: 50297 Updated by: j...@php.net Reported By: pby_fr at yahoo dot fr -Status: Open +Status: Bogus Bug Type: I18N and L10N related Operating System: Windows Vista 64 PHP Version: 5.3.1 New Comment: Well there's your problem. The method isn't static.. Previous Comments: [2009-11-27 15:08:49] pby_fr at yahoo dot fr formatMessage being a static method, it is not possible to use getErrorMessage! I tested with a full object code: $fmt = new MessageFormatter(fr_FR, with accent à é); $fmt isn't an object, but FALSE Whit $fmt = new MessageFormatter(fr_FR, with accent a e); $fmt is an object, and everything works fine. Anyway, I must switch back to PHP 5.2, therefore I will recode a very simple formatter instead of use this class. [2009-11-26 10:08:22] j...@php.net Try this: http://www.php.net/manual/en/messageformatter.geterrormessage.php You might have something like wrong locale there or something.. [2009-11-25 20:37:49] pby_fr at yahoo dot fr Description: Using accent character in the pattern of MessageFormatter::formatMessage return an empty string. Reproduce code: --- echo (MessageFormatter::formatMessage(fr_FR, with accent à é, array())); Expected result: to display: with accent à é Actual result: -- display nothing -- Edit this bug report at http://bugs.php.net/?id=50297edit=1
