[I can't reach the PHP web site (100% packet loss), so I can't open a bug
report at this time]
I have found a leak in the Zend engine:
class A
{
var $t = null;
function &run(&$t)
{
$this->t = &$t;
return $this->t->run();
}
}
clas
BTW: This was with CVS PHP updated this morning,
./configure --disable-pear --without-gd --without-mysql --enable-debug
> zend_hash.c(291) : Freeing 0x0818E474 (37 bytes), script=leak.php
> Last leak repeated 1 time
> zend_hash.c(202) : Freeing 0x08193D1C (20 bytes), script=leak.php
> Last lea
I don't have enough mental strength to dive into that script right now, but
be advised that if you create circular references (which apparently you do)
then yes, it will leak. PHP doesn't support circular references.
Zeev
At 15:06 28/3/2001, Wez Furlong wrote:
>[I can't reach the PHP web site
> I don't have enough mental strength to dive into that script
> right now, but
:-)
> be advised that if you create circular references (which
> apparently you do)
> then yes, it will leak. PHP doesn't support circular references.
Ahhh.
It may sound like a stupid question, but why not?
An
Erhm all this talk about memory leaks - made me curious.
How do I go about getting the sort of output, that Wez are showing
below.
I suspect that the extension I'm writing on has some severe memory
issues.
These issues are occuring in the PHP script, that utilizes my extension.
Every other reload
I do come up with the most stupid questions - sorry :)
Thomas Wentzel wrote:
>
> Erhm all this talk about memory leaks - made me curious.
> How do I go about getting the sort of output, that Wez are showing
> below.
> I suspect that the extension I'm writing on has some severe memory
> issues.
WF>> Ahhh.
WF>>
WF>> It may sound like a stupid question, but why not?
Because reference-counting mechanisms of memory management are not fit to
deal with circular references.
WF>> And is it likely to in the future?
I won't be holding my breath for it. That's the basic property of
reference-cou
Hi Wez!
On Wed, 28 Mar 2001, Wez Furlong wrote:
> [I can't reach the PHP web site (100% packet loss), so I can't open a bug
> report at this time]
>
> I have found a leak in the Zend engine:
>
> class A
> {
> var $t = null;
>
> function &run(&$t)
> {
> $this->t
Thank you very much, Wez!
Perhaps you can be so nice as to answer my next question also ;)
Whenever I do a configure with --enable-debug I get close to
a zillion errors when compiling (or linking rather) it seems that I get
the following two errors for each function in my code:
"multiple definit
DUH!!!
I did a buildconf and then the errors disappeared...
Thomas Wentzel wrote:
>
> Thank you very much, Wez!
>
> Perhaps you can be so nice as to answer my next question also ;)
> Whenever I do a configure with --enable-debug I get close to
> a zillion errors when compiling (or linking rath
hi,
> I won't be holding my breath for it. That's the basic property of
> reference-counting, so it's not easy to make it behave differently.
> Anyway, unless you have very-long-running very-memory-greedy scripts,
> these leaks shouldn't bother you - Zend memory manager cleans them up on
> every
BB>> i have hit on this issue while trying to make a sapi module. my
BB>> problem was that memory emalloc-ed _before_ the request got
BB>> efree-ed by the memory manager after the request and when i
BB>> efree it afterwards a total memory mess occurs (sigsegv,
BB>> infinite loop in libc free or so
12 matches
Mail list logo
