Bug #52913 [Com]: Incorrect SNI (Server name indicator) when using a SoapClient through a proxy
Edit report at https://bugs.php.net/bug.php?id=52913&edit=1 ID: 52913 Comment by: taneli at crasman dot fi Reported by:terje dot gjerde at visma dot no Summary:Incorrect SNI (Server name indicator) when using a SoapClient through a proxy Status: Open Type: Bug Package:OpenSSL related Operating System: Windows Server 2008 r2 PHP Version:5.3.3 Block user comment: N Private report: N New Comment: You can workaround this option by specifying a SNI_server_name in a stream context like this: $wsdl = 'http://what.ever.host/service.wsdl'; $host = parse_url($wsdl, PHP_URL_HOST); $opts = array('ssl' => array('SNI_server_name' => $host, 'SNI_enabled' => TRUE)); $context = stream_context_create($opts); $soap = new \SoapClient($wsdl, array('proxy_host' => 'localhost', 'proxy_port' => 8080, 'stream_context' => $context)); Previous Comments: [2012-07-02 08:17:41] daniel dot buschke at nextiraone dot eu We have reproduced this bug in PHP 5.3.10 on Linux (OpenWRT). If you set an IP as proxy, PHP is shouting an internal IP address out to the world. I think that is critical, isn't it? regards Daniel [2012-06-26 16:58:31] daniel dot buschke at nextiraone dot eu Workaround: Locallly override APACHESERVER with the IP of PROXY in hosts file and set APACHESERVER as $config['proxy_host']. This is very ugly but works (for us). cheers Daniel [2010-09-23 16:23:51] terje dot gjerde at visma dot no Description: When calling a url on apache server with name "APACHESERVER" through a proxy with name "PROXY" the following error occurs: Hostname PROXY provided via SNI and hostname APACHESERVER provided via HTTP are different ie calling url: https://APACHESERVER/ws.php with proxy at: http://PROXY:8080/ Test script: --- $config = array('location' => WEBSERVICE_LOCATION, 'classmap' => $wsclassmap, 'trace' => 1, ); if (WEBSERVICE_PROXY_HOST && WEBSERVICE_PROXY_PORT) { $config['proxy_host'] = WEBSERVICE_PROXY_HOST; $config['proxy_port'] = WEBSERVICE_PROXY_PORT; } $ws_client = new SoapClient($wsdl,$config); -- Edit this bug report at https://bugs.php.net/bug.php?id=52913&edit=1
Bug #60198 [Com]: Array to string notice from array functions
Edit report at https://bugs.php.net/bug.php?id=60198&edit=1 ID: 60198 Comment by: taneli at crasman dot fi Reported by:simon at simon dot geek dot nz Summary:Array to string notice from array functions Status: Not a bug Type: Bug Package:*General Issues PHP Version:5.4SVN-2011-11-02 (SVN) Block user comment: N Private report: N New Comment: Maybe adding an array_diff_recursive function would be a good solution? Previous Comments: [2011-11-11 00:53:18] chx1975 at gmail dot com This should be changed to a documentation bug because up until now if you had outside knowledge that those arrays are the same (for eg they are empty) then this simply worked. If you decided to break it, then it needs to be documented as a change because from a user perspective it is one. [2011-11-11 00:51:23] ras...@php.net The problem here is that these functions aren't recursive. They just go one level deep and assume arrays of scalars. This means that the notice is a good idea because the result when you pass it nested arrays is likely not the one you wanted. For example. If we change your code example slightly: $left = [ 1, 2, [3] ]; $right = [2, 'Array']; What should the intersection of these two be? Surely just the '2' since there is no nested array with a 3 in $right and there is no string 'Array' in $left. But the actual output is: [ 2, [3] ] Oops! That's not what we expected and that is why this result gives you a notice telling you that the result is likely flawed because of an array to string conversion. Now, it might be nice if array_intersect was smarter and could handle nested arrays, but that would be a different feature enhancement bug. It also looks like this is well-documented. The array_intersect() doc page has this highlighted note: Note: Two elements are considered equal if and only if (string) $elem1 === (string) $elem2. In words: when the string representation is the same. [2011-11-11 00:05:29] chx1975 at gmail dot com This affects the Drupal project. All our tests are failing because of this bug. We see it with array_intersect_assoc(). [2011-11-02 08:33:27] simon at simon dot geek dot nz Description: Some of the array_* functions that compare elements in multiple arrays do so by (string)$elem1 === (string)$elem2. If $elem1 or $elem2 is an array, then the array to string notice is thrown. Two examples of functions that can throw this are array_intersect() and array_diff(). If these functions are not expected to take arrays with other arrays as values, this should be mentioned on the documentation pages. Test script: --- b [1] => Array ( [0] => a ) ) Actual result: -- PHP Notice: Array to string conversion in /Users/simon/test.php on line 4 PHP Notice: Array to string conversion in /Users/simon/test.php on line 4 PHP Notice: Array to string conversion in /Users/simon/test.php on line 5 PHP Notice: Array to string conversion in /Users/simon/test.php on line 5 PHP Notice: Array to string conversion in /Users/simon/test.php on line 5 Notice: Array to string conversion in /Users/simon/test.php on line 4 Notice: Array to string conversion in /Users/simon/test.php on line 4 Array ( ) Notice: Array to string conversion in /Users/simon/test.php on line 5 Notice: Array to string conversion in /Users/simon/test.php on line 5 Notice: Array to string conversion in /Users/simon/test.php on line 5 Array ( [0] => b [1] => Array ( [0] => a ) ) -- Edit this bug report at https://bugs.php.net/bug.php?id=60198&edit=1
#43177 [Opn]: Errors in eval()'ed code produce status code 500
ID: 43177 User updated by: taneli at crasman dot fi Reported By: taneli at crasman dot fi Status: Open Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.2.4 New Comment: Here's a patch for this issue: --- php-5.2.4-vanilla/main/main.c 2007-11-01 15:20:37.0 +0200 +++ php-5.2.4/main/main.c 2007-11-01 17:26:45.0 +0200 @@ -957,11 +957,15 @@ if (!SG(headers_sent) && SG(sapi_headers).http_response_code == 200 ) { - sapi_header_line ctr = {0}; - - ctr.line = "HTTP/1.0 500 Internal Server Error"; - ctr.line_len = strlen(ctr.line); - sapi_header_op(SAPI_HEADER_REPLACE, &ctr TSRMLS_CC); + if (!EG(current_execute_data) || + !EG(current_execute_data)->opline || + EG(current_execute_data)->opline->opcode != ZEND_INCLUDE_OR_EVAL) { + sapi_header_line ctr = {0}; + + ctr.line = "HTTP/1.0 500 Internal Server Error"; + ctr.line_len = strlen(ctr.line); + sapi_header_op(SAPI_HEADER_REPLACE, &ctr TSRMLS_CC); + } } /* the parser would return 1 (failure), we can bail out nicely */ if (type != E_PARSE) { Previous Comments: -------------------- [2007-11-02 11:41:44] taneli at crasman dot fi Description: Errors in eval()'ed code produces HTTP status code 500 for the request. Reproduce code: --- Script: Result: # curl -I http://localhost/test.php HTTP/1.0 500 Internal Server Error Expected result: Since parse errors and such in eval()'ed code don't interrupt the script or make it bail out, I think 200 would be a more approriate code. -- Edit this bug report at http://bugs.php.net/?id=43177&edit=1
#43177 [NEW]: Errors in eval()'ed code produce status code 500
From: taneli at crasman dot fi Operating system: Linux PHP version: 5.2.4 PHP Bug Type: Feature/Change Request Bug description: Errors in eval()'ed code produce status code 500 Description: Errors in eval()'ed code produces HTTP status code 500 for the request. Reproduce code: --- Script: Result: # curl -I http://localhost/test.php HTTP/1.0 500 Internal Server Error Expected result: Since parse errors and such in eval()'ed code don't interrupt the script or make it bail out, I think 200 would be a more approriate code. -- Edit bug report at http://bugs.php.net/?id=43177&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43177&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43177&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43177&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43177&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43177&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43177&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43177&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43177&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43177&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43177&r=support Expected behavior:http://bugs.php.net/fix.php?id=43177&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43177&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43177&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43177&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43177&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43177&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43177&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43177&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43177&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43177&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43177&r=mysqlcfg
#33595 [Com]: recursive references leak memory
ID: 33595 Comment by: taneli at crasman dot fi Reported By: rodricg at sellingsource dot com Status: Assigned Bug Type: Class/Object related Operating System: * PHP Version: 6CVS-2005-08-02 Assigned To: dmitry New Comment: It shouldn't be a known "got cha". I just wrote a backgrounded daemon using PHP and I had to instate a checker process just to restart the process any time it dies (because it leaks memory about 30 megs per "daemon loop", because of references). Previous Comments: [2006-11-02 22:28:05] judas dot iscariote at gmail dot com taneli at crasman dot fi : - This is a well known "gotcha" see [1] - for the gory details, please see [2], this is not "that easy" to fix. 1. http://en.wikipedia.org/wiki/Reference_counting#Advantages_and_disadvantages 2. ftp://ftp.cs.utexas.edu/pub/garbage/bigsurv.ps ---------------- [2006-11-01 09:07:48] taneli at crasman dot fi Please address this bug, it's very short-sighted to rely on the fact that memory is freed on shutdown (especially when your either your box starts trashing or memory_limit kicks in and fails your request because of a bug in the interpreter). [2006-08-15 12:02:00] ruslan dot kyrychuk at gmail dot com Maybe solutution can be to call destructor every time when new object is assigned to old reference? Example: b = new B($this); } function __destruct () { $this->b->__destruct(); } } class B { function __construct ($parent = NULL) { $this->parent = $parent; } function __destruct () { unset($this->parent); } } for ($i = 0 ; $i < 100 ; $i++) { $a = new A(); $a->__destruct(); } echo number_format(memory_get_usage()); ?> $a->__destruct(); can be called automatically because new reference is created. Then writing correct destructors will solve this issue. Or maybe I missing something? [2006-05-04 14:08:22] frode at coretrek dot com I worked around this exact problem by using a proxy class with a destructor that explicitly breaks the cycle; I got the idea from a perl.com[1] article describing how perl suffers from the same problem. It's also interesting to note that perl has chosen a different (less elegant) solution to the problem than python, by introducing weak references. [1] http://www.perl.com/pub/a/2002/08/07/proxyobject.html [2006-04-13 06:24:02] seufert at gmail dot com I have been experiencing this problem. Unfortunately i have an application which relies heavily on a class->driver arrangement where both the class and the driver class need a reference to each other. I was wondering if we could have a way of getting an uncounted reference to the object to pass to the child? So the child would have a reference to the parent, but it would not be counted, and therefore when all external references to the parent are removed/unset, the parent will GC, and then the child will be freed as usual. Is this a workable solution? Even just a reference count decrement would work. Not a perfect solution, but it would solve calling descructors all the time. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/33595 -- Edit this bug report at http://bugs.php.net/?id=33595&edit=1
#33595 [Com]: recursive references leak memory
ID: 33595 Comment by: taneli at crasman dot fi Reported By: rodricg at sellingsource dot com Status: Assigned Bug Type: Class/Object related Operating System: * PHP Version: 6CVS-2005-08-02 Assigned To: dmitry New Comment: Please address this bug, it's very short-sighted to rely on the fact that memory is freed on shutdown (especially when your either your box starts trashing or memory_limit kicks in and fails your request because of a bug in the interpreter). Previous Comments: [2006-08-15 12:02:00] ruslan dot kyrychuk at gmail dot com Maybe solutution can be to call destructor every time when new object is assigned to old reference? Example: b = new B($this); } function __destruct () { $this->b->__destruct(); } } class B { function __construct ($parent = NULL) { $this->parent = $parent; } function __destruct () { unset($this->parent); } } for ($i = 0 ; $i < 100 ; $i++) { $a = new A(); $a->__destruct(); } echo number_format(memory_get_usage()); ?> $a->__destruct(); can be called automatically because new reference is created. Then writing correct destructors will solve this issue. Or maybe I missing something? [2006-05-04 14:08:22] frode at coretrek dot com I worked around this exact problem by using a proxy class with a destructor that explicitly breaks the cycle; I got the idea from a perl.com[1] article describing how perl suffers from the same problem. It's also interesting to note that perl has chosen a different (less elegant) solution to the problem than python, by introducing weak references. [1] http://www.perl.com/pub/a/2002/08/07/proxyobject.html [2006-04-13 06:24:02] seufert at gmail dot com I have been experiencing this problem. Unfortunately i have an application which relies heavily on a class->driver arrangement where both the class and the driver class need a reference to each other. I was wondering if we could have a way of getting an uncounted reference to the object to pass to the child? So the child would have a reference to the parent, but it would not be counted, and therefore when all external references to the parent are removed/unset, the parent will GC, and then the child will be freed as usual. Is this a workable solution? Even just a reference count decrement would work. Not a perfect solution, but it would solve calling descructors all the time. [2006-02-22 15:12:21] K dot Londenberg at librics dot de The problem with circular references is a known weakness of reference counting schemes. Python uses a workaround (cycle detector). Excerpt from http://wingware.com/psupport/python-manual/2.4/ext/refcounts.html: " While Python uses the traditional reference counting implementation, it also offers a cycle detector that works to detect reference cycles. This allows applications to not worry about creating direct or indirect circular references; these are the weakness of garbage collection implemented using only reference counting. Reference cycles consist of objects which contain (possibly indirect) references to themselves, so that each object in the cycle has a reference count which is non-zero. Typical reference counting implementations are not able to reclaim the memory belonging to any objects in a reference cycle, or referenced from the objects in the cycle, even though there are no further references to the cycle itself. " Maybe this would also be a viable Strategy for PHP.. [2006-01-19 10:31:05] letssurf at gmail dot com Thank you for your solution. It's the same path we had taken here. We had created a kill() method to do the same job. Shame it hasn't been fixed. Thank you again :) 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/33595 -- Edit this bug report at http://bugs.php.net/?id=33595&edit=1
#39328 [Bgs]: Memory leak when object contains reference to "parent" object
ID: 39328 User updated by: taneli at crasman dot fi Reported By: taneli at crasman dot fi Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.1.6 New Comment: That was quick. Looks like another version of this is assigned already (just found it), so how come this was marked "Bogus"? :) http://bugs.php.net/bug.php?id=33595 Previous Comments: [2006-11-01 09:01:11] [EMAIL PROTECTED] 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 . [2006-11-01 08:52:20] taneli at crasman dot fi Description: The example says it the best. Reproducible in both 5.1.6 and 4.4.4 (with minor changes), all extensions disabled. Definately related to references, although I'm not sure if the code below is good practice, but I've run into it on more than one occasion. I think it should be freeing the objects when they go out of scope, but the reference counting must be broken somehow. Might be related to #22055, but this one's been around for ages. Reproduce code: --- ba = array(); for ($i = 0; $i < 100; $i++) $this->ba[] = new B($this); } function __destruct() { // never gets called die("Freeing class A\n"); } } class B { var $a; function B($a) { // function B(&$a), and: $this->a = $a; // $this->a =& $a; leaks in php 4.4.4 // remove line above to prevent leak } function __destruct() { // never gets called either die("Freeing class B\n"); } } $smu = memory_get_usage(); while (true) { $ba = array(); for ($i = 0; $i < 100; $i++) $ba[] = new A(); $emu = memory_get_usage(); echo sprintf("leak %.1f kB\r", ($emu - $smu) / 1024.0); } }?> Expected result: No memory leak. Actual result: -- Rapidly increasing memory leak. -- Edit this bug report at http://bugs.php.net/?id=39328&edit=1
#39328 [NEW]: Memory leak when object contains reference to "parent" object
From: taneli at crasman dot fi Operating system: Linux PHP version: 5.1.6 PHP Bug Type: Scripting Engine problem Bug description: Memory leak when object contains reference to "parent" object Description: The example says it the best. Reproducible in both 5.1.6 and 4.4.4 (with minor changes), all extensions disabled. Definately related to references, although I'm not sure if the code below is good practice, but I've run into it on more than one occasion. I think it should be freeing the objects when they go out of scope, but the reference counting must be broken somehow. Might be related to #22055, but this one's been around for ages. Reproduce code: --- ba = array(); for ($i = 0; $i < 100; $i++) $this->ba[] = new B($this); } function __destruct() { // never gets called die("Freeing class A\n"); } } class B { var $a; function B($a) { // function B(&$a), and: $this->a = $a; // $this->a =& $a; leaks in php 4.4.4 // remove line above to prevent leak } function __destruct() { // never gets called either die("Freeing class B\n"); } } $smu = memory_get_usage(); while (true) { $ba = array(); for ($i = 0; $i < 100; $i++) $ba[] = new A(); $emu = memory_get_usage(); echo sprintf("leak %.1f kB\r", ($emu - $smu) / 1024.0); } }?> Expected result: No memory leak. Actual result: -- Rapidly increasing memory leak. -- Edit bug report at http://bugs.php.net/?id=39328&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39328&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39328&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39328&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39328&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39328&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39328&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39328&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39328&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39328&r=support Expected behavior:http://bugs.php.net/fix.php?id=39328&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39328&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39328&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39328&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39328&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39328&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39328&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39328&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39328&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39328&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39328&r=mysqlcfg
#35891 [WFx]: Erroneous code thru eval() causes memory leak
ID: 35891 User updated by: taneli at crasman dot fi Reported By: taneli at crasman dot fi Status: Wont fix Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.1.1, 4.4.1 New Comment: There used to be a php_check_syntax() function, but it only accepted files and insisted on executing the specified file. Previous Comments: [2006-01-04 14:58:40] taneli at crasman dot fi That would be just fine if there was a method to check PHP's syntax (other than "php -l") and/or the entire script would terminate properly (the script continues to run even if eval()'ed code contains a parse error). Of course, I don't see why a *parse* error should leave any engine to an unstable state. Apparently this is reason why user error handlers were disabled for the more serious errors? [2006-01-04 14:51:54] [EMAIL PROTECTED] This is expected. After parse error (wherever it happens) the engine is in unstable state and is unable to gracefully free all the memory allocated before. Just don't do it [tm]. ---- [2006-01-04 13:59:02] taneli at crasman dot fi Also present in PHP 4.4.1. BTW: Worst CAPTCHA images, ever. ---- [2006-01-04 13:53:57] taneli at crasman dot fi Description: Running unparsable code - which shouldn't be done, of course, but - causes a memory leak. Proper, parsable code does not cause memory leaks. Reproduce code: --- Expected result: Erroneous code eval(): Memory used before: 42568 Loop 1, memory used: 42568 ... Loop 999, memory used: 42568 Memory used after: 42568 Proper code eval(): Memory used before: 42568 Loop 1, memory used: 42568 ... Loop 999, memory used: 42568 Memory used after: 42568 Actual result: -- Erroneous code eval(): Memory used before: 42568 Loop 0, memory used: 49960 Loop 1, memory used: 57040 Loop 2, memory used: 64088 Loop 3, memory used: 71136 ... Loop 999, memory used: 7073088 Memory used after: 7073064 Proper code eval(): Memory used before: 7073064 Loop 0, memory used: 7073376 ... Loop 999, memory used: 7073376 Memory used after: 7073352 -- Edit this bug report at http://bugs.php.net/?id=35891&edit=1
#35891 [WFx]: Erroneous code thru eval() causes memory leak
ID: 35891 User updated by: taneli at crasman dot fi Reported By: taneli at crasman dot fi Status: Wont fix Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.1.1, 4.4.1 New Comment: That would be just fine if there was a method to check PHP's syntax (other than "php -l") and/or the entire script would terminate properly (the script continues to run even if eval()'ed code contains a parse error). Of course, I don't see why a *parse* error should leave any engine to an unstable state. Apparently this is reason why user error handlers were disabled for the more serious errors? Previous Comments: [2006-01-04 14:51:54] [EMAIL PROTECTED] This is expected. After parse error (wherever it happens) the engine is in unstable state and is unable to gracefully free all the memory allocated before. Just don't do it [tm]. ---- [2006-01-04 13:59:02] taneli at crasman dot fi Also present in PHP 4.4.1. BTW: Worst CAPTCHA images, ever. ---- [2006-01-04 13:53:57] taneli at crasman dot fi Description: Running unparsable code - which shouldn't be done, of course, but - causes a memory leak. Proper, parsable code does not cause memory leaks. Reproduce code: --- Expected result: Erroneous code eval(): Memory used before: 42568 Loop 1, memory used: 42568 ... Loop 999, memory used: 42568 Memory used after: 42568 Proper code eval(): Memory used before: 42568 Loop 1, memory used: 42568 ... Loop 999, memory used: 42568 Memory used after: 42568 Actual result: -- Erroneous code eval(): Memory used before: 42568 Loop 0, memory used: 49960 Loop 1, memory used: 57040 Loop 2, memory used: 64088 Loop 3, memory used: 71136 ... Loop 999, memory used: 7073088 Memory used after: 7073064 Proper code eval(): Memory used before: 7073064 Loop 0, memory used: 7073376 ... Loop 999, memory used: 7073376 Memory used after: 7073352 -- Edit this bug report at http://bugs.php.net/?id=35891&edit=1
#35891 [Opn]: Erroneous code thru eval() causes memory leak
ID: 35891 User updated by: taneli at crasman dot fi Reported By: taneli at crasman dot fi Status: Open Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.1.1 New Comment: Also present in PHP 4.4.1. BTW: Worst CAPTCHA images, ever. Previous Comments: [2006-01-04 13:53:57] taneli at crasman dot fi Description: Running unparsable code - which shouldn't be done, of course, but - causes a memory leak. Proper, parsable code does not cause memory leaks. Reproduce code: --- Expected result: Erroneous code eval(): Memory used before: 42568 Loop 1, memory used: 42568 ... Loop 999, memory used: 42568 Memory used after: 42568 Proper code eval(): Memory used before: 42568 Loop 1, memory used: 42568 ... Loop 999, memory used: 42568 Memory used after: 42568 Actual result: -- Erroneous code eval(): Memory used before: 42568 Loop 0, memory used: 49960 Loop 1, memory used: 57040 Loop 2, memory used: 64088 Loop 3, memory used: 71136 ... Loop 999, memory used: 7073088 Memory used after: 7073064 Proper code eval(): Memory used before: 7073064 Loop 0, memory used: 7073376 ... Loop 999, memory used: 7073376 Memory used after: 7073352 -- Edit this bug report at http://bugs.php.net/?id=35891&edit=1
#35891 [NEW]: Erroneous code thru eval() causes memory leak
From: taneli at crasman dot fi Operating system: Linux PHP version: 5.1.1 PHP Bug Type: Scripting Engine problem Bug description: Erroneous code thru eval() causes memory leak Description: Running unparsable code - which shouldn't be done, of course, but - causes a memory leak. Proper, parsable code does not cause memory leaks. Reproduce code: --- Expected result: Erroneous code eval(): Memory used before: 42568 Loop 1, memory used: 42568 ... Loop 999, memory used: 42568 Memory used after: 42568 Proper code eval(): Memory used before: 42568 Loop 1, memory used: 42568 ... Loop 999, memory used: 42568 Memory used after: 42568 Actual result: -- Erroneous code eval(): Memory used before: 42568 Loop 0, memory used: 49960 Loop 1, memory used: 57040 Loop 2, memory used: 64088 Loop 3, memory used: 71136 ... Loop 999, memory used: 7073088 Memory used after: 7073064 Proper code eval(): Memory used before: 7073064 Loop 0, memory used: 7073376 ... Loop 999, memory used: 7073376 Memory used after: 7073352 -- Edit bug report at http://bugs.php.net/?id=35891&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35891&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35891&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35891&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35891&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35891&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35891&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35891&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35891&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35891&r=support Expected behavior:http://bugs.php.net/fix.php?id=35891&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35891&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35891&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35891&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35891&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35891&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35891&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35891&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35891&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35891&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35891&r=mysqlcfg
#22510 [Com]: Zend Engine crashes calling FREE_ZVAL from zend_assign_to_variable_reference
ID: 22510 Comment by: taneli at crasman dot fi Reported By: php at codewhore dot org Status: Closed Bug Type: Scripting Engine problem Operating System: Linux 2.4 PHP Version: 4CVS-2003-06-01 (stable) New Comment: No fix for 4.3. I've gotten bitten by apparently the same bug: Program received signal SIGSEGV, Segmentation fault. 0x081a193f in _efree (ptr=0x84409a4) at /usr/src/www/php-4.3.4/Zend/zend_alloc.c:259 259 REMOVE_POINTER_FROM_LIST(p); (gdb) backtrace #0 0x081a193f in _efree (ptr=0x84409a4) at /usr/src/www/php-4.3.4/Zend/zend_alloc.c:259 #1 0x081b8b89 in zend_assign_to_variable_reference (result=0xa806b48, variable_ptr_ptr=0x16c21858, value_ptr_ptr=0x16c04030, Ts=0xbff80a70) at /usr/src/www/php-4.3.4/Zend/zend_execute.c:271 #2 0x081ba8d3 in execute (op_array=0xa8000d4) at /usr/src/www/php-4.3.4/Zend/zend_execute.c:163 #3 0x081bbda7 in execute (op_array=0xa7d67e4) at /usr/src/www/php-4.3.4/Zend/zend_execute.c:1660 #4 0x081bbda7 in execute (op_array=0xa4c37a4) at /usr/src/www/php-4.3.4/Zend/zend_execute.c:1660 #5 0x081bbda7 in execute (op_array=0xa5105f4) at /usr/src/www/php-4.3.4/Zend/zend_execute.c:1660 #6 0x081bbda7 in execute (op_array=0xa41b854) at /usr/src/www/php-4.3.4/Zend/zend_execute.c:1660 #7 0x081af74d in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/www/php-4.3.4/Zend/zend.c:884 #8 0x081896e7 in php_execute_script (primary_file=0xbff8bfb0) at /usr/src/www/php-4.3.4/main/main.c:1729 #9 0x081c0c17 in main (argc=4, argv=0xbff8c074) at /usr/src/www/php-4.3.4/sapi/cli/php_cli.c:819 Previous Comments: [2003-07-12 04:24:52] [EMAIL PROTECTED] The fix by Zeev will be in php5. [2003-06-02 10:56:43] [EMAIL PROTECTED] Just tested your last script with PHP 5.0.0-dev (ZE2), and it does not crash: # sapi/cli/php /home/jani/t.php Notice: Undefined variable: a in /home/jani/t.php on line 32 /usr/src/web/php/php5/Zend/zend_execute.c(2782) : Freeing 0x089681F4 (16 bytes), script=/home/jani/t.php And commenting out the line 32 (with $a=$a) makes it not crash in PHP 4.3.3-dev too: $ php t.php /usr/src/web/php/php4/Zend/zend_execute.c(1702) : Freeing 0x088A427C (12 bytes), script=t.php [2003-06-01 11:38:31] php at codewhore dot org A shorter crashing version of tests/lang/22510.phpt. Notice that removal of the silence operator (@) in method2() makes the crash go away. foo; } function &method2() { return @$this->foo; } } class bar { function run1() { $instance = new foo(); $instance->method1(); } function run2() { $instance = new foo(); $instance->method2(); $instance->method2(); } } function ouch(&$bar) { $bar->run1(); } function ok(&$bar) { $a = $a; $bar->run2(); } $bar = new bar(); ok($bar); ouch($bar); ?> [2003-03-02 17:30:18] php at codewhore dot org Accidently posted the non-crashing code snippet. Here's the one that crashes: function finalize() { $cl =& $this->commit_list; /* Note: These are references; we leave the value, $x, unused. */ foreach ($cl as $k => $x) { if (!$cl[$k]->transaction_commit()) return $this->throw(E_SYS); } return true; } [2003-03-02 17:28:54] php at codewhore dot org I've been able to reproducibly crash the PHP interpreter with a section of code that I'm working that passes around and calls through a lot of references. The function that causes the crash looks like: function finalize() { /* Note: These are references; we leave the value, $x, unused. */ foreach ($this->commit_list as $k => $x) { if (!$this->commit_list[$k]->transaction_commit()) return $this->throw(E_SYS); } return true; } I haven't managed to narrow it down any further - executing similar code in isolation hasn't been able to reproduce the crash yet. I'll keep trying. The backtrace: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 8158)] 0x4034913f in _efree (ptr=0x403b4564) at /usr/src/web-server/php-4.3-cvs/Zend/zend_alloc.c:233 233 REMOVE_POINTER_FROM_LIST(p); (gdb) bt #0 0x4034913f in _efree (ptr=0x403b4564) at /usr/src/web-server/php-4.3-cvs/Zend/zend_alloc.c:233 #1 0x403669fe in zend_assign_to_variable_reference (result=