#50761 [NEW]: system.multiCall cause Segmentation fault
From: hiroaki dot kawai at gmail dot com Operating system: PHP version: 5.3.1 PHP Bug Type: XMLRPC-EPI related Bug description: system.multiCall cause Segmentation fault Description: xmlrpc-epi supports system.multiCall(), which packs multiple xmlrpc method call transactions into one. Using this method in php extension cause php process crash. The point was that we must let xmlrpc-epi to decode the multicall request. We must check the method name in the callback function. This bug exists very long time. http://bugs.php.net/bug.php?id=27446 patch is available: - --- xmlrpc-epi-php.c.orig 2009-08-18 09:41:43.0 +0900 +++ xmlrpc-epi-php.c2010-01-14 13:58:48.028867000 +0900 @@ -892,12 +892,23 @@ static XMLRPC_VALUE php_xmlrpc_callback(XMLRPC_SERVER server, XMLRPC_REQUEST xRequest, void* data) /* {{{ */ { xmlrpc_callback_data* pData = (xmlrpc_callback_data*)data; + zval** php_function; zval* xmlrpc_params; zval* callback_params[3]; TSRMLS_FETCH(); /* convert xmlrpc to native php types */ + ZVAL_STRING(pData->xmlrpc_method, XMLRPC_RequestGetMethodName(xRequest), 1); xmlrpc_params = XMLRPC_to_PHP(XMLRPC_RequestGetData(xRequest)); + + /* check if the called method has been previous registered */ + if(zend_hash_find(Z_ARRVAL_P(pData->server->method_map), + Z_STRVAL_P(pData->xmlrpc_method), + Z_STRLEN_P(pData->xmlrpc_method) + 1, + (void**)&php_function) == SUCCESS) { + + pData->php_function = *php_function; + } /* setup data hoojum */ callback_params[0] = pData->xmlrpc_method; @@ -913,7 +924,7 @@ zval_ptr_dtor(&xmlrpc_params); - return NULL; + return PHP_to_XMLRPC(pData->return_data TSRMLS_CC); } /* }}} */ @@ -1082,34 +1093,17 @@ if (xRequest) { const char* methodname = XMLRPC_RequestGetMethodName(xRequest); - zval **php_function; XMLRPC_VALUE xAnswer = NULL; MAKE_STD_ZVAL(data.xmlrpc_method); /* init. very important. spent a frustrating day finding this out. */ MAKE_STD_ZVAL(data.return_data); Z_TYPE_P(data.return_data) = IS_NULL; /* in case value is never init'd, we don't dtor to think it is a string or something */ Z_TYPE_P(data.xmlrpc_method) = IS_NULL; - if (!methodname) { - methodname = ""; - } - /* setup some data to pass to the callback function */ - Z_STRVAL_P(data.xmlrpc_method) = estrdup(methodname); - Z_STRLEN_P(data.xmlrpc_method) = strlen(methodname); - Z_TYPE_P(data.xmlrpc_method) = IS_STRING; data.caller_params = *caller_params; data.php_executed = 0; data.server = server; - /* check if the called method has been previous registered */ - if (zend_hash_find(Z_ARRVAL_P(server- >method_map), - Z_STRVAL_P(data.xmlrpc_method), - Z_STRLEN_P(data.xmlrpc_method) + 1, - (void**)&php_function) == SUCCESS) { - - data.php_function = *php_function; - } - /* We could just call the php method directly ourselves at this point, but we do this * with a C callback in case the xmlrpc library ever implements some cool usage stats, * or somesuch. @@ -1119,7 +1113,7 @@ zval_dtor(data.return_data); FREE_ZVAL(data.return_data); data.return_data = XMLRPC_to_PHP(xAnswer); - } else if (data.php_executed && !out.b_php_out) { + } else if (data.php_executed && !out.b_php_out && !xAnswer) { xAnswer = PHP_to_XMLRPC(data.return_data TSRMLS_CC); } Reproduce code: --- system.multiCall methodNametestMethodA paramsA methodNametestMethodB paramsB '; function testA($methodName, $params, $var){ return "C"; } function testB($methodName, $params, $var){ return "D"; } $server = xmlrpc_server_create(); xmlrpc_server_register_method($server, 'testMethodA', 'testA'); xmlrpc_server_register_method($server, 'testMethodB', 'testB'); $res = xmlrpc_server_call_method($server, $req, null); echo $res; Expected result:
#50760 [Opn->Bgs]: ping
ID: 50760 Updated by: ahar...@php.net Reported By: postmaster at wj8 dot net -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: windows PHP Version: 5.3.1 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2010-01-15 03:17:21] postmaster at wj8 dot net my web is www.wj8.net, and mysql is ok,but sometimes cannot connect mysql with a warning,don't find the mysql,just the mysql is good for running.cou me. [2010-01-15 03:14:58] postmaster at wj8 dot net Description: hi,i am a chinese webmaster Reproduce code: --- mysql eroor Expected result: mysql can't find,but mysql is ok running,i don't know what wrong. Actual result: -- php+mysql when running ,had a erore about "can't find the mysql or can't connet mysql,but the mysql is good a running" -- Edit this bug report at http://bugs.php.net/?id=50760&edit=1
#50760 [Com]: ping
ID: 50760 Comment by: postmaster at wj8 dot net Reported By: postmaster at wj8 dot net Status: Open Bug Type: *General Issues Operating System: windows PHP Version: 5.3.1 New Comment: my web is www.wj8.net, and mysql is ok,but sometimes cannot connect mysql with a warning,don't find the mysql,just the mysql is good for running.cou me. Previous Comments: [2010-01-15 03:14:58] postmaster at wj8 dot net Description: hi,i am a chinese webmaster Reproduce code: --- mysql eroor Expected result: mysql can't find,but mysql is ok running,i don't know what wrong. Actual result: -- php+mysql when running ,had a erore about "can't find the mysql or can't connet mysql,but the mysql is good a running" -- Edit this bug report at http://bugs.php.net/?id=50760&edit=1
#50760 [NEW]: ping
From: postmaster at wj8 dot net Operating system: windows PHP version: 5.3.1 PHP Bug Type: *General Issues Bug description: ping Description: hi,i am a chinese webmaster Reproduce code: --- mysql eroor Expected result: mysql can't find,but mysql is ok running,i don't know what wrong. Actual result: -- php+mysql when running ,had a erore about "can't find the mysql or can't connet mysql,but the mysql is good a running" -- Edit bug report at http://bugs.php.net/?id=50760&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50760&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50760&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50760&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50760&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50760&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50760&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50760&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50760&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50760&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50760&r=support Expected behavior: http://bugs.php.net/fix.php?id=50760&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50760&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50760&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50760&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50760&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50760&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50760&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50760&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50760&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50760&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50760&r=mysqlcfg
#50759 [Bgs]: SimpleXML ::atrributes() feature does not recognize hyphenated attributes
ID: 50759 Updated by: ahar...@php.net Reported By: stevendamico at gmail dot com Status: Bogus Bug Type: SimpleXML related Operating System: Windows PHP Version: 5.2.12 New Comment: For the record, that link should have been to http://au2.php.net/manual/en/simplexml.examples-basic.php (Insert ritual complaint about bug tracker auto-linkification here.) Previous Comments: [2010-01-15 01:55:47] ahar...@php.net Per example #5 in http://au2.php.net/manual/en/simplexml.examples-basic.php, the idiomatic way to access attributes in a SimpleXML tree is to access them in the same way as array elements. In your example, this should work (and works for me): echo $doc->...->{'recorded-vote'}->legislator['name-id']; Closing, as this isn't a bug in PHP itself. Thanks for your interest in PHP! [2010-01-14 23:19:47] stevendamico at gmail dot com Description: Using SimpleXML and SimpleXML_load_file to load an external XML file. The ::attributes feature does not recognize hyphens in attribute features, no documentation on how to resolve feature and the solution for dealing with hyphens in nodes (by putting it in curly braces and quotes {''}) does not solve the problem. This is my first time submitting a bug and I'm an amateur, but there is no documentation for a solution. Not sure if I selected the proper bug category. Sorry for any mistakes. Reproduce code: --- --- >From manual page: simplexmlelement.attributes#Description --- portion of xml file (parent nodes left out for simplicity): AbercrombieAye ex. 1: echo {'recorded-vote'}[0]->legislator->attributes()->{'name-id'}; ex. 2: print_r ({'recorded-vote'}[0]->legislator->attributes()); Expected result: ex. 1 A14 ex. 2 SimpleXMLElement Object ( [...@attributes] => Array ( [name-id] => A14 [sort-field] => Abercrombie [unaccented-name] => Abercrombie [party] => D [state] => HI [role] => legislator ) ) Actual result: -- ex. 1 0 To clarify, all that outputs is the digit zero. ex. 2 SimpleXMLElement Object ( [...@attributes] => Array ( [party] => D [state] => HI [role] => legislator ) ) -- Edit this bug report at http://bugs.php.net/?id=50759&edit=1
#50759 [Opn->Bgs]: SimpleXML ::atrributes() feature does not recognize hyphenated attributes
ID: 50759 Updated by: ahar...@php.net Reported By: stevendamico at gmail dot com -Status: Open +Status: Bogus -Bug Type: Scripting Engine problem +Bug Type: SimpleXML related Operating System: Windows PHP Version: 5.2.12 New Comment: Per example #5 in http://au2.php.net/manual/en/simplexml.examples-basic.php, the idiomatic way to access attributes in a SimpleXML tree is to access them in the same way as array elements. In your example, this should work (and works for me): echo $doc->...->{'recorded-vote'}->legislator['name-id']; Closing, as this isn't a bug in PHP itself. Thanks for your interest in PHP! Previous Comments: [2010-01-14 23:19:47] stevendamico at gmail dot com Description: Using SimpleXML and SimpleXML_load_file to load an external XML file. The ::attributes feature does not recognize hyphens in attribute features, no documentation on how to resolve feature and the solution for dealing with hyphens in nodes (by putting it in curly braces and quotes {''}) does not solve the problem. This is my first time submitting a bug and I'm an amateur, but there is no documentation for a solution. Not sure if I selected the proper bug category. Sorry for any mistakes. Reproduce code: --- --- >From manual page: simplexmlelement.attributes#Description --- portion of xml file (parent nodes left out for simplicity): AbercrombieAye ex. 1: echo {'recorded-vote'}[0]->legislator->attributes()->{'name-id'}; ex. 2: print_r ({'recorded-vote'}[0]->legislator->attributes()); Expected result: ex. 1 A14 ex. 2 SimpleXMLElement Object ( [...@attributes] => Array ( [name-id] => A14 [sort-field] => Abercrombie [unaccented-name] => Abercrombie [party] => D [state] => HI [role] => legislator ) ) Actual result: -- ex. 1 0 To clarify, all that outputs is the digit zero. ex. 2 SimpleXMLElement Object ( [...@attributes] => Array ( [party] => D [state] => HI [role] => legislator ) ) -- Edit this bug report at http://bugs.php.net/?id=50759&edit=1
#50755 [Opn]: PDO DBLIB Fails with OOM
ID: 50755 User updated by: ssufficool at gmail dot com Reported By: ssufficool at gmail dot com Status: Open Bug Type: PDO related Operating System: Linux 2.6.30-gentoo-r2 PHP Version: 5.3.1 New Comment: I have a patch that removes client side buffering and allows for large rowset queries without memory consumption. Compiled and tested http://svn.php.net/repository/php/php-src/branches/PHP_5_2 SVN Revision: 293557 I can send patch via e-mail. Previous Comments: [2010-01-14 19:09:48] ssufficool at gmail dot com Description: When querying large tables (> 800,000 rows) with PDO DBLIB I get out of memory. The same select query works fine using: linux# tsql -H host -U user -P pass SELECT * from aVeryLargeTable go quit on the command line using the freetds (dblib) library without consuming client-side memory. Reproduce code: --- $pdo = new PDO('dblib:host=host','user','pass'); echo "Creating table...\n"; $pdo->query("CREATE TABLE large_table (field_1 nvarchar(4000))"); $pdo->query("DECLARE @n int; set @n = 0; WHILE (@n < 5) BEGIN insert into large_table values( replicate(4000,'-') ); set @n = @n + 1; END"); echo "Prepare\n"; $rs = $pdo->prepare("SELECT * FROM large_table"); echo "Execute\n"; /*OOM HERE**/ $rs->execute( ); Expected result: A valid handle to a resultset in $rs Actual result: -- Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 48 bytes) in /home/ssufficool/tds_test.php on line 12 It looks like the guts of ext/pdo_dblib/dblib_stmt.c:pdo_dblib_stmt_execute() at "/* let's fetch all the data */" Should be moved to: pdo_dblib_stmt_fetch() and only when a scrollable cursor is requested should the data be buffered at the client (not required for ct-lib) -- Edit this bug report at http://bugs.php.net/?id=50755&edit=1
#50722 [Fbk->Opn]: Memory corruption / SegFault with WSDL in-memory cache
ID: 50722 User updated by: meatloafninja at gmail dot com Reported By: meatloafninja at gmail dot com -Status: Feedback +Status: Open Bug Type: SOAP related Operating System: CentOS 5.x PHP Version: 5.2.12 New Comment: It is not fixed, I can still reproduce the segmentation fault with the snapshot version. Previous Comments: [2010-01-13 13:34:10] srina...@php.net thanks for taking time to report this issue to us. can u please try to reproduce this issue with the latest snapshot. i am currently not able to reproduce with the latest snapshot. you can get the latest snapshot php source from http://snaps.php.net/ For Windows: http://windows.php.net/snapshots/ [2010-01-11 20:48:56] srina...@php.net sounds similar to bug #50675 (See Also) [2010-01-11 17:51:12] meatloafninja at gmail dot com Description: If you enable WSDL caching and set the cache type to 2 (memory) or 3 (both disk and memory), and create a SoapServer with a WSDL, and within the context of that SoapServer create multiple SoapClient connections to external web services with WSDLs (exceeding the soap.wsdl_cache_limit setting), the SoapServer's in-memory copy of its own WSDL will get removed / freed. This causes a segmentation fault of the web server child process or a corrupt / invalid XML response, as the SoapServer will be unable to access its own WSDL when the time comes to send its response to the original requesting client. The SoapServer WSDL should be protected from removal. Reproduce code: --- http://some.other.host/client1.wsdl";); $client2 = new SoapClient("http://some.other.host/client2.wsdl";); $client3 = new SoapClient("http://some.other.host/client3.wsdl";); $client4 = new SoapClient("http://some.other.host/client4.wsdl";); $client5 = new SoapClient("http://some.other.host/client5.wsdl";); return $x; //web server segfaults or corrupt XML returned } $server = new SoapServer("server.wsdl"); $server->addFunction("test"); $server->handle(); ?> Expected result: A valid XML response as defined by server.wsdl. Actual result: -- Either a segmentation fault on the web server and a "Could not fetch HTTP headers" error on the client, or a corrupted XML response. -- Edit this bug report at http://bugs.php.net/?id=50722&edit=1
#50759 [NEW]: SimpleXML ::atrributes() feature does not recognize hyphenated attributes
From: stevendamico at gmail dot com Operating system: Windows PHP version: 5.2.12 PHP Bug Type: Scripting Engine problem Bug description: SimpleXML ::atrributes() feature does not recognize hyphenated attributes Description: Using SimpleXML and SimpleXML_load_file to load an external XML file. The ::attributes feature does not recognize hyphens in attribute features, no documentation on how to resolve feature and the solution for dealing with hyphens in nodes (by putting it in curly braces and quotes {''}) does not solve the problem. This is my first time submitting a bug and I'm an amateur, but there is no documentation for a solution. Not sure if I selected the proper bug category. Sorry for any mistakes. Reproduce code: --- --- >From manual page: simplexmlelement.attributes#Description --- portion of xml file (parent nodes left out for simplicity): AbercrombieAye ex. 1: echo {'recorded-vote'}[0]->legislator->attributes()->{'name-id'}; ex. 2: print_r ({'recorded-vote'}[0]->legislator->attributes()); Expected result: ex. 1 A14 ex. 2 SimpleXMLElement Object ( [...@attributes] => Array ( [name-id] => A14 [sort-field] => Abercrombie [unaccented-name] => Abercrombie [party] => D [state] => HI [role] => legislator ) ) Actual result: -- ex. 1 0 To clarify, all that outputs is the digit zero. ex. 2 SimpleXMLElement Object ( [...@attributes] => Array ( [party] => D [state] => HI [role] => legislator ) ) -- Edit bug report at http://bugs.php.net/?id=50759&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50759&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50759&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50759&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50759&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50759&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50759&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50759&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50759&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50759&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50759&r=support Expected behavior: http://bugs.php.net/fix.php?id=50759&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50759&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50759&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50759&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50759&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50759&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50759&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50759&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50759&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50759&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50759&r=mysqlcfg
#48777 [Com]: Option to control SoapFault HTTP Status return (Reopen of #43507)
ID: 48777 Comment by: ld at e dot pl Reported By: jeff_dafoe at harte-hanks dot com Status: Open Bug Type: SOAP related Operating System: Linux PHP Version: 5.2.10 New Comment: This patch you made doesn't make sense for most applications. Simply you put: if (use_http_error_status) { sapi_add_header("HTTP/1.1 500 Internal Service Error", sizeof("HTTP/1.1 500 Internal Service Error")-1, 1); } but use_http_error_status is false only if HTTP_USER_AGENT=='Shockwave Flash' what it's only true if you are using AIR standalone but if you have embeded Flex code into a webpage then you HTTP_USER_AGENT is a browser one not the Shackwave Flash. Could you go here for something simpler like setting for SoapServer class telling the system if you want this HTTP 500 or not? Previous Comments: [2009-07-02 13:53:12] jeff_dafoe at harte-hanks dot com Description: Bug #43507 describes an issue with Adobe Flex / Flash / Air where the host browser does not pass the HTTP response body down to the Flash player when the browser receives a HTTP status code of 500. The bug suggests that the ability to set the HTTP status code be allowed. The fix that was decided on instead was to look for the user agent string "Shockwave Flash". The issue with this solution is that the player's requests either never did, only do on some platforms, or no longer contain this user agent string. The player's requests contain the user agent string associated with the host browser. AIR requests (a platform where the host browser is integrated into the Flash plugin, essentially) contain the Webkit UA string. To work around this we have patched soap.c's soap_server_fault_ex to set use_http_error_status to 0. Ideally, this setting could be exposed in the SoapServer constructor's "options" or "features". Since this is a workaround for a limitation in web browser's NAPI and not a problem with the SOAP library itself, making the use_http_error_status available as an option seems like an acceptable compromise. Reproduce code: --- throw new SoapFault('Client', $_SERVER['HTTP_USER_AGENT']); Expected result: HTTP/1.1 200 OK Actual result: -- HTTP/1.1 500 Internal Service Error -- Edit this bug report at http://bugs.php.net/?id=48777&edit=1
#50754 [Opn->Bgs]: var_export emits erroneous outputs on vars that contain recursive references
ID: 50754 Updated by: der...@php.net Reported By: andrew at trib dot tv -Status: Open +Status: Bogus Bug Type: Output Control Operating System: Fed 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 Remove the @ and you see what really happens: Fatal error: Nesting level too deep - recursive dependency? in - on line 9 Previous Comments: [2010-01-14 16:52:57] andrew at trib dot tv Description: My case is one in which var_export is being used to expose private members of classes present in the context of an error. So an error occurs, a custom handler is invoked, and it var_exports any variables in the error context which are objects, so that developers investigating the problem can see the values of private vars within these objects at the time the error occured. However, doing this: $str = var_export($object, true); If $object contains recursive references, var_export not only fails with a fatal error that cannot be handled or suppressed, but also flushes its internal output buffer, so if you've set the second argument to true, wanting the output returned rather than sent to the browser, you're out of luck, because it's gone. This is a security issue, because in some situations, a developer may have implemented var_export on objects with passwords stored within, and expects to get the object returned in a string. If the entire content of the object (up to the recursive reference) is instead output to the browser, this data is inadvertently exposed. I'd say that in such situations var_export should trigger an E_WARNING and return null or false. Then it can be safely used on objects that do not contain recursive references without having to know whether they do or not before you call the function. I'm aware of previous bugs filed on this issue, notably 17874 and 16074, so I raise this specifically in relation to te security implications, and also making the point that it is not possible to detect whether an object contains *private* recursive references before you take your life in your hands by throwing it at var_export and crossing your fingers! Cheers, Andrew Reproduce code: --- reftoself = $this; } } $x = new PrivateThing; $y = @var_export($x, true); echo "No passwords here!"; ?> Expected result: No passwords here! Actual result: -- PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( -- Edit this bug report at http://bugs.php.net/?id=50754&edit=1
#50717 [Opn->Ana]: Slow download speed
ID: 50717 Updated by: ras...@php.net Reported By: abaddon_a2006 at yahoo dot com -Status: Open +Status: Analyzed Bug Type: cURL related Operating System: fedora 12 PHP Version: 5.3.1 New Comment: I doubt this is a PHP issue, if it even is an issue at all. From the PHP side there is no difference between a request with a cookie and one without. That's all inside libcurl. Try emulating the same thing from the command-line curl client with and without a cookie jar and see if you see the same effect. I predict you will. Previous Comments: [2010-01-14 21:40:38] abaddon_a2006 at yahoo dot com any info about this [2010-01-12 10:59:56] abaddon_a2006 at yahoo dot com curl 7.19.7 (i386-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.4.5 zlib/1.2.3 libidn/1.9 libssh2/1.2 Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp Features: GSS-Negotiate IDN IPv6 Largefile SSL libz [2010-01-12 10:19:25] j...@php.net What curl version have you compiled PHP with? [2010-01-11 16:02:15] abaddon_a2006 at yahoo dot com here it is a code that reproduce the problem $ch = curl_init(); curl_setopt($ch, CURLOPT_COOKIEJAR, "name"); curl_setopt($ch, CURLOPT_URL,"http://url/login.php";); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, 'user=username&password=pass'); ob_start(); // prevent any output curl_exec ($ch); // execute the curl command ob_end_clean(); // stop preventing output curl_close ($ch); unset($ch); $opt = array( CURLOPT_RETURNTRANSFER => 1, CURLOPT_COOKIEFILE => "name", CURLOPT_USERAGENT => "Mozilla/5.001 (windows; U; NT4.0; en-US; rv:1.0) Gecko/25250101", CURLOPT_PORT => "80" ); if i submit this code everything is ok 0.21246290206909 seconds this is the time response but if i add this under it $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, 'http://url'); curl_setopt_array($ch,$opt); $content = curl_exec($ch); print_r(curl_getinfo($ch)); curl_close($ch); here is what it does return and it's weird yesterday i had no problem with namelookup_time and today it does seem that it's unable to calculate it... Array ( [url] => http://url [content_type] => text/html; charset=utf-8 [http_code] => 200 [header_size] => 244 [request_size] => 227 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 0 [total_time] => 5.878797 [namelookup_time] => 2.6E-5 [connect_time] => 0.06947 [pretransfer_time] => 0.069475 [size_upload] => 0 [size_download] => 19463 [speed_download] => 3310 [speed_upload] => 0 [download_content_length] => -1 [upload_content_length] => 0 [starttransfer_time] => 5.74344 [redirect_time] => 0 ) This page was created in 6.0242450237274 seconds hope this will be fixed soon thank you [2010-01-10 22:35:20] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. 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/50717 -- Edit this bug report at http://bugs.php.net/?id=50717&edit=1
#50717 [Opn]: Slow download speed
ID: 50717 User updated by: abaddon_a2006 at yahoo dot com Reported By: abaddon_a2006 at yahoo dot com Status: Open Bug Type: cURL related Operating System: fedora 12 PHP Version: 5.3.1 New Comment: any info about this Previous Comments: [2010-01-12 10:59:56] abaddon_a2006 at yahoo dot com curl 7.19.7 (i386-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.4.5 zlib/1.2.3 libidn/1.9 libssh2/1.2 Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp Features: GSS-Negotiate IDN IPv6 Largefile SSL libz [2010-01-12 10:19:25] j...@php.net What curl version have you compiled PHP with? [2010-01-11 16:02:15] abaddon_a2006 at yahoo dot com here it is a code that reproduce the problem $ch = curl_init(); curl_setopt($ch, CURLOPT_COOKIEJAR, "name"); curl_setopt($ch, CURLOPT_URL,"http://url/login.php";); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, 'user=username&password=pass'); ob_start(); // prevent any output curl_exec ($ch); // execute the curl command ob_end_clean(); // stop preventing output curl_close ($ch); unset($ch); $opt = array( CURLOPT_RETURNTRANSFER => 1, CURLOPT_COOKIEFILE => "name", CURLOPT_USERAGENT => "Mozilla/5.001 (windows; U; NT4.0; en-US; rv:1.0) Gecko/25250101", CURLOPT_PORT => "80" ); if i submit this code everything is ok 0.21246290206909 seconds this is the time response but if i add this under it $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, 'http://url'); curl_setopt_array($ch,$opt); $content = curl_exec($ch); print_r(curl_getinfo($ch)); curl_close($ch); here is what it does return and it's weird yesterday i had no problem with namelookup_time and today it does seem that it's unable to calculate it... Array ( [url] => http://url [content_type] => text/html; charset=utf-8 [http_code] => 200 [header_size] => 244 [request_size] => 227 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 0 [total_time] => 5.878797 [namelookup_time] => 2.6E-5 [connect_time] => 0.06947 [pretransfer_time] => 0.069475 [size_upload] => 0 [size_download] => 19463 [speed_download] => 3310 [speed_upload] => 0 [download_content_length] => -1 [upload_content_length] => 0 [starttransfer_time] => 5.74344 [redirect_time] => 0 ) This page was created in 6.0242450237274 seconds hope this will be fixed soon thank you [2010-01-10 22:35:20] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-01-10 18:14:27] abaddon_a2006 at yahoo dot com Description: If you use cURL to login and store a cookie with CURLOPT_COOKIEJAR, "cookie"); and later retrieve the cookie with CURLOPT_COOKIEFILE the download speed is very low i dont know why this is happening but it's happening. tested without cookie download speed is normal,but with cookie is somewhere around 7KB maximum -- Edit this bug report at http://bugs.php.net/?id=50717&edit=1
#50757 [NEW]: PDO MYSQL issue with BIT data type not setting correct value
From: christian at activemediaworks dot com Operating system: MAC OSX 10.5.8 PHP version: 5.2.12 PHP Bug Type: PDO related Bug description: PDO MYSQL issue with BIT data type not setting correct value Description: When trying to insert a row with a 0-value into a column of type BIT(1), if the value for the column is not hard-coded into SQL statement, it causes the value to be inserted to become 1. If it is hardcoded, it is okay. Reproduce code: --- /* This results in the value of the column being set to 1 (incorrect) */ $db = new PDO ( "mysql:dbname=db1234;host=localhost", "user1234", "pass1234" ); $stmt = $db->prepare("INSERT INTO mytable (mybit) VALUES (?)"); $stmt->execute(array(0)); db_disconnect($db); /* This results in the value of the column being set to 0 (correct) */ $db = new PDO ( "mysql:dbname=db1234;host=localhost", "user1234", "pass1234" ); $stmt = $db->prepare("INSERT INTO mytable (mybit) VALUES (0)"); $stmt->execute(); db_disconnect($db); Actual result: -- The first example inserts a row with the column value set to 1 (wrong) The second example inserts a row with the column value set to 0 (right) -- Edit bug report at http://bugs.php.net/?id=50757&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50757&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50757&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50757&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50757&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50757&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50757&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50757&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50757&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50757&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50757&r=support Expected behavior: http://bugs.php.net/fix.php?id=50757&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50757&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50757&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50757&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50757&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50757&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50757&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50757&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50757&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50757&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50757&r=mysqlcfg
#50756 [NEW]: CURLOPT_FTP_SKIP_PASV_IP does not exist
From: rob dot apodaca at gmail dot com Operating system: any PHP version: 5.3.1 PHP Bug Type: Feature/Change Request Bug description: CURLOPT_FTP_SKIP_PASV_IP does not exist Description: The CURLOPT_FTP_SKIP_PASV_IP option is part of libcurl (see http://curl.haxx.se/libcurl/c/curl_easy_setopt.html ) but no predefined constant exists for use with curl_setopt(). -- Edit bug report at http://bugs.php.net/?id=50756&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50756&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50756&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50756&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50756&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50756&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50756&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50756&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50756&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50756&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50756&r=support Expected behavior: http://bugs.php.net/fix.php?id=50756&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50756&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50756&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50756&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50756&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50756&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50756&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50756&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50756&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50756&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50756&r=mysqlcfg
#50755 [NEW]: PDO DBLIB Fails with OOM
From: ssufficool at gmail dot com Operating system: Linux 2.6.30-gentoo-r2 PHP version: 5.3.1 PHP Bug Type: PDO related Bug description: PDO DBLIB Fails with OOM Description: When querying large tables (> 800,000 rows) with PDO DBLIB I get out of memory. The same select query works fine using: linux# tsql -H host -U user -P pass SELECT * from aVeryLargeTable go quit on the command line using the freetds (dblib) library without consuming client-side memory. Reproduce code: --- $pdo = new PDO('dblib:host=host','user','pass'); echo "Creating table...\n"; $pdo->query("CREATE TABLE large_table (field_1 nvarchar(4000))"); $pdo->query("DECLARE @n int; set @n = 0; WHILE (@n < 5) BEGIN insert into large_table values( replicate(4000,'-') ); set @n = @n + 1; END"); echo "Prepare\n"; $rs = $pdo->prepare("SELECT * FROM large_table"); echo "Execute\n"; /*OOM HERE**/ $rs->execute( ); Expected result: A valid handle to a resultset in $rs Actual result: -- Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 48 bytes) in /home/ssufficool/tds_test.php on line 12 It looks like the guts of ext/pdo_dblib/dblib_stmt.c:pdo_dblib_stmt_execute() at "/* let's fetch all the data */" Should be moved to: pdo_dblib_stmt_fetch() and only when a scrollable cursor is requested should the data be buffered at the client (not required for ct-lib) -- Edit bug report at http://bugs.php.net/?id=50755&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50755&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50755&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50755&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50755&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50755&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50755&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50755&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50755&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50755&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50755&r=support Expected behavior: http://bugs.php.net/fix.php?id=50755&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50755&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50755&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50755&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50755&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50755&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50755&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50755&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50755&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50755&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50755&r=mysqlcfg
#47589 [Bgs]: PDO DBLIB Fails with OOM on large recordsets
ID: 47589 User updated by: ssufficool at gmail dot com -Reported By: ssufficool at roadrunner dot com +Reported By: ssufficool at gmail dot com Status: Bogus Bug Type: PDO related Operating System: Linux (Gentoo) PHP Version: 5.2.9 New Comment: new e-mail Previous Comments: [2010-01-14 18:20:33] ssufficool at roadrunner dot com Please re-open this bug. I understand that the behaviour is shared across the PDO::DBLIB and MSSQL_* functions, however other PDO drivers do not have this issue (I.E. PDO:POSTGRESQL) and the same query issued on the command line via freetds (tsql) does not consume memory like this. I am using a CURSOR_FWDONLY and this should not require buffering all the rows on the client. [2009-03-06 17:04:47] ssufficool at roadrunner dot com My understanding of Bogus is indeed Bogus. After setting batchsize to 0 in php.ini, mssql_query also barfs on large recordssets. Apologies for the noise. [2009-03-06 16:36:43] ssufficool at gmail dot com Description: When pulling large recordsets with PDO DBLIB I get out of memory. This type of large recordset query works fine on mssql_* functions using the freetds library. This issue has been marked "Bogus" in the past. But since this works with other functions using FreeTDS, this issue may lie in the PDO layer. Correct me if my understanding of Bogus is Bogus. Reproduce code: --- $pdo_ms = new PDO('dblib: host=host', 'user','pass'); /* We die here */ $rs = $pdo_ms->query("SELECT TOP 5 from aVeryLargeTable"); Expected result: A valid handle to a resultset in $rs Actual result: -- Available memory exhausted, tried to allocate -- Edit this bug report at http://bugs.php.net/?id=47589&edit=1
#47589 [Bgs]: PDO DBLIB Fails with OOM on large recordsets
ID: 47589 User updated by: ssufficool at roadrunner dot com Reported By: ssufficool at roadrunner dot com Status: Bogus Bug Type: PDO related Operating System: Linux (Gentoo) PHP Version: 5.2.9 New Comment: Please re-open this bug. I understand that the behaviour is shared across the PDO::DBLIB and MSSQL_* functions, however other PDO drivers do not have this issue (I.E. PDO:POSTGRESQL) and the same query issued on the command line via freetds (tsql) does not consume memory like this. I am using a CURSOR_FWDONLY and this should not require buffering all the rows on the client. Previous Comments: [2009-03-06 17:04:47] ssufficool at roadrunner dot com My understanding of Bogus is indeed Bogus. After setting batchsize to 0 in php.ini, mssql_query also barfs on large recordssets. Apologies for the noise. [2009-03-06 16:36:43] ssufficool at roadrunner dot com Description: When pulling large recordsets with PDO DBLIB I get out of memory. This type of large recordset query works fine on mssql_* functions using the freetds library. This issue has been marked "Bogus" in the past. But since this works with other functions using FreeTDS, this issue may lie in the PDO layer. Correct me if my understanding of Bogus is Bogus. Reproduce code: --- $pdo_ms = new PDO('dblib: host=host', 'user','pass'); /* We die here */ $rs = $pdo_ms->query("SELECT TOP 5 from aVeryLargeTable"); Expected result: A valid handle to a resultset in $rs Actual result: -- Available memory exhausted, tried to allocate -- Edit this bug report at http://bugs.php.net/?id=47589&edit=1
#50754 [NEW]: var_export emits erroneous outputs on vars that contain recursive references
From: andrew at trib dot tv Operating system: Fed PHP version: 5.3.1 PHP Bug Type: Output Control Bug description: var_export emits erroneous outputs on vars that contain recursive references Description: My case is one in which var_export is being used to expose private members of classes present in the context of an error. So an error occurs, a custom handler is invoked, and it var_exports any variables in the error context which are objects, so that developers investigating the problem can see the values of private vars within these objects at the time the error occured. However, doing this: $str = var_export($object, true); If $object contains recursive references, var_export not only fails with a fatal error that cannot be handled or suppressed, but also flushes its internal output buffer, so if you've set the second argument to true, wanting the output returned rather than sent to the browser, you're out of luck, because it's gone. This is a security issue, because in some situations, a developer may have implemented var_export on objects with passwords stored within, and expects to get the object returned in a string. If the entire content of the object (up to the recursive reference) is instead output to the browser, this data is inadvertently exposed. I'd say that in such situations var_export should trigger an E_WARNING and return null or false. Then it can be safely used on objects that do not contain recursive references without having to know whether they do or not before you call the function. I'm aware of previous bugs filed on this issue, notably 17874 and 16074, so I raise this specifically in relation to te security implications, and also making the point that it is not possible to detect whether an object contains *private* recursive references before you take your life in your hands by throwing it at var_export and crossing your fingers! Cheers, Andrew Reproduce code: --- reftoself = $this; } } $x = new PrivateThing; $y = @var_export($x, true); echo "No passwords here!"; ?> Expected result: No passwords here! Actual result: -- PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( -- Edit bug report at http://bugs.php.net/?id=50754&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50754&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50754&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50754&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50754&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50754&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50754&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50754&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50754&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50754&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50754&r=support Expected behavior: http://bugs.php.net/fix.php?id=50754&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50754&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50754&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50754&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50754&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50754&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50754&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50754&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50754&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50754&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50754&r=mysqlcfg
#50743 [Bgs]: No escape function escapes properly
ID: 50743 Updated by: ras...@php.net Reported By: eric at sharecorp dot com Status: Bogus Bug Type: Strings related Operating System: Linux PHP Version: 5.2.12 New Comment: mysql_real_escape_string() does take the character set of the connection into account. I also tested your script, with a slight change. You forgot to pass 'UTF-8' to your htmlentities call: Input: __ handler.php ___ SQL for creating news2 _ REATE TABLE IF NOT EXISTS `news2` ( `id` int(11) NOT NULL auto_increment, `title` varchar(40) collate utf8_unicode_ci NOT NULL, `date` date NOT NULL, `tagline` varchar(120) collate utf8_unicode_ci NOT NULL, `article` text collate utf8_unicode_ci NOT NULL, `image` int(11) NOT NULL, `image_orig` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=44 ; _ Demo text __ We are pleased to announce our improved website. We've updated it to have a cleaner, more modern look, improved existing features and added some new features as well. Let's take a quick tour of the Products section. The first thing you'll notice when you click on the Products link is that the product categories have been updated. This is now consistent with our 2010 Color Catalog. The second thing that you'll notice is that the products may not be listed alphabetically in their respective categories. The products are now ranked by the most clicked on to least clicked on. In other words, our most popular products are listed at the top of each category. A third thing you may notice is that there's an Equipment section. All of the products listed in the Color Catalog's Equipment section can now be found here along with a picture. ___ The insertion of the above text falters after "Let's take a quick tour of the" and nothing else posts. [2010-01-13 18:25:35] ras...@php.net Are you sure? mysql> select * from users where name=rlerdorf; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '��rlerdorf��' at line 1 mysql> select * from users where name="rlerdorf"; Empty set (0.03 sec) As far as I can tell, MySQL does not treat those odd quotes as regular quotes anywhere. Please provide a standalone test case along with your MySQL version that shows this. [2010-01-13 18:19:59] eric at sharecorp dot com Description: None of the escaping functions are able to properly handle style quotes, which are produced by default by open office. Functions that I have tested include mysql_real_escape_string, htmlentities, addslashes and addcslashes. This behavior causes text insertion into mysql to fail as it interprets these quotes as normal double quotes. Reproduce code: --- $title = $_POST['title']; $date = $_POST['date']; $tagline = $_POST['tagline']; $article =nl2br(htmlentities($_POST['article'],ENT_QUOTES)); // $query = "INSERT INTO news (title, date, tagline, article, image, image_orig) VALUES ('$title', '$date', '$tagline', '$article', '$image',$image_orig')" Expected result: The should be caught, escaped properly and not affecting the query. In this case $article was the varible containing the quotes in question. Actual result: -- All text after the opening quote is dropped from the data inserted into the query. -- Edit this bug report at http://bugs.php.net/?id=50743&edit=1
#50753 [Opn->Asn]: crypt_sha256.c / crypt_sha512.c - Gnu specific code, non-Gnu compiler
ID: 50753 Updated by: johan...@php.net Reported By: yatessc at telkom dot co dot za -Status: Open +Status: Assigned Bug Type: Compile Failure Operating System: Solaris 9 Sparc PHP Version: 5.3.2RC1 -Assigned To: +Assigned To: dsp New Comment: Related to #50496. David, as you expected the other C99 types create some trouble, too :-/ Previous Comments: [2010-01-14 15:22:03] yatessc at telkom dot co dot za Description: Using Sun ONE Studio 8 cc compiler on Solaris 9 Sparc. Compilation of ext/standard/crypt_sha512.c fails with: "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 376: syntax error before or at: __attribute__ "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 377: invalid type combination "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 378: syntax error before or at: __attribute__ "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 380: invalid type combination "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 416: warning: implicit function declaration: __alignof__ "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 416: syntax error before or at: uint64_t "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 419: undefined symbol: tmp "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 419: syntax error before or at: uint64_t "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 420: cannot recover from previous errors ext/standard/crypt_sha256.c also fails with similar errors, just different line numbers. I believe that __attribute__ and __alignof__ are Gnu specific extensions, although __alignof__ has been adopted by some other compilers (e.g. Sun Studio, but only from Release 12 onwards). The problem still exists with yesterday's snapshot (php5.3-201001130730.tar.gz). -- Edit this bug report at http://bugs.php.net/?id=50753&edit=1
#50753 [NEW]: crypt_sha256.c / crypt_sha512.c - Gnu specific code, non-Gnu compiler
From: yatessc at telkom dot co dot za Operating system: Solaris 9 Sparc PHP version: 5.3.2RC1 PHP Bug Type: Compile Failure Bug description: crypt_sha256.c / crypt_sha512.c - Gnu specific code, non-Gnu compiler Description: Using Sun ONE Studio 8 cc compiler on Solaris 9 Sparc. Compilation of ext/standard/crypt_sha512.c fails with: "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 376: syntax error before or at: __attribute__ "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 377: invalid type combination "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 378: syntax error before or at: __attribute__ "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 380: invalid type combination "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 416: warning: implicit function declaration: __alignof__ "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 416: syntax error before or at: uint64_t "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 419: undefined symbol: tmp "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 419: syntax error before or at: uint64_t "/usr/local/php5.3-201001130730/ext/standard/crypt_sha512.c", line 420: cannot recover from previous errors ext/standard/crypt_sha256.c also fails with similar errors, just different line numbers. I believe that __attribute__ and __alignof__ are Gnu specific extensions, although __alignof__ has been adopted by some other compilers (e.g. Sun Studio, but only from Release 12 onwards). The problem still exists with yesterday's snapshot (php5.3-201001130730.tar.gz). -- Edit bug report at http://bugs.php.net/?id=50753&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50753&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50753&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50753&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50753&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50753&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50753&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50753&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50753&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50753&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50753&r=support Expected behavior: http://bugs.php.net/fix.php?id=50753&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50753&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50753&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50753&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50753&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50753&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50753&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50753&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50753&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50753&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50753&r=mysqlcfg
#50676 [Bgs]: rename across Volumes throws warning "Operation not permitted"
ID: 50676 Updated by: ahar...@php.net Reported By: andreas at heigl dot org Status: Bogus Bug Type: Filesystem function related Operating System: Mac OS X 10.6 PHP Version: 5.3.1 New Comment: The warnings may also be coming from the chown() and chmod() calls that occur between the copy and unlink when the rename call has to be faked across partitions -- there's no way of distinguishing them, since the warnings in php_plain_files_rename() just wrap strerror(). I wonder if this might be worth morphing into a doc bug: the rename manual page currently says that, as of 4.3.3, "rename() is now able to rename files across partitions on *nix based systems", which does seem to be overstating things a little. Something along the lines of "rename() may be able to rename files across partitions on *nix based systems, provided the appropriate permissions are held. Warnings may be thrown if the destination filesystem doesn't permit chown() or chmod() calls to be made on files." might be better. Previous Comments: [2010-01-14 15:10:12] paj...@php.net Volumes can be mounted everywhere on windows as well. That does not change the fact that they are a different volume. Please read the underlying documentations for rename and how it works, that may help to understand the limitation. [2010-01-14 14:45:05] andreas at heigl dot org I understand, that rename can only operate on the same volume (like the move-command). But unlike in windows on a Mac (as on any other UNIX-like environment) volumes can be mount anywhere in the folder-hirachy, so that it is rather difficult to check whether source and target of the rename are on the same volume or not. And as I pointed out in the original bug-report, the source-file actually is deleted, so there is no need for the error message. [2010-01-14 13:56:49] il...@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 rename() can only work "normally" when operating on the same volume. In your case it emulates rename via copy & delete. I would guess since it cannot delete file from the original volume, it gives you an error message. [2010-01-11 12:59:23] p dot szalko at gmail dot com The same bug is in PHP 5.2.11 and Mac OS X 10.5 [2010-01-06 10:16:00] andreas at heigl dot org Description: When renaming files acros Volumes a warning is triggered that the "Operation is not permitted. The operation is executed though. Reproduce code: --- - Create two images and mount them (Image1, Image2). - Disable the 'Ignore Owner'-Feature on both of them and set permissions so the WebServer can access the files. - Add a file to one of the mounted volumes (touch /Volumes/Image1/testfile) ini_set ( 'error_reporting', E_ALL ); ini_set ( 'display_errors', true ); rename ( '/Volumes/Image1/testfile', '/Volumes/Image2/testfile' ); Expected result: The file /Volumes/Image1/testfile has been copied to /Volumes/Image2/testfile ad the original file has been removed. No error should be triggered Actual result: -- The file /Volumes/Image1/testfile has been copied to /Volumes/Image2/testfile ad the original file has been removed. Additionally the following error is triggered: rename(/Volumes/Image1/testfile,/Volumes/Image2/testfile): Operation not permitted in renametest.php on line n -- Edit this bug report at http://bugs.php.net/?id=50676&edit=1
#50743 [Bgs]: No escape function escapes properly
ID: 50743 User updated by: eric at sharecorp dot com Reported By: eric at sharecorp dot com Status: Bogus Bug Type: Strings related Operating System: Linux PHP Version: 5.2.12 New Comment: What about mysql_real_escape_string, should that function not catch these types of inputs? Previous Comments: [2010-01-14 10:20:51] j...@php.net htmlentities() is not unicode aware in PHP 5.x. Use the mbstring / iconv functions to deal with such strings. [2010-01-13 18:54:05] eric at sharecorp dot com Mysql version 5.0.84-r1 from gentoo portage. Stand alone example follows: form.php _ Input: __ handler.php ___ SQL for creating news2 _ REATE TABLE IF NOT EXISTS `news2` ( `id` int(11) NOT NULL auto_increment, `title` varchar(40) collate utf8_unicode_ci NOT NULL, `date` date NOT NULL, `tagline` varchar(120) collate utf8_unicode_ci NOT NULL, `article` text collate utf8_unicode_ci NOT NULL, `image` int(11) NOT NULL, `image_orig` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=44 ; _ Demo text __ We are pleased to announce our improved website. We've updated it to have a cleaner, more modern look, improved existing features and added some new features as well. Let's take a quick tour of the Products section. The first thing you'll notice when you click on the Products link is that the product categories have been updated. This is now consistent with our 2010 Color Catalog. The second thing that you'll notice is that the products may not be listed alphabetically in their respective categories. The products are now ranked by the most clicked on to least clicked on. In other words, our most popular products are listed at the top of each category. A third thing you may notice is that there's an Equipment section. All of the products listed in the Color Catalog's Equipment section can now be found here along with a picture. ___ The insertion of the above text falters after "Let's take a quick tour of the" and nothing else posts. [2010-01-13 18:25:35] ras...@php.net Are you sure? mysql> select * from users where name=rlerdorf; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '��rlerdorf��' at line 1 mysql> select * from users where name="rlerdorf"; Empty set (0.03 sec) As far as I can tell, MySQL does not treat those odd quotes as regular quotes anywhere. Please provide a standalone test case along with your MySQL version that shows this. [2010-01-13 18:19:59] eric at sharecorp dot com Description: None of the escaping functions are able to properly handle style quotes, which are produced by default by open office. Functions that I have tested include mysql_real_escape_string, htmlentities, addslashes and addcslashes. This behavior causes text insertion into mysql to fail as it interprets these quotes as normal double quotes. Reproduce code: --- $title = $_POST['title']; $date = $_POST['date']; $tagline = $_POST['tagline']; $article =nl2br(htmlentities($_POST['article'],ENT_QUOTES)); // $query = "INSERT INTO news (title, date, tagline, article, image, image_orig) VALUES ('$title', '$date', '$tagline', '$article', '$image',$image_orig')" Expected result: The should be caught, escaped properly and not affecting the query. In this case $article was the varible containing the quotes in question. Actual result: -- All text after the opening quote is dropped from the data inserted into the query. -- Edit this bug report at http://bugs.php.net/?id=50743&edit=1
#50670 [Fbk->Opn]: Incorrect Iteration over large (10k elements) xml file
ID: 50670 User updated by: niklas at frubar dot net Reported By: niklas at frubar dot net -Status: Feedback +Status: Open Bug Type: SimpleXML related Operating System: Linux 2.6.9 x86_64 -PHP Version: 5.*, 6 +PHP Version: 5.3.* New Comment: Reproduce Code -- XML; for($i = 1; $i < 15000; $i++) $xml .= ''; $xml .= << XML; function traverse($node) { static $list; foreach ($node->children() as $child) traverse($child); $list[] = $node->attributes(); echo $node['id'] . "\n"; } traverse(new SimpleXMLElement($xml)); ?> Previous Comments: [2010-01-11 09:16:28] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-01-05 20:04:17] matth at mlalonde dot net Same results in 5.2.9 as with 5.2.12. [2010-01-05 19:37:23] niklas at frubar dot net It works with other array values, if you replace $list[] = $node->attributes(); with $c = array(); $list[] = $c; it resets the iteration at the same node. $list[] = array(); does not reset the iteration however. $list[] = new stdClass(); does reset the iteration. Adding simple integers or strings to the array do not reset. [2010-01-05 18:57:45] niklas at frubar dot net Description: When iterating over a large xml object and storing attributes of all nodes in an array, somehow the iteration gets reset (always at the same element) Tested with 5.3.1 and php-5.3 svn HEAD, does not occur on php-5.2.12. Reproduce code: --- children() as $child) traverse($child); $list[] = $node->attributes(); echo $node['id'] . "\n"; } traverse(new SimpleXMLElement('data.xml', null, true)); data.xml: [...] Expected result: 1 2 3 [.. continuous numbers ..] 14997 14998 14999 Actual result: -- 1 2 3 [.. continuous numbers ..]9994 9995 9996 2 3 4 [.. continuous numbers ..] 14997 14998 14999 -- Edit this bug report at http://bugs.php.net/?id=50670&edit=1
#50676 [Bgs]: rename across Volumes throws warning "Operation not permitted"
ID: 50676 Updated by: paj...@php.net Reported By: andreas at heigl dot org Status: Bogus Bug Type: Filesystem function related Operating System: Mac OS X 10.6 PHP Version: 5.3.1 New Comment: Volumes can be mounted everywhere on windows as well. That does not change the fact that they are a different volume. Please read the underlying documentations for rename and how it works, that may help to understand the limitation. Previous Comments: [2010-01-14 14:45:05] andreas at heigl dot org I understand, that rename can only operate on the same volume (like the move-command). But unlike in windows on a Mac (as on any other UNIX-like environment) volumes can be mount anywhere in the folder-hirachy, so that it is rather difficult to check whether source and target of the rename are on the same volume or not. And as I pointed out in the original bug-report, the source-file actually is deleted, so there is no need for the error message. [2010-01-14 13:56:49] il...@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 rename() can only work "normally" when operating on the same volume. In your case it emulates rename via copy & delete. I would guess since it cannot delete file from the original volume, it gives you an error message. [2010-01-11 12:59:23] p dot szalko at gmail dot com The same bug is in PHP 5.2.11 and Mac OS X 10.5 [2010-01-06 10:16:00] andreas at heigl dot org Description: When renaming files acros Volumes a warning is triggered that the "Operation is not permitted. The operation is executed though. Reproduce code: --- - Create two images and mount them (Image1, Image2). - Disable the 'Ignore Owner'-Feature on both of them and set permissions so the WebServer can access the files. - Add a file to one of the mounted volumes (touch /Volumes/Image1/testfile) ini_set ( 'error_reporting', E_ALL ); ini_set ( 'display_errors', true ); rename ( '/Volumes/Image1/testfile', '/Volumes/Image2/testfile' ); Expected result: The file /Volumes/Image1/testfile has been copied to /Volumes/Image2/testfile ad the original file has been removed. No error should be triggered Actual result: -- The file /Volumes/Image1/testfile has been copied to /Volumes/Image2/testfile ad the original file has been removed. Additionally the following error is triggered: rename(/Volumes/Image1/testfile,/Volumes/Image2/testfile): Operation not permitted in renametest.php on line n -- Edit this bug report at http://bugs.php.net/?id=50676&edit=1
#50676 [Bgs]: rename across Volumes throws warning "Operation not permitted"
ID: 50676 User updated by: andreas at heigl dot org Reported By: andreas at heigl dot org Status: Bogus Bug Type: Filesystem function related Operating System: Mac OS X 10.6 PHP Version: 5.3.1 New Comment: I understand, that rename can only operate on the same volume (like the move-command). But unlike in windows on a Mac (as on any other UNIX-like environment) volumes can be mount anywhere in the folder-hirachy, so that it is rather difficult to check whether source and target of the rename are on the same volume or not. And as I pointed out in the original bug-report, the source-file actually is deleted, so there is no need for the error message. Previous Comments: [2010-01-14 13:56:49] il...@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 rename() can only work "normally" when operating on the same volume. In your case it emulates rename via copy & delete. I would guess since it cannot delete file from the original volume, it gives you an error message. [2010-01-11 12:59:23] p dot szalko at gmail dot com The same bug is in PHP 5.2.11 and Mac OS X 10.5 [2010-01-06 10:16:00] andreas at heigl dot org Description: When renaming files acros Volumes a warning is triggered that the "Operation is not permitted. The operation is executed though. Reproduce code: --- - Create two images and mount them (Image1, Image2). - Disable the 'Ignore Owner'-Feature on both of them and set permissions so the WebServer can access the files. - Add a file to one of the mounted volumes (touch /Volumes/Image1/testfile) ini_set ( 'error_reporting', E_ALL ); ini_set ( 'display_errors', true ); rename ( '/Volumes/Image1/testfile', '/Volumes/Image2/testfile' ); Expected result: The file /Volumes/Image1/testfile has been copied to /Volumes/Image2/testfile ad the original file has been removed. No error should be triggered Actual result: -- The file /Volumes/Image1/testfile has been copied to /Volumes/Image2/testfile ad the original file has been removed. Additionally the following error is triggered: rename(/Volumes/Image1/testfile,/Volumes/Image2/testfile): Operation not permitted in renametest.php on line n -- Edit this bug report at http://bugs.php.net/?id=50676&edit=1
#50751 [NEW]: Setting memcache handler by ini_set doesn't work with enabled safe_mode
From: kukulich at kukulich dot cz Operating system: PHP version: 5.3.1 PHP Bug Type: Session related Bug description: Setting memcache handler by ini_set doesn't work with enabled safe_mode Description: Setting memcache handler by ini_set doesn't work with enabled safe_mode. It works with disabled safe_mode. It also works if handler and save_path are set in php.ini. Reproduce code: --- http://bugs.php.net/?id=50751&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50751&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50751&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50751&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50751&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50751&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50751&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50751&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50751&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50751&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50751&r=support Expected behavior: http://bugs.php.net/fix.php?id=50751&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50751&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50751&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50751&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50751&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50751&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50751&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50751&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50751&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50751&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50751&r=mysqlcfg
#39138 [Com]: LOCK_NB for flock() does not work
ID: 39138 Comment by: sp at vovochka dot org dot ua Reported By: php at koterov dot ru Status: No Feedback Bug Type: Filesystem function related Operating System: Windows, Linux PHP Version: 5.1.6 New Comment: Guys! Are you going to fix this bug. It is more than 3 years old! It is reproducable on NTFS. Previous Comments: [2007-05-28 10:50:44] bugreporter at sigproc dot de Hi, problem might be just due to unclear documentation on how to apply LOCK_NB. The current flock docu says one should "add LOCK_NB to $operation" (i.e. to the second parameter of the function). A comment on the docu page wants to assure us that neither of the following will work (administrator at proxy-list dot org, 30-Apr-2007 08:30) (Rather separate flock calls should be used.) So question to the PHP devs: what is the right way to do it? Cheers [2006-10-22 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-10-14 13:09:50] tony2...@php.net Where can I see the results? (as I'm unable to reproduce it locally) [2006-10-13 19:06:49] php at koterov dot ru I cannot try snapshot on Linux - I have no machine for experiments. And you said that Linux has no problem in new version. Now we are talking about Windows only. [2006-10-13 14:20:28] tony2...@php.net Wait, so did you try the snapshot on Linux? Or are you talking only of Windows now? 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/39138 -- Edit this bug report at http://bugs.php.net/?id=39138&edit=1
#50676 [Opn->Bgs]: rename across Volumes throws warning "Operation not permitted"
ID: 50676 Updated by: il...@php.net Reported By: andreas at heigl dot org -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: Mac OS X 10.6 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 rename() can only work "normally" when operating on the same volume. In your case it emulates rename via copy & delete. I would guess since it cannot delete file from the original volume, it gives you an error message. Previous Comments: [2010-01-11 12:59:23] p dot szalko at gmail dot com The same bug is in PHP 5.2.11 and Mac OS X 10.5 [2010-01-06 10:16:00] andreas at heigl dot org Description: When renaming files acros Volumes a warning is triggered that the "Operation is not permitted. The operation is executed though. Reproduce code: --- - Create two images and mount them (Image1, Image2). - Disable the 'Ignore Owner'-Feature on both of them and set permissions so the WebServer can access the files. - Add a file to one of the mounted volumes (touch /Volumes/Image1/testfile) ini_set ( 'error_reporting', E_ALL ); ini_set ( 'display_errors', true ); rename ( '/Volumes/Image1/testfile', '/Volumes/Image2/testfile' ); Expected result: The file /Volumes/Image1/testfile has been copied to /Volumes/Image2/testfile ad the original file has been removed. No error should be triggered Actual result: -- The file /Volumes/Image1/testfile has been copied to /Volumes/Image2/testfile ad the original file has been removed. Additionally the following error is triggered: rename(/Volumes/Image1/testfile,/Volumes/Image2/testfile): Operation not permitted in renametest.php on line n -- Edit this bug report at http://bugs.php.net/?id=50676&edit=1
#50749 [NEW]: max_file_uploads counts empty uploads as well
From: anzenews at volja dot net Operating system: Linux PHP version: 5.2.12 PHP Bug Type: PHP options/info functions Bug description: max_file_uploads counts empty uploads as well Description: Setting max_file_uploads limits the number of file input fields on HTML page instead of limiting the number of actually uploaded files. Reproduce code: --- \n". ''."\n"; }; ?> Expected result: When you upload a single file (in the LAST!!! input box) and hit "OK!", you should see the uploaded file. Actual result: -- Instead you see just 20 empty file uploads. (if max_file_uploads is set to 20, as per default) The max_file_uploads setting should never count empty files. -- Edit bug report at http://bugs.php.net/?id=50749&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50749&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50749&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50749&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50749&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50749&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50749&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50749&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50749&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50749&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50749&r=support Expected behavior: http://bugs.php.net/fix.php?id=50749&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50749&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50749&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50749&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50749&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50749&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50749&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50749&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50749&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50749&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50749&r=mysqlcfg
#50737 [Fbk->Opn]: stream_set_blocking creates high cpu usage
ID: 50737 User updated by: jason at lentink dot net Reported By: jason at lentink dot net -Status: Feedback +Status: Open Bug Type: Streams related Operating System: Linux PHP Version: 5.2.12 New Comment: Whatever you want :) http://www.grasvezel.nl/media/software/cpuload.txt Here is a complete undressed file which only has the problem. Previous Comments: [2010-01-14 12:17:19] j...@php.net I asked for small, complete script NOT for a framework. [2010-01-14 12:13:36] jason at lentink dot net I could provide you guys with a small script bug i can also point you to the place where the problem exists since it happens in Zend Framework. http://framework.zend.com/svn/framework/standard/trunk/library/Zend/Queu e/Stomp/Client/Connection.php The function is used at line 79. What i see on my servers is that when there are simultaneous request made to the same script the problem increases more rapidly. [2010-01-13 12:07:10] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-01-13 09:58:52] jason at lentink dot net Description: When using stream_set_blocking on a stream will create a huge load on cpu. When using this function it uses up to 50% of the cpu. When not using this function it will only use 0.1% cpu usage. Reproduce code: --- $this->_socket = fsockopen($str, $port, $errno, $errstr); stream_set_blocking($this->_socket, 0); // non blocking Expected result: An socket which will be opened fast. in a non-blocking mode. Actual result: -- An open socket. But the cpu use is enormous. -- Edit this bug report at http://bugs.php.net/?id=50737&edit=1
#39263 [Com]: Enable image(gif|jpg|png) functions to save to a php stream
ID: 39263 Comment by: lgynove at 163 dot com Reported By: wb at pro-net dot co dot uk Status: Assigned Bug Type: Feature/Change Request Operating System: * PHP Version: 5CVS, 6CVS Assigned To: pajoye New Comment: still not fix... three year Previous Comments: [2008-08-17 11:32:31] ni...@php.net Pierre, are you still working on that bug or maybe you need some help? [2006-10-26 12:43:02] paj...@php.net I cannot agree more. I have a patch for a general imageto function, it needs clean up and to be updated for the current head. I'm not sure when I will do it but this feature will be in php, and the sooner the better. [2006-10-26 08:54:20] wb at pro-net dot co dot uk Description: It would be nice to be able to save a GD image directly to an already open php stream. Reproduce code: --- Expected result: Image saved using the stream $fp. Actual result: -- Nothing :) -- Edit this bug report at http://bugs.php.net/?id=39263&edit=1
#50737 [Opn->Fbk]: stream_set_blocking creates high cpu usage
ID: 50737 Updated by: j...@php.net Reported By: jason at lentink dot net -Status: Open +Status: Feedback Bug Type: Streams related Operating System: Linux PHP Version: 5.2.12 New Comment: I asked for small, complete script NOT for a framework. Previous Comments: [2010-01-14 12:13:36] jason at lentink dot net I could provide you guys with a small script bug i can also point you to the place where the problem exists since it happens in Zend Framework. http://framework.zend.com/svn/framework/standard/trunk/library/Zend/Queu e/Stomp/Client/Connection.php The function is used at line 79. What i see on my servers is that when there are simultaneous request made to the same script the problem increases more rapidly. [2010-01-13 12:07:10] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-01-13 09:58:52] jason at lentink dot net Description: When using stream_set_blocking on a stream will create a huge load on cpu. When using this function it uses up to 50% of the cpu. When not using this function it will only use 0.1% cpu usage. Reproduce code: --- $this->_socket = fsockopen($str, $port, $errno, $errstr); stream_set_blocking($this->_socket, 0); // non blocking Expected result: An socket which will be opened fast. in a non-blocking mode. Actual result: -- An open socket. But the cpu use is enormous. -- Edit this bug report at http://bugs.php.net/?id=50737&edit=1
#50737 [Fbk->Opn]: stream_set_blocking creates high cpu usage
ID: 50737 User updated by: jason at lentink dot net Reported By: jason at lentink dot net -Status: Feedback +Status: Open Bug Type: Streams related Operating System: Linux PHP Version: 5.2.12 New Comment: I could provide you guys with a small script bug i can also point you to the place where the problem exists since it happens in Zend Framework. http://framework.zend.com/svn/framework/standard/trunk/library/Zend/Queu e/Stomp/Client/Connection.php The function is used at line 79. What i see on my servers is that when there are simultaneous request made to the same script the problem increases more rapidly. Previous Comments: [2010-01-13 12:07:10] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-01-13 09:58:52] jason at lentink dot net Description: When using stream_set_blocking on a stream will create a huge load on cpu. When using this function it uses up to 50% of the cpu. When not using this function it will only use 0.1% cpu usage. Reproduce code: --- $this->_socket = fsockopen($str, $port, $errno, $errstr); stream_set_blocking($this->_socket, 0); // non blocking Expected result: An socket which will be opened fast. in a non-blocking mode. Actual result: -- An open socket. But the cpu use is enormous. -- Edit this bug report at http://bugs.php.net/?id=50737&edit=1
#50746 [Bgs]: ICONV broken in CLI
ID: 50746 User updated by: werner at aloah-from-hell dot de Reported By: werner at aloah-from-hell dot de Status: Bogus Bug Type: ICONV related Operating System: Linux X86_64, Kernel 2.6.32.2 PHP Version: 5.2.12 New Comment: Hi, I've found a difference in the config.log file. Seems like as in PHP 5.2.12 (during configure) this line (which is present in the config.log of PHP 5.2.11) is missing: configure:46684: checking if iconv is glibc's regards, Werner Previous Comments: [2010-01-14 11:22:03] werner at aloah-from-hell dot de Hi, as requested: I've installed the latest Snapshot (http://snaps.php.net/php5.2-latest.tar.gz). Same result with this version: server2:/usr/src/php5.2-201001140930# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' Notice: iconv(): Unknown error (29) in Command line code on line 1 server2:/usr/src/php5.2-20100114093# Werner [2010-01-14 10:56:51] werner at aloah-from-hell dot de Hi again, I've switched back to PHP 5.2.11 on server2 (on which the iconv-call did not work with PHP-CLI 5.2.12) and it's working: server2:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' abcde server2:# Compared to PHP-CLI 5.2.12: server2:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' Notice: iconv(): Unknown error (29) in Command line code on line 1 server2:# So maybe this could be a PHP issue ? Thanks, Werner strace php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso- 8859-1","abcde"), PHP_EOL;' [2010-01-14 10:27:19] werner at aloah-from-hell dot de Hi, unfornately the are the same: server2:# diff /usr/local/lib/php.ini /home/werner/php.ini server2:# Also the phpinfo-Output for iconv on both systems is identical: server1: iconv iconv support => enabled iconv implementation => glibc iconv library version => 2.3.6 Directive => Local Value => Master Value iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1+ server2: iconv iconv support => enabled iconv implementation => glibc iconv library version => 2.3.6 Directive => Local Value => Master Value iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1 Bye, Werner [2010-01-14 10:22:07] j...@php.net I'm quite sure they aren't totally identical. Most likely the one where it doesn't work is not installed properly or someone has messed something there. Anyway, since this sure isn't PHP bug -> bogus. [2010-01-14 10:18:26] werner at aloah-from-hell dot de Hi, the hardware-specs are the same - same for the PHP configuration. I'll need more testing here ... Anyway, thanks again. Werner 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/50746 -- Edit this bug report at http://bugs.php.net/?id=50746&edit=1
#50748 [Bgs]: func_get_args() should be able to pass variables as reference
ID: 50748 User updated by: gahgneh+php at gmail dot com Reported By: gahgneh+php at gmail dot com Status: Bogus Bug Type: Variables related Operating System: Windows XP SP3 PHP Version: 5.2.12 New Comment: I usually prefer to check if the variable(s) are empty before calling indexes on them. Or make it able to func_get_args() to pass variables by reference, or extend isset() and empty() to check multiple items. If the parameter is not a reference, PHP gives a undefined index notice. Previous Comments: [2010-01-14 11:16:51] johan...@php.net For passing references we would need to know at the time the parameters are prepared, before actually invoking the function, that references are expected. That can only be done by defining it in the signature ... but when doing that func_get_args() is rather useless - the only case would be an undefined number of reference parameters which can be simulated by using an array of references as parameter ... but then again: There's barely any reason for using references these days in PHP. [2010-01-14 11:00:04] gahgneh+php at gmail dot com Description: func_get_args() should be able to pass variables as reference Reproduce code: --- function ref(){ $args = func_get_args(); $args[0] = 10; $args[1] = 11; } $value = 0; $value2 = 1; ref($value, $value2); echo $value,$value2; // prints 01 Expected result: $value to contain "int 10" and $value2 to contain "int 11" There should be a * pointer operator like C++, to tell the variable to behave like function ref(int* p = null){ *p = 10; } -- Edit this bug report at http://bugs.php.net/?id=50748&edit=1
#50746 [Bgs]: ICONV broken in CLI
ID: 50746 User updated by: werner at aloah-from-hell dot de Reported By: werner at aloah-from-hell dot de Status: Bogus Bug Type: ICONV related Operating System: Linux X86_64, Kernel 2.6.32.2 PHP Version: 5.2.12 New Comment: Hi, as requested: I've installed the latest Snapshot (http://snaps.php.net/php5.2-latest.tar.gz). Same result with this version: server2:/usr/src/php5.2-201001140930# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' Notice: iconv(): Unknown error (29) in Command line code on line 1 server2:/usr/src/php5.2-20100114093# Werner Previous Comments: [2010-01-14 10:56:51] werner at aloah-from-hell dot de Hi again, I've switched back to PHP 5.2.11 on server2 (on which the iconv-call did not work with PHP-CLI 5.2.12) and it's working: server2:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' abcde server2:# Compared to PHP-CLI 5.2.12: server2:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' Notice: iconv(): Unknown error (29) in Command line code on line 1 server2:# So maybe this could be a PHP issue ? Thanks, Werner strace php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso- 8859-1","abcde"), PHP_EOL;' [2010-01-14 10:27:19] werner at aloah-from-hell dot de Hi, unfornately the are the same: server2:# diff /usr/local/lib/php.ini /home/werner/php.ini server2:# Also the phpinfo-Output for iconv on both systems is identical: server1: iconv iconv support => enabled iconv implementation => glibc iconv library version => 2.3.6 Directive => Local Value => Master Value iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1+ server2: iconv iconv support => enabled iconv implementation => glibc iconv library version => 2.3.6 Directive => Local Value => Master Value iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1 Bye, Werner [2010-01-14 10:22:07] j...@php.net I'm quite sure they aren't totally identical. Most likely the one where it doesn't work is not installed properly or someone has messed something there. Anyway, since this sure isn't PHP bug -> bogus. [2010-01-14 10:18:26] werner at aloah-from-hell dot de Hi, the hardware-specs are the same - same for the PHP configuration. I'll need more testing here ... Anyway, thanks again. Werner [2010-01-14 10:15:56] j...@php.net No idea since I do not know the specs of your servers. :) Check the diff between their phpinfo() output on iconv section. 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/50746 -- Edit this bug report at http://bugs.php.net/?id=50746&edit=1
#50748 [Opn->Bgs]: func_get_args() should be able to pass variables as reference
ID: 50748 Updated by: johan...@php.net Reported By: gahgneh+php at gmail dot com -Status: Open +Status: Bogus Bug Type: Variables related Operating System: Windows XP SP3 PHP Version: 5.2.12 New Comment: For passing references we would need to know at the time the parameters are prepared, before actually invoking the function, that references are expected. That can only be done by defining it in the signature ... but when doing that func_get_args() is rather useless - the only case would be an undefined number of reference parameters which can be simulated by using an array of references as parameter ... but then again: There's barely any reason for using references these days in PHP. Previous Comments: [2010-01-14 11:00:04] gahgneh+php at gmail dot com Description: func_get_args() should be able to pass variables as reference Reproduce code: --- function ref(){ $args = func_get_args(); $args[0] = 10; $args[1] = 11; } $value = 0; $value2 = 1; ref($value, $value2); echo $value,$value2; // prints 01 Expected result: $value to contain "int 10" and $value2 to contain "int 11" There should be a * pointer operator like C++, to tell the variable to behave like function ref(int* p = null){ *p = 10; } -- Edit this bug report at http://bugs.php.net/?id=50748&edit=1
#50748 [NEW]: func_get_args() should be able to pass variables as reference
From: gahgneh+php at gmail dot com Operating system: Windows XP SP3 PHP version: 5.2.12 PHP Bug Type: Variables related Bug description: func_get_args() should be able to pass variables as reference Description: func_get_args() should be able to pass variables as reference Reproduce code: --- function ref(){ $args = func_get_args(); $args[0] = 10; $args[1] = 11; } $value = 0; $value2 = 1; ref($value, $value2); echo $value,$value2; // prints 01 Expected result: $value to contain "int 10" and $value2 to contain "int 11" There should be a * pointer operator like C++, to tell the variable to behave like function ref(int* p = null){ *p = 10; } -- Edit bug report at http://bugs.php.net/?id=50748&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50748&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50748&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50748&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50748&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50748&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50748&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50748&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50748&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50748&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50748&r=support Expected behavior: http://bugs.php.net/fix.php?id=50748&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50748&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50748&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50748&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50748&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50748&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50748&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50748&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50748&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50748&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50748&r=mysqlcfg
#50746 [Bgs]: ICONV broken in CLI
ID: 50746 User updated by: werner at aloah-from-hell dot de Reported By: werner at aloah-from-hell dot de Status: Bogus Bug Type: ICONV related Operating System: Linux X86_64, Kernel 2.6.32.2 PHP Version: 5.2.12 New Comment: Hi again, I've switched back to PHP 5.2.11 on server2 (on which the iconv-call did not work with PHP-CLI 5.2.12) and it's working: server2:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' abcde server2:# Compared to PHP-CLI 5.2.12: server2:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' Notice: iconv(): Unknown error (29) in Command line code on line 1 server2:# So maybe this could be a PHP issue ? Thanks, Werner strace php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso- 8859-1","abcde"), PHP_EOL;' Previous Comments: [2010-01-14 10:27:19] werner at aloah-from-hell dot de Hi, unfornately the are the same: server2:# diff /usr/local/lib/php.ini /home/werner/php.ini server2:# Also the phpinfo-Output for iconv on both systems is identical: server1: iconv iconv support => enabled iconv implementation => glibc iconv library version => 2.3.6 Directive => Local Value => Master Value iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1+ server2: iconv iconv support => enabled iconv implementation => glibc iconv library version => 2.3.6 Directive => Local Value => Master Value iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1 Bye, Werner [2010-01-14 10:22:07] j...@php.net I'm quite sure they aren't totally identical. Most likely the one where it doesn't work is not installed properly or someone has messed something there. Anyway, since this sure isn't PHP bug -> bogus. [2010-01-14 10:18:26] werner at aloah-from-hell dot de Hi, the hardware-specs are the same - same for the PHP configuration. I'll need more testing here ... Anyway, thanks again. Werner [2010-01-14 10:15:56] j...@php.net No idea since I do not know the specs of your servers. :) Check the diff between their phpinfo() output on iconv section. [2010-01-14 10:13:21] werner at aloah-from-hell dot de Hi, thanks for the quick response. I did some more testing ... and it seems like the problem is not related to PHP. On one machine with PHP 5.2.12 installed: server1:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' abcde server1:# server2:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' Notice: iconv(): Unknown error (29) in Command line code on line 1 server2:# The configure-Options for PHP are the same on both machines. Any Ideas? regards, Werner 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/50746 -- Edit this bug report at http://bugs.php.net/?id=50746&edit=1
#50744 [Opn->Bgs]: Missing days in Sept 1752
ID: 50744 Updated by: der...@php.net Reported By: nuke at psu dot edu -Status: Open +Status: Bogus Bug Type: Date/time related Operating System: * PHP Version: 5.3SVN-2010-01-14 (snap) 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 PHP implements the ISO 8601 calendar (which is a proleptic Gregorian calendar with modifications for the year 0, see http://en.wikipedia.org/wiki/Gregorian_calendar#Proleptic_Gregorian_calendar and http://en.wikipedia.org/wiki/ISO_8601#Dates). The reason is that the switch over from the Julian calendar to the Gregorian calendar wasn't in 1752 for every locality (see http://en.wikipedia.org/wiki/Gregorian_calendar#Timeline) If I were to implement this correctly, then you would have to set in which locality the calendar was used. I would also have to add support for very specific rules for for example Sweden which messed up and required a February 30th at one point: See the 5th and 6th paragraph of http://en.wikipedia.org/wiki/Gregorian_calendar#Adoption_in_Europe Previous Comments: [2010-01-14 08:03:59] nuke at psu dot edu Description: In ext/date/lib/interval.c around line 58, there should be a flag to test for years before, say, 1753, and throw a warning for people to use the Calendar functions, assuming those functions are doing it correctly. I'd check the Calendar functions today, esp. GregoriantoJD, except that it's already 3am here. Besides, that'd be a different test. Here's one webpage about the issue I found in 1752: http://www.genealogytoday.com/columns/everyday/030902.html Reproduce code: --- $one = new DateTime("1752-09-02 00:00:00"); $two = new DateTime("1752-09-14 00:00:00"); $diff = $one->diff($two); echo $diff->days."=1"; Expected result: 1=1 Actual result: -- 12=1 -- Edit this bug report at http://bugs.php.net/?id=50744&edit=1
#50746 [Bgs]: ICONV broken in CLI
ID: 50746 User updated by: werner at aloah-from-hell dot de Reported By: werner at aloah-from-hell dot de Status: Bogus Bug Type: ICONV related Operating System: Linux X86_64, Kernel 2.6.32.2 PHP Version: 5.2.12 New Comment: Hi, unfornately the are the same: server2:# diff /usr/local/lib/php.ini /home/werner/php.ini server2:# Also the phpinfo-Output for iconv on both systems is identical: server1: iconv iconv support => enabled iconv implementation => glibc iconv library version => 2.3.6 Directive => Local Value => Master Value iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1+ server2: iconv iconv support => enabled iconv implementation => glibc iconv library version => 2.3.6 Directive => Local Value => Master Value iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1 Bye, Werner Previous Comments: [2010-01-14 10:22:07] j...@php.net I'm quite sure they aren't totally identical. Most likely the one where it doesn't work is not installed properly or someone has messed something there. Anyway, since this sure isn't PHP bug -> bogus. [2010-01-14 10:18:26] werner at aloah-from-hell dot de Hi, the hardware-specs are the same - same for the PHP configuration. I'll need more testing here ... Anyway, thanks again. Werner [2010-01-14 10:15:56] j...@php.net No idea since I do not know the specs of your servers. :) Check the diff between their phpinfo() output on iconv section. [2010-01-14 10:13:21] werner at aloah-from-hell dot de Hi, thanks for the quick response. I did some more testing ... and it seems like the problem is not related to PHP. On one machine with PHP 5.2.12 installed: server1:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' abcde server1:# server2:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' Notice: iconv(): Unknown error (29) in Command line code on line 1 server2:# The configure-Options for PHP are the same on both machines. Any Ideas? regards, Werner [2010-01-14 10:01:23] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Works fine for me. Enable error reporting and displaying too..or does it actually crash for you..? Try this: # php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1", "abcde"), PHP_EOL;' 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/50746 -- Edit this bug report at http://bugs.php.net/?id=50746&edit=1
#50746 [Opn->Bgs]: ICONV broken in CLI
ID: 50746 Updated by: j...@php.net Reported By: werner at aloah-from-hell dot de -Status: Open +Status: Bogus Bug Type: ICONV related Operating System: Linux X86_64, Kernel 2.6.32.2 PHP Version: 5.2.12 New Comment: I'm quite sure they aren't totally identical. Most likely the one where it doesn't work is not installed properly or someone has messed something there. Anyway, since this sure isn't PHP bug -> bogus. Previous Comments: [2010-01-14 10:18:26] werner at aloah-from-hell dot de Hi, the hardware-specs are the same - same for the PHP configuration. I'll need more testing here ... Anyway, thanks again. Werner [2010-01-14 10:15:56] j...@php.net No idea since I do not know the specs of your servers. :) Check the diff between their phpinfo() output on iconv section. [2010-01-14 10:13:21] werner at aloah-from-hell dot de Hi, thanks for the quick response. I did some more testing ... and it seems like the problem is not related to PHP. On one machine with PHP 5.2.12 installed: server1:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' abcde server1:# server2:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' Notice: iconv(): Unknown error (29) in Command line code on line 1 server2:# The configure-Options for PHP are the same on both machines. Any Ideas? regards, Werner [2010-01-14 10:01:23] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Works fine for me. Enable error reporting and displaying too..or does it actually crash for you..? Try this: # php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1", "abcde"), PHP_EOL;' [2010-01-14 09:24:43] werner at aloah-from-hell dot de Description: Hi everybody, we've discovered, that the PHP funktion iconv() does not work with the PHP-CLI in PHP 5.2.12. PHP is configured with the following Options: ./configure --enable-magic-quotes --enable-libxml --enable-session -- with-pcre-regex --with-pear --enable-xml --enable-simplexml --enable- static --enable-safe-mode --enable-sigchild --disable-debug --disable- rpath --enable-cli --enable-bcmath --enable-exif --enable-gd-native- ttf --enable-gd-jis-conv --enable-mbstring --enable-mbreg ex --enable-posix --enable-sockets --with-curl --with-gd=/usr/local -- with-ttf --with-png-dir=/usr --with-jpeg-dir --with-t1lib --with-zlib --with-iconv --with-imap=/usr/lib64 --with-imap-ssl --with-mysql -- with-openssl --with-kerberos --with-xpm-dir --with-freetype-dir=/usr - -with-apxs2=/usr/local/apache2/bin/apxs --disable-cgi --dis able-ipv6 --disable-pdo --without-sqlite --disable-spl --with- mcrypt=/usr --enable-soap ICONV-Support ist active: server:# php -r 'phpinfo();'|grep -i iconv ... iconv iconv support => enabled iconv implementation => glibc iconv library version => 2.3.6 iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1 Kind regards, Werner Reproduce code: --- Expected result: With PHP 5.2.11: server:# /usr/local/bin/php /tmp/test.php abcde server:# Actual result: -- With PHP 5.2.12: server:# /usr/local/bin/php /tmp/test.php server:# -- Edit this bug report at http://bugs.php.net/?id=50746&edit=1
#50743 [Opn->Bgs]: No escape function escapes properly
ID: 50743 Updated by: j...@php.net Reported By: eric at sharecorp dot com -Status: Open +Status: Bogus Bug Type: Strings related Operating System: Linux PHP Version: 5.2.12 New Comment: htmlentities() is not unicode aware in PHP 5.x. Use the mbstring / iconv functions to deal with such strings. Previous Comments: [2010-01-13 18:54:05] eric at sharecorp dot com Mysql version 5.0.84-r1 from gentoo portage. Stand alone example follows: form.php _ Input: __ handler.php ___ SQL for creating news2 _ REATE TABLE IF NOT EXISTS `news2` ( `id` int(11) NOT NULL auto_increment, `title` varchar(40) collate utf8_unicode_ci NOT NULL, `date` date NOT NULL, `tagline` varchar(120) collate utf8_unicode_ci NOT NULL, `article` text collate utf8_unicode_ci NOT NULL, `image` int(11) NOT NULL, `image_orig` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=44 ; _ Demo text __ We are pleased to announce our improved website. We've updated it to have a cleaner, more modern look, improved existing features and added some new features as well. Let's take a quick tour of the Products section. The first thing you'll notice when you click on the Products link is that the product categories have been updated. This is now consistent with our 2010 Color Catalog. The second thing that you'll notice is that the products may not be listed alphabetically in their respective categories. The products are now ranked by the most clicked on to least clicked on. In other words, our most popular products are listed at the top of each category. A third thing you may notice is that there's an Equipment section. All of the products listed in the Color Catalog's Equipment section can now be found here along with a picture. ___ The insertion of the above text falters after "Let's take a quick tour of the" and nothing else posts. [2010-01-13 18:25:35] ras...@php.net Are you sure? mysql> select * from users where name=rlerdorf; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '��rlerdorf��' at line 1 mysql> select * from users where name="rlerdorf"; Empty set (0.03 sec) As far as I can tell, MySQL does not treat those odd quotes as regular quotes anywhere. Please provide a standalone test case along with your MySQL version that shows this. [2010-01-13 18:19:59] eric at sharecorp dot com Description: None of the escaping functions are able to properly handle style quotes, which are produced by default by open office. Functions that I have tested include mysql_real_escape_string, htmlentities, addslashes and addcslashes. This behavior causes text insertion into mysql to fail as it interprets these quotes as normal double quotes. Reproduce code: --- $title = $_POST['title']; $date = $_POST['date']; $tagline = $_POST['tagline']; $article =nl2br(htmlentities($_POST['article'],ENT_QUOTES)); // $query = "INSERT INTO news (title, date, tagline, article, image, image_orig) VALUES ('$title', '$date', '$tagline', '$article', '$image',$image_orig')" Expected result: The should be caught, escaped properly and not affecting the query. In this case $article was the varible containing the quotes in question. Actual result: -- All text after the opening quote is dropped from the data inserted into the query. -- Edit this bug report at http://bugs.php.net/?id=50743&edit=1
#50746 [Fbk->Opn]: ICONV broken in CLI
ID: 50746 User updated by: werner at aloah-from-hell dot de Reported By: werner at aloah-from-hell dot de -Status: Feedback +Status: Open Bug Type: ICONV related Operating System: Linux X86_64, Kernel 2.6.32.2 PHP Version: 5.2.12 New Comment: Hi, the hardware-specs are the same - same for the PHP configuration. I'll need more testing here ... Anyway, thanks again. Werner Previous Comments: [2010-01-14 10:15:56] j...@php.net No idea since I do not know the specs of your servers. :) Check the diff between their phpinfo() output on iconv section. [2010-01-14 10:13:21] werner at aloah-from-hell dot de Hi, thanks for the quick response. I did some more testing ... and it seems like the problem is not related to PHP. On one machine with PHP 5.2.12 installed: server1:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' abcde server1:# server2:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' Notice: iconv(): Unknown error (29) in Command line code on line 1 server2:# The configure-Options for PHP are the same on both machines. Any Ideas? regards, Werner [2010-01-14 10:01:23] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Works fine for me. Enable error reporting and displaying too..or does it actually crash for you..? Try this: # php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1", "abcde"), PHP_EOL;' [2010-01-14 09:24:43] werner at aloah-from-hell dot de Description: Hi everybody, we've discovered, that the PHP funktion iconv() does not work with the PHP-CLI in PHP 5.2.12. PHP is configured with the following Options: ./configure --enable-magic-quotes --enable-libxml --enable-session -- with-pcre-regex --with-pear --enable-xml --enable-simplexml --enable- static --enable-safe-mode --enable-sigchild --disable-debug --disable- rpath --enable-cli --enable-bcmath --enable-exif --enable-gd-native- ttf --enable-gd-jis-conv --enable-mbstring --enable-mbreg ex --enable-posix --enable-sockets --with-curl --with-gd=/usr/local -- with-ttf --with-png-dir=/usr --with-jpeg-dir --with-t1lib --with-zlib --with-iconv --with-imap=/usr/lib64 --with-imap-ssl --with-mysql -- with-openssl --with-kerberos --with-xpm-dir --with-freetype-dir=/usr - -with-apxs2=/usr/local/apache2/bin/apxs --disable-cgi --dis able-ipv6 --disable-pdo --without-sqlite --disable-spl --with- mcrypt=/usr --enable-soap ICONV-Support ist active: server:# php -r 'phpinfo();'|grep -i iconv ... iconv iconv support => enabled iconv implementation => glibc iconv library version => 2.3.6 iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1 Kind regards, Werner Reproduce code: --- Expected result: With PHP 5.2.11: server:# /usr/local/bin/php /tmp/test.php abcde server:# Actual result: -- With PHP 5.2.12: server:# /usr/local/bin/php /tmp/test.php server:# -- Edit this bug report at http://bugs.php.net/?id=50746&edit=1
#50746 [Opn->Fbk]: ICONV broken in CLI
ID: 50746 Updated by: j...@php.net Reported By: werner at aloah-from-hell dot de -Status: Open +Status: Feedback Bug Type: ICONV related Operating System: Linux X86_64, Kernel 2.6.32.2 PHP Version: 5.2.12 New Comment: No idea since I do not know the specs of your servers. :) Check the diff between their phpinfo() output on iconv section. Previous Comments: [2010-01-14 10:13:21] werner at aloah-from-hell dot de Hi, thanks for the quick response. I did some more testing ... and it seems like the problem is not related to PHP. On one machine with PHP 5.2.12 installed: server1:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' abcde server1:# server2:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' Notice: iconv(): Unknown error (29) in Command line code on line 1 server2:# The configure-Options for PHP are the same on both machines. Any Ideas? regards, Werner [2010-01-14 10:01:23] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Works fine for me. Enable error reporting and displaying too..or does it actually crash for you..? Try this: # php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1", "abcde"), PHP_EOL;' [2010-01-14 09:24:43] werner at aloah-from-hell dot de Description: Hi everybody, we've discovered, that the PHP funktion iconv() does not work with the PHP-CLI in PHP 5.2.12. PHP is configured with the following Options: ./configure --enable-magic-quotes --enable-libxml --enable-session -- with-pcre-regex --with-pear --enable-xml --enable-simplexml --enable- static --enable-safe-mode --enable-sigchild --disable-debug --disable- rpath --enable-cli --enable-bcmath --enable-exif --enable-gd-native- ttf --enable-gd-jis-conv --enable-mbstring --enable-mbreg ex --enable-posix --enable-sockets --with-curl --with-gd=/usr/local -- with-ttf --with-png-dir=/usr --with-jpeg-dir --with-t1lib --with-zlib --with-iconv --with-imap=/usr/lib64 --with-imap-ssl --with-mysql -- with-openssl --with-kerberos --with-xpm-dir --with-freetype-dir=/usr - -with-apxs2=/usr/local/apache2/bin/apxs --disable-cgi --dis able-ipv6 --disable-pdo --without-sqlite --disable-spl --with- mcrypt=/usr --enable-soap ICONV-Support ist active: server:# php -r 'phpinfo();'|grep -i iconv ... iconv iconv support => enabled iconv implementation => glibc iconv library version => 2.3.6 iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1 Kind regards, Werner Reproduce code: --- Expected result: With PHP 5.2.11: server:# /usr/local/bin/php /tmp/test.php abcde server:# Actual result: -- With PHP 5.2.12: server:# /usr/local/bin/php /tmp/test.php server:# -- Edit this bug report at http://bugs.php.net/?id=50746&edit=1
#50746 [Fbk->Opn]: ICONV broken in CLI
ID: 50746 User updated by: werner at aloah-from-hell dot de Reported By: werner at aloah-from-hell dot de -Status: Feedback +Status: Open Bug Type: ICONV related Operating System: Linux X86_64, Kernel 2.6.32.2 PHP Version: 5.2.12 New Comment: Hi, thanks for the quick response. I did some more testing ... and it seems like the problem is not related to PHP. On one machine with PHP 5.2.12 installed: server1:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' abcde server1:# server2:# php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1","abcde"), PHP_EOL;' Notice: iconv(): Unknown error (29) in Command line code on line 1 server2:# The configure-Options for PHP are the same on both machines. Any Ideas? regards, Werner Previous Comments: [2010-01-14 10:01:23] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Works fine for me. Enable error reporting and displaying too..or does it actually crash for you..? Try this: # php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1", "abcde"), PHP_EOL;' [2010-01-14 09:24:43] werner at aloah-from-hell dot de Description: Hi everybody, we've discovered, that the PHP funktion iconv() does not work with the PHP-CLI in PHP 5.2.12. PHP is configured with the following Options: ./configure --enable-magic-quotes --enable-libxml --enable-session -- with-pcre-regex --with-pear --enable-xml --enable-simplexml --enable- static --enable-safe-mode --enable-sigchild --disable-debug --disable- rpath --enable-cli --enable-bcmath --enable-exif --enable-gd-native- ttf --enable-gd-jis-conv --enable-mbstring --enable-mbreg ex --enable-posix --enable-sockets --with-curl --with-gd=/usr/local -- with-ttf --with-png-dir=/usr --with-jpeg-dir --with-t1lib --with-zlib --with-iconv --with-imap=/usr/lib64 --with-imap-ssl --with-mysql -- with-openssl --with-kerberos --with-xpm-dir --with-freetype-dir=/usr - -with-apxs2=/usr/local/apache2/bin/apxs --disable-cgi --dis able-ipv6 --disable-pdo --without-sqlite --disable-spl --with- mcrypt=/usr --enable-soap ICONV-Support ist active: server:# php -r 'phpinfo();'|grep -i iconv ... iconv iconv support => enabled iconv implementation => glibc iconv library version => 2.3.6 iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1 Kind regards, Werner Reproduce code: --- Expected result: With PHP 5.2.11: server:# /usr/local/bin/php /tmp/test.php abcde server:# Actual result: -- With PHP 5.2.12: server:# /usr/local/bin/php /tmp/test.php server:# -- Edit this bug report at http://bugs.php.net/?id=50746&edit=1
#50745 [Opn->Bgs]: INF==INF evals to FALSE
ID: 50745 Updated by: j...@php.net Reported By: alvaro at demogracia dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows PHP Version: 5.3.2RC1 New Comment: This is because there was bug in handling INF (and NaN) in Windows prior to 5.3.1 which was fixed. And yes, that's the _expected_ result too. You can't compare infinity to infinity. Previous Comments: [2010-01-14 08:33:54] alvaro at demogracia dot com Description: The INF==INF comparison evals to FALSE in 5.3.1 and 5.3.2RC1 Windows releases. It used to be TRUE in previous versions including 5.3.0 and 5.2.11. I've tested it in Windows XP and Windows Server 2008. It's also FALSE in 5.2.10 under Red Hat Enterprise Linux 5. The strict comparison INF===INF evals to TRUE in all cases. Please note I'm referring to the INF numeric constant, not an 'INF' string. Reproduce code: --- Expected result: bool(true) Actual result: -- bool(false) -- Edit this bug report at http://bugs.php.net/?id=50745&edit=1
#50746 [Opn->Fbk]: ICONV broken in CLI
ID: 50746 Updated by: j...@php.net -Summary: PHP-CLI 5.2.12 - ICONV broken in CLI Reported By: werner at aloah-from-hell dot de -Status: Open +Status: Feedback Bug Type: ICONV related Operating System: Linux X86_64, Kernel 2.6.32.2 PHP Version: 5.2.12 New Comment: Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Works fine for me. Enable error reporting and displaying too..or does it actually crash for you..? Try this: # php -n -d error_reporting=E_ALL -r 'echo iconv("utf-8", "iso-8859-1", "abcde"), PHP_EOL;' Previous Comments: [2010-01-14 09:24:43] werner at aloah-from-hell dot de Description: Hi everybody, we've discovered, that the PHP funktion iconv() does not work with the PHP-CLI in PHP 5.2.12. PHP is configured with the following Options: ./configure --enable-magic-quotes --enable-libxml --enable-session -- with-pcre-regex --with-pear --enable-xml --enable-simplexml --enable- static --enable-safe-mode --enable-sigchild --disable-debug --disable- rpath --enable-cli --enable-bcmath --enable-exif --enable-gd-native- ttf --enable-gd-jis-conv --enable-mbstring --enable-mbreg ex --enable-posix --enable-sockets --with-curl --with-gd=/usr/local -- with-ttf --with-png-dir=/usr --with-jpeg-dir --with-t1lib --with-zlib --with-iconv --with-imap=/usr/lib64 --with-imap-ssl --with-mysql -- with-openssl --with-kerberos --with-xpm-dir --with-freetype-dir=/usr - -with-apxs2=/usr/local/apache2/bin/apxs --disable-cgi --dis able-ipv6 --disable-pdo --without-sqlite --disable-spl --with- mcrypt=/usr --enable-soap ICONV-Support ist active: server:# php -r 'phpinfo();'|grep -i iconv ... iconv iconv support => enabled iconv implementation => glibc iconv library version => 2.3.6 iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1 Kind regards, Werner Reproduce code: --- Expected result: With PHP 5.2.11: server:# /usr/local/bin/php /tmp/test.php abcde server:# Actual result: -- With PHP 5.2.12: server:# /usr/local/bin/php /tmp/test.php server:# -- Edit this bug report at http://bugs.php.net/?id=50746&edit=1
#50746 [NEW]: PHP-CLI 5.2.12 - ICONV broken in CLI
From: werner at aloah-from-hell dot de Operating system: Linux X86_64, Kernel 2.6.32.2 PHP version: 5.2.12 PHP Bug Type: ICONV related Bug description: PHP-CLI 5.2.12 - ICONV broken in CLI Description: Hi everybody, we've discovered, that the PHP funktion iconv() does not work with the PHP-CLI in PHP 5.2.12. PHP is configured with the following Options: ./configure --enable-magic-quotes --enable-libxml --enable-session -- with-pcre-regex --with-pear --enable-xml --enable-simplexml --enable- static --enable-safe-mode --enable-sigchild --disable-debug --disable- rpath --enable-cli --enable-bcmath --enable-exif --enable-gd-native- ttf --enable-gd-jis-conv --enable-mbstring --enable-mbreg ex --enable-posix --enable-sockets --with-curl --with-gd=/usr/local -- with-ttf --with-png-dir=/usr --with-jpeg-dir --with-t1lib --with-zlib --with-iconv --with-imap=/usr/lib64 --with-imap-ssl --with-mysql -- with-openssl --with-kerberos --with-xpm-dir --with-freetype-dir=/usr - -with-apxs2=/usr/local/apache2/bin/apxs --disable-cgi --dis able-ipv6 --disable-pdo --without-sqlite --disable-spl --with- mcrypt=/usr --enable-soap ICONV-Support ist active: server:# php -r 'phpinfo();'|grep -i iconv ... iconv iconv support => enabled iconv implementation => glibc iconv library version => 2.3.6 iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1 Kind regards, Werner Reproduce code: --- Expected result: With PHP 5.2.11: server:# /usr/local/bin/php /tmp/test.php abcde server:# Actual result: -- With PHP 5.2.12: server:# /usr/local/bin/php /tmp/test.php server:# -- Edit bug report at http://bugs.php.net/?id=50746&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50746&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50746&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50746&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50746&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50746&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50746&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50746&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50746&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50746&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50746&r=support Expected behavior: http://bugs.php.net/fix.php?id=50746&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50746&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50746&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50746&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50746&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50746&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50746&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50746&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50746&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50746&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50746&r=mysqlcfg
#50745 [NEW]: INF==INF evals to FALSE
From: alvaro at demogracia dot com Operating system: Windows PHP version: 5.3.2RC1 PHP Bug Type: Scripting Engine problem Bug description: INF==INF evals to FALSE Description: The INF==INF comparison evals to FALSE in 5.3.1 and 5.3.2RC1 Windows releases. It used to be TRUE in previous versions including 5.3.0 and 5.2.11. I've tested it in Windows XP and Windows Server 2008. It's also FALSE in 5.2.10 under Red Hat Enterprise Linux 5. The strict comparison INF===INF evals to TRUE in all cases. Please note I'm referring to the INF numeric constant, not an 'INF' string. Reproduce code: --- Expected result: bool(true) Actual result: -- bool(false) -- Edit bug report at http://bugs.php.net/?id=50745&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50745&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50745&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50745&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50745&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50745&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50745&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50745&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50745&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50745&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50745&r=support Expected behavior: http://bugs.php.net/fix.php?id=50745&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50745&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50745&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50745&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50745&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50745&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50745&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50745&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50745&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50745&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50745&r=mysqlcfg
#50741 [Fbk->Csd]: Midsized array of objects with arrays cause crash
ID: 50741 User updated by: thorsten dot engel at matrix-computer dot com Reported By: thorsten dot engel at matrix-computer dot com -Status: Feedback +Status: Closed Bug Type: Reproducible crash Operating System: Win32+Gentoo Linux PHP Version: 5.3.2RC1 New Comment: Thanks, you *are right*. I only had 250MB as memory ;-). With your help I could narrow down this problem to a "__PHP_Incomplete_Class_Name" in the session that seems to cause this problem. I'll investigate this now. Thanks for your help. Previous Comments: [2010-01-13 17:41:25] ras...@php.net Unable to reproduce here. What do you mean by crash? Memory is tracked more accurately in PHP 5.3 so if you are hitting your configured memory limit, that's not a bug. Run it without a memory limit. [2010-01-13 17:36:30] thorsten dot engel at matrix-computer dot com Description: Hi, we love php and tried to migrate from 5.2.11 to 5.3.1 and found a "crash" when using midsize array of objects (nesting level=2). This problem does not exist on 5.2.4, 5.2.6, 5.2.11, but exists ins 5.3.0, 5.3.1 and 5.3.2RC1. We could reproduce it as well on win32 and on linux. It crashed in our case at around 10.000 on win32 and around 7600 on linux. It would be great if you guys can reproduce this as well! Warm regards, Thorsten Reproduce code: --- class test { protected $_a = array(); protected $_b = array(); protected $_i = array(); public function __construct($a,$b) { $this->_a = (array) $a; $this->_b = (array) $b; $this->_i = array(); if (count($a) == 0) { for ($i=0;$i<10;$i++) $this->_i[$i] = new test(array('1','2'), array()); } } } $s = array(); for ($i=0;$i<15000;$i++) { print $i.''; $x = new test(array(),array()); $s[] = $x; } Expected result: completing with 15.000 lines. Actual result: -- crashing after 7.000 until 10.000 lines. -- Edit this bug report at http://bugs.php.net/?id=50741&edit=1
#50744 [NEW]: Missing days in Sept 1752
From: nuke at psu dot edu Operating system: All? PHP version: 5.3SVN-2010-01-14 (snap) PHP Bug Type: Date/time related Bug description: Missing days in Sept 1752 Description: In ext/date/lib/interval.c around line 58, there should be a flag to test for years before, say, 1753, and throw a warning for people to use the Calendar functions, assuming those functions are doing it correctly. I'd check the Calendar functions today, esp. GregoriantoJD, except that it's already 3am here. Besides, that'd be a different test. Here's one webpage about the issue I found in 1752: http://www.genealogytoday.com/columns/everyday/030902.html Reproduce code: --- $one = new DateTime("1752-09-02 00:00:00"); $two = new DateTime("1752-09-14 00:00:00"); $diff = $one->diff($two); echo $diff->days."=1"; Expected result: 1=1 Actual result: -- 12=1 -- Edit bug report at http://bugs.php.net/?id=50744&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50744&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50744&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50744&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50744&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50744&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50744&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50744&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50744&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50744&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50744&r=support Expected behavior: http://bugs.php.net/fix.php?id=50744&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50744&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50744&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50744&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50744&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50744&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50744&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50744&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50744&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50744&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50744&r=mysqlcfg