Bug #52913 [Com]: Incorrect SNI (Server name indicator) when using a SoapClient through a proxy

2013-05-21 Thread taneli at crasman dot fi
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

2012-03-09 Thread taneli at crasman dot fi
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

2007-11-02 Thread taneli at crasman dot fi
 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

2007-11-02 Thread taneli at crasman dot fi
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

2007-01-24 Thread taneli at crasman dot fi
 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

2006-11-01 Thread taneli at crasman dot fi
 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

2006-11-01 Thread taneli at crasman dot fi
 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

2006-11-01 Thread taneli at crasman dot fi
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

2006-01-04 Thread taneli at crasman dot fi
 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

2006-01-04 Thread taneli at crasman dot fi
 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

2006-01-04 Thread taneli at crasman dot fi
 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

2006-01-04 Thread taneli at crasman dot fi
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

2004-02-24 Thread taneli at crasman dot fi
 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=