Hi all,
I get an error with my program:
Fatal error: Allowed memory size of 134217728 bytes exhausted at
/home/courtois/php-5.3.6/Zend/zend_execute.h:163 (tried to allocate 261900
bytes) in /var/www/dev4.sociatomdev.com/chroot/htdocs/templeet/fetch.php on
line 580
- The same error occurs with
Le 01/04/2011 15:20, Pierre Joye a écrit :
> hi,
>
> In php 5.3+ the memory limit default is 256MB, not 128MB. 5.3 does not
> necessary use more memory but actually uses and reports its usage more
> efficiently. I would suggest to use this default value and try again.
the exact same bug occurs
Le 01/04/2011 18:46, Pascal COURTOIS a écrit :
> Le 01/04/2011 15:20, Pierre Joye a écrit :
>> hi,
>>
>> In php 5.3+ the memory limit default is 256MB, not 128MB. 5.3 does not
>> necessary use more memory but actually uses and reports its usage more
>> efficie
Le 03/04/2011 12:46, Pierre Joye a écrit :
> Try to run it by disabling the zend memory manager:
with zend memory manager disabled the program works fine.
I'll try with valgrind as you suggest
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/u
Le 03/04/2011 12:46, Pierre Joye a écrit :
> USE_ZEND_ALLOC=0 valgrind php --leak-check=full sapi/cli/php ... (or
> httpd if you use apache or only reproducible there)
>
> That will tell you if there are actual leaks.
it IS leaking:
==9772== Memcheck, a memory error detector
==9772== Copyright
Le 03/04/2011 13:30, Peter Beverloo a écrit :
> The parsing change you are proposing is invalid per RFC 1738.
RFC 1738 has been obsoleted by RFC 3986
http://tools.ietf.org/html/rfc3986
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.
Le 03/04/2011 15:46, Patrick ALLAERT a écrit :
> Sounds like "now" is a good time to fill in a bug report at
> http://bugs.php.net/ :)
The trouble is I don't know how to fill in such bug report.
It happens with my template engine which is thousands of lines
of PHP. The template engine has been
Le 03/04/2011 20:37, Pierre Joye a écrit :
> post it with the necessary steps to reproduce it. We may try to reduce
> the code to the minimal we need to get the leak (I remember someone
> having a tool for that)
ok, thanks: http://bugs.php.net/bug.php?id=54460
--
PHP Internals - PHP Runtime Deve
Le 11/04/2011 19:17, Michael Morris a écrit :
> But don't ask the engine to be rewritten to encourage bad coding practices
> which failing to properly initialize variables is a prime example of. It's
> this sort of thinking that got register_globals and magic_quotes put into
> the language no doub
Le 10/05/2011 07:46, Lester Caine a écrit :
> The existing tools had been working well, but nowadays things are simply
> becoming a mess ...
>
I agree.
Why not fixing the several hundreds of bugs in PHP before just even thinking
about adding new features ???
I much respect people using my
Le 29/05/2011 07:05, Gwynne Raskind a écrit :
> On May 28, 2011, at 10:55 PM, Martin Scotta wrote:
>> I really dont like to move away from PHP, but compared to others... it's
>> just a template language with steroids.
>>
>> and please dont get me wrong, I love PHP, it's is still my favourite but...
Le 29/05/2011 09:41, Gwynne Raskind a écrit :
> The balance between rapid development, learning curve, and usability.
> One line in Python or PHP or even C# can equate to thousands in C.
no doubt
> Python or Java might be a better match for what I'm doing,
sure
> but then
> there's the q
Le 16/06/2011 04:36, dukeofgaming a écrit :
> Hi,
>
> I think that —in any context— the "if it aint broke don't fix it" is a very
> depressing attitude to have, and a very wrong one in any open source
> community.
What I feel depressing is the urge of the PHP core team to fix working
features
Le 16/06/2011 07:23, Stas Malyshev a écrit :
> Hi!
>
>> On every PHP project I work on I had to find workarounds because
>> PHP crashes. Behaviour bugs (feature not working as intended) are
>> annoying but memory leaks and memory corruptions are just a no no
>> no in production environment. The on
Le 16/06/2011 08:01, dukeofgaming a écrit :
> Sorry if the question is dumb, but, how many core developers does PHP have?,
> how many in total (including non-core contributors)?.
That's not the point. Whatever the project is, every developer should fix
existing bugs before even thinking about
Le 16/06/2011 08:10, Stas Malyshev a écrit :
> Hi!
>
>> what I did every single time. Among all my bug reports I had one
>> answer from decoder-...@own-hero.net (thanks to him) who reduced
>> the test case for a memory leak (bug 54460). I'm not talking about
>> bugs in modules but bugs in *core* w
Le 16/06/2011 08:52, Lester Caine a écrit :
> Pascal I am sure that many people here would be more than happy to
> hear about particular problems you are hitting.
Ok, then why when I signal a bug noone cares ?
> Like Stas I have
> never had problems with the stability of PHP5 in 10 years of r
Le 16/06/2011 09:19, Lester Caine a écrit :
>>when you have a bug in PHP it should not ever ever crash PHP and
>> unfortunately I encountered that case dozens of times.
> At least on Linux is just recovers and carries on
If PHP crashes, yes, it recovers but it's VERY resource and time consum
Le 16/06/2011 09:29, Stas Malyshev a écrit :
> On 6/15/11 11:38 PM, Pascal COURTOIS wrote:
>>In bug 614904 I submitted a TWO lines program which crashed PHP on
>> a absolutely standard i386 debian install. I got no answer.
>> Of course the bug disapeared in following ver
Le 16/06/2011 09:56, Stas Malyshev a écrit :
> On 6/15/11 11:38 PM, Pascal COURTOIS wrote:
>> as I said earlier, test case was reduced to:
>
> The leaks you'll be seeing in this code is probably caused by the
> fact that main function (i.e. global context) is not destroyed
Le 16/06/2011 10:12, Stas Malyshev a écrit :
> Hi!
>
> On 6/16/11 1:05 AM, Pascal COURTOIS wrote:
>> If you call "minuscule" a leak that requires more than 128Mb as it
>> normally requires about 4Mb, then it's minuscule but whatever you
>> name it
Le 16/06/2011 11:36, Johannes Schlüter a écrit :
> On Thu, 2011-06-16 at 08:12 +0200, Pascal COURTOIS wrote:
>> Le 16/06/2011 08:01, dukeofgaming a écrit :
>>
>>> Sorry if the question is dumb, but, how many core developers does PHP have?,
>>> how many in total
Le 16/06/2011 12:12, Pierre Joye a écrit :
> It is not what Johannes said and we do fix bugs every single day. What
> Johannes said is that we can't force a volunteer to do something
> specific instead of what he wants to do.
>
> It is also totally off topic btw.
It is really on topic since le
Le 16/06/2011 12:31, Rasmus a écrit :
> On 06/16/2011 11:03 AM, Pascal COURTOIS wrote:
>> If you followed the thread you have seen the reduced test case is
>> VERY short and the ONLY constructions involved are user functions and
>> exceptions. FULL STOP. Not even a single ad
Le 16/06/2011 13:42, Rasmus a écrit :
> On 06/16/2011 11:40 AM, Pascal COURTOIS wrote:
>> Le 16/06/2011 12:31, Rasmus a écrit :
>>> On 06/16/2011 11:03 AM, Pascal COURTOIS wrote:
>>>> If you followed the thread you have seen the reduced test case is
>>>
Le 16/06/2011 18:11, Andi Gutmans a écrit :
> I have some news for you. Ruby has crashes, Python has crashes,
Probably. any references about that ?
> even Java has security issues and crashes (check out the Java bug database.
> It's bigger than ours).
IMHO java is a big s**t but that's rea
Le 16/06/2011 08:10, Stas Malyshev a écrit :
> Hi!
>
>> what I did every single time. Among all my bug reports I had one
>> answer from decoder-...@own-hero.net (thanks to him) who reduced
>> the test case for a memory leak (bug 54460). I'm not talking about
>> bugs in modules but bugs in *core* w
Hi,
Is there any way that a variable can be changed within a function without
passing it by reference ?
I have a code like that:
function myfunction($var)
{
print_r($var); => prints $var which is an object
anotherfunction($var); // call by value
print_r($var); => $var has changed
Le 29/06/2011 16:57, Hannes Magnusson a écrit :
> We have the data now and work is now ongoing migrating the two now.
> museum is also up, and snaps will probably be running before the weekend.
great, thanks :-)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: ht
Le 29/06/2011 17:00, Richard Quadling a écrit :
> For objects, $var is always an alias to an object identifier which
> points to the same object...
>
> http://docs.php.net/manual/en/language.oop5.references.php
thanks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vis
30 matches
Mail list logo
