Hi,
Short-array syntax, Native JSON, "Currying". I can
almost only say one thing: WHY?!
And because of that, I'd like to forward a mail by Zeev from a few years
ago. I think it applies now even more than then:
---------- Forwarded message ----------
Date: Thu, 09 Mar 2006 12:57:32 +0200
From: Zeev Suraski zeev@zend.com
To: internals@lists.php.net
Subject: [PHP-DEV] Give the Language a Rest motion
I'd like to raise a motion to 'Give the Language a Rest'.
Almost a decade since we started with the 2nd iteration on the syntax (PHP 3),
and 2 more major versions since then, and we're still heatedly debating on
adding new syntactical, core level features.
Is it really necessary? I'd say in almost all cases the answer's no, and a
bunch of cases where a new feature could be useful does not constitute a good
enough reason to add a syntax level feature. We might have to account for new
technologies, or maybe new ways of thinking that might arise, but needless to
say, most of the stuff we've been dealing with in recent times doesn't exactly
fall in the category of cutting edge technology.
My motion is to make it much, much more difficult to add new syntax-level
features into PHP. Consider only features which have significant traction to a
large chunk of our userbase, and not something that could be useful in some
extremely specialized edge cases, usually of PHP being used for non web stuff.
How do we do it? Unfortunately, I can't come up with a real mechanism to
'enforce' a due process and reasoning for new features.
Instead, please take at least an hour to bounce this idea in the back of your
mind, preferably more. Make sure you think about the full context, the huge
audience out there, the consequences of making the learning curve steeper with
every new feature, and the scope of the goodness that those new features bring.
Consider how far we all come and how successful the PHP language is today, in
implementing all sorts of applications most of us would have never even thought
of when we created the language.
Once you're done thinking, decide for yourself. Does it make sense to be
discussing new language level features every other week? Or should we, perhaps,
invest more in other fronts, which would be beneficial for a far bigger
audience. The levels above - extensions to keep with the latest technologies,
foundation classes, etc. Pretty much, the same direction other mature languages
went to.
To be clear, and to give this motion higher chances of success, I'm not talking
about jump. PHP can live with jump, almost as well as it could live without it
:) I'm talking about the general sentiment.
Zeev
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Hi,
Short-array syntax, Native JSON, "Currying". I can
almost only say one thing: WHY?!And because of that, I'd like to forward a mail by Zeev from a few years
ago. I think it applies now even more than then:
I'd to disagree.
I love activities on the list, even for features I would never want to
see implemented in php. It is how it works, it is how it should work,
Getting constant new requests, discussing new possible features,
moving forward. Even if it does not mean it has to be uncontrollable
and that we should implement every 2nd request.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi,
Short-array syntax, Native JSON, "Currying". I can
almost only say one thing: WHY?!And because of that, I'd like to forward a mail by Zeev from a few years
ago. I think it applies now even more than then:snip
I think that it is better to have healthy discussion about the language,
than to stop accepting feature request at all.
of course we have to carefully select which RFCs are good enough and worthy
for inclusion, and properly introduce them into the language and for the
users.
I really like the current buzz, but maybe there are some people like you,
who are more in favor for the previous flow of conversations(fewer
participants, fewer discussions).
Tyrael
Hi Derick and all,
I think we have had some reasonable additions to the language in PHP 5.3 + will have a couple of good ones in PHP 5.4. That said, I do agree we should have a strong bias against language feature creep unless there is a really strong compelling reason.
I do think that an increase of focus on enriching the eco-system around the core language esp. PHP extensions will be a lot more valuable. This is especially so if we can target many of the up and coming technologies and get such extensions production ready to bundle in Core PHP (hence my previous email re: adding some modern extensions).
We've benefited in the past from a lot of enhancements and innovation around extensions incl. SimpleXML, variety of database, json, datetime, etc... Having another wave of really strong core extensions would be very beneficial and consistent with our past bias to deliver everything Web developers need out-of-the-box.
Hence my suggestion to bundle MongoDB extension and possibly work on additional extensions. Some of my suggestions probably rightfully didn't get much interest such as Thrift.
Maybe we should consider making a list of extensions we think could be beneficial and the new mentorship program can actually help deliver some of them?
Stas, on a different note, weren't we going to roll a 5.4 alpha?
Andi
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Tuesday, June 07, 2011 4:05 AM
To: PHP Developers Mailing List
Subject: [PHP-DEV] Give the Language a Rest motion (fwd)Hi,
Short-array syntax, Native JSON, "Currying". I can almost only say one thing:
WHY?!And because of that, I'd like to forward a mail by Zeev from a few years ago. I
think it applies now even more than then:---------- Forwarded message ----------
Date: Thu, 09 Mar 2006 12:57:32 +0200
From: Zeev Suraski zeev@zend.com
To: internals@lists.php.net
Subject: [PHP-DEV] Give the Language a Rest motionI'd like to raise a motion to 'Give the Language a Rest'.
Almost a decade since we started with the 2nd iteration on the syntax (PHP 3),
and 2 more major versions since then, and we're still heatedly debating on
adding new syntactical, core level features.Is it really necessary? I'd say in almost all cases the answer's no, and a bunch of
cases where a new feature could be useful does not constitute a good enough
reason to add a syntax level feature. We might have to account for new
technologies, or maybe new ways of thinking that might arise, but needless to
say, most of the stuff we've been dealing with in recent times doesn't exactly
fall in the category of cutting edge technology.My motion is to make it much, much more difficult to add new syntax-level
features into PHP. Consider only features which have significant traction to a
large chunk of our userbase, and not something that could be useful in some
extremely specialized edge cases, usually of PHP being used for non web stuff.How do we do it? Unfortunately, I can't come up with a real mechanism to
'enforce' a due process and reasoning for new features.Instead, please take at least an hour to bounce this idea in the back of your
mind, preferably more. Make sure you think about the full context, the huge
audience out there, the consequences of making the learning curve steeper with
every new feature, and the scope of the goodness that those new features bring.
Consider how far we all come and how successful the PHP language is today, in
implementing all sorts of applications most of us would have never even thought
of when we created the language.Once you're done thinking, decide for yourself. Does it make sense to be
discussing new language level features every other week? Or should we,
perhaps, invest more in other fronts, which would be beneficial for a far bigger
audience. The levels above - extensions to keep with the latest technologies,
foundation classes, etc. Pretty much, the same direction other mature
languages went to.To be clear, and to give this motion higher chances of success, I'm not talking
about jump. PHP can live with jump, almost as well as it could live without it
:) I'm talking about the general sentiment.Zeev
--
http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation:
http://xdebug.org/donate.php
twitter: @derickr and @xdebug--
To unsubscribe, visit:
http://www.php.net/unsub.php
Hi!
Stas, on a different note, weren't we going to roll a 5.4 alpha?
I was going to write about it soon, but since you asked: I was waiting
for RFC/voting discussion and vote in hope that we could get it all
ready before the alpha, but it looks like it is taking longer than
expected. So I think maybe we can have the alpha before that - and the
RFC says we should have alpha in June anyway, and June is already
half-gone :)
The original plan was this week, so maybe this Thursday?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
+1, for Thursday :-)
-----邮件原件-----
发件人: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
发送时间: 2011年6月15日 15:24
收件人: Andi Gutmans
抄送: PHP Developers Mailing List
主题: [PHP-DEV] Re: 5.4 alpha, was: [PHP-DEV] Give the Language a Rest
motion (fwd)
Hi!
Stas, on a different note, weren't we going to roll a 5.4 alpha?
I was going to write about it soon, but since you asked: I was waiting for
RFC/voting discussion and vote in hope that we could get it all ready before
the alpha, but it looks like it is taking longer than expected. So I think
maybe we can have the alpha before that - and the RFC says we should have
alpha in June anyway, and June is already half-gone :) The original plan was
this week, so maybe this Thursday?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
To unsubscribe, visit:
http://www.php.net/unsub.php
Hi!
The original plan was this week, so maybe this Thursday?
After some consideration, we decided to do it on next Monday, the 20th.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Stas, on a different note, weren't we going to roll a 5.4 alpha?
I was going to write about it soon, but since you asked: I was waiting
for RFC/voting discussion and vote in hope that we could get it all
ready before the alpha, but it looks like it is taking longer than
expected. So I think maybe we can have the alpha before that - and the
RFC says we should have alpha in June anyway, and June is already
half-gone :)
The original plan was this week, so maybe this Thursday?
Zeev edited it today. So I hope it's ready for voting within the
next days, so we can move forward.
Hence my suggestion to bundle MongoDB extension and possibly work on additional extensions. Some of my suggestions probably rightfully didn't get much interest such as Thrift.
See my comment in your other thread and below.
Maybe we should consider making a list of extensions we think could be beneficial and the new mentorship program can actually help deliver some of them?
I do not thnk it is a good thing to begin a discussion about this
exact topic and then totally ignore it.
I also think that it is somehow wrong to post something asking to do
not propose new things when we finally have more people involved in
proposals and discussions. Maybe that's just me me but I do think that
the main problem we have (besides the ones we identified and try to
fix right now) is the complete lack of open discussions about possible
new features, in this list with new or existing contributors.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Wednesday, June 15, 2011 2:33 AM
To: Andi Gutmans
Cc: Derick Rethans; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)Hence my suggestion to bundle MongoDB extension and possibly work on
additional extensions. Some of my suggestions probably rightfully didn't get
much interest such as Thrift.See my comment in your other thread and below.
Maybe we should consider making a list of extensions we think could be
beneficial and the new mentorship program can actually help deliver some of
them?I do not thnk it is a good thing to begin a discussion about this exact topic and
then totally ignore it.
I think it got lost in the very long and varying discussions. Will dig up and take a look. I had a couple of hectic weeks.
I also think that it is somehow wrong to post something asking to do not propose
new things when we finally have more people involved in proposals and
discussions. Maybe that's just me me but I do think that the main problem we
have (besides the ones we identified and try to fix right now) is the complete
lack of open discussions about possible new features, in this list with new or
existing contributors.
I did not say we should not propose or have discussions (I am in favor of adding [] for arrays for example). But I am saying the bias should be not to include new language functionality unless it has very broad appeal & serious upside impact. The bias should be against feature creep.
Andi
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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.
If the signal to noise ratio is the problem, I think its better to focus on
that problem, not shutting down the signal. If PHP is a resource crunched
project, I think its better to focus on that problem, not rejecting feature
requests.
(I might appear as impertinent with what I'm going to say, but bear with me,
I'm being well-intentioned and mean no offense; just want to be honest).
Regarding the signal to noise ratio, I have one question: how did traits get
accepted?, having seen the kind of conversations in the lists it makes
almost no sense to me how something so "radical" and complex could make its
way to PHP so quickly and a simple and convenient thing like a short array
syntax cannot, and something so basic as annotations raises so much
pointless (just not to say ignorant) debate. Was it the to-the-point RFC and
solid patch?, was it that the conversations were just on another level so
not anyone could just say —or troll— "traits are no solution! spit, lets
do aspects instead!". I know it took some time, but while lurking the lists
IIRC I never saw any opposition to traits... could anyone tell me what was
the magic behind this?, could it be repeated?.
Regarding resources, I think this is one of the main things rendering the
community unhealthy (at least it feels like that to me) and I even feel
bitterness in the air. I think that the definite solution to this is a DVCS
like git and hosting the code at github, or like mercurial and hosting the
code at bitbucket, please don't be angered at this suggestion (as I know the
switch to SVN is a fairly recent one), you can ask around SVN geeks that
went the distributed way and they will tell you things, wonderful things of
how they don't know how could they could endure that much with that in their
project, and if its an open source one, how much the switch has done in
favor of contributions.
Regardless of everything, I like that the PHP community has so much passion
and energy, sometimes in a not constructive way, but that is a good problem
to have in my opinion, really, don't take it for granted, it just needs a
little direction.
Best regards,
David Vega
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Wednesday, June 15, 2011 2:33 AM
To: Andi Gutmans
Cc: Derick Rethans; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)Hence my suggestion to bundle MongoDB extension and possibly work on
additional extensions. Some of my suggestions probably rightfully didn't
get
much interest such as Thrift.See my comment in your other thread and below.
Maybe we should consider making a list of extensions we think could be
beneficial and the new mentorship program can actually help deliver some
of
them?I do not thnk it is a good thing to begin a discussion about this exact
topic and
then totally ignore it.I think it got lost in the very long and varying discussions. Will dig up
and take a look. I had a couple of hectic weeks.I also think that it is somehow wrong to post something asking to do not
propose
new things when we finally have more people involved in proposals and
discussions. Maybe that's just me me but I do think that the main problem
we
have (besides the ones we identified and try to fix right now) is the
complete
lack of open discussions about possible new features, in this list with
new or
existing contributors.I did not say we should not propose or have discussions (I am in favor of
adding [] for arrays for example). But I am saying the bias should be not to
include new language functionality unless it has very broad appeal & serious
upside impact. The bias should be against feature creep.Andi
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
What I am saying is if we accepted even 50% of what people felt very passionate about because their "favorite language of the day" has it then PHP would become overly complex, bloated and very challenging for users to pick up. C++ for example was a good language but is a good example of trying to do too much and getting overly complex over time (at least in my opinion).
I do think we should have new feature discussions and need to ensure PHP evolves with the market and its users but have to ensure that we still keep it simple, easy to adopt and maintainable. Also, I think we do not need 100 ways of doing the same thing. Choice is good but too much choice is not.
As I said in my previous email, while I think there are areas we can and should innovate in and evolve the core language I believe a lot of the innovation also has to happen at the framework and extension-level. I do not think there's a resource issue at the language level. When a new feature does get slated to be included we always have plenty of resources deployed on it to harden it and make sure it gets into the core vm in the right way (it is almost never the same as the original patch).
I do think having more people work on extensions for some of the up and coming technologies would be super valuable. Seems like everyone wants to try and get their favorite language feature in but less are stepping up to work on extensions. What can you contribute?
Andi
From: dukeofgaming [mailto:dukeofgaming@gmail.com]
Sent: Wednesday, June 15, 2011 7:36 PM
To: Andi Gutmans
Cc: Pierre Joye; Derick Rethans; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)
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.
If the signal to noise ratio is the problem, I think its better to focus on that problem, not shutting down the signal. If PHP is a resource crunched project, I think its better to focus on that problem, not rejecting feature requests.
(I might appear as impertinent with what I'm going to say, but bear with me, I'm being well-intentioned and mean no offense; just want to be honest).
Regarding the signal to noise ratio, I have one question: how did traits get accepted?, having seen the kind of conversations in the lists it makes almost no sense to me how something so "radical" and complex could make its way to PHP so quickly and a simple and convenient thing like a short array syntax cannot, and something so basic as annotations raises so much pointless (just not to say ignorant) debate. Was it the to-the-point RFC and solid patch?, was it that the conversations were just on another level so not anyone could just say -or troll- "traits are no solution! spit, lets do aspects instead!". I know it took some time, but while lurking the lists IIRC I never saw any opposition to traits... could anyone tell me what was the magic behind this?, could it be repeated?.
Regarding resources, I think this is one of the main things rendering the community unhealthy (at least it feels like that to me) and I even feel bitterness in the air. I think that the definite solution to this is a DVCS like git and hosting the code at github, or like mercurial and hosting the code at bitbucket, please don't be angered at this suggestion (as I know the switch to SVN is a fairly recent one), you can ask around SVN geeks that went the distributed way and they will tell you things, wonderful things of how they don't know how could they could endure that much with that in their project, and if its an open source one, how much the switch has done in favor of contributions.
Regardless of everything, I like that the PHP community has so much passion and energy, sometimes in a not constructive way, but that is a good problem to have in my opinion, really, don't take it for granted, it just needs a little direction.
Best regards,
David Vega
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Wednesday, June 15, 2011 2:33 AM
To: Andi Gutmans
Cc: Derick Rethans; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)Hence my suggestion to bundle MongoDB extension and possibly work on
additional extensions. Some of my suggestions probably rightfully didn't get
much interest such as Thrift.See my comment in your other thread and below.
Maybe we should consider making a list of extensions we think could be
beneficial and the new mentorship program can actually help deliver some of
them?I do not thnk it is a good thing to begin a discussion about this exact topic and
then totally ignore it.
I think it got lost in the very long and varying discussions. Will dig up and take a look. I had a couple of hectic weeks.
I also think that it is somehow wrong to post something asking to do not propose
new things when we finally have more people involved in proposals and
discussions. Maybe that's just me me but I do think that the main problem we
have (besides the ones we identified and try to fix right now) is the complete
lack of open discussions about possible new features, in this list with new or
existing contributors.
I did not say we should not propose or have discussions (I am in favor of adding [] for arrays for example). But I am saying the bias should be not to include new language functionality unless it has very broad appeal & serious upside impact. The bias should be against feature creep.
Andi
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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
instead of focusing on the 1800 open bug tickets.
On every PHP project I work on I had to find workarounds because PHP crashes.
Behaviour bugs (feature not working as intented) are annoying but memory leaks and
memory corruptions are just a no no no in production environnement. The only way
to call PHP when its memory leaks and get corrupted is to call it via CGI which
is much too slow for a production server.
What I need is a very stable language on which I can rely and I'm very sad to
to say PHP is getting worse and worse on that point of view versions after versions.
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 only way
A key to fixing memory corruption is providing good bug reports - with
backtraces, valgrind reports, etc. If you have such reports and nothing
happens to them - you may want to try to raise the profile of bug
reports that are bothering you by mentioning them on the list and
calling for volonteers to fix them. Usually if bug is in frequently used
module and reproduceable, there would be somebody who can fix it.
What I need is a very stable language on which I can rely and I'm very sad to
to say PHP is getting worse and worse on that point of view versions after versions.
I can not contradict your experience, it is what it is, but my
experience for years working with PHP was exactly the opposite.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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 only wayA key to fixing memory corruption is providing good bug reports -
with backtraces, valgrind reports, etc. If you have such reports and
nothing happens to them - you may want to try to raise the profile of
bug reports that are bothering you by mentioning them on the list and
calling for volonteers to fix them. Usually if bug is in frequently
used module and reproduceable, there would be somebody who can fix
it.
what I did every single time. Among all my bug reports I had one answer
from decoder-php@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 which can be reproduced with few lines of core PHP.
What I need is a very stable language on which I can rely and I'm
very sad to to say PHP is getting worse and worse on that point of
view versions after versions.I can not contradict your experience, it is what it is, but my
experience for years working with PHP was exactly the opposite.
To tell you the truth, I've been asked to rewrite the framework I
did in Ruby because of these problems. I'm of course very reluctant
to go that way but in the end I may have no choice :-(
Hi!
what I did every single time. Among all my bug reports I had one answer
from decoder-php@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 which can be reproduced with few lines of core PHP.
I am reading the list pretty closely and I don't remember any emails
from you raising the question of reproducible corruption bugs recently,
except indeed for 54460 which seems to be a memory leak, though presence
of xcache in the trace suggests it may not even be a PHP bug. It talks
about bug in a template engine containing thousands of lines. This is
pretty hard work to debug something starting with huge unknown code, so
no wonder nobody got to it yet. PHP is a volunteer project, and it's not
easy to find volunteers to dig into thousand lines of unknown code to
find a bug that may not even be there. It's quite a hard work.
I must have missed other ones. But if they are still reproducible in 5.4
and you have reproducing code, you're welcome to share on the list.
Unfortunately, bugs.php.net seems to be down, but once it gets up we
could look into it and see if we can fix any. As I said, good
reproduction makes it better.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
what I did every single time. Among all my bug reports I had one
answer
Stas, how I can i finally persuade you to quote the name of the people
you're replying to? :) I find it very hard to follow any discussion
you're involved in.
Thanks,
Mike
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-php@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 which can be reproduced with few
lines of core PHP.I am reading the list pretty closely and I don't remember any emails
from you raising the question of reproducible corruption bugs
recently, except indeed for 54460 which seems to be a memory leak,
though presence of xcache in the trace suggests it may not even be a
PHP bug. It talks about bug in a template engine containing thousands
of lines. This is pretty hard work to debug something starting with
huge unknown code, so no wonder nobody got to it yet. PHP is a
volunteer project, and it's not easy to find volunteers to dig into
thousand lines of unknown code to find a bug that may not even be
there. It's quite a hard work.
as I said earlier, test case was reduced to:
<?php
class TempleetRedirect extends Exception {};
Function parseform($template) {
$txt = eval_list($templatecache[$template]['template']);
}
Function eval_list($array) {
throw new TempleetRedirect($file);
}
Function parsetemplate($template) {
$txt = parseform($template);
}
try
{
$output=parsetemplate($global_var['template']);
}
catch (TempleetRedirect $r)
{
exit();
}
?>
as you can see there's nothing but PHP core instructions in that code.
I must have missed other ones. But if they are still reproducible in
5.4 and you have reproducing code, you're welcome to share on the
list. Unfortunately, bugs.php.net seems to be down, but once it gets
up we could look into it and see if we can fix any.
for memory leaks if the bug is fixed it will not happen again but
for memory corruption it's something totaly different. The fact that
a bug disapears doesn't mean in any way it has been fixed.
As I said, good
reproduction makes it better.
I've been debugging in lots of languages including assembly codes
for over 30 years so I know precisely what you mean. So when it's
possible to reproduce a bug in some known conditions, the wait-and-see
attitude is not a good option because it's very likely that the bug
will disapear. Memory coruptions are much like terrorist attacks:
you never know where and when it will happen.
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 versions of PHP but what is fixed ?
Not as far as I know.
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 versions of PHP but what is fixed ?
Not as far as I know.
614904 doesn't look like real bug number. Must be a typo.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Le 16/06/2011 09:29, Stas Malyshev a écrit :
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 versions of PHP but what is fixed ?
Not as far as I know.614904 doesn't look like real bug number. Must be a typo.
ooops, sorry. You're right. It's a bug I submitted to debian because of the way
they work with releases having a version with no feature update but including
security updates, which means the versions in debian distribution are not exactly
the ones released. Since debian requires that bug submitted should not be submitted
also to program developpers, I complied. May be it was a mistake...
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 when exit() is
called, since . It can be argued as a bug, but very minor one and
totally unlikely to cause any problems both because the leak is
minuscule and the fact that memory manager will clean it up anyway on
shutdown. I would have very hard time believing this very short-time
leak can cause any problems in any production code.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Le 16/06/2011 09:56, Stas Malyshev a écrit :
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 when
exit() is called, since . It can be argued as a bug, but very minor
one and totally unlikely to cause any problems both because the leak
is minuscule and the fact that memory manager will clean it up anyway
on shutdown.
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 it just does not run.
I would have very hard time believing this very
short-time leak can cause any problems in any production code.
It does
Hi!
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 it just does not run.
Sorry, if your example generates memory footprint of 128Mb, something is
seriously wrong with your build. There's no way this code can produce
128Mb footprint. If it's another code, they we'd need to investigate
what causes that leak, which must be different from the one this code
produces.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Le 16/06/2011 10:12, Stas Malyshev a écrit :
Hi!
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 it just does not run.Sorry, if your example generates memory footprint of 128Mb, something
is seriously wrong with your build. There's no way this code can
produce 128Mb footprint. If it's another code, they we'd need to
investigate what causes that leak,
that's a deal. I have no time right now but I will summerize on tuesday
the whole thing that leaded to this code.
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-php@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 which can be reproduced with few
lines of core PHP.I am reading the list pretty closely and I don't remember any emails
from you raising the question of reproducible corruption bugs
recently, except indeed for 54460 which seems to be a memory leak,
bug 54460 has disapeared from bugs.php.net . Is due to the crash ?
On Wed, Jun 29, 2011 at 3:36 PM, Pascal COURTOIS
Pascal.Courtois@nouvo.com wrote:
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-php@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 which can be reproduced with few
lines of core PHP.I am reading the list pretty closely and I don't remember any emails
from you raising the question of reproducible corruption bugs
recently, except indeed for 54460 which seems to be a memory leak,bug 54460 has disapeared from bugs.php.net . Is due to the crash ?
I also tried to access a bug linkg and bug.php?id=xxx failed to work.
Has there been a data problem ?
On Wed, Jun 29, 2011 at 3:36 PM, Pascal COURTOIS
Pascal.Courtois@nouvo.com wrote: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-php@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 which can be reproduced with few
lines of core PHP.I am reading the list pretty closely and I don't remember any emails
from you raising the question of reproducible corruption bugs
recently, except indeed for 54460 which seems to be a memory leak,bug 54460 has disapeared from bugs.php.net . Is due to the crash ?
I also tried to access a bug linkg and bug.php?id=xxx failed to work.
Has there been a data problem ?
No.
Some people just wanted some bugsweb so an old database was restored
rather then waiting few hours for the actual data export.
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.
-Hannes
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 :-)
On Wed, Jun 29, 2011 at 4:57 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
No.
Some people just wanted some bugsweb so an old database was restored
rather then waiting few hours for the actual data export.
The "some people" actually make it so that bugs.php.net was available
by the time 5.4.0 was released. After having waiting more than two
weeks with absolutely zero progress nor info about a possible recovery
of the data.
I would appreciate if you would show a bit more respect to the people
actually making the work and keep the house working, now and later.
Thanks.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
On Wed, Jun 29, 2011 at 3:36 PM, Pascal COURTOIS
Pascal.Courtois@nouvo.com wrote: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-php@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 which can be reproduced with few
lines of core PHP.I am reading the list pretty closely and I don't remember any emails
from you raising the question of reproducible corruption bugs
recently, except indeed for 54460 which seems to be a memory leak,bug 54460 has disapeared from bugs.php.net . Is due to the crash ?
I also tried to access a bug linkg and bug.php?id=xxx failed to work.
Has there been a data problem ?
A recent backup was restored minutes ago, so these bugs are back again.
Regards,
Philip
On Wed, Jun 29, 2011 at 4:36 PM, Pascal COURTOIS
Pascal.Courtois@nouvo.com wrote:
bug 54460 has disapeared from bugs.php.net . Is due to the crash ?
Yes, the data was not available by the time we release PHP
5.4.0-alpha1. So we went with an alternative and temporary solution,
see http://news.php.net/php.internals/53635
As you can see the data has been now restored and everything went fine
as planed in our alternative plan. The "old" bugs will be editable
again in the next couple of hours.
Thanks for your understanding,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pascal COURTOIS wrote:
What I need is a very stable language on which I can rely and I'm
very sad to to say PHP is getting worse and worse on that point of
view versions after versions.I can not contradict your experience, it is what it is, but my
experience for years working with PHP was exactly the opposite.To tell you the truth, I've been asked to rewrite the framework I
did in Ruby because of these problems. I'm of course very reluctant
to go that way but in the end I may have no choice:-(
Pascal
I am sure that many people here would be more than happy to hear about
particular problems you are hitting. Like Stas I have never had problems with
the stability of PHP5 in 10 years of running it. YES I can get it to crash, but
it has always told me why and fixing the problem clears that up. I do have sites
that become unstable, but I have yet to find a situation where PHP was the
problem ...
My grumble is with having to rewrite code simply because someone has decided
that what I was doing is no longer acceptable ... if I can run my code with
display_errors ON then I know I've got clean code :)
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
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 running
it.
PHP5 did not exist 10 years ago ;-)
Anyway, around 2001 it took me one year (not full time) to find out
there was a memory corruption in PHP. At that time I was using mod_php.
It crashed Apache.
YES I can get it to crash, but it has always told me why and
fixing the problem clears that up. I do have sites that become
unstable, but I have yet to find a situation where PHP was the
problem ...
when you have a bug in PHP it should not ever ever crash PHP and
unfortunately I encountered that case dozens of times.
My grumble is with having to rewrite code simply because someone has
decided that what I was doing is no longer acceptable ... if I can
run my code with display_errors ON then I know I've got clean code
:)
I 1000% agree
Pascal COURTOIS wrote:
Like Stas I have
never had problems with the stability of PHP5 in 10 years of running
it.PHP5 did not exist 10 years ago ;-)
OK coming on 8 years ... seems longer :)
I looked at PHP4, but PHP5 was at release candidate stage so I decided that I'd
skip straight to that. But I still had to learn PHP4 as people expected
backwards compatibility. My ISP 1and1 STILL list PHP4 as the default for virtual
hosting :(
Anyway, around 2001 it took me one year (not full time) to find out
there was a memory corruption in PHP. At that time I was using mod_php.
It crashed Apache.YES I can get it to crash, but it has always told me why and
fixing the problem clears that up. I do have sites that become
unstable, but I have yet to find a situation where PHP was the
problem ...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
The earlier windows stuff I had used to just crash the whole machine. PHP was
something of a refreshing change ...
I am behind you on getting what we have a lot better. Many thing have been
pushed in and then forgotten ... like PDO!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
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 consumming.
If PHP corrupts some memory, it does not crash fastcgi processes but the next
request(s) behave erratically.
-----Original Message-----
From: Pascal COURTOIS [mailto:Pascal.Courtois@nouvo.com]
Sent: Thursday, June 16, 2011 12:28 AM
To: Lester Caine
Cc: PHP internals
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)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 onIf PHP crashes, yes, it recovers but it's VERY resource and time consumming.
If PHP corrupts some memory, it does not crash fastcgi processes but the
next
request(s) behave erratically.
I have some news for you. Ruby has crashes, Python has crashes, even Java has security issues and crashes (check out the Java bug database. It's bigger than ours).
Of course our goal is to reduce this as much as possible for PHP and as was stated here, short concise reproducible scripts do get attention.
Re: memory models, PHP actually has a memory model that is very robust and prevents leaks from happening. Every memory model has its pros and cons but leak-free Java is a great example of where the memory model more often than not bites you in your tush more than you'd think (and I can say that after having done quite a bit of Websphere development - yuck).
So just help us with identifying root cause and you will see the internals@ group very much jumping on the issues and try to resolve them.
Andi
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 really out of topic
On Thu, Jun 16, 2011 at 12:14 AM, Pascal COURTOIS <Pascal.Courtois@nouvo.com
wrote:
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
instead of focusing on the 1800 open bug tickets.
Sorry if the question is dumb, but, how many core developers does PHP have?,
how many in total (including non-core contributors)?.
Regards,
David
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 improving. That's the way I do and
that's why there is no bug I'm aware in my programs.
On Thu, Jun 16, 2011 at 1:12 AM, Pascal COURTOIS
Pascal.Courtois@nouvo.comwrote:
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 improving. That's the way I do and
that's why there is no bug I'm aware in my programs.
I really mean the question, regardless.
On Thu, Jun 16, 2011 at 1:12 AM, Pascal COURTOIS
Pascal.Courtois@nouvo.comwrote: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 improving. That's the way I do and
that's why there is no bug I'm aware in my programs.I really mean the question, regardless.
It's difficult to say, but there are a total of 1,568 php.net accounts. The karma[1] rules aren't straightforward to parse but quickly it shows at least 194 people with full php-src[2] karma, and 54 humans made 1,971 SVN commits to php-src within the last 365 days. Those numbers include tests, so the number of ~active core developers appears closer to 10-20. Of course this doesn't include other parts like PECL and documentation but enough hastily created and probably misleading statistics for today.
As for the point of the question, php.net could certainly use more contributors and ideally we'd clone Felipe. A lot.
[1] http://svn.php.net/viewvc/SVNROOT/global_avail?view=markup
[2] http://svn.php.net/viewvc/php/php-src/
Regards,
Philip
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 improving. That's the way I do and
that's why there is no bug I'm aware in my programs.
Feel free to contribute. PHP is driven by volunteers spending their free
time on it. For many it is more fun to implement new stuff they probably
"need" than fixing bugs in some code which has some side effects which
are not always easy to predict and which they actually don't use.
johannes
Le 16/06/2011 11:36, Johannes Schlüter a écrit :
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 improving. That's the way I do and
that's why there is no bug I'm aware in my programs.Feel free to contribute. PHP is driven by volunteers spending their free
time on it.
I know. I also have a GPL project. Nonetheless some societies use it,
and some people rely on it to get paid. I have absolutely no legal contract
with anyone but I have a moral contract and when I'm signaled a bug, it is mostly
fixed within few hours. I just can't imagine replying to a bug submission
"Hey guy, its a free project. Why don't you fix it yourself ?"
My conscience tells me to not release a program if people using it can
shoot themself in the foot.
For many it is more fun to implement new stuff they probably
"need" than fixing bugs in some code which has some side effects which
are not always easy to predict and which they actually don't use.
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 addition nor a loop nor nothing.
I can't imagine nobody uses user functions and exceptions.
2011/6/16 Pascal COURTOIS Pascal.Courtois@nouvo.com:
I know. I also have a GPL project. Nonetheless some societies use it,
and some people rely on it to get paid. I have absolutely no legal contract
with anyone but I have a moral contract and when I'm signaled a bug, it is mostly
fixed within few hours. I just can't imagine replying to a bug submission
"Hey guy, its a free project. Why don't you fix it yourself ?"
My conscience tells me to not release a program if people using it can
shoot themself in the foot.
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.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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 letting someone insert his wonderful clever
feature in a project, whatever it is, and not maintain it is a project
management problem. PHP makes me think of a ship with tens of stirring wheels.
Of course no one can be forced to do what he doesn't want but a free
project doesn't mean unmanaged project and a managed project means
people with responsibilities.
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 letting someone insert his wonderful clever
feature in a project, whatever it is, and not maintain it is a project
management problem. PHP makes me think of a ship with tens of stirring wheels.
Of course no one can be forced to do what he doesn't want but a free
project doesn't mean unmanaged project and a managed project means
people with responsibilities.
We are fixing bugs. We don't accept any new feature. Sometimes we might
accept features in order to motivate contributors hoping they also fix
bugs in the future.
And even if the reproduce case is short: Some things in the engine are
hard to fix, need thought and verification. Some things even can't be
fixed within a "bug fix" release (x.y.z+1) as they require API changes
or such.
And then there are cases where severity is valuated differently. There
are things "we" (whomever that includes) don't consider a use case as a
proper/important use case and focus on other issues while it might be
"critical" for few users ...
We're welcoming people providing bug fixes. We'd love having zero bugs.
But life isn't easy. We also welcome people who go through the bug
reports and verify them, simplify test cases etc. This is also work to
be done. We receive quite a few bug reports per day (well not right now
as the system is down :-/ ) most of them aren't bugs but wrong
expectations, many are probably bugs, few are actual easy to verify
bugs. Going through them also costs quite some time.
johannes
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 addition nor a loop nor nothing.
I can't imagine nobody uses user functions and exceptions.
You might also consider that your particular case is rather unique. I
tried your test case and saw no leak after the request. Everything is
freed on request shutdown. That means that for pretty much everyone
doing standard short web requests, this style of code would work
perfectly for them.
-Rasmus
Le 16/06/2011 12:31, Rasmus a écrit :
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 addition nor a loop nor nothing.
I can't imagine nobody uses user functions and exceptions.You might also consider that your particular case is rather unique. I
since decoder-php@own-hero.net could reduce the case from my original
program in the conditions I stated, he could obvously detect the leaks.
Le 16/06/2011 12:31, Rasmus a écrit :
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 addition nor a loop nor nothing.
I can't imagine nobody uses user functions and exceptions.You might also consider that your particular case is rather unique. I
since decoder-php@own-hero.net could reduce the case from my original
program in the conditions I stated, he could obvously detect the leaks.
I'm not saying there aren't any. There are known leaks in compile_file()
when you throw an exception like that, so if you call a huge amount of
these within a single request, you are going to have problems. But that
is not something the average person hits, and again, they are all
free'ed on request shutdown, so it isn't like it is a persistent leak.
eg.
rasmus@x220:~/php-src/branches/PHP_5_3$ USE_ZEND_ALLOC=0 valgrind
--leak-check=full sapi/cli/php pas.php
==17658== Memcheck, a memory error detector
==17658== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==17658== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==17658== Command: sapi/cli/php pas.php
==17658==
==17658==
==17658== HEAP SUMMARY:
==17658== in use at exit: 3,376 bytes in 18 blocks
==17658== total heap usage: 25,077 allocs, 25,059 frees, 3,952,839
bytes allocated
==17658==
==17658== 9 bytes in 1 blocks are possibly lost in loss record 3 of 16
==17658== at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
==17658== by 0x78F2DF: _estrndup (zend_alloc.c:2503)
==17658== by 0x78477B: lex_scan (zend_language_scanner.l:1817)
==17658== by 0x7994DF: zendlex (zend_compile.c:4969)
==17658== by 0x77B9B4: zendparse (zend_language_parser.c:3291)
==17658== by 0x77F3BE: compile_file (zend_language_scanner.l:364)
==17658== by 0x601350: phar_compile_file (phar.c:3393)
==17658== by 0x7ACF48: zend_execute_scripts (zend.c:1187)
==17658== by 0x75AA52: php_execute_script (main.c:2284)
==17658== by 0x8406D3: main (php_cli.c:1193)
==17658==
==17658== 14 bytes in 1 blocks are possibly lost in loss record 4 of 16
==17658== at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
==17658== by 0x7A8D9A: zend_str_tolower_dup (zend_operators.c:1884)
==17658== by 0x79B36E: zend_do_begin_function_call (zend_compile.c:1571)
==17658== by 0x77E64B: zendparse (zend_language_parser.y:671)
==17658== by 0x77F3BE: compile_file (zend_language_scanner.l:364)
==17658== by 0x601350: phar_compile_file (phar.c:3393)
==17658== by 0x7ACF48: zend_execute_scripts (zend.c:1187)
==17658== by 0x75AA52: php_execute_script (main.c:2284)
==17658== by 0x8406D3: main (php_cli.c:1193)
==17658==
==17658== 17 bytes in 1 blocks are possibly lost in loss record 5 of 16
==17658== at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
==17658== by 0x78F2DF: _estrndup (zend_alloc.c:2503)
==17658== by 0x78059A: lex_scan (zend_language_scanner.l:1695)
==17658== by 0x7994DF: zendlex (zend_compile.c:4969)
==17658== by 0x77B9B4: zendparse (zend_language_parser.c:3291)
==17658== by 0x77F3BE: compile_file (zend_language_scanner.l:364)
==17658== by 0x601350: phar_compile_file (phar.c:3393)
==17658== by 0x7ACF48: zend_execute_scripts (zend.c:1187)
==17658== by 0x75AA52: php_execute_script (main.c:2284)
==17658== by 0x8406D3: main (php_cli.c:1193)
==17658==
==17658== 648 (232 direct, 416 indirect) bytes in 1 blocks are
definitely lost in loss record 15 of 16
==17658== at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
==17658== by 0x77F344: compile_file (zend_language_scanner.l:334)
==17658== by 0x601350: phar_compile_file (phar.c:3393)
==17658== by 0x7ACF48: zend_execute_scripts (zend.c:1187)
==17658== by 0x75AA52: php_execute_script (main.c:2284)
==17658== by 0x8406D3: main (php_cli.c:1193)
==17658==
==17658== 1,680 bytes in 1 blocks are possibly lost in loss record 16 of 16
==17658== at 0x4C290A4: realloc (vg_replace_malloc.c:525)
==17658== by 0x7A2273: pass_two (zend_opcode.c:380)
==17658== by 0x77F407: compile_file (zend_language_scanner.l:376)
==17658== by 0x601350: phar_compile_file (phar.c:3393)
==17658== by 0x7ACF48: zend_execute_scripts (zend.c:1187)
==17658== by 0x75AA52: php_execute_script (main.c:2284)
==17658== by 0x8406D3: main (php_cli.c:1193)
==17658==
==17658== LEAK SUMMARY:
==17658== definitely lost: 232 bytes in 1 blocks
==17658== indirectly lost: 416 bytes in 6 blocks
==17658== possibly lost: 1,720 bytes in 4 blocks
==17658== still reachable: 1,008 bytes in 7 blocks
==17658== suppressed: 0 bytes in 0 blocks
==17658== Reachable blocks (those to which a pointer was found) are not
shown.
==17658== To see them, rerun with: --leak-check=full --show-reachable=yes
==17658==
==17658== For counts of detected and suppressed errors, rerun with: -v
==17658== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 12 from 6)
Le 16/06/2011 12:31, Rasmus a écrit :
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 addition nor a loop nor nothing.
I can't imagine nobody uses user functions and exceptions.You might also consider that your particular case is rather unique. I
since decoder-php@own-hero.net could reduce the case from my original
program in the conditions I stated, he could obvously detect the leaks.I'm not saying there aren't any. There are known leaks in compile_file()
when you throw an exception like that, so if you call a huge amount of
these within a single request, you are going to have problems. But that
is not something the average person hits, and again, they are all
free'ed on request shutdown, so it isn't like it is a persistent leak.
I was bit unclear there. The cause of the leaks is the exit() in your
exception, not the exception itself.
-Rasmus
Le 16/06/2011 13:42, Rasmus a écrit :
Le 16/06/2011 12:31, Rasmus a écrit :
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 addition nor a loop nor nothing.
I can't imagine nobody uses user functions and exceptions.You might also consider that your particular case is rather unique. I
since decoder-php@own-hero.net could reduce the case from my original
program in the conditions I stated, he could obvously detect the leaks.I'm not saying there aren't any. There are known leaks in compile_file()
when you throw an exception like that, so if you call a huge amount of
these within a single request,
which is not the case. At most I will have 3 or 4 exceptions per request.
you are going to have problems. But that
is not something the average person hits, and again, they are all
free'ed on request shutdown, so it isn't like it is a persistent leak.
Ok, as said before I will summerize the facts on tuesday.
Hi!
I'm not saying there aren't any. There are known leaks in compile_file()
when you throw an exception like that, so if you call a huge amount of
these within a single request, you are going to have problems. But that
You actually can't call huge amount of these in one request, as this
particular leak is caused by bailing out from zend_execute_scripts,
which causes main op array not be freed. zend_execute_scripts() is
called only once, so you can't have this leak multiple times as far as I
can see. Whatever caused the original problem, it's highly unlikely it
is this leak.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I'm not saying there aren't any. There are known leaks in compile_file()
when you throw an exception like that, so if you call a huge amount of
these within a single request, you are going to have problems. But thatYou actually can't call huge amount of these in one request, as this
particular leak is caused by bailing out from zend_execute_scripts,
which causes main op array not be freed. zend_execute_scripts() is
called only once, so you can't have this leak multiple times as far as I
can see. Whatever caused the original problem, it's highly unlikely it
is this leak.
I was thinking it was a bunch of nested eval()'s that might cause this.
An exit from within an eval'ed op_array would cause this same leak I think.
But yes, I agree, in order to leak 128M or whatever it was he said, it
is unlikely that it is due to this.
-Rasmus
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Wednesday, June 15, 2011 2:33 AM
To: Andi Gutmans
Cc: Derick Rethans; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)Hence my suggestion to bundle MongoDB extension and possibly work on
additional extensions. Some of my suggestions probably rightfully didn't get
much interest such as Thrift.See my comment in your other thread and below.
Maybe we should consider making a list of extensions we think could be
beneficial and the new mentorship program can actually help deliver some of
them?I do not thnk it is a good thing to begin a discussion about this exact topic and
then totally ignore it.I think it got lost in the very long and varying discussions. Will dig up and take a look. I had a couple of hectic weeks.
It was not a long discussion and you began this thread :)
http://news.php.net/php.internals/52898
I also think that it is somehow wrong to post something asking to do not propose
new things when we finally have more people involved in proposals and
discussions. Maybe that's just me me but I do think that the main problem we
have (besides the ones we identified and try to fix right now) is the complete
lack of open discussions about possible new features, in this list with new or
existing contributors.I did not say we should not propose or have discussions (I am in favor of adding [] for arrays for example). But I am saying the bias should be not to include new language functionality unless it has very broad appeal & serious upside impact. The bias should be against feature creep.
Right, that's why we introduce a voting RFC in addition to the release
RFC, with some "large majority" concept. However I still think that
such posts are inappropriate, timely and generally, while being of
freedom of speak ;-)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org